On 7/23/20 10:26 AM, Jack Woehr wrote:
My brain hurts, I'd have to see this.

It's not that complicated: the launcher checks for the existence of JVMs, going through a list of acceptable options from the first choice to the last choice.

First, we
RTVCURDIR RTNDIR(&CD) DIRNAMLEN(&CDL)
so that we can return to whatever the current directory was before we started looking for JVMs.

Then we go through the first of several nested blocks of the pattern
CHGVAR VAR(&VER) VALUE('XYY') CD DIR('/qopensys/QIBM/ProdData/JavaVM/jdkXX/YYbit') MONMSG MSGID(CPFA0A9) EXEC(DO)
where X and XX are the Java version, and YY is 32 or 64. &VER keeps track of the last version tried. If the CD fails (indicating that the JVM directory doesn't exist), then the DO group tries another block of the same pattern. If the last one we try fails, we RETURN with a message, "Unable to find a compatible JVM."

Once all the DO-groups are closed, we
RTVCURDIR RTNDIR(&JD) DIRNAMLEN(&JDL) ADDENVVAR ENVVAR(JAVA_HOME) VALUE(&JD) REPLACE(*YES)

and then reset the current directory to the saved value with
CD DIR(&CD)

If Mr. Oberholtzer is right, then simply globally changing "qopensys" to "QOpenSys" in the JVM detector blocks should solve the problem. But I definitely want to know why, in the case of this specific Java 8 on this one specific box, a capitalization difference causes the JVM to crap-out, while the capitalization self-corrects in every other case (including Java 6 on the same box).

--
JHHL

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].