Re: Clarification on DASD mod conversion of SYSRES
Many of our tailored members are apply to all four of my LPARs and reside in SYS1.WSU.PARMLIB LPAR specific members are in SYS1.lparname.PARMLIB Changes are first IPL'd in SYS1.lparname.PARMLIB.OVERRIDE Which is where I was before the migration to FNTS, so Changed, common members where in SYS1.FNTS.PARMLIB And changed LPAR members in SYS!.FNTS.lparname.PARMLIB. I should (and have many) moved the migration members further down. On the other hand, I've only IPL'd production twice since my migration IPL in December 2017. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Jousma, David > Sent: Friday, August 30, 2019 10:54 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Clarification on DASD mod conversion of SYSRES > > 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 On > Behalf Of Gibney, Dave > Sent: Friday, August 30, 2019 1:48 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 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.PARMLIBWSUFNT > PARMLIB SYS1.FNTS.PARMLIB WSUFNT > PARMLIB SYS1.WSUMVS1.PARMLIB.OVERRIDEPARM01 > 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 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 > > 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 > > robin...@sce.com > > > > -Original Message- > > From: IBM Mainframe Discussion List 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 datase
Re: Clarification on DASD mod conversion of SYSRES
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 On Behalf Of Gibney, Dave Sent: Friday, August 30, 2019 1:48 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 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.PARMLIBWSUFNT PARMLIB SYS1.FNTS.PARMLIB WSUFNT PARMLIB SYS1.WSUMVS1.PARMLIB.OVERRIDEPARM01 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 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 > 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 > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List 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 , it fails if > you try to set > 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 > ) and C23DL1 (which has everything cataloged to ) , > C23DL2 (same format but ) and C23DL3 (same format but > ), 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 to C23RSB and everything i
Re: Clarification on DASD mod conversion of SYSRES
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.PARMLIBWSUFNT PARMLIB SYS1.FNTS.PARMLIB WSUFNT PARMLIB SYS1.WSUMVS1.PARMLIB.OVERRIDEPARM01 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 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 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 , it fails if you try > to set > 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 > ) and C23DL1 (which has everything cataloged to ) , C23DL2 > (same format but ) and C23DL3 (same format but ), 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 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 11 and 22 > 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
Re: Clarification on DASD mod conversion of SYSRES
I would put it outside of the target zone but would keep a close tab on IBM changes that you potentially might want to mirror. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
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 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 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 , it fails if you try to set 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 ) and C23DL1 (which has everything cataloged to ) , C23DL2 (same format but ) and C23DL3 (same format but ), 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 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 11 and 22 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
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 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 , it fails if you try to set 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 ) and C23DL1 (which has everything cataloged to ) , C23DL2 (same format but ) and C23DL3 (same format but ), 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 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 11 and 22 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
Re: [External] Re: Clarification on DASD mod conversion of SYSRES
Brian, What datasets do you mean by "IPL datasets cataloged to "? Everything on my SYSRES is cataloged to except SYS1.PARMLIB and we IPL just fine. According to the 2.2 INIT & TUNING manual, changing is not allowed in IEASYMxx at all. The further documented restriction is that SYS1.PARMLIB cannot use nor can any dataset defined in the LOADxx member being used unless the LOADxx member also has the vol-ser defined therein so the system can find it. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Westerman Sent: Friday, August 30, 2019 2: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 , it fails if you try to set 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 ) and C23DL1 (which has everything cataloged to ) , C23DL2 (same format but ) and C23DL3 (same format but ), 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 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 11 and 22 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 The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
You can't IPL with the IPL datasets cataloged to , it fails if you try to set 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 ) and C23DL1 (which has everything cataloged to ) , C23DL2 (same format but ) and C23DL3 (same format but ), 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 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 11 and 22 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
Re: Clarification on DASD mod conversion of SYSRES
>I just checked my master cat and EVERY entry has , 2, or 3 except >SYS1.PARMLIB on the SYSRES It has **. and both are set >to since we use mod 27s. We are at z/OS 2.3. All, thanks for checking. So my conclusion way back when must have been wrong. I had left SYS1.PARMLIB (that came with ADCD) on the sysres. There was no SYS1.IBM.PARMLIB, and SYS1.PARMLIB was the one that was SMP/E-maintained. All other parmlibs were on the volume I had established called ZOSCAT. (One more thing that wasn't right with the ADCD systems). Given that at 1.13 there was no rescue system and I had to IPL the old, functioning system every time I needed to make a change, I must have overlooked that only SYS1.PARMLIB needs to be catalogued on volume **. At least it didn't do any harm having everything else on sysres catalogued on ** instead of Still, the wordings in the books could do with some clarification, preferably in one central place. The day I did that migration (away from the ADCD res vols to my own) I must have IPL'd 20 times or so until I got things right. It was a long day. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
I just checked my master cat and EVERY entry has , 2, or 3 except SYS1.PARMLIB on the SYSRES It has **. and both are set to since we use mod 27s. We are at z/OS 2.3. On Thu, Aug 29, 2019 at 12:17 AM Barbara Nitz wrote: > >I have never has a problem using anywhere ** could have been > used. > >Actually, the resolution of occurs very early in the IPL, long > before CAS is initialized. > > > >The difference is that is resolved by CAS, which is not yet > initialized at that moment. Until then, ** does the built-in > substitution. > > The non-full-function CAS address space used to start way after LPA and > Linklist are built. When I had LPA and Linklist data sets catalogued on > volume (z/OS 1.13), the IPL essentially failed, because LPA was > rather empty and also Linklist only had the automatically added libraries > in it. Very hard to get a system up that way. > > There used to be a gap in the asid numbers (IIRC, it was a missing number > 8) that was the non-full-function asid. When I just checked z/OS 2.3, that > gap is gone. So either there isn't an early CAS anymore (the full-function > CATALOG asid has number x'2B') or the early CAS uses REUSEASID=YES or the > startup sequence was completely rewritten. > > In any case, when I check the VOLUME parm for DEFINE NONVSAM, it still > reads to me that volume ** covers the sysres volume and is > supposed to be used for *extensions* of the sysres volume. This reads: > "The symbol name is intended to represent the volume that is a logical > extension of the system residence volume. > ... IBM recommends the use of the symbol for the first logical > extension to the system reference volume, for the second, and so on." > > So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres > catalogued to volume instead of volume ** ??? > > Barbara > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
I got curious. Looks like ** and are interchangeable for everything with one restriction noted below RTFMing in Init & Tuning: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.ieae200/ieae20035.htm I see the following restrictions for indirect cataloging: Indirect volume serial support can only be used for data sets residing on SYSRES and its logical extensions. These are typically data sets that are installed as part of a system build process. Use with user or application data sets is not supported. Cataloged data sets must be non-VSAM and non-SMS-managed. The volume must be mounted and online when a request is made to retrieve information from the catalog. You are responsible for managing volumes where the data sets reside. If you move a data set from one volume to another, you must make the related changes. Changes include: setting up parmlib, proclib, and JCL. establishing system management procedures such as security, backup, and recovery. The following cannot be catalogued with a system symbol: SYS1.PARMLIB Any parmlib data set listed in LOADxx without a volume name. Any parmlib data set (including SYS1.PARMLIB) can be catalogued with six asterisks (**). _ 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 On Behalf Of Matthew Stitt Sent: Thursday, August 29, 2019 9:46 AM 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 mis-wrote. My LPALSTxx and PROGxx do not utilized the variable. Only on the APF statements is it used. Sorry for the confusion. All the datasets except for the VSAM (ZFS) on my the volume I use for SMP/E target and IPL are cataloged with for the volume name. Even SYS1.NUCLEUS, SYS1.LPALIB, and SYS1.LINKLIB, which must be on the IPL volume anyway. Except for SYS1.PARMLIB and SYS1.PROCLIB, which are cataloged using ** for the volume name. I've had IPL issues when not using that convention. But usage of that special volume name implies they are on the IPL volume. On Thu, 29 Aug 2019 12:49:47 +, David Spiegel wrote: >Hi Matthew, >That is not the same as CATALOGing Datasets to VOL(). > >Regards, >David > >On 2019-08-29 08444, Matthew Stitt wrote: >> On my systems, I use the volume parameter of the LPALSTxx, PROGxx, etc. >> Volume is set to (or (on mod-54, so not needed now) ). Have >> no issues with IPL using this method. >> >> Matthew >> >> On Thu, 29 Aug 2019 10:58:15 +, Richards, Robert B. >> wrote: >> >>>> So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres >>>> catalogued to volume instead of volume ** ??? >>> Not in my shop (z/OS 2.3). All my references to are all contained >>> in IEASYM00 and are used to substring its first four characters for the >>> setting of , etc. >>> >>> Bob > -- 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
Re: [External] Re: Clarification on DASD mod conversion of SYSRES
Hi Barbara, z/OS 2.2, SYS1.PARMLIB cataloged using **, SYS1.PROCLIB not on the res volume, everything else cataloged to It works fine. I'll keep your warning about PARMLIB in the back of my mind and not try something dumb like recataloging it to when we go to 2.4 next year. :-) Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Barbara Nitz Sent: Thursday, August 29, 2019 12:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Clarification on DASD mod conversion of SYSRES >I have never has a problem using anywhere ** could have been used. >Actually, the resolution of occurs very early in the IPL, long before >CAS is initialized. > >The difference is that is resolved by CAS, which is not yet initialized >at that moment. Until then, ** does the built-in substitution. The non-full-function CAS address space used to start way after LPA and Linklist are built. When I had LPA and Linklist data sets catalogued on volume (z/OS 1.13), the IPL essentially failed, because LPA was rather empty and also Linklist only had the automatically added libraries in it. Very hard to get a system up that way. There used to be a gap in the asid numbers (IIRC, it was a missing number 8) that was the non-full-function asid. When I just checked z/OS 2.3, that gap is gone. So either there isn't an early CAS anymore (the full-function CATALOG asid has number x'2B') or the early CAS uses REUSEASID=YES or the startup sequence was completely rewritten. In any case, when I check the VOLUME parm for DEFINE NONVSAM, it still reads to me that volume ** covers the sysres volume and is supposed to be used for *extensions* of the sysres volume. This reads: "The symbol name is intended to represent the volume that is a logical extension of the system residence volume. ... IBM recommends the use of the symbol for the first logical extension to the system reference volume, for the second, and so on." So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres catalogued to volume instead of volume ** ??? Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
I mis-wrote. My LPALSTxx and PROGxx do not utilized the variable. Only on the APF statements is it used. Sorry for the confusion. All the datasets except for the VSAM (ZFS) on my the volume I use for SMP/E target and IPL are cataloged with for the volume name. Even SYS1.NUCLEUS, SYS1.LPALIB, and SYS1.LINKLIB, which must be on the IPL volume anyway. Except for SYS1.PARMLIB and SYS1.PROCLIB, which are cataloged using ** for the volume name. I've had IPL issues when not using that convention. But usage of that special volume name implies they are on the IPL volume. On Thu, 29 Aug 2019 12:49:47 +, David Spiegel wrote: >Hi Matthew, >That is not the same as CATALOGing Datasets to VOL(). > >Regards, >David > >On 2019-08-29 08444, Matthew Stitt wrote: >> On my systems, I use the volume parameter of the LPALSTxx, PROGxx, etc. >> Volume is set to (or (on mod-54, so not needed now) ). Have >> no issues with IPL using this method. >> >> Matthew >> >> On Thu, 29 Aug 2019 10:58:15 +, Richards, Robert B. >> wrote: >> So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres catalogued to volume instead of volume ** ??? >>> Not in my shop (z/OS 2.3). All my references to are all contained >>> in IEASYM00 and are used to substring its first four characters for the >>> setting of , etc. >>> >>> Bob > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
Hi Matthew, That is not the same as CATALOGing Datasets to VOL(). Regards, David On 2019-08-29 08:44, Matthew Stitt wrote: > On my systems, I use the volume parameter of the LPALSTxx, PROGxx, etc. > Volume is set to (or (on mod-54, so not needed now) ). Have no > issues with IPL using this method. > > Matthew > > On Thu, 29 Aug 2019 10:58:15 +, Richards, Robert B. > wrote: > >>> So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres >>> catalogued to volume instead of volume ** ??? >> Not in my shop (z/OS 2.3). All my references to are all contained in >> IEASYM00 and are used to substring its first four characters for the setting >> of , etc. >> >> Bob >> > -- > 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
Re: Clarification on DASD mod conversion of SYSRES
On my systems, I use the volume parameter of the LPALSTxx, PROGxx, etc. Volume is set to (or (on mod-54, so not needed now) ). Have no issues with IPL using this method. Matthew On Thu, 29 Aug 2019 10:58:15 +, Richards, Robert B. wrote: >> So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres >> catalogued to volume instead of volume ** ??? > >Not in my shop (z/OS 2.3). All my references to are all contained in >IEASYM00 and are used to substring its first four characters for the setting >of , etc. > >Bob > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
> So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres > catalogued to volume instead of volume ** ??? Not in my shop (z/OS 2.3). All my references to are all contained in IEASYM00 and are used to substring its first four characters for the setting of , etc. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Barbara Nitz Sent: Thursday, August 29, 2019 1:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Clarification on DASD mod conversion of SYSRES >I have never has a problem using anywhere ** could have been used. >Actually, the resolution of occurs very early in the IPL, long before >CAS is initialized. > >The difference is that is resolved by CAS, which is not yet initialized >at that moment. Until then, ** does the built-in substitution. The non-full-function CAS address space used to start way after LPA and Linklist are built. When I had LPA and Linklist data sets catalogued on volume (z/OS 1.13), the IPL essentially failed, because LPA was rather empty and also Linklist only had the automatically added libraries in it. Very hard to get a system up that way. There used to be a gap in the asid numbers (IIRC, it was a missing number 8) that was the non-full-function asid. When I just checked z/OS 2.3, that gap is gone. So either there isn't an early CAS anymore (the full-function CATALOG asid has number x'2B') or the early CAS uses REUSEASID=YES or the startup sequence was completely rewritten. In any case, when I check the VOLUME parm for DEFINE NONVSAM, it still reads to me that volume ** covers the sysres volume and is supposed to be used for *extensions* of the sysres volume. This reads: "The symbol name is intended to represent the volume that is a logical extension of the system residence volume. ... IBM recommends the use of the symbol for the first logical extension to the system reference volume, for the second, and so on." So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres catalogued to volume instead of volume ** ??? Barbara -- 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
Re: Clarification on DASD mod conversion of SYSRES
>What if the res volume is spreaded on two volumes ? Can we still use >'**' ? No, not according to how I read the book. Only the data sets on the volume that you specify in the IPLPARM can use **. Any other volume containing non-VSAM system data sets would be considered an *extension* of the sysres volume and would need to have the symbol(s) (n>1) defined and would need to be catalogued to volume Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
What if the res volume is spreaded on two volumes ? Can we still use '**' ? On Thu, 29 Aug, 2019, 9:17 AM Barbara Nitz, wrote: > >I have never has a problem using anywhere ** could have been > used. > >Actually, the resolution of occurs very early in the IPL, long > before CAS is initialized. > > > >The difference is that is resolved by CAS, which is not yet > initialized at that moment. Until then, ** does the built-in > substitution. > > The non-full-function CAS address space used to start way after LPA and > Linklist are built. When I had LPA and Linklist data sets catalogued on > volume (z/OS 1.13), the IPL essentially failed, because LPA was > rather empty and also Linklist only had the automatically added libraries > in it. Very hard to get a system up that way. > > There used to be a gap in the asid numbers (IIRC, it was a missing number > 8) that was the non-full-function asid. When I just checked z/OS 2.3, that > gap is gone. So either there isn't an early CAS anymore (the full-function > CATALOG asid has number x'2B') or the early CAS uses REUSEASID=YES or the > startup sequence was completely rewritten. > > In any case, when I check the VOLUME parm for DEFINE NONVSAM, it still > reads to me that volume ** covers the sysres volume and is > supposed to be used for *extensions* of the sysres volume. This reads: > "The symbol name is intended to represent the volume that is a logical > extension of the system residence volume. > ... IBM recommends the use of the symbol for the first logical > extension to the system reference volume, for the second, and so on." > > So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres > catalogued to volume instead of volume ** ??? > > Barbara > > -- > 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
Re: Clarification on DASD mod conversion of SYSRES
>I have never has a problem using anywhere ** could have been used. >Actually, the resolution of occurs very early in the IPL, long before >CAS is initialized. > >The difference is that is resolved by CAS, which is not yet initialized >at that moment. Until then, ** does the built-in substitution. The non-full-function CAS address space used to start way after LPA and Linklist are built. When I had LPA and Linklist data sets catalogued on volume (z/OS 1.13), the IPL essentially failed, because LPA was rather empty and also Linklist only had the automatically added libraries in it. Very hard to get a system up that way. There used to be a gap in the asid numbers (IIRC, it was a missing number 8) that was the non-full-function asid. When I just checked z/OS 2.3, that gap is gone. So either there isn't an early CAS anymore (the full-function CATALOG asid has number x'2B') or the early CAS uses REUSEASID=YES or the startup sequence was completely rewritten. In any case, when I check the VOLUME parm for DEFINE NONVSAM, it still reads to me that volume ** covers the sysres volume and is supposed to be used for *extensions* of the sysres volume. This reads: "The symbol name is intended to represent the volume that is a logical extension of the system residence volume. ... IBM recommends the use of the symbol for the first logical extension to the system reference volume, for the second, and so on." So, has anyone IPL'd z/OS 2.2 or higher with the data sets on the sysres catalogued to volume instead of volume ** ??? Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
As I said before, that is the reason for the existence of SYSn.IPLPARM. To locate SYS1.PARMLIB when it is not on the sysres (among other things). -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jesse 1 Robinson Sent: Wednesday, August 28, 2019 11:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Clarification on DASD mod conversion of SYSRES System symbols are defined IEASYMxx, which resides in (some) PARMLIB as specified in LOADxx. I don't think you can resolve a system symbol whose location is itself determined by IEASYSMxx until you have found and read that SYM member. My personal preference for a variety of reasons is to keep the 'business' SYS1.PARMLIB away from sysres on a fixed, hard-coded volser. . . 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 On Behalf Of David Spiegel Sent: Wednesday, August 28, 2019 6:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Clarification on DASD mod conversion of SYSRES Hi Allan, Try using to Catalog SYS1.PARMLIB on the SYSRES and let me know if it works. In z/OS 2.1 it didn't. Regards, David On 2019-08-28 08:35, Allan Staller wrote: > I have never has a problem using anywhere ** could have been used. > Actually, the resolution of occurs very early in the IPL, long before > CAS is initialized. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Vernooij, Kees (ITOP NM) - KLM > Sent: Wednesday, August 28, 2019 1:16 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Clarification on DASD mod conversion of SYSRES > > The difference is that is resolved by CAS, which is not yet > initialized at that moment. Until then, ** does the built-in substitution. > > Kees. > > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Barbara Nitz >> Sent: 28 August, 2019 6:52 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Clarification on DASD mod conversion of SYSRES >> >>> There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes >>> and >> have been for years. Probably the only issue you might have is if you >> are going from a multi-sysres config where you had multiple system >> symbols for catalog purposes, you'll just have to fix that to all use >> either >> ** or >> >> The last time I did this exercise (when rearranging an ADCD system) >> about >> 4-5 years ago I fell flat on my face when I catalogued the sysres >> data sets on the sysres I IPL'd from to use the qualifier >> The system didn't come up because it found just about nothing. After >> staring at the manual for a while, I read the manual that you *must* >> use ** for all data sets on the sysres volume you use to IPL. >> Sure enough, once I had recatalogued everything from to **, the >> system came up. >> >> Has that changed in the meantime? Are and ** interchangeable? >> >> Regards, Barbara >> >> - >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO >> IBM-MAIN > > For information, services and offers, please visit our web site: > https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.comdata=02%7C01%7Callan.staller%40HCL.COM%7C266a8972e1004c5e2be108d72bd85ab2%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637026080593682584sdata=W3gFrqEjK58bi3JYFyX15eu5FLktGvwoY4e%2Fc58R%2B3w%3Dreserved=0. > This e-mail and any attachment may contain confidential and privileged > material intended for the addressee only. If you are not the addressee, you > are notified that no part of the e-mail or any attachment may be disclosed, > copied or distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have received > this e-mail by error, please notify the sender immediately by return e-mail, > and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission of > this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > regis
Re: Clarification on DASD mod conversion of SYSRES
System symbols are defined IEASYMxx, which resides in (some) PARMLIB as specified in LOADxx. I don't think you can resolve a system symbol whose location is itself determined by IEASYSMxx until you have found and read that SYM member. My personal preference for a variety of reasons is to keep the 'business' SYS1.PARMLIB away from sysres on a fixed, hard-coded volser. . . 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 On Behalf Of David Spiegel Sent: Wednesday, August 28, 2019 6:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Clarification on DASD mod conversion of SYSRES Hi Allan, Try using to Catalog SYS1.PARMLIB on the SYSRES and let me know if it works. In z/OS 2.1 it didn't. Regards, David On 2019-08-28 08:35, Allan Staller wrote: > I have never has a problem using anywhere ** could have been used. > Actually, the resolution of occurs very early in the IPL, long before > CAS is initialized. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Vernooij, Kees (ITOP NM) - KLM > Sent: Wednesday, August 28, 2019 1:16 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Clarification on DASD mod conversion of SYSRES > > The difference is that is resolved by CAS, which is not yet > initialized at that moment. Until then, ** does the built-in substitution. > > Kees. > > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Barbara Nitz >> Sent: 28 August, 2019 6:52 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Clarification on DASD mod conversion of SYSRES >> >>> There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes >>> and >> have been for years. Probably the only issue you might have is if you >> are going from a multi-sysres config where you had multiple system >> symbols for catalog purposes, you'll just have to fix that to all use >> either >> ** or >> >> The last time I did this exercise (when rearranging an ADCD system) >> about >> 4-5 years ago I fell flat on my face when I catalogued the sysres >> data sets on the sysres I IPL'd from to use the qualifier >> The system didn't come up because it found just about nothing. After >> staring at the manual for a while, I read the manual that you *must* >> use ** for all data sets on the sysres volume you use to IPL. >> Sure enough, once I had recatalogued everything from to **, the >> system came up. >> >> Has that changed in the meantime? Are and ** interchangeable? >> >> Regards, Barbara >> >> - >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO >> IBM-MAIN > > For information, services and offers, please visit our web site: > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.comdata=02%7C01%7C%7Cbf2e9dc5359541b195a408d72bb46234%7C84df9e7fe9f640afb435%7C1%7C0%7C637025926094132509sdata=wBXxO2VChKVTDUY4zaxIEb55Pcld%2FbFEugNxBw0nzZA%3Dreserved=0. > This e-mail and any attachment may contain confidential and privileged > material intended for the addressee only. If you are not the addressee, you > are notified that no part of the e-mail or any attachment may be disclosed, > copied or distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have received > this e-mail by error, please notify the sender immediately by return e-mail, > and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission of > this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > -- >
Re: Clarification on DASD mod conversion of SYSRES
Yeah, but, you said: "... I have never has a problem using anywhere ** could have been used. ..." Had you (or anyone else) placed SYS1.PARMLIB on your SYSRES, your statement would not be completely true (for e.g. SYS1.PARMLIB) On 2019-08-28 09:56, Allan Staller wrote: > I haven't had SYS1.PARMLIB on the resvol for years. That is the purpose of > SYSn.IPLPARM > > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > David Spiegel > Sent: Wednesday, August 28, 2019 8:54 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Clarification on DASD mod conversion of SYSRES > > Hi Allan, > Try using to Catalog SYS1.PARMLIB on the SYSRES and let me know if it > works. > In z/OS 2.1 it didn't. > > Regards, > David > > On 2019-08-28 08:35, Allan Staller wrote: >> I have never has a problem using anywhere ** could have been used. >> Actually, the resolution of occurs very early in the IPL, long before >> CAS is initialized. >> >> HTH, >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of Vernooij, Kees (ITOP NM) - KLM >> Sent: Wednesday, August 28, 2019 1:16 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Clarification on DASD mod conversion of SYSRES >> >> The difference is that is resolved by CAS, which is not yet >> initialized at that moment. Until then, ** does the built-in >> substitution. >> >> Kees. >> >> >>> -Original Message----- >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >>> On Behalf Of Barbara Nitz >>> Sent: 28 August, 2019 6:52 >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: Clarification on DASD mod conversion of SYSRES >>> >>>> There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes >>>> and >>> have been for years. Probably the only issue you might have is if you >>> are going from a multi-sysres config where you had multiple system >>> symbols for catalog purposes, you'll just have to fix that to all use >>> either >>> ** or >>> >>> The last time I did this exercise (when rearranging an ADCD system) >>> about >>> 4-5 years ago I fell flat on my face when I catalogued the sysres >>> data sets on the sysres I IPL'd from to use the qualifier >>> The system didn't come up because it found just about nothing. After >>> staring at the manual for a while, I read the manual that you *must* >>> use ** for all data sets on the sysres volume you use to IPL. >>> Sure enough, once I had recatalogued everything from to **, the >>> system came up. >>> >>> Has that changed in the meantime? Are and ** interchangeable? >>> >>> Regards, Barbara >>> >>> - >>> - For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO >>> IBM-MAIN >> >> For information, services and offers, please visit our web site: >> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.comdata=02%7C01%7C%7C4d105a9209ee4af9f4ef08d72bbfa6cc%7C84df9e7fe9f640afb435%7C1%7C0%7C637025974476818948sdata=CLpqrM1fJ8gLTviJElZ2O8xVucm2824Jbs8QE4aLKfo%3Dreserved=0. >> This e-mail and any attachment may contain confidential and privileged >> material intended for the addressee only. If you are not the addressee, you >> are notified that no part of the e-mail or any attachment may be disclosed, >> copied or distributed, and that any other action related to this e-mail or >> attachment is strictly prohibited, and may be unlawful. If you have received >> this e-mail by error, please notify the sender immediately by return e-mail, >> and delete this message. >> >> Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its >> employees shall not be liable for the incorrect or incomplete transmission >> of this e-mail or any attachments, nor responsible for any delay in receipt. >> Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal >> Dutch Airlines) is registered in Amstelveen, The Netherlands, with >> registered number 33014286 >> >> >> >> -- >> For IBM-MAIN subscribe / signoff / archive acc
Re: Clarification on DASD mod conversion of SYSRES
I haven't had SYS1.PARMLIB on the resvol for years. That is the purpose of SYSn.IPLPARM -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Spiegel Sent: Wednesday, August 28, 2019 8:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Clarification on DASD mod conversion of SYSRES Hi Allan, Try using to Catalog SYS1.PARMLIB on the SYSRES and let me know if it works. In z/OS 2.1 it didn't. Regards, David On 2019-08-28 08:35, Allan Staller wrote: > I have never has a problem using anywhere ** could have been used. > Actually, the resolution of occurs very early in the IPL, long before > CAS is initialized. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Vernooij, Kees (ITOP NM) - KLM > Sent: Wednesday, August 28, 2019 1:16 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Clarification on DASD mod conversion of SYSRES > > The difference is that is resolved by CAS, which is not yet > initialized at that moment. Until then, ** does the built-in substitution. > > Kees. > > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Barbara Nitz >> Sent: 28 August, 2019 6:52 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Clarification on DASD mod conversion of SYSRES >> >>> There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes >>> and >> have been for years. Probably the only issue you might have is if you >> are going from a multi-sysres config where you had multiple system >> symbols for catalog purposes, you'll just have to fix that to all use >> either >> ** or >> >> The last time I did this exercise (when rearranging an ADCD system) >> about >> 4-5 years ago I fell flat on my face when I catalogued the sysres >> data sets on the sysres I IPL'd from to use the qualifier >> The system didn't come up because it found just about nothing. After >> staring at the manual for a while, I read the manual that you *must* >> use ** for all data sets on the sysres volume you use to IPL. >> Sure enough, once I had recatalogued everything from to **, the >> system came up. >> >> Has that changed in the meantime? Are and ** interchangeable? >> >> Regards, Barbara >> >> - >> - For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO >> IBM-MAIN > > For information, services and offers, please visit our web site: > https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.comdata=02%7C01%7Callan.staller%40HCL.COM%7Cdb67ae296af44a70c50608d72bbf4a0d%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637025972918826665sdata=hqK5Jp8J%2BajoiWDJOv67Xq6wrdhR0l6xqAADfu3uBDw%3Dreserved=0. > This e-mail and any attachment may contain confidential and privileged > material intended for the addressee only. If you are not the addressee, you > are notified that no part of the e-mail or any attachment may be disclosed, > copied or distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have received > this e-mail by error, please notify the sender immediately by return e-mail, > and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission of > this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > -- > -- > -- > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted,
Re: Clarification on DASD mod conversion of SYSRES
Hi Allan, Try using to Catalog SYS1.PARMLIB on the SYSRES and let me know if it works. In z/OS 2.1 it didn't. Regards, David On 2019-08-28 08:35, Allan Staller wrote: > I have never has a problem using anywhere ** could have been used. > Actually, the resolution of occurs very early in the IPL, long before > CAS is initialized. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Vernooij, Kees (ITOP NM) - KLM > Sent: Wednesday, August 28, 2019 1:16 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Clarification on DASD mod conversion of SYSRES > > The difference is that is resolved by CAS, which is not yet > initialized at that moment. Until then, ** does the built-in substitution. > > Kees. > > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] >> On Behalf Of Barbara Nitz >> Sent: 28 August, 2019 6:52 >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Clarification on DASD mod conversion of SYSRES >> >>> There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes >>> and >> have been for years. Probably the only issue you might have is if you >> are going from a multi-sysres config where you had multiple system >> symbols for catalog purposes, you'll just have to fix that to all use >> either >> ** or >> >> The last time I did this exercise (when rearranging an ADCD system) >> about >> 4-5 years ago I fell flat on my face when I catalogued the sysres data >> sets on the sysres I IPL'd from to use the qualifier The >> system didn't come up because it found just about nothing. After >> staring at the manual for a while, I read the manual that you *must* >> use ** for all data sets on the sysres volume you use to IPL. Sure >> enough, once I had recatalogued everything from to **, the >> system came up. >> >> Has that changed in the meantime? Are and ** interchangeable? >> >> Regards, Barbara >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, send >> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > For information, services and offers, please visit our web site: > https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.comdata=02%7C01%7C%7Cbf2e9dc5359541b195a408d72bb46234%7C84df9e7fe9f640afb435%7C1%7C0%7C637025926094132509sdata=wBXxO2VChKVTDUY4zaxIEb55Pcld%2FbFEugNxBw0nzZA%3Dreserved=0. > This e-mail and any attachment may contain confidential and privileged > material intended for the addressee only. If you are not the addressee, you > are notified that no part of the e-mail or any attachment may be disclosed, > copied or distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have received > this e-mail by error, please notify the sender immediately by return e-mail, > and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission of > this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Netherlands, with registered > number 33014286 > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > -- > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses > in transmission. The e mail and its contents (with or without referred > errors) shall therefore not attach any liability on the originator or HCL or > its affiliates. Views or opinions, if any, presented in this email are solely > those of the author and may not necessarily reflect the view
Re: Clarification on DASD mod conversion of SYSRES
I have never has a problem using anywhere ** could have been used. Actually, the resolution of occurs very early in the IPL, long before CAS is initialized. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Vernooij, Kees (ITOP NM) - KLM Sent: Wednesday, August 28, 2019 1:16 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Clarification on DASD mod conversion of SYSRES The difference is that is resolved by CAS, which is not yet initialized at that moment. Until then, ** does the built-in substitution. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Barbara Nitz > Sent: 28 August, 2019 6:52 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Clarification on DASD mod conversion of SYSRES > > >There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes > >and > have been for years. Probably the only issue you might have is if you > are going from a multi-sysres config where you had multiple system > symbols for catalog purposes, you'll just have to fix that to all use > either > ** or > > The last time I did this exercise (when rearranging an ADCD system) > about > 4-5 years ago I fell flat on my face when I catalogued the sysres data > sets on the sysres I IPL'd from to use the qualifier The > system didn't come up because it found just about nothing. After > staring at the manual for a while, I read the manual that you *must* > use ** for all data sets on the sysres volume you use to IPL. Sure > enough, once I had recatalogued everything from to **, the system > came up. > > Has that changed in the meantime? Are and ** interchangeable? > > Regards, Barbara > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.klm.comdata=02%7C01%7Callan.staller%40HCL.COM%7C1545bf6d89234c404fbd08d72b81e09b%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637025709161169071sdata=UuXgsKiggwiIWplEpZIOKWcSKYCQKlFtRsiTmiD4xnc%3Dreserved=0. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender imme
Re: Clarification on DASD mod conversion of SYSRES
Volume and volume ** are equivalent. HLQ is a whole different matter. i.e. DEF NVSAM(NAME(datasetname) DEVT(3390) VOL()) and DEF NVSAM(NAME(datasetname) DEVT(3390) VOL(**)) Should resolve identically. The "advantage of is that it is easily extensible to ,... HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Barbara Nitz Sent: Tuesday, August 27, 2019 11:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Clarification on DASD mod conversion of SYSRES >There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes and have >been for years. Probably the only issue you might have is if you are going >from a multi-sysres config where you had multiple system symbols for catalog >purposes, you'll just have to fix that to all use either ** or The last time I did this exercise (when rearranging an ADCD system) about 4-5 years ago I fell flat on my face when I catalogued the sysres data sets on the sysres I IPL'd from to use the qualifier The system didn't come up because it found just about nothing. After staring at the manual for a while, I read the manual that you *must* use ** for all data sets on the sysres volume you use to IPL. Sure enough, once I had recatalogued everything from to **, the system came up. Has that changed in the meantime? Are and ** interchangeable? Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: -- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
I sit corrected. Thanks for teaching me something today. Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Wednesday, August 28, 2019 2:15 AM, Vernooij, Kees (ITOP NM) - KLM wrote: > The difference is that is resolved by CAS, which is not yet > initialized at that moment. Until then, ** does the built-in substitution. > > Kees. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Barbara Nitz > > Sent: 28 August, 2019 6:52 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Clarification on DASD mod conversion of SYSRES > > > > > There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes and > > > have been for years. Probably the only issue you might have is if you > > > are going from a multi-sysres config where you had multiple system symbols > > > for catalog purposes, you'll just have to fix that to all use either > > > ** or > > > > The last time I did this exercise (when rearranging an ADCD system) about > > 4-5 years ago I fell flat on my face when I catalogued the sysres data > > sets on the sysres I IPL'd from to use the qualifier The system > > didn't come up because it found just about nothing. After staring at the > > manual for a while, I read the manual that you must use ** for all > > data sets on the sysres volume you use to IPL. Sure enough, once I had > > recatalogued everything from to **, the system came up. > > Has that changed in the meantime? Are and ** interchangeable? > > Regards, Barbara > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain confidential > and privileged material intended for the addressee only. If you are not the > addressee, you are notified that no part of the e-mail or any attachment may > be disclosed, copied or distributed, and that any other action related to > this e-mail or attachment is strictly prohibited, and may be unlawful. If you > have received this e-mail by error, please notify the sender immediately by > return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission of > this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Netherlands, with registered > number 33014286 > > -- > > 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
Re: Clarification on DASD mod conversion of SYSRES
Thanks Barbara. Makes sense. _ 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 On Behalf Of Barbara Nitz Sent: Wednesday, August 28, 2019 12:52 AM 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** >There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes and have >been for years. Probably the only issue you might have is if you are going >from a multi-sysres config where you had multiple system symbols for catalog >purposes, you'll just have to fix that to all use either ** or The last time I did this exercise (when rearranging an ADCD system) about 4-5 years ago I fell flat on my face when I catalogued the sysres data sets on the sysres I IPL'd from to use the qualifier The system didn't come up because it found just about nothing. After staring at the manual for a while, I read the manual that you *must* use ** for all data sets on the sysres volume you use to IPL. Sure enough, once I had recatalogued everything from to **, the system came up. Has that changed in the meantime? Are and ** interchangeable? Regards, Barbara -- 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
Re: Clarification on DASD mod conversion of SYSRES
The difference is that is resolved by CAS, which is not yet initialized at that moment. Until then, ** does the built-in substitution. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Barbara Nitz > Sent: 28 August, 2019 6:52 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Clarification on DASD mod conversion of SYSRES > > >There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes and > have been for years. Probably the only issue you might have is if you > are going from a multi-sysres config where you had multiple system symbols > for catalog purposes, you'll just have to fix that to all use either > ** or > > The last time I did this exercise (when rearranging an ADCD system) about > 4-5 years ago I fell flat on my face when I catalogued the sysres data > sets on the sysres I IPL'd from to use the qualifier The system > didn't come up because it found just about nothing. After staring at the > manual for a while, I read the manual that you *must* use ** for all > data sets on the sysres volume you use to IPL. Sure enough, once I had > recatalogued everything from to **, the system came up. > > Has that changed in the meantime? Are and ** interchangeable? > > Regards, Barbara > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
All disks larger than model-9 until model-58 (the max before EAV) are just model-9's, only with more space. Nobody/software should notice the difference. Our Sysres's are model-30's for many years after being expanded dynamically from model-27's since we needed some more room. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jake Anderson > Sent: 27 August, 2019 19:12 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Clarification on DASD mod conversion of SYSRES > > Hello Group > > I am planning convert the SMPE res volume DASD from mod 9 to mod 27 and > also our production alternate respack to mod 27.(Which is not live now). > This is due to the growing res volume . > > With this conversion will there be any impact or any other changes that > need to be looked at prior to IPL ? > > Any comments on above would be appreciated. > > Jake > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
>There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes and have >been for years. Probably the only issue you might have is if you are going >from a multi-sysres config where you had multiple system symbols for catalog >purposes, you'll just have to fix that to all use either ** or The last time I did this exercise (when rearranging an ADCD system) about 4-5 years ago I fell flat on my face when I catalogued the sysres data sets on the sysres I IPL'd from to use the qualifier The system didn't come up because it found just about nothing. After staring at the manual for a while, I read the manual that you *must* use ** for all data sets on the sysres volume you use to IPL. Sure enough, once I had recatalogued everything from to **, the system came up. Has that changed in the meantime? Are and ** interchangeable? Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: Clarification on DASD mod conversion of SYSRES
Or as a temporary solution until you're firmly onto a single SYSRES, you could place something like this in IEASYMxx: SYSDEF SYMDEF(='') This way you won't need to change your catalog entries at the cutover time, minimizing your chance of problems. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jake Anderson Sent: Tuesday, August 27, 2019 1:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Clarification on DASD mod conversion of SYSRES Yes I do have two and Might be having ** would be a good idea ? On Tue, 27 Aug, 2019, 9:42 PM Jousma, David, < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes and > have been for years. Probably the only issue you might have is if you are > going from a multi-sysres config where you had multiple system symbols > for catalog purposes, you'll just have to fix that to all use either > ** or > > > __ > ___ > 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 On > Behalf Of Jake Anderson > Sent: Tuesday, August 27, 2019 1:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Clarification on DASD mod conversion of SYSRES > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > Hello Group > > I am planning convert the SMPE res volume DASD from mod 9 to mod 27 > and also our production alternate respack to mod 27.(Which is not live now). > This is due to the growing res volume . > > With this conversion will there be any impact or any other changes > that need to be looked at prior to IPL ? > > Any comments on above would be appreciated. > > Jake > > -- > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
If SYS1.PARMLIB is on your SYSRES, DO NOT Catalog it on VOL(). VOL(**), however, does work for SYS1.PARMLIB. On 2019-08-27 14:06, Mark Jacobs wrote: > resolves to the same value as ** and was meant as a replacement > for using ** in catalog entries. > > Mark Jacobs > > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.comdata=02%7C01%7C%7C0a0ea46e17cc4353294808d72b195595%7C84df9e7fe9f640afb435%7C1%7C0%7C637025260136295804sdata=Q%2BMZi9gCArWuIdg7BADjnWVitfmRQ7N4BcRWNvPk51w%3Dreserved=0 > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, August 27, 2019 2:03 PM, Jake Anderson > wrote: > >> Yes I do have two and Might be having ** would be a >> good idea ? >> >> On Tue, 27 Aug, 2019, 9:42 PM Jousma, David, < >> 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: >> >>> There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes and >>> have been for years. Probably the only issue you might have is if you are >>> going from a multi-sysres config where you had multiple system symbols for >>> catalog purposes, you'll just have to fix that to all use either ** or >>> >>> >>> 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 Jake Anderson >>> Sent: Tuesday, August 27, 2019 1:12 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Clarification on DASD mod conversion of SYSRES >>> CAUTION EXTERNAL EMAIL >>> DO NOT open attachments or click on links from unknown senders or >>> unexpected emailsHello Group >>> I am planning convert the SMPE res volume DASD from mod 9 to mod 27 and >>> also our production alternate respack to mod 27.(Which is not live now). >>> This is due to the growing res volume . >>> With this conversion will there be any impact or any other changes that >>> need to be looked at prior to IPL ? >>> Any comments on above would be appreciated. >>> Jake >>> >>> For IBM-MAIN subscribe / signoff / archive access instructions, send email >>> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN CAUTION >>> EXTERNAL EMAILDO NOT open attachments or click on links from unknown >>> senders or >>> unexpected emailsThis 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 >> -- >> >> 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 > . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
I actually still use both. Everything on my sysres (except ZFS) are cataloged with ** for historical reasons I guess. I don’t migrate to a new mastercat when building next z/os release in Serverpac, so the only really "safe" method to convert from ** to in the catalog would be to copy the master cat, make the changes, and then IPL off of it. Probably more work that it is worth. ZFS datasets on my SYSRES have the SYSRES as the 2nd qualifier in it, and I use In BPXPRMxx to reference them and various other places I use the symbol. _ 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 On Behalf Of Jake Anderson Sent: Tuesday, August 27, 2019 2:04 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** Yes I do have two and Might be having ** would be a good idea ? On Tue, 27 Aug, 2019, 9:42 PM Jousma, David, < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes and > have been for years. Probably the only issue you might have is if you are > going from a multi-sysres config where you had multiple system symbols > for catalog purposes, you'll just have to fix that to all use either > ** or > > > __ > ___ > 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 On > Behalf Of Jake Anderson > Sent: Tuesday, August 27, 2019 1:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Clarification on DASD mod conversion of SYSRES > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > Hello Group > > I am planning convert the SMPE res volume DASD from mod 9 to mod 27 > and also our production alternate respack to mod 27.(Which is not live now). > This is due to the growing res volume . > > With this conversion will there be any impact or any other changes > that need to be looked at prior to IPL ? > > Any comments on above would be appreciated. > > Jake > > -- > 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 > -- 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 appr
Re: Clarification on DASD mod conversion of SYSRES
resolves to the same value as ** and was meant as a replacement for using ** in catalog entries. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Tuesday, August 27, 2019 2:03 PM, Jake Anderson wrote: > Yes I do have two and Might be having ** would be a > good idea ? > > On Tue, 27 Aug, 2019, 9:42 PM Jousma, David, < > 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > > > There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes and > > have been for years. Probably the only issue you might have is if you are > > going from a multi-sysres config where you had multiple system symbols for > > catalog purposes, you'll just have to fix that to all use either ** or > > > > > > 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 Jake Anderson > > Sent: Tuesday, August 27, 2019 1:12 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Clarification on DASD mod conversion of SYSRES > > CAUTION EXTERNAL EMAIL > > DO NOT open attachments or click on links from unknown senders or > > unexpected emailsHello Group > > I am planning convert the SMPE res volume DASD from mod 9 to mod 27 and > > also our production alternate respack to mod 27.(Which is not live now). > > This is due to the growing res volume . > > With this conversion will there be any impact or any other changes that > > need to be looked at prior to IPL ? > > Any comments on above would be appreciated. > > Jake > > > > For IBM-MAIN subscribe / signoff / archive access instructions, send email > > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN CAUTION > > EXTERNAL EMAILDO NOT open attachments or click on links from unknown > > senders or > > unexpected emailsThis 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 > > -- > > 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
Re: Clarification on DASD mod conversion of SYSRES
Yes I do have two and Might be having ** would be a good idea ? On Tue, 27 Aug, 2019, 9:42 PM Jousma, David, < 01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote: > There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes and > have been for years. Probably the only issue you might have is if you are > going from a multi-sysres config where you had multiple system symbols for > catalog purposes, you'll just have to fix that to all use either ** or > > > > _ > 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 On Behalf > Of Jake Anderson > Sent: Tuesday, August 27, 2019 1:12 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Clarification on DASD mod conversion of SYSRES > > **CAUTION EXTERNAL EMAIL** > > **DO NOT open attachments or click on links from unknown senders or > unexpected emails** > > Hello Group > > I am planning convert the SMPE res volume DASD from mod 9 to mod 27 and > also our production alternate respack to mod 27.(Which is not live now). > This is due to the growing res volume . > > With this conversion will there be any impact or any other changes that > need to be looked at prior to IPL ? > > Any comments on above would be appreciated. > > Jake > > -- > 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 > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clarification on DASD mod conversion of SYSRES
There shouldn’t be Jake. I'm running MOD-54's for my sysres volumes and have been for years. Probably the only issue you might have is if you are going from a multi-sysres config where you had multiple system symbols for catalog purposes, you'll just have to fix that to all use either ** or _ 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 On Behalf Of Jake Anderson Sent: Tuesday, August 27, 2019 1:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Clarification on DASD mod conversion of SYSRES **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** Hello Group I am planning convert the SMPE res volume DASD from mod 9 to mod 27 and also our production alternate respack to mod 27.(Which is not live now). This is due to the growing res volume . With this conversion will there be any impact or any other changes that need to be looked at prior to IPL ? Any comments on above would be appreciated. Jake -- 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
Clarification on DASD mod conversion of SYSRES
Hello Group I am planning convert the SMPE res volume DASD from mod 9 to mod 27 and also our production alternate respack to mod 27.(Which is not live now). This is due to the growing res volume . With this conversion will there be any impact or any other changes that need to be looked at prior to IPL ? Any comments on above would be appreciated. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
