On Wed, 11 May 2016 09:27:25 +1000, Andrew Rowley <and...@blackhillsoftware.com> wrote:
>On 11/05/2016 1:15, Mark Zelden wrote: >> Since multiple levels of the >> OS are being maintained I "APPLY REDO" pointing to a copy of the SMP/E >> controlled loadlib using the proper level of the JES2 macro library. It >> makes little >> sense (at least to me) to run one apply, change the dddef, then run another >> apply for >> each JES2 level. >It still feels like laying a trap for the next person who comes along >who is unaware of the process. > >What I would be inclined to do is clone the SMP/E zones and keep a >separate set of datasets for each JES2 level. Than it is much clearer >what is going on and exactly what is installed in each dataset. DASD is >cheaper than time sent scratching my head (or an outage caused by an >incorrect JES2 macro level). > >I have always worked on the principle that the SMP/E zones should >reflect exactly what is installed in the target and distribution >libraries. If you assemble with a different SYSLIB it breaks that principle. > >But, I admit, it is a long time since I have maintained a real system >with SMP/E. > >Andrew Rowley > I would not be inclined to do so at all. Overkill IMO. Why would I want to have separate zones and all the target libe and have to install all my maintenance to the software twice just to assemble JES2 exits against different levels of JES2 macro libraries. My process is extremely simple and is error free. The SMP/E zones for the product know nothing about the macros being included from JES2 anyway (the JES2 code is in a completely different set of SMP/E zones). Step 1: Copy SMP/E maintained product.loadlib to product.loadlib.Z1020100 (sample name) Step 2: APPLY REDO usermod with override of SYSLIB and DD for product.loadlib My APF and LNKLST entries includes "product.loadlib.&SYSOSLVL." This makes OS migration / fall back less complicated. From the product's standpoint everything in SMP/E is 100% correct. Any maintenance to the product itself is done to the base library. If I apply product maintenance, I do have to run the JES2 exit "APPLY REDO" job once for each OS level being maintained as a post apply step. Once all systems are at the same OS level, it's one job i need to run instead of two. At that point I could change the dddef to point to "product.loadlib.&SYSOSLVL." and change / verify the JES2 macro DDDEF points to the library is also correct (volser pointing to my OS maintenance sysres), but I don't. Most of the products have non-smp/e options for doing this (asm/lnk outside of SMP/E), so SMP/E is almost "besides the point" for these exits / stubs that are JES2 maintenance dependent. I know shops that do these sort of assemblies / links as part of their cloning process every time they clone so they don't even need usermods on the OS side to determine if a macro has been updated. Some of the products I have worked with have this sort of dependency and never account for it at all in their installation / maintenance procedures. Anyway, different strokes for different folks. I've been using this method for many years, just with my own symbol for the OS level (&SYSOSLVL hasn't been around long). Cheers, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
