z/OS UNIX System Services and Java requirements
After your site activates self-describing agents on a hub Tivoli Enterprise Monitoring Server, the monitoring server must have access to a Java™ Runtime Environment running under IBM®'s 31-bit or 64-bit Java SDK Version 5 (or higher) and an HFS or zFS file system accessed through z/OS UNIX. The self describing agent function stores the application support packages in the z/OS UNIX file system and then invokes the Java jar command to extract the files from the application support packages stored there. Since IBM's Java runs on z/OS® under z/OS UNIX, this also means z/OS UNIX must be available with ~50MB of working space.
If your environment has more than 10 to 15 agent types, see the hardware and software requirements section of the IBM Tivoli Monitoring: Installation and Setup Guide for more details on the storage requirements.
If you use the self-describing agents feature on a Tivoli Enterprise Monitoring Server running on z/OS, you must supply the z/OS UNIX directory where Java is installed. Using the PARMGEN configuration method, the directory is specified in the GBL_HFS_JAVA_DIRn parameter. The value you supply gets set as the TEMS_JAVA_BINPATH statement in the KDSDPROF file, which is created in the monitoring server's z/OS UNIX support directory.
When a monitoring server running on z/OS installs a self-describing agent, it prepends the TEMS_JAVA_BINPATH value to the default z/OS UNIX PATH setting so it can locate the Java /bin directory where the jar utility resides. The jar utility is required to extract the files from the application support packages that were uploaded from the agent.
You must ensure that no older or inconsistent version of Java remains in the default z/OS UNIX PATH or LIBPATH libraries, because the older Java binaries may conflict with the Java binaries in the directory you supplied in a previous configuration. For example, the default LIBPATH on most z/OS UNIX systems is LIBPATH=/lib:/usr/lib:. Because this specification contains no Java binary directories, it will not conflict with the TEMS_JAVA_BINPATH setting, and so the jar utility invoked by a monitoring server should run successfully.
But if there is a LIBPATH setting that includes a Java directory with a different version of Java than you specified during configuration, the self-describing function could fail when it calls the jar utility. This failure occurs because the TEMS_JAVA_BINPATH value specifying one Java version has been prepended to the PATH setting, with a different Java version specified in LIBPATH. If these are incompatible Java versions, the jar utility cannot work correctly.
To resolve this problem, update the default z/OS UNIX LIBPATH setting so that it either omits the Java directory or specifies a directory at the same Java level. IBM recommends that, if the jar utility invoked by the monitoring server fails to complete successfully, you verify that there isn't an inconsistent level of Java specified in the default z/OS UNIX PATH or LIBPATH setting that may be causing a binary incompatibility.