I am trying to launch an exe on a Windows 2000 system using the ILA, or IO Adapter. I am using a scripted operation employing a custom script where I use Java’s Runtime class to start the application. This works fine when I run the adapter in debug mode. But, when I start the adapter noramlly the process does not work. Nothing happens. I then revert back to debug mode and the process kicks off the application from my attempts to run the integration with the adapter started. It’s as if the attempts to kick off the scripted operation get queued up and only run once the adatper is in debug mode.

Any help is appreciated.

Just a guess but it may have something to do with having the Script Security enabled in the adapters config. I can’t think of a reason why it would work in debug though.
Might be worth checking that setting on the Java panel in the adapter config and making sure it’s deselected.

Thanks for the idea Tim. I did have to do that to get this
work in debug mode. But that didn’t help this problem.
I appreciate the feedback…

In [url=“wmusers.com”]wmusers.com greg wrote:

“When in debug mode, the adapter process runs as the user that started the process. So, if your adapter does not run in regular mode, but will start in debug mode, there is an environment discrepancy between the user that kicked off the process in debug, and the user that normally runs the adapter process.”

What user is the adapter monitor process running as? Does it have permissions to the directory/file you’re trying to access?

The adapter tools were installed using Generic User. I am starting the adapter in debug mode, testing locally on my 2k workstation so it would be my userid. Other than specifying a user when the adapter monitor is installed, is there a way to specify a particualar userid to use with each adapter running on a machine? I’ll experiment with this a little bit to see if that is where were running into a problem. Thanks for the feedback!

As Rob had said, there is a difference between running in debug mode and regular mode. When you run in debug mode or from the command line, you are running the adapter process as “you” (whomever you logged in as). When you run the adapter in regular mode, the process runs as the user designated by the adapter config tool (bin by default for Unix, System Account default for windows). This is likely to create a discrepency between the user environments for the two different modes you are running the adapter in.

Thanks all. I reinstalled the adapter config tool to use a specific ID with Admin rights. I logged into the machine as the user I set up also. No luck. In debug, Runtime.exec() kicks off the app but in normal mode, nothing. Any other ideas are welcome. Thanks again.

I don’t have a solution, but I do have a suggestion for an approach to find out more information. Adapters can be run independently from the adapter monitor. In other words you can start adapters from the command line. I don’t remember the exact syntax, but the documentation covers it somewhere. Or someone with fresher memory can chime in.

This will at least tell you the adapter monitor is contributing to the problem or not as you are now running it from the same user as you are in debug while not using the adapter monitor to start it.

Good luck,
Andreas

Problem resolved. WM support informed me that the activeworks service needs to have the “allow the service to interact with the desktop” option selected under the System Account. This worked. I am still not sure why it did not work when I had the monitor installed with a full rights user account. But, I reinstalled the config tool as a generic user and set up the service with this option and it works.

Thanks to everyone for the input.

How do we resolve the same on solaris boxes.