Long post....... Charles, (and Ed, Shane, and Mark) and all,
It would be really nice if vendors picked up on this and added the functionality, but I don't see it happening. Not all sites want to have a common parmlib for all products, so why force anyone into this? Mark, you gave a good example of SDSF server where you have a choice, and if vendors did that, it would be great, but again, I don't see it happening. That is why I was wondering if this facility exists or could be written for CBT. Ideally, you could code it on any DD that is being opened for PDS already. In my example, I think I gave a red herring on the first notation, in that that DD statement specified dataset and member, which is just a sequential BSAM or QSAM read, not really what I was thinking, but the second DD statement in that example is what I was talking about. In reality, if coding something like a SUBSYS=PARM statement, the remaining portion of the coded DD statement would be ignored from processing other than it has to pass a JCL syntax check rules. The beauty of something like this in my mind is that then as a user of many vendor products, *I* can choose what ones I want to do this too. I can also have a OEM Parmlib that may have different security requirements, and I don't have to give update authority to SYS1.PARMLIB to every one that maintains products if that were a concern. Another benefit of this method(if I'm being selfish) is it would supplement our software upgrade process. First, we share PROCLIB and PARMLIB with manys systems in the plex. Typically we go through a couple of mass software upgrades per year, says ISV's 2 and 3rd quarter, z/OS 1st quarter. We do this because it takes so long to migrate it through all of our development and production systems which have IPL limitations. When I begin to roll the software out via IPL(I realize that not all software requires an IPL to implement, but as a general rule that is how we affect the change), a new LOADxx member is created for the system being affected by typically add another PARMLIB to the concatenation Like this: PARMLIB SYS1.MIGRAT.PARMLIB <<<<---NEW EMPTY PARMLIB PARMLIB SYS1.PARMLIB PARMLIB SYS1.IBM.PARMLIB PARMLIB SYS1.OEM.PARMLIB The only things that go into this new parmlib are those members that need changes to support the current software upgrades, in addition to a MSTRJCLxx and JES2PARM members that have an added migration PROCLIB(SYS1.MIGRAT.PROCLIB) in their respective concatenations too. At IPL time, we use this load member to IPL into the new software(new sysres via load parm, and common vendor sysres via system symbol and indirect cataloging) and PARM changes. This allows us to IPL into the new software with no pre-IPL work(typically), and the backout is to re-IPL using the old load parm(and old sysres and/or old common vendor sysres), again, typically no backout system modifications either. Once all systems in the complex are upgraded, these migration PARMLIB and PROCLIB are collapsed back into their original "homes" ready to start over for the next time. To circle back around to the topic, we have the majority of our third party product parms in SYS1.PARMLIB. With many systems, that makes for a large PARMLIB(ours is in the 600-1000 member range) and the majority of those 3rd party products all hard code SYS1.PARMLIB in their JCL, so during the above process, we have to move the procs (TMSINIT proc in the original example) into the the MIGRAT proclib for the sole purpose of having this shared proc point to a new PARMLIB due to CA-1 parm changes(mind you this is just an example, the same is true for many products). Finally, to be complete, I could see where it would be nice to additional user defined concatenations for other uses. Maybe for applications use, or other common enterprise wide data, and access the same way via a SUBSYS=???? Statement. This IBM would have to probably implement, maybe not. Maybe this would be good for application developers where they pull different parms for production vs. test, and can reduce the amount of proc changes to support. Sorry for being long winded, just wanted to get my thoughts in. Dave ________________________________________________________ Dave Jousma Principal Systems Programmer [EMAIL PROTECTED] 616.653.8429 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Charles Mills Sent: Tuesday, March 14, 2006 5:06 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Wishing for a JCL based PARMLIB Concatenation search I'm asking as the architect of a vendor product - is this what you customer sysprogs would like? Would you like vendor products to get their parametization from a member of the PARMLIB concatenation? Would that be a good thing - one less "special" parm file to keep track of? Or would you perceive it as making the "owners" of application products mess around in a "system" parameter concatenation? This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- 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
