Integration

Hello,

We have an application which is part VB6 and part Java (32-bit) which runs on Windows. We use JRockit for performance and larger memory capability. JRockit is not installed as the public JVM. Our Java process is started by copying java.exe from the jre\bin to another name in our application directory and starting that. This is done so that the process has a known name and can be killed if found running when the application starts. No part of the JRockit jre is in the path, nor should it need to be. This has worked flawlessly on hundreds of PCs. Recently we encountered a Windows XP-32 system where the Java part of the application failed to start. Here is the messages the customer gets:

Could not bind _logforceprintv
Could not locate osal.dll.
DLI FAILURE: Could not load library osal.dll.

osal.dll was not a part of an earlier version of JRockit but it is in the bin diirectory of the version we have been using since about last summer, which is:

Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Oracle JRockit(R) (build R28.0.1-21-133393-1.6.0_20-20100512-2132-windows-ia32, compiled mode)

I had our customer prepend the jre\bin path to the path in a command window and then execute the application. This worked but when he put the path into the system environment variable instead and attempted to run the application, it failed as above, even after restarting the system. I don't understand that result. I have only found osal.dll in a broad internet search in the context of an incorrect environment variable setting for an Oracle product. That variable does not exist on this customer's system.

My questions are:
1) Has this problem been seen and is there a fix?
2) Why is osal.dll not found the way the rest of the jvm runtime components are?

Any help would be appreciated as I can not reproduce this problem and it is not desirable to use the customer's system for a lot of experimentation. If I could reproduce the problem, my next step would be to install the latest JRockit, but I want to hold off on the customer's system until hearing that there had been a change which would affect osal.dll.

Thanks

Stewart