Paul, That can happen, if the GRSRNL is out sync between LPARs. You would need to setup the LPAR with GRSRNL that is currently running on the LPAR which is still up. Then after the LPAR is up and running, you might be able to issue SET GRSRNL=xx, depending upon the changes. I have hit that situation before. :)
Jerry -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Feller, Paul Sent: Monday, June 29, 2020 3:57 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GRSRNL Example [EXTERNAL] This message was sent from an external source outside of Western & Southern's network. Do not click links or open attachments unless you recognize the sender and know the contents are safe. ________________________________________________________________________________________________________________________ We don't update our GRSRNL to much. Last time it was update was in 2016. There is one thing you might want to watch. We ran into an issue one time when changes did get made an lpar got IPL before a SET GRSRNL=xx command was issues. The lpar would not IPL, it went into a wait state. I don't recall how we got out of the situation. We may have backed out the changes and then IPLed. After that we may have put the changes back in and did the SET GRSRNL=xx command. It has been a few years. So now we have a warning at the top of the member indicating this issue could happen if the SET GRSRNL=xx command does not get done before an IPL is done. Thanks.. Paul Feller GTS Mainframe Technical Support -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Jesse 1 Robinson Sent: Monday, June 29, 2020 2:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GRSRNL Example [EXTERNAL] The two examples given--from Richard Pinion and Jerry Edington--differ quite significantly aside from entries for optional products that a shop may or may not run. Our list, which has evolved over many decades, resembles Jerry's much more than Richard's. I'm not aware of any problems here, but I have to question whether all entries are necessary/useful. This an arena where entries get added but seldom removed. Is there a consensus for spare vs. verbose? . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Norman Hollander Sent: Monday, June 29, 2020 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):FW: GRSRNL Example CAUTION EXTERNAL EMAIL Perfect! Thanks... Don't have ACF2, but I can figure out the RACF ones. -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Edgington, Jerry Sent: Monday, June 29, 2020 11:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GRSRNL Example Here is what I have. /********************************************************************/ /* SYSTEMS EXCLUSION RESOURCE NAME LIST */ /********************************************************************/ /* */ RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(SYS1.DCMLIB) RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSDSN) RNAME(SYS1.DUMP) /********************************************************************/ /* SYSTEMS EXCLUSION RESOURCE NAME LIST - PATTERN */ /********************************************************************/ /* */ RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSZJES2) RNAME(SYS1.HASPCKP1) RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSZJES2) RNAME(SYS1.HASPCKP2) RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSZJES2) RNAME(SYS1.HASPCKP3) RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSZJES2) RNAME(SYS1.HASPCKP4) /********************************************************************/ /* SYSTEMS CONVERSION NAME LIST - RNLDEF STATEMENTS */ /********************************************************************/ RNLDEF RNL(CON) TYPE(PATTERN) QNAME(*) /* CONVERT ALL RESERVES */ RNLDEF RNL(CON) TYPE(GENERIC) QNAME(IGDCDSXS) /* SMS RESOURCE NAME */ RNLDEF RNL(CON) TYPE(GENERIC) QNAME(SPZAPLIB) /* ISPF AND LINKEAGE EDITOR */ RNLDEF RNL(CON) TYPE(GENERIC) QNAME(SYSIEWLP) /* ISPF AND LINKEAGE EDITOR */ RNLDEF RNL(CON) TYPE(GENERIC) QNAME(SYSIGGV2) /* CATALOGS */ RNLDEF RNL(CON) TYPE(GENERIC) QNAME(SYSZRACF) /* RACF DATABASE */ RNLDEF RNL(CON) TYPE(GENERIC) QNAME(SYSZVVDS) /* VVDS */ RNLDEF RNL(CON) TYPE(GENERIC) QNAME(SYSVTOC) /* DISK VTOC */ /********************************************************************/ /* SYSTEMS INCLUSION RESOURCE NAME LIST */ /********************************************************************/ /* */ RNLDEF RNL(INCL) TYPE(GENERIC) QNAME(SYSDSN) RNAME(IXGLOGR) RNLDEF RNL(INCL) TYPE(GENERIC) QNAME(SYSDSN) RNLDEF RNL(INCL) TYPE(GENERIC) QNAME(SYSIKJBC) RNLDEF RNL(INCL) TYPE(GENERIC) QNAME(SYSZVOLS) /* AUTO TAPE SWITCHING AND VOLUMES */ /* */ /********************************************************************/ /* CA ACF2 */ /********************************************************************/ RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(ACF.ACF2.LOGONIDS) RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(ACF.ACF2.ALTLIDS) RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(ACF.ACF2.RULES) RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(ACF.ACF2.ALTRULES) RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(ACF.ACF2.INFOSTG) RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSDSN) RNAME(ACF.ACF2.ALTINFO) RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSVSAM) RNAME(ACF.ACF2) RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSDSN) RNAME(ACF.ACF2) /* */ -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Norman Hollander Sent: Monday, June 29, 2020 1:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: GRSRNL Example Been a while since I've done this. Anyone have a good example of a GRSRNL for a Sysplex? DASD only shared among the Sysplex members. TIA! zN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- Please note: This message originated outside your organization. Please use caution when opening links or attachments. ---------------------------------------------------------------------- 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
