Agreed! Our parmlib concatenation consist of the business parmlib that resides on MCAT pack, followed by the serverpack provided sys1.ibm.parmlib. The sys1.parmlib from serverpack never gets used in our shop, except to take a peek at what IBM thinks we should do on something.
_____________________________________________________________________________________________________ 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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Jesse 1 Robinson Sent: Friday, August 30, 2019 12:28 PM To: IBM-MAIN@LISTSERV.UA.EDU 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'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 **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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
