IBM is apparently planning further enhancements in their support for Java components and JAR and shell scripts as a utility.
In APAR IO03469 (PTFs available March 2006, and discussed in the quoted posts below), IBM first introduced SMPJHOME and SMPCPATH, and ceased using a logon shell - all for RECEIVE command and certain GIMxxx service routines. Now, in APAR IO04924, IBM appears to be extending this same concept to APPLY and RESTORE processing. After IO04924, the user's .profile or the site's /etc/profile will no longer influence how SMP/E APPLY or RESTORE processing works. This strikes me as a very important enhancement, and I look forward to getting the IO04924 PTFs once they become available. Brian On Sat, 26 Aug 2006 08:46:02 -0500, Brian Peterson wrote: >In APAR IO03469, IBM has changed SMP/E to no longer run the user's >$HOME/.profile or /etc/profile scripts. > >Apparently IBM concluded that Paul was correct - that running those scripts >was a "Bad Idea". > >Brian > >PROBLEM CONCLUSION: >SMP/E V3.4 has been updated to invoke all Java functions >(including MessageDigest) using the /bin/sh utility instead of >/bin/login. This change ensures the SMP/E effective UID is used >and sufficient authority exists to access files created by other >SMP/E processes in the filesystem. > >With this change, SMP/E will no longer support the use of a UNIX >logon profile to define the PATH and CLASSPATH UNIX environment >variables. The new SMPCPATH and SMPJHOME DD statements or DDDEF >entries should be used instead. Attributes in the SMP/E client >data set can also be used where applicable. In cases where a >value is defined in a DD statement, DDDEF entry, and a client >data set, the DD statement takes presedence, followed by a DDDEF >entry and then the attributes in the client data set. > >Additionally, SMP/E V3.2, V3.3 and V3.4 have all been updated to >install ++JARUPD elements by spawning /bin/sh instead of >/bin/login to run the Java jar commands to update the >appropriate Java Archive files. The SMPJHOME DD or DDDEF entry >is used to get the Java home location and therefore must now >always be specified when applying or accepting a SYSMOD >containing a ++JARUPD element. > >On Thu, 15 Sep 2005 22:20:41 -0500, Paul Gilmartin wrote: > >>Lately, running a RECEIVE FROMNETWORK on SMP/E v3r4.01 on a system >>lacking ICSF, I was surprised to observe in SYSPRINT some chatter I >>recognize as originating from my ~/.profile script. I surmise SMP/E >>invokes a login shell to call java. This strikes me as a Bad Idea. >>It exposes RECEIVE to the vagaries of individual users' .profiles. >>Various users using identical JCL are apt to experience different >>results. Tech support will get service calls on apparently >>unpredictable behavior. These will be resolved as User Error, but >>resource will be spent diagnosing them. >> >>There should be no need to allow the user setup in .profile -- the >>CLIENT data set already contains attributes such as "javahome" and >>"classpath". Others could be added there, even a setup script that >>the user could, at his own risk, direct to his ~/.profile. Otherwise, >>SMP/E ought to exec() the java executable directly, not via a shell. >> >>It ain't your father's SMP/E >> >>-- gil ---------------------------------------------------------------------- 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
