Holy parmlibs batman!!! Why on earth so many? _____________________________________________________________________________________________________ Dave Jousma AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI 49546 616.653.8429 | fax: 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Gibney, Dave Sent: Friday, August 30, 2019 1:48 PM To: [email protected] Subject: Re: Clarification on DASD mod conversion of SYSRES **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I learned this from Skip, I think at my first SHARE. IMHO, SYS1.PARMLIB should be on SYSRES and EMPTY. SYS1.IBM.PARMLIB, on SYSRES and SMP/E maintained. My current production parmlib concatenation is: PARMLIB SYS1.FNTS.WSUMVS1.PARMLIB WSUFNT PARMLIB SYS1.FNTS.PARMLIB WSUFNT PARMLIB SYS1.WSUMVS1.PARMLIB.OVERRIDE PARM01 PARMLIB SYS1.WSUMVS1.PARMLIB PARM01 PARMLIB SYS1.WSU.PARMLIB IODF00 PARMLIB SYS1.IBM.PARMLIB ****** PARMLIB SYS1.PARMLIB ****** When I migrated from local to MFaaS at FNTS, I only changed a couple members. > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Jesse 1 Robinson > Sent: Friday, August 30, 2019 9:28 AM > To: [email protected] > Subject: Re: Clarification on DASD mod conversion of SYSRES > > I'd like to address a question implied in this thread: where should I > put the installation 'business' PARMLIB, that is, the data set that > typically contains > 90+% of all required members, which are often tailored and do not > 90+change at > all from release to release. I would argue strongly in favor of > putting this PARMLIB on some sysprog-owned volume *away* from the ServerPac > set. > Some reasons and a war story. > > -- This user-created and managed PARMLIB will not be unexpectedly > updated by PTF. > > -- This PARMLIB can contain IBM-, ISV-, and installation-owned members. > > -- This PARMLIB requires little in the way of updates, any one of > which could possibly finger-check into failure on the next IPL. > > The story. In a previous life, we kept the business PARMLIB on sysres. > The VTAM guy made a critical change on a remote system shortly before IPL. > Then we switched sysres to a PARMLIB that did not have this change. > VTAM would not come up. The data center was 400 miles away. It was > before TCP/IP. Fixing the problem would be trivial if only we could > log on. The only staff on site were operators. We were facing a long > drive up the California coast just to submit a simple job. We were > finally able to talk an operator through editing up a job (local > non-SNA 3270) and submitting it, which corrected the problem. > > Of course we should have had better 'procedures'. Good luck with that. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > [email protected] > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Brian Westerman > Sent: Friday, August 30, 2019 12:13 AM > To: [email protected] > Subject: (External):Re: Clarification on DASD mod conversion of SYSRES > > You can't IPL with the IPL datasets cataloged to &SYSR1, it fails if > you try to set > &SYSR1 to something in IEASYMxx. The same is true if you try to use a > symbolic for the catalog volume(s) (assuming it's separate from the > res volume(s)), but I think that issue is the ICF catalogs themselves. > You can however catalog normal non-vsam datasets to any symbol you > want so long as you identify it in the IEASYMxx member. I ALWAYS > catalog ALL my DLIB and some VENDOR volumes that way, it makes life > (and maintenance) a lot easier to be able to change the volsers. > > (i.e. one of the sites I manage has their current IPL vols as is > C23RS1 (which has every cataloged as ******) , C23RS2 ( which has > everything cataloged to > &SYSR2) and C23DL1 (which has everything cataloged to &SYSDL1) , > C23DL2 (same format but &SYSDL2) and C23DL3 (same format but > &SYSDL3), and the next one will be D23RS1, and D23RS2, D23DL1, D23DL2 > and D23DL3. There is no re cataloging of datasets necessary, I just > change the IEASYMxx member and everything is where it needs to be. My > Backup SYSRES's are C23RSA and C23RSB and again, I just point the IPL > to C23RSA and IEASYMxx is changed to point &SYSR2 to C23RSB and everything is > set yo IPL and go. > > The names of the volumes themselves can be whatever I want to make > them easy to remember in an emergency, they could be 111111 and 222222 > and the process would be the same. > > It's very easy to do maintenance this way. > > Brian > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** 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: INFO IBM-MAIN
