Our goal is how to identify the jvm type as z/OS Connect when z/OS Connect is running with Java17.
Current method used is to examine the USS callable Service BPX1GTH to scan the returned values. The returned values are truncated, and the item searched is not in the string due to the fact it is beyond the truncated returned value from the callable service BPX1GTH.
BPX1GTH service when called to get z/OS Connect EE Java17 threads PGTHF output area (limited to 2048 bytes), does not indicate an error in PGTHBLIMITF flag or somewhere else, if not all arguments could be copied into PGTHF output area.
Java17, unlike Java8 for example, uses much more arguments + parms so they don’t fit into a buffer. In addition when trying to reduce the args+parms size, by using Xoptionsfile=… option, untypical behavior also occurs.
When Xoptionsfile= … is used with J17 JVMs the content of the Xoptionsfile=/aaa/bbb/ccc/option.file is being concatenated to the args instead of just Xoptionsfile=/aaa/bbb/ccc/option.file string. This inflates the args and much more space is used in 2048 buffer.
Example:
Java17 PGTHF output area with Xoptionsfile:
/shrd/java17/J17.13/J17.0_64/bin/java.-javaagent:/shrd/IBM/zosconnectGA/v3r0/bin/../wlp/bin/tools/ws-javaagent.jar.
-Dcom.ibm.ws.zos.core.angelName=BAQZANGA.(content of option.file)
-Dcom.ibm.ws.zos.core.angelRequired=true. (content of option.file)
-Dhttp.keepAlive=false. (content of option.file)
-Xmx9096m. (content of option.file)
--add-exports.java.base/sun.security.action=ALL-UNNAMED.--add-exports.java.naming/com.sun.jndi.ldap=ALL-UNNAMED.--add-exports.java.naming/com.sun.jndi.url.ldap=ALL-UNNAMED.--add-exports.jdk.naming.dns/com.sun.jndi.dns=ALL-UNNAMED.--add-exports.jdk.naming.dns/com.sun.jndi.url.dns=ALL-UNNAMED.--add-exports.java.security.jgss/sun.security.krb5.internal=ALL-UNNAMED.--add-exports.jdk.attach/sun.tools.attach=ALL-UNNAMED.--add-opens.java.base/java.util=ALL-UNNAMED.--add-opens.java.base/java.lang=ALL-UNNAMED.--add-opens.java.base/java.util.concurrent=ALL-UNNAMED.--add-opens.java.base/java.io=ALL-UNNAMED.--add-opens.java.base/java.nio=ALL-UNNAMED.--add-opens.java.base/sun.nio.ch=ALL-UNNAMED.--add-opens.java.naming/javax.naming.spi=ALL-UNNAMED.--add-opens.java.naming/com.sun.naming.internal=ALL-UNNAMED.--add-opens.jdk.naming.rmi/com.sun.jndi.url.rmi=ALL-UNNAMED.--add-opens.java.naming/javax.naming=ALL-UNNAMED.--add-opens.java.rmi/java.rmi=ALL-UNNAMED.--add-opens.java.sql/java.sql=ALL-UNNAMED.--add-opens.java.management/javax.management=ALL-UNNAMED.--add-opens.java.base/java.lang.reflect=ALL-UNNAMED.--add-opens.java.desktop/java.awt.image=ALL-UNNAMED.--add-opens.java.base/java.security=ALL-UNNAMED.--add-opens.java.base/java.net=ALL-UNNAMED.--add-opens.java.base/java.text=ALL-UNNAMED.--add-opens.java.base/sun.net.www.protocol.https=ALL-UNNAMED.--add-exports.jdk.management.agent/jdk.internal.agent=ALL-UNNAMED.--add-exports.java.base/jdk.internal.vm=ALL-UNNAMED.--add-exports.java.base/com.ibm.misc=ALL-UNNAMED.-Dfile.encoding=UTF-8.-cp./shrd/IBM/zosconnectGA/v3r0/bin/tools/zosconnect.jar:/usr/include/java_classes/ifaedjreg.jar:/usr/include/java_classes/IRRRacf.jar.com.ibm.zosconnect.product.Launcher.zconsrsh.—clean
(content of option.file) – indicates that those options are the content of Xoptionsfile=/aaa/bbb/ccc/option.file. All –add-exports are being automatically used and there is no option to exclude them which also contributes to PGTHF’s 2048 buffer inflation.
Java8 PGTHF output area with Xoptionsfile (very same JVM as above except java version):
/shrd/java/J8.0_64/bin/java.-javaagent:/shrd/IBM/zosconnectGA/v3r0/bin/../wlp/bin/tools/ws-javaagent.jar.
-Xoptionsfile=/aaa/bbb/ccc/dev/option.file
-Dfile.encoding=UTF-8.-cp./shrd/IBM/zosconnectGA/v3r0/bin/tools/zosconnect.jar:/usr/include/java_classes/ifaedjreg.jar:/usr/include/java_classes/IRRRacf.jar.com.ibm.zosconnect.product.Launcher.zconsrsh.—clean
Here Xoptionsfile=/aaa/bbb/ccc/dev/option.file string is being concatenated instead of its content.
This issue has a high impact on the customers since we no longer can recognize ZCEE server as such.
So the idea could be either to extend 2048 buffer or give some indication in case not all arguments could be copied into PGTHF output area. And if such indication was triggered – include some kind of pointer where the whole arguments could be accessed.