On Thu, 25 Oct 2007 12:41:51 -0400, Andy White <[EMAIL PROTECTED]> wrote:
>I am trying to find out from anyone out there running z/OS and supporting >Java. We have multiple programming areas that are requesting we put up a >very specific version of Java or SDK. > >Let me be specific we have installed a ddef SAJV15D which has a path of >/service/tgta/usr/lpp/java/J5.0_64/IBM/ >and we have multiple versions of java installed. Originally we used SMP/E to install Java. But since each update is a complete replacement, we really found no benefit. When a new version was needed, the requirement came from the WebSphere group and they always requested the updates by names like 1.4.2 SR5. > >Now here is the real life challenge. We are installing IBM's EDK (for data >encryption key store) they have a very specific JDK/SDK . We can easily >copy it to its own directory but how does one maintain it in an automated >way? > Not sure what you mean by maintain it in an automated way? >Now the question is when your told to install a specific version, we run >RSU monthly etc but if it doesn't know about it in the SMP/E zone how do >you do it? > You can't. But if you want, you can create different target zones for each release... but we need different levels of the same release so that just doesn't work (see above). Since you are "told to install a specific version" (as we are), then that is what prompts you to get something new. Or you can just look periodically at IBM's web site: http://www-03.ibm.com/servers/eserver/zseries/software/java/ Here is what we do. We support a system level default Java. The level is at the lowest common denominator (example: 1.4.2 31-bit). It gets mounted at the default mount point of /usr/lpp/JAVA. We put JAVA_HOME and other environment vars in /etc/profile to point to the default. This is usually good enough for the majority of our Java users. The "OS" team supports the default version. We used to support all of the versions, but since WebSphere drove most of the requirements, they started installing and maintaining their own versions. For WebSphere, they have their own environment variables and point at a static local directory where we install z/OS UNIX software. In production and QA, that directory is a symlink pointing to where they have the desired version of Java. That way, they just update the symlink to swap new levels in. Our WebSphere development LPAR often has 3 or 4 different levels of Java mounted. That same directory structure is used for all the other levels / flavors of Java as well. They get pointed to via environment variables in the process(es) that invokes them if they don't want the default. For example, we are installing a product that required 1.4.2 SR7 (IIRC). That application runs in batch and while it could use BPXBTCH, JZOS was preferred and is being used. JZOS gives you a convenient way to specify the environment variables to point to the right level of Java. Another product being tested needed V5 64-bit. HTH, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html