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 <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Jesse 1 Robinson > Sent: Friday, August 30, 2019 9:28 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 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 > robin...@sce.com > > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of Brian Westerman > Sent: Friday, August 30, 2019 12:13 AM > To: IBM-MAIN@LISTSERV.UA.EDU > 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 > lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
