Java program works in one partition but not the other on same machine

[Mark Szkolnicki]

Hi all!

I was testing some of the Java programs that Joop has been linking on his site (http://joopn.home.xs4all.nl/os2ecs/indexe.htm). He has done some excellent work there, and should be congratulated, for testing and getting a lot of Java programs to run successfully on OS/2 / eCS at the moment and hopefully ArcaOS in future.

I posted here, because I've ran into an interesting issue related to two of the Java games that run successfully on eCS - BioGenesis and the Free Colonization (FreeCol) game.

I have two  standalone eCS v2.1 partitions on the machine where I've installed both games. The games are on a separate partition from either of the OS's as is the Java installation (160GA5).  I've created a CMD file for each of the games, and placed it in the directory with the respective game, and then run it from a program object on the desktop.

When I run the OS from one of the partitions, both games open and run successfully, no problem - running the OS from the other partition however, neither game opens at all, although it looks like Java has run, executing the command file, and watching the results.

As the command file is essentially running the same Java 6 installation on the same partition, I don't think the problem is with Java. Looking at the CONFIG.SYS files on both OS partitions I don't see any difference, Java wise, that would have a bearing on the issue, so was wondering if anything else within the OS may have a bearing on this. All the other Java programs I am testing work successfully using the same command files from either eCS OS partition.

The partition that is not working with those particular two Java programs was reinstalled recently, so there maybe something different there.

As I've not spent a lot of time playing with Java programs, I'm not familiar with how the current Java 6 accesses the OS, so no idea as to what may be needed or may be missing. Was just curious whether anyone else has run into this (including Joop, if your looking in)

Anyway, if anyone has any bright ideas, I'd be interested and Best!

Mark

[xynixme]

When I run the OS from one of the partitions, both games open and run successfully, no problem - running the OS from the other partition however, neither game opens at all, although it looks like Java has run, executing the command file, and watching the results.

I'm not using anything you've mentioned and I haven't seen any command file, but did you reboot between attempts? Did the first successful executions create or change some file (setup/INI/EA/high-score), which still refers to the previous partition? Does it work when you use the same drive letter and directory structures?

[Dave Yeo]

Did you install all the prerequisites? libc065 or libc066 and forwarder, gcc446.dll or gcc1.dll and forwarder and odin? If using yum, perhaps share your Unixroots.
Also look in popuplog.os2 in the root of the non-working install

[Mark Szkolnicki]

When I run the OS from one of the partitions, both games open and run successfully, no problem - running the OS from the other partition however, neither game opens at all, although it looks like Java has run, executing the command file, and watching the results.

I'm not using anything you've mentioned and I haven't seen any command file, but did you reboot between attempts? Did the first successful executions create or change some file (setup/INI/EA/high-score), which still refers to the previous partition? Does it work when you use the same drive letter and directory structures?

Hi Andre!

Yes, I did reboot between attempts. I have not actually tried to play either game at the moment, as I was assuring myself that the Java program came up on the partition in question. AFAIK, looking in both of the program directories, and in the location specified by JAVA_HOME in CONFIG.SYS, I see no files created related to either program.

Not having used many Java programs, I'm not sure if INI or CONFIG files are created to store settings, where they would reside, but I have assumed they would be either in the directory for the program, or the location specified by JAVA_HOME

By same drive letter and directory structures I assume you mean for both the JAVA 6 location and the programs in question.

While the OS partitions are different (Drives D: and F: respectively) the Java 6 installation is the same on both (located on Drive E:) and the programs reside on Drive G:

But that does get me thinking about the JAVA_HOME setting .................

Thanks for the suggestions, Andre and Best!

M

[xynixme]

I'm not sure if INI or CONFIG files are created to store settings, where they would reside, but I have assumed they would be either in the directory for the program, or the location specified by JAVA_HOME

Something like that, yes. FWIW, I've just started Jetris (different OS version, different Java, different game) for the first time and it stores its data in the %HOME%\.jetris directory.

So you could try to delete relevant entries under %HOME% too, if such a directory was created by the games. Nevertheless it's more likely that there's a problem with a missing "program" file (Java, requirements) indeed.

HTH.

[Mark Szkolnicki]

Did you install all the prerequisites? libc065 or libc066 and forwarder, gcc446.dll or gcc1.dll and forwarder and odin? If using yum, perhaps share your Unixroots.
Also look in popuplog.os2 in the root of the non-working install

Hi Dave!

First of all a Happy New Year to you!

Since this was a new install of the eCS v2.1 partition, I did take the time to install ANPM, at once, to bring files to the latest level in the UNIXROOT structure immediately. I had been wondering if some libraries may be missing that the Java 6 runtime may require.

I know for a fact that all of the libc (0.6.6-30), gcc-fwd and gcc1 libs (4.9.2.1-3) and odin libs (0.8.9-1) are present, as I need them for various of the programs (including yours) that are currently at the latest versions, I also have SDL (1.2.15-5) and libQT4 (4.7.3.2-1) libraries installed. I mention the last two as all the aforementioned libraries are the usual culprits for getting programs which are not specifically written for pure OS/2 / eCS to run.

Also would you know Dave, whether any Java programs which may create INI or CONFIG files would store them anywhere outside of their own directories or other than in the location specified by JAVA HOME? Andre previously had a good suggestion related to possible created program files, but I could not find any anywhere.

And come to think of it, I do know of one difference with the partition that was newly installed - I was experimenting with creating a separate UNIXROOT on my shared SYSTEM partition (Drive E:), so SET UNIXROOT is pointing to E: there, and its where ANPM installed all the files, for the partition where the two Java programs don't run.

Could that affect the GA5 version of Java 6?

In regards to popuplog.os2, nothing startling there - I had a pesky little problem with a little network game program that I'm fond of playing called qNetWalk, and was trying a number of things with that to get it working again, so it  showed up multiple times in popuplog.

I traced the problem there to qNetWalk not liking any of the SDL12.dll files past the 2008 version (5/11/2008 188,402 bytes). Installing that file locally in the qNetWalk directory seems to have solved that while keeping the latest SDL12.DLL for other reasons.

Best!

M

[Dave Yeo]

As André said, most store their configuration etc in %HOME%, often in a directory/file that starts with a dot (hidden on *nix systems).
Did you check your config.sys for references to other Java installs, things like CLASSPATH?
You could always test by wrapping your Java program(s) in a script to point at your other UNIXROOT along with BEGINLIBPATH and PATH.

[Mark Szkolnicki]

As André said, most store their configuration etc in %HOME%, often in a directory/file that starts with a dot (hidden on *nix systems).
Did you check your config.sys for references to other Java installs, things like CLASSPATH?
You could always test by wrapping your Java program(s) in a script to point at your other UNIXROOT along with BEGINLIBPATH and PATH.

Hi Dave!

Had a look in the HOME path (X:\HOME\DEFAULT) specified for both OS partitions and there are indeed entries in a .config directory (and actually outside of it as well - many programs are not following strict UNIX conventions). While many of the QT4 programs I use have config or INI files there, I saw no indications that any of the Java programs held settings (or any other data) there.

No CLASSPATH statements are there other than the ones originally put in by eCS at the time of installation - the same statements are present in the CONFIG.SYS for both partitions.

I don't know whether this would perform the same function, but for the partition where the programs did not come up, I briefly edited the CONFIG.SYS to direct SET UNIXROOT to the other partition, rebooted and  briefly tested whether the behaviour changed - the same thing occurred as previously. I also tested in the opposite direction, setting UNIXROOT for the partition where the programs do come up to the shared E: drive and rebootedi. Both programs still ran, despite using the test UNIX framework on Drive E, instead of the one on the partition.

As I normally don't spent a lot of time writing Rexx or other command files, I assume by your reference to a script that I could modify the current command file, to add a "SET UNIXROOT" statement at the beginning prior to the JAVA related statements. I could do that, but, if the tests I did above showed no difference, would it be of any value?

Best!

Mark

[Dave Yeo]

It's the LIBPATH that's most important. Something like

Code: [Select]

set UNIXROOT=x:
set PATH=x:\usr\bin;%PATH%
set BEGINLIBPATH=x:\usr\lib
set LIBPATHSTRICT=T

Changing x as needed and run at a cmd prompt then try running the Java program from the same cmd prompt. You could even just type the above into a cmd prompt

[ivan]

Had a look in the HOME path (X:\HOME\DEFAULT) specified for both OS partitions and there are indeed entries in a .config directory (and actually outside of it as well - many programs are not following strict UNIX conventions). While many of the QT4 programs I use have config or INI files there, I saw no indications that any of the Java programs held settings (or any other data) there.

That is understandable if you are using the parameter -Duser.home=<path to java program> when starting the java program because that tells the program to put every thing in its directory.

Something that also helps is NOT having the home directory on the boot partition.  Our test machine has the home directory on drive G and have it listed as such in the config.sys of the 4 versions of OS/2 we can boot from.  We are also now going to try and see of putting all of the unix dlls into one directory on that drive, and listing it in the LIBPATH will work (if it does it will simplify testing).

[xynixme]

We are also now going to try and see of putting all of the unix dlls into one directory on that drive, and listing it in the LIBPATH will work (if it does it will simplify testing).

Thread-drift: if you record which apps requires which DLL, then you should be finer than fine. I guess the list of exceptions (not a CPU's) to be tested isn't that long. Some apps require a specific version of a DLL, and most of those apps are older than current DLL versions.

Sometimes it does help to avoid installers. A recent example is the WarpIN version of the browser Links. It's bad and it's evil, unless you really want to meet the devil of e.g. JPEG.DLLs. Nevertheless the install script of Links can be used to create an own INSTALL.CMD, with Dave's earlier LIBPATHSTRICT and BEGINLIBPATH added to the object's settings. In my case it's an added bonus that I don't have to backup both the whole install package and the installed files anymore.

Let's return to Java...

[Mark Szkolnicki]

It's the LIBPATH that's most important. Something like

Code: [Select]

set UNIXROOT=x:
set PATH=x:\usr\bin;%PATH%
set BEGINLIBPATH=x:\usr\lib
set LIBPATHSTRICT=T

Changing x as needed and run at a cmd prompt then try running the Java program from the same cmd prompt. You could even just type the above into a cmd prompt

Actually I tried that, Dave, and it was a no go - but I will file away the advice, as it may come in useful for another issue I'm examining. By the way was set LIBPATHSTRICT=T supposed to be "T" or changing "X" as needed (I tried it either way - no difference)

After a good nights sleep, I solved the problem this morning - and the solution may be a quirk or bug in the programs involved.

Reading the requirements for Java 6 GA5, from both your note, and the instructions made me wonder what was installed on the partition that worked. It was installed three years ago and has had numerous libraries added to it, prior to our using the UNIX framework of installation, I found all the requisites there (which I should probably clean up sometime to avoid DLL conflicts), including GCC446,dll, the LIBc's in \eCS\dll  and Odin ............ but not on the new partition.

I tried out having just the GCC and LIBc in the partition - no difference

In summary, it needed the ODIN libraries to be installed on the boot partition.

Once they were there, both programs started up - and without even a boot to load the new LIBPATH from CONFIG.SYS, which was interesting.

I then remmed out the ODIN statements afterwards to see if I could reproduce the problem - and again both programs started up!

To verify this, I went to another machine, where I had installed a new eCS 2.2 partition with the UNIXROOT also on the E: SYSTEM partition on that machine, started up the same programs, with the same parameters, and couldn't get the programs to run. Installing ODIN on that boot partition again eliminated the problem (and yes removing references to ODIN in the CONFIG.SYS and rebooting again the programs still started up)

I have a number of Java programs now, and they all have started up and ran without any problems with Java 6, with the ODIN libraries installed in the UNIX framework in either configuration (ie. located either on the boot partition or on the shared SYSTEM partition. I can only conclude that there is some quirk or bug in these two programs which need to know that certain dll's are present, for whatever reason, on the boot partition, even if they don't use them (or perhaps they would be important in playing the game, as I having tried playing either yet.). Not being a programmer, I'm not sure of the intricacies of why this would occur - being a troubleshooter by profession I only know only that it solved this particular problem.

If that is indeed the solution, I expect anyone installing all libraries to a UNIXROOT on the boot partition using YUM or ANPM would never notice this issue But this was an interesting little troubleshooting problem.

If you or others have any questions let me know.

Best and Thanks for the guidance!

Mark

[Mark Szkolnicki]

We are also now going to try and see of putting all of the unix dlls into one directory on that drive, and listing it in the LIBPATH will work (if it does it will simplify testing).

Thread-drift: if you record which apps requires which DLL, then you should be finer than fine. I guess the list of exceptions (not a CPU's) to be tested isn't that long. Some apps require a specific version of a DLL, and most of those apps are older than current DLL versions.

Sometimes it does help to avoid installers. A recent example is the WarpIN version of the browser Links. It's bad and it's evil, unless you really want to meet the devil of e.g. JPEG.DLLs. Nevertheless the install script of Links can be used to create an own INSTALL.CMD, with Dave's earlier LIBPATHSTRICT and BEGINLIBPATH added to the object's settings. In my case it's an added bonus that I don't have to backup both the whole install package and the installed files anymore.

Let's return to Java...

Hi Andre!

Just wanted to give you a note of thanks in addition to Dave. Your suggestions and his gave me some idea of where to look to solve the problem, which I think is a quirk or bug most wouldn't encounter.

But I always find these discussions useful, as after 26 years of using this operating system, I'm still amazed at how much more there is to learn.

Best, Sir!

Mark

[Dave Yeo]

Sounds like installing Odin with YUM/RPM didn't initialize the registry.
The OpenJDK is ported from Windows and uses the Odin libraries instead of the real Windows libraries. Being a Windows clone (sorta), things depend on the registry.
Be easy to test, move \os2\system\USER.DAT and \os2\system\USER.DAT out of the way. Open REGEDIT2 which will create a very minimal registry and test. IIRC the old Odin install would add a bunch of stuff to the registry. Beware that other Windows ports such as some Flash versions also use the registry.

[Pete]

Hi Ivan

...
 We are also now going to try and see of putting all of the unix dlls into one directory on that drive, and listing it in the LIBPATH will work (if it does it will simplify testing).

I have 1 "unix libs" directory, K:\DLLS,  that I share between 3 eCS installations and is on the libpath in all 3 eCS installations. It contains gcc/libc + all dll files required to run current Seamonkey, OpenOffice, VirtualBox and other software.

It certainly makes sure that all eCS installations are "in step" - no more booting to a different volume and finding something does not work due to outdated/missing dll file(s).  :-)

I have not had any problems with this setup to date.


Regards

Pete