Batch REXX, Consoles & SYSPLEX
I have a REXX Exec that is run in a batch job, that is invoked from a MPF exit after the 'BPXI004I OMVS Initialization Complete' message is displayed. The REXX Exec determines what processor and LPAR it is in and issues a 'CONSOLE ACTIVATE', 'CONSOLE SYSCMD... (to start the appropriate TCPIP)' and a 'CONSOLE DEACTIVATE'. The 'CONSOLE' command is specified in the IKJTSOxx parmlib member. The modules IKJCNXCI (CONSPROF authority for TSO User) and IKJCNXAC (CONSOLE authority for TSO User) are in SYS1.LPALIB. This works flawlessly in a non-SYSPLEX environment. In a SYSPLEX(GRS) environment the REXX Exec comes back with; IKJ55303I CONSOLE command terminated. MCSOPER input parm contains error. RC=x'10', REASON CODE=x'38', which means "command associated in OPERPARM segment not valid". As I am on a diminishing time line, any guidance and assistance from those who work in a real world Sysplex and have 'been there and done that', will be appreciated. Thanks, S. Veryl Ellis -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICHRDSNT Table. RACF in sysplex communications mode
Yep. Got that. My confusion was that it wasn't immediately obvious that once the system was IPLed it was in Sysplex communications mode. 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 Friday, May 24, 2019 8:56 AM, Allan Staller wrote: > I just went through this. There are 2 "levels" of RACF sharing > SYSPLEX Data Sharing (CF required) and SYSPLEX Communications (no CF > required). > > SYSPLEX Data Sharing is b'10001100' (x'8C') > SYSPLEX Communication is b'10001000' (x'88'). > > What you have set up is SYSPLEX Communication. RACF will not be using the CF > in this mode. > I believe the bits are described in the data areas manual for ICHRDSNT. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Mark Jacobs > Sent: Thursday, May 23, 2019 5:38 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: ICHRDSNT Table. RACF in sysplex communications mode > > Since there's more activity here than in the RACF mailing list, thought I'd > ask here first. I changed the flag byte in the RACF dataset names table to > enable sysplex communications today, and ipled the first system with the > changed table. Even though it's not talking to another system yet via XCF, I > had thought the RVARY LIST command issued on that system would have told me > that it's enabled for sysplex communications. I've verified that this system > is using the updated load module. > > rvary list > ICH15013I RACF DATABASE STATUS: > ACTIVE USE NUM VOLUME DATASET > > YES PRIM 1 SYS001 SYS1.PROD.RACF > YES BACK 1 SYS011 SYS1.PROD.RACF.BACKUP > ICH15020I RVARY COMMAND HAS FINISHED PROCESSING. > READY > > Here's what I set in the table; > > ICHRDSNT CSECT > DC AL1(1) INDICATES ONE RACF DATA SET > DC CL44'SYS1.PROD.RACF' PRIMARY RACF DS NAME > DC CL44'SYS1.PROD.RACF.BACKUP' BACKUP RACF DS NAME > DC AL1(255) # OF RESIDENT DATA BLOCKS > > - DCB'01234567' BIT COUNT >DCB'10001000' SYSPLEX, NON DATASHARING >END > > > > Any ideas? > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.com=02|01|allan.staller%40HCL.COM|93996759aae54386463508d6dfcf5db6|189de737c93a4f5a8b686f4ca9941912|0|0|636942479084451598=%2FHIUk2TQxS0YeB15GLXH%2BkeBg6%2FAJTzJyp%2FjKrzEJ0s%3D=0 > > > > 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
Re: ICHRDSNT Table. RACF in sysplex communications mode
I just went through this. There are 2 "levels" of RACF sharing SYSPLEX Data Sharing (CF required) and SYSPLEX Communications (no CF required). SYSPLEX Data Sharing is b'10001100' (x'8C') SYSPLEX Communication is b'10001000' (x'88'). What you have set up is SYSPLEX Communication. RACF will not be using the CF in this mode. I believe the bits are described in the data areas manual for ICHRDSNT. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Jacobs Sent: Thursday, May 23, 2019 5:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: ICHRDSNT Table. RACF in sysplex communications mode Since there's more activity here than in the RACF mailing list, thought I'd ask here first. I changed the flag byte in the RACF dataset names table to enable sysplex communications today, and ipled the first system with the changed table. Even though it's not talking to another system yet via XCF, I had thought the RVARY LIST command issued on that system would have told me that it's enabled for sysplex communications. I've verified that this system is using the updated load module. rvary list ICH15013I RACF DATABASE STATUS: ACTIVE USE NUM VOLUME DATASET -- --- --- -- --- YES PRIM 1 SYS001 SYS1.PROD.RACF YES BACK 1 SYS011 SYS1.PROD.RACF.BACKUP ICH15020I RVARY COMMAND HAS FINISHED PROCESSING. READY Here's what I set in the table; ICHRDSNT CSECT DCAL1(1) INDICATES ONE RACF DATA SET DCCL44'SYS1.PROD.RACF' PRIMARY RACF DS NAME DCCL44'SYS1.PROD.RACF.BACKUP' BACKUP RACF DS NAME DCAL1(255) # OF RESIDENT DATA BLOCKS *DCB'01234567' BIT COUNT DCB'10001000' SYSPLEX, NON DATASHARING END Any ideas? Sent from [ProtonMail](https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotonmail.comdata=02%7C01%7Callan.staller%40HCL.COM%7C93996759aae54386463508d6dfcf5db6%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636942479084451598sdata=2L65kcSXzRAvREzt6rUY2bgAWxqdHRQ%2F4Ln%2FphzAytM%3Dreserved=0), Swiss-based encrypted email. GPG Public Key - https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.comdata=02%7C01%7Callan.staller%40HCL.COM%7C93996759aae54386463508d6dfcf5db6%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C636942479084451598sdata=%2FHIUk2TQxS0YeB15GLXH%2BkeBg6%2FAJTzJyp%2FjKrzEJ0s%3Dreserved=0 -- 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: ICHRDSNT Table. RACF in sysplex communications mode
Structures are setup, but since datasharing isn't yet activated they're not allocated. 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 Friday, May 24, 2019 6:42 AM, Elardus Engelbrecht wrote: > Mark Jacobs wrote: > > > Since there's more activity here than in the RACF mailing list, thought I'd > > ask here first. I changed the flag byte in the RACF dataset names table to > > enable sysplex communications today, and ipled the first system with the > > changed table. Even though it's not talking to another system yet via XCF, > > I had thought the RVARY LIST command issued on that system would have told > > me that it's enabled for sysplex communications. I've verified that this > > system is using the updated load module. > > Are your structures setup and activated? > > Do a D XCF,STRUCTURE to see them. > > ... also issue D XCF,STRUCTURE,STRNAME= > > Check these output: > > . > > STATUS: ALLOCATED > . > > CONNECTION NAME ID VERSION SYSNAME JOBNAME ASID STATE > > IRRP001@ 02 00020058 RACFDS 0017 ACTIVE > > If you don't see it, check your setup of the CF structure. > > > rvary list > > ICH15013I ACCF DATABASE STATUS: > > ACTIVE USE NUM VOLUME DATASET > > > > YES PRIM 1 SYS001 SYS1.PROD.RACF > > YES BACK 1 SYS011 SYS1.PROD.RACF.BACKUP > > ICH15020I RVARY COMMAND HAS FINISHED PROCESSING. > > > Here's what I set in the table; > > > ICHRDSNT CSECT > > DC AL1(1) INDICATES ONE RACF DATA SET > > DC CL44'SYS1.PROD.RACF' PRIMARY RACF DS NAME > > DC CL44'SYS1.PROD.RACF.BACKUP' BACKUP RACF DS NAME > > DC AL1(255) # OF RESIDENT DATA BLOCKS > > > > - DCB'01234567' BIT COUNT > > DCB'10001000' SYSPLEX, NON DATASHARING > > END > > > > > > AL1(1) is easy ... ;-) > > > Any ideas? > > I have first X'C8' - 1100 1000 during all the initial setup of CF and the > structures. > > Then IPL, etc. where you get SysPlex and NON DATASHARING. > > Then after verifying all is Ok and you can get DATASHARING working, then I > code in X'CC' - 1100 1100 (and then IPL at a convenient time) > > If all is working you should get this: > > MEMBER IS SYSPLEX COMMUNICATIONS ENABLED & IN DATA SHARING MODE. > > Ok, above is perhaps too elaborate, but I was just very cautious and have > practised on a sandbox SysPlex. > > Good luck! > > Groete / Greetings > Elardus Engelbrecht > > > > 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: ICHRDSNT Table. RACF in sysplex communications mode
Mark Jacobs wrote: >Since there's more activity here than in the RACF mailing list, thought I'd >ask here first. I changed the flag byte in the RACF dataset names table to >enable sysplex communications today, and ipled the first system with the >changed table. Even though it's not talking to another system yet via XCF, I >had thought the RVARY LIST command issued on that system would have told me >that it's enabled for sysplex communications. I've verified that this system >is using the updated load module. Are your structures setup and activated? Do a D XCF,STRUCTURE to see them. ... also issue D XCF,STRUCTURE,STRNAME= Check these output: . STATUS: ALLOCATED . CONNECTION NAME ID VERSION SYSNAME JOBNAME ASID STATE -- -- IRRP001@ 02 00020058 RACFDS 0017 ACTIVE If you don't see it, check your setup of the CF structure. >rvary list >ICH15013I ACCF DATABASE STATUS: >ACTIVE USE NUM VOLUME DATASET >-- --- --- -- --- > YES PRIM 1 SYS001 SYS1.PROD.RACF > YES BACK 1 SYS011 SYS1.PROD.RACF.BACKUP >ICH15020I RVARY COMMAND HAS FINISHED PROCESSING. >Here's what I set in the table; >ICHRDSNT CSECT > DCAL1(1) INDICATES ONE RACF DATA SET > DCCL44'SYS1.PROD.RACF' PRIMARY RACF DS NAME > DCCL44'SYS1.PROD.RACF.BACKUP' BACKUP RACF DS NAME > DCAL1(255) # OF RESIDENT DATA BLOCKS >*DCB'01234567' BIT COUNT > DCB'10001000' SYSPLEX, NON DATASHARING > END AL1(1) is easy ... ;-) >Any ideas? I have first X'C8' - 1100 1000 during all the initial setup of CF and the structures. Then IPL, etc. where you get SysPlex and NON DATASHARING. Then after verifying all is Ok and you can get DATASHARING working, then I code in X'CC' - 1100 1100 (and then IPL at a convenient time) If all is working you should get this: MEMBER IS SYSPLEX COMMUNICATIONS ENABLED & IN DATA SHARING MODE. Ok, above is perhaps too elaborate, but I was just very cautious and have practised on a sandbox SysPlex. Good luck! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ICHRDSNT Table. RACF in sysplex communications mode
Once we're all 2.3 or higher we'll look at it. I'm working at a software development company now and we need to run many different levels of z/OS and other products. Makes it interesting for sure. Mark Jacobs Sent from ProtonMail mobile Original Message On May 23, 2019, 7:23 PM, Mark Zelden wrote: > Nothing to do with your question, but I'd though I'd mention if you at z/OS > 2.3 you can > use the IRRPRMxx parmlib member instead of the assembled / linked table. One > less usermod. :-) There is a utility called DSNT2PRM that you can download > that > will create the member for you. It also replaces the range table which I had > in > one of my sysplexes. > > The only "bad thing" that I wish IBM would change (are you listening IBM) is > that there > are no messages at IPL time from RACF that the parmlib member is what was > used. > The only proof is the "IEE252I MEMBER IRRPRMxx FOUND IN " message. > Of course deleting the linked table and IPLing is also proof, but I wanted > something > more after I migrated to the parmlib member before removing the linked table > as > a cleanup step. > > Best Regards, > > Mark > -- > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS > ITIL v3 Foundation Certified > mailto:m...@mzelden.com > Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html > Systems Programming expert at http://search390.techtarget.com/ateExperts/ > > On Thu, 23 May 2019 22:51:13 +, Mark Jacobs > wrote: > >>Never mind. I found out how to verify. >> >> -D XCF,GRP,IRRXCF00 >> IXC332I 18.48.52 DISPLAY XCF 551 >> GROUP IRRXCF00: SYSD >> >>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 Thursday, May 23, 2019 6:37 PM, Mark Jacobs >><0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: >> >>> Since there's more activity here than in the RACF mailing list, thought I'd >>> ask here first. I changed the flag byte in the RACF dataset names table to >>> enable sysplex communications today, and ipled the first system with the >>> changed table. Even though it's not talking to another system yet via XCF, >>> I had thought the RVARY LIST command issued on that system would have told >>> me that it's enabled for sysplex communications. I've verified that this >>> system is using the updated load module. >>> >>> rvary list >>> ICH15013I RACF DATABASE STATUS: >>> ACTIVE USE NUM VOLUME DATASET >>> >>> YES PRIM 1 SYS001 SYS1.PROD.RACF >>> YES BACK 1 SYS011 SYS1.PROD.RACF.BACKUP >>> ICH15020I RVARY COMMAND HAS FINISHED PROCESSING. >>> READY >>> >>> Here's what I set in the table; >>> >>> ICHRDSNT CSECT >>> DC AL1(1) INDICATES ONE RACF DATA SET >>> DC CL44'SYS1.PROD.RACF' PRIMARY RACF DS NAME >>> DC CL44'SYS1.PROD.RACF.BACKUP' BACKUP RACF DS NAME >>> DC AL1(255) # OF RESIDENT DATA BLOCKS >>> >>> - DC B'01234567' BIT COUNT >>> DC B'10001000' SYSPLEX, NON DATASHARING >>> END >>> >>> >>> >>> Any ideas? >>> >>> Sent from ProtonMail, Swiss-based encrypted email. >>> >>> GPG Public Key - >>> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com >>> >>> >>> >>> 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: ICHRDSNT Table. RACF in sysplex communications mode
Nothing to do with your question, but I'd though I'd mention if you at z/OS 2.3 you can use the IRRPRMxx parmlib member instead of the assembled / linked table. One less usermod. :-) There is a utility called DSNT2PRM that you can download that will create the member for you. It also replaces the range table which I had in one of my sysplexes. The only "bad thing" that I wish IBM would change (are you listening IBM) is that there are no messages at IPL time from RACF that the parmlib member is what was used. The only proof is the "IEE252I MEMBER IRRPRMxx FOUND IN " message. Of course deleting the linked table and IPLing is also proof, but I wanted something more after I migrated to the parmlib member before removing the linked table as a cleanup step. Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ On Thu, 23 May 2019 22:51:13 +, Mark Jacobs wrote: >Never mind. I found out how to verify. > > -D XCF,GRP,IRRXCF00 > IXC332I 18.48.52 DISPLAY XCF 551 > GROUP IRRXCF00:SYSD > >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 Thursday, May 23, 2019 6:37 PM, Mark Jacobs ><0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > >> Since there's more activity here than in the RACF mailing list, thought I'd >> ask here first. I changed the flag byte in the RACF dataset names table to >> enable sysplex communications today, and ipled the first system with the >> changed table. Even though it's not talking to another system yet via XCF, I >> had thought the RVARY LIST command issued on that system would have told me >> that it's enabled for sysplex communications. I've verified that this system >> is using the updated load module. >> >> rvary list >> ICH15013I RACF DATABASE STATUS: >> ACTIVE USE NUM VOLUME DATASET >> >> YES PRIM 1 SYS001 SYS1.PROD.RACF >> YES BACK 1 SYS011 SYS1.PROD.RACF.BACKUP >> ICH15020I RVARY COMMAND HAS FINISHED PROCESSING. >> READY >> >> Here's what I set in the table; >> >> ICHRDSNT CSECT >> DC AL1(1) INDICATES ONE RACF DATA SET >> DC CL44'SYS1.PROD.RACF' PRIMARY RACF DS NAME >> DC CL44'SYS1.PROD.RACF.BACKUP' BACKUP RACF DS NAME >> DC AL1(255) # OF RESIDENT DATA BLOCKS >> >> - DCB'01234567' BIT COUNT >>DCB'10001000' SYSPLEX, NON DATASHARING >>END >> >> >> >> Any ideas? >> >> Sent from ProtonMail, Swiss-based encrypted email. >> >> GPG Public Key - >> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com >> >> >> >> 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: ICHRDSNT Table. RACF in sysplex communications mode
Never mind. I found out how to verify. -D XCF,GRP,IRRXCF00 IXC332I 18.48.52 DISPLAY XCF 551 GROUP IRRXCF00:SYSD 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 Thursday, May 23, 2019 6:37 PM, Mark Jacobs <0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote: > Since there's more activity here than in the RACF mailing list, thought I'd > ask here first. I changed the flag byte in the RACF dataset names table to > enable sysplex communications today, and ipled the first system with the > changed table. Even though it's not talking to another system yet via XCF, I > had thought the RVARY LIST command issued on that system would have told me > that it's enabled for sysplex communications. I've verified that this system > is using the updated load module. > > rvary list > ICH15013I RACF DATABASE STATUS: > ACTIVE USE NUM VOLUME DATASET > > YES PRIM 1 SYS001 SYS1.PROD.RACF > YES BACK 1 SYS011 SYS1.PROD.RACF.BACKUP > ICH15020I RVARY COMMAND HAS FINISHED PROCESSING. > READY > > Here's what I set in the table; > > ICHRDSNT CSECT > DC AL1(1) INDICATES ONE RACF DATA SET > DC CL44'SYS1.PROD.RACF' PRIMARY RACF DS NAME > DC CL44'SYS1.PROD.RACF.BACKUP' BACKUP RACF DS NAME > DC AL1(255) # OF RESIDENT DATA BLOCKS > > - DCB'01234567' BIT COUNT >DCB'10001000' SYSPLEX, NON DATASHARING >END > > > > Any ideas? > > Sent from ProtonMail, Swiss-based encrypted email. > > GPG Public Key - > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com > > > > 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
ICHRDSNT Table. RACF in sysplex communications mode
Since there's more activity here than in the RACF mailing list, thought I'd ask here first. I changed the flag byte in the RACF dataset names table to enable sysplex communications today, and ipled the first system with the changed table. Even though it's not talking to another system yet via XCF, I had thought the RVARY LIST command issued on that system would have told me that it's enabled for sysplex communications. I've verified that this system is using the updated load module. rvary list ICH15013I RACF DATABASE STATUS: ACTIVE USE NUM VOLUME DATASET -- --- --- -- --- YES PRIM 1 SYS001 SYS1.PROD.RACF YES BACK 1 SYS011 SYS1.PROD.RACF.BACKUP ICH15020I RVARY COMMAND HAS FINISHED PROCESSING. READY Here's what I set in the table; ICHRDSNT CSECT DCAL1(1) INDICATES ONE RACF DATA SET DCCL44'SYS1.PROD.RACF' PRIMARY RACF DS NAME DCCL44'SYS1.PROD.RACF.BACKUP' BACKUP RACF DS NAME DCAL1(255) # OF RESIDENT DATA BLOCKS *DCB'01234567' BIT COUNT DCB'10001000' SYSPLEX, NON DATASHARING END Any ideas? Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about batch programs using EXCI in a parallel Sysplex
On Fri, 8 Mar 2019 08:16:10 +1300, Laurence Chiu wrote: >But we have a number of batch jobs that calls CICS transactions in those >regions and we are wondering what happens if the batch job is running in a >LPAR where the region isn't. > >Will it abend or will MRO work out to send the work to the region running >in the other LPAR? I just ran a quick test and was able to see the effect of an EXCI batch running on one LPAR in the CICS running on another. Don't know what the requirements are in terms of MRO and/or VTAM definitions, though. Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about batch programs using EXCI in a parallel Sysplex
I think you'll want to ask this question in the CICS list. https://listserv.uga.edu/cgi-bin/wa?A0=CICS-L Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Question about batch programs using EXCI in a parallel Sysplex
Looking at implementing a parallel Sysplex primarily to support CICS regions that need to be up on more than one LPAR. But some of the regions are not Sysplex compliant so we'll run them on one LPAR only. But we have a number of batch jobs that calls CICS transactions in those regions and we are wondering what happens if the batch job is running in a LPAR where the region isn't. Will it abend or will MRO work out to send the work to the region running in the other LPAR? Thanks Larry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Multi-Site Parallel Sysplex
I think Dave will provide better information but I'm researching the same thing myself and found this document useful. http://www.redbooks.ibm.com/redpieces/abstracts/sg248241.html?Open On Sat, Mar 2, 2019, 9:12 AM Mark Regan wrote: > Cross posting to both IBM-MAIN and IBMTCP-L > > I'm helping a coworker (she supports IBM Comm Server) whose is seeking > information about companies or information that could be shared to assist > with > solution building to provide a Multi-Site Parallel Sysplex implementation > in our > infrastructure, utilizing GDPS-PPRC, two sites. Would anyone have > reference too > or know how we would proceed to find a company that has already done this > type > of implementation, that we could speak with? We are looking for > information in > regards to the network solution for IP spanning across two sites mostly. > > We are basically trying to find out how they implemented MSPS across two > sites > and if they had issues or concerns. IBM has not provided a company to > speak > with, so we are fishing on our own. > > Below is some content to what our network architect is seeking information > about, as he stated it would be good to have a source to speak with > outside of > IBM. > > Considerations for Multisite Sysplex Data Sharing - > <http://www.redbooks.ibm.com/abstracts/sg247263.html?Open> > http://www.redbooks.ibm.com/abstracts/sg247263.html?Open > Exploiting Parallel Sysplex: A Customer Perspective - > <http://www.redbooks.ibm.com/abstracts/sg247108.html?Open> > http://www.redbooks.ibm.com/abstracts/sg247108.html?Open > > Communications Server also has a Share presentation that has a page on > stateful > firewalls that may be of interest as well - > < > https://events.share.org/Summer2017/Public/SessionDetails.aspx?FromPage=Session > s.aspx=3102=28 > <https://events.share.org/Summer2017/Public/SessionDetails.aspx?FromPage=Sessions.aspx=3102=28> > > > > https://events.share.org/Summer2017/Public/SessionDetails.aspx?FromPage=Sessions > .aspx=3102=28 > <https://events.share.org/Summer2017/Public/SessionDetails.aspx?FromPage=Sessions.aspx=3102=28> > > For a customer reference, we are trying to get in contact with an IBM GDPS > SME. > I believe finding a customer who recently implemented GDPS PPRC or Metro > Mirror > would be appropriate. However, we are not sure if we will be able to > locate a > customer before the end of the week. I will let you know when I do. > > Regards, > > Mark T. Regan, K8MTR > CTO1 USNR-Retired, 1969-1991 > > > -- > 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
Multi-Site Parallel Sysplex
Cross posting to both IBM-MAIN and IBMTCP-L I'm helping a coworker (she supports IBM Comm Server) whose is seeking information about companies or information that could be shared to assist with solution building to provide a Multi-Site Parallel Sysplex implementation in our infrastructure, utilizing GDPS-PPRC, two sites. Would anyone have reference too or know how we would proceed to find a company that has already done this type of implementation, that we could speak with? We are looking for information in regards to the network solution for IP spanning across two sites mostly. We are basically trying to find out how they implemented MSPS across two sites and if they had issues or concerns. IBM has not provided a company to speak with, so we are fishing on our own. Below is some content to what our network architect is seeking information about, as he stated it would be good to have a source to speak with outside of IBM. Considerations for Multisite Sysplex Data Sharing - <http://www.redbooks.ibm.com/abstracts/sg247263.html?Open> http://www.redbooks.ibm.com/abstracts/sg247263.html?Open Exploiting Parallel Sysplex: A Customer Perspective - <http://www.redbooks.ibm.com/abstracts/sg247108.html?Open> http://www.redbooks.ibm.com/abstracts/sg247108.html?Open Communications Server also has a Share presentation that has a page on stateful firewalls that may be of interest as well - <https://events.share.org/Summer2017/Public/SessionDetails.aspx?FromPage=Session s.aspx=3102=28> https://events.share.org/Summer2017/Public/SessionDetails.aspx?FromPage=Sessions .aspx=3102=28 For a customer reference, we are trying to get in contact with an IBM GDPS SME. I believe finding a customer who recently implemented GDPS PPRC or Metro Mirror would be appropriate. However, we are not sure if we will be able to locate a customer before the end of the week. I will let you know when I do. Regards, Mark T. Regan, K8MTR CTO1 USNR-Retired, 1969-1991 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: API for accessing available DASD to each LPAR in a sysplex.
On Wed, 12 Dec 2018 19:33:14 -0500, Matt Hogstrom wrote: >I’m looking to detect differences across the LPARs in terms of shared storage >and want to pull together an aggregate view. I wonder if an API into the active IODF would help. I don't know if such is available. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: API for accessing available DASD to each LPAR in a sysplex.
Thanks Scott and Steve, this will get me started. Matt Hogstrom PGP Key: 0x90ECB270 “You can’t put too much water in a nuclear reactor" > On Dec 12, 2018, at 7:24 PM, Steve Horein wrote: > > You may want to try: IBMzOS_LogicalDisk > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.cfzu100/ibmzos_logicaldisk.htm > > On Wed, Dec 12, 2018 at 12:41 PM Matt Hogstrom wrote: > >> Is there a callable API that returns the list of online volumes to LPARs >> in a Sysplex? I assume one could route a command and write scripts. I’m >> looking for an API that can be incorporated into a program where all the >> searching and cataloging is done. >> >> Matt Hogstrom >> m...@hogstrom.org >> PGP Key: 0x90ECB270 >> >> “It may be cognitive, but, it ain’t intuitive." >> — Hogstrom >> >> >> -- >> 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: API for accessing available DASD to each LPAR in a sysplex.
I’m looking to detect differences across the LPARs in terms of shared storage and want to pull together an aggregate view. Matt Hogstrom PGP Key: 0x90ECB270 “Quantity has a quality all its own.” — Joseph Stalin > On Dec 12, 2018, at 4:23 PM, Tony Harminc wrote: > > running -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: API for accessing available DASD to each LPAR in a sysplex.
You may want to try: IBMzOS_LogicalDisk https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.cfzu100/ibmzos_logicaldisk.htm On Wed, Dec 12, 2018 at 12:41 PM Matt Hogstrom wrote: > Is there a callable API that returns the list of online volumes to LPARs > in a Sysplex? I assume one could route a command and write scripts. I’m > looking for an API that can be incorporated into a program where all the > searching and cataloging is done. > > Matt Hogstrom > m...@hogstrom.org > PGP Key: 0x90ECB270 > > “It may be cognitive, but, it ain’t intuitive." > — Hogstrom > > > -- > 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: API for accessing available DASD to each LPAR in a sysplex.
On Wed, 12 Dec 2018 at 13:41, Matt Hogstrom wrote: > Is there a callable API that returns the list of online volumes to LPARs > in a Sysplex? I assume one could route a command and write scripts. I’m > looking for an API that can be incorporated into a program where all the > searching and cataloging is done. > Just to be clear here... You're looking for an API that will tell you about volumes online to *other* LPARs as well as the one you're running in? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: API for accessing available DASD to each LPAR in a sysplex.
On Wed, 12 Dec 2018 13:41:24 -0500, Matt Hogstrom wrote: >Is there a callable API that returns the list of online volumes to LPARs in a >Sysplex? I assume one could route a command and write scripts. I’m looking >for an API that can be incorporated into a program where all the searching and >cataloging is done. > >Matt Hogstrom >m...@hogstrom.org >PGP Key: 0x90ECB270 > >“It may be cognitive, but, it ain’t intuitive." >— Hogstrom > For an application API, consider CVAF (or DADSM) -- these services have been around for decades; handles dynamic configuration changes, pinned UCBs, and the like. As for "catalog information", likely need to interrogate reading BCS, VVDS components and post-process results for correlation, while also need to consider "shared" vs "dedicated" device configuration scenario (i.e., duplicate information handling). Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: API for accessing available DASD to each LPAR in a sysplex.
IDCAMS DCOLECT VOLS(*) will give you the volume data you need. Other record types can give you the cataloged data sets. On Wed, Dec 12, 2018 at 12:41 PM Matt Hogstrom wrote: > > Is there a callable API that returns the list of online volumes to LPARs in a > Sysplex? I assume one could route a command and write scripts. I’m looking > for an API that can be incorporated into a program where all the searching > and cataloging is done. > > Matt Hogstrom > m...@hogstrom.org > PGP Key: 0x90ECB270 > > “It may be cognitive, but, it ain’t intuitive." > — Hogstrom > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
API for accessing available DASD to each LPAR in a sysplex.
Is there a callable API that returns the list of online volumes to LPARs in a Sysplex? I assume one could route a command and write scripts. I’m looking for an API that can be incorporated into a program where all the searching and cataloging is done. Matt Hogstrom m...@hogstrom.org PGP Key: 0x90ECB270 “It may be cognitive, but, it ain’t intuitive." — Hogstrom -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Un-Sysplex a zOS System
It would be better to disable cics applications, remove tn3270 from desktops that no longer require access, and disable apps calling mainframe. Rob Schramm On Thu, Aug 30, 2018, 7:08 AM Mark Jacobs - Listserv < mark.jac...@custserv.com> wrote: > Thanks to everyone. I'm going to recommend to management that we don't go > down this path, and use a more reasonable one. > > Our new owners are closing our division, which includes shutting down the > mainframe environment for most things. One or two applications need to have > a mainframe home for a while after everything else is shutdown, hence > research on whether it's feasible to begin a system split prior to > everything else being shut down. > > Mark Jacobs > > Elardus Engelbrecht wrote on 8/30/18 2:35 AM: > > Mark Jacobs - Listserv wrote: > > > > We're in a parallel sysplex, sharing most everything, and need to begin > planning activities to remove one system from the sysplex, while continuing > to use it to run a subset of our current workload. > > > > Why? You lose many benefits of being in a SysPlex, but do you have > workload/performance problems? Do you have applications being migrated off > mainframe? > > > Alternative. Create a NEW Sysplex and build up your new LPAR inside it. > > > > > Some of the things we need to consider are; > > > > If you want to move a LPAR off the Sysplex, consider isolating and > duplicate everything. > > > > > * PDS/e Sharing > * Catalogs (we're ECS shared now) > > > > No sharing of catalogs. Just that unless you like taking risks. > > > > > * Shared DASD > > > > You can share DASD and its contents, but just make sure > allocation/deletion of datasets are limited/restricted. Say you create a > dsn A.B.C in one Sysplex, then you cannot delete it in other Sysplex or > LPAR outside the original Sysplex. > > > > > * RACF Database Sharing (Sysplex Enabled) > > > > Do not share RACF DB outside a Sysplex. Turn of sharing completely and > only enable that for remaining LPARs inside the Sysplex. You will need a > separate ICHRDSNT module for each LPAR. > > Also, consider separate naming standards for each LPAR inside/outside your > Sysplex. > > > > > * JES2 Checkpoint in CF > > > > You have enough volsers for all the duplicate datasets? You need a set of > Checkpoint for each unshared JES2 datasets. The same goes for > HSM/SMS/SMF/Automation software/Tape Management system/etc. > > > > > * ZFS File Systems? (This system is not in a shared OMVS Environment) > > > > Consider creating the zFS for each LPAR without sharing of course. > > > > > I'd like people to shoot things at me that I might have missed while I > keep on looking myself. > > > > Good luck. You will need it. > > Groete / Greetings > Elardus Engelbrecht > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> > with the message: INFO IBM-MAIN > > > > Please be alert for any emails that may ask you for login information or > directs you to login via a link. If you believe this message is a phish or > aren't sure whether this message is trustworthy, please send the original > message as an attachment to 'phish...@meredith.com phish...@meredith.com>'. > > > > -- > > Mark Jacobs > Time Customer Service > Global Technology Services > > The standard you walk past is the standard you accept. > Lt. Gen. David Morrison > > > This electronic message, including any attachments, may contain > proprietary, confidential or privileged information for the sole use of the > intended recipient(s). You are hereby notified that any unauthorized > disclosure, copying, distribution, or use of this message is prohibited. If > you have received this message in error, please immediately notify the > sender by reply e-mail and delete it. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Rob Schramm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Un-Sysplex a zOS System
Just dial down the defined capacity of each LPAR as work leaves the mainframe. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Un-Sysplex a zOS System
Thanks to everyone. I'm going to recommend to management that we don't go down this path, and use a more reasonable one. Our new owners are closing our division, which includes shutting down the mainframe environment for most things. One or two applications need to have a mainframe home for a while after everything else is shutdown, hence research on whether it's feasible to begin a system split prior to everything else being shut down. Mark Jacobs Elardus Engelbrecht wrote on 8/30/18 2:35 AM: Mark Jacobs - Listserv wrote: We're in a parallel sysplex, sharing most everything, and need to begin planning activities to remove one system from the sysplex, while continuing to use it to run a subset of our current workload. Why? You lose many benefits of being in a SysPlex, but do you have workload/performance problems? Do you have applications being migrated off mainframe? Alternative. Create a NEW Sysplex and build up your new LPAR inside it. Some of the things we need to consider are; If you want to move a LPAR off the Sysplex, consider isolating and duplicate everything. * PDS/e Sharing * Catalogs (we're ECS shared now) No sharing of catalogs. Just that unless you like taking risks. * Shared DASD You can share DASD and its contents, but just make sure allocation/deletion of datasets are limited/restricted. Say you create a dsn A.B.C in one Sysplex, then you cannot delete it in other Sysplex or LPAR outside the original Sysplex. * RACF Database Sharing (Sysplex Enabled) Do not share RACF DB outside a Sysplex. Turn of sharing completely and only enable that for remaining LPARs inside the Sysplex. You will need a separate ICHRDSNT module for each LPAR. Also, consider separate naming standards for each LPAR inside/outside your Sysplex. * JES2 Checkpoint in CF You have enough volsers for all the duplicate datasets? You need a set of Checkpoint for each unshared JES2 datasets. The same goes for HSM/SMS/SMF/Automation software/Tape Management system/etc. * ZFS File Systems? (This system is not in a shared OMVS Environment) Consider creating the zFS for each LPAR without sharing of course. I'd like people to shoot things at me that I might have missed while I keep on looking myself. Good luck. You will need it. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message: INFO IBM-MAIN Please be alert for any emails that may ask you for login information or directs you to login via a link. If you believe this message is a phish or aren't sure whether this message is trustworthy, please send the original message as an attachment to 'phish...@meredith.com<mailto:phish...@meredith.com>'. -- Mark Jacobs Time Customer Service Global Technology Services The standard you walk past is the standard you accept. Lt. Gen. David Morrison This electronic message, including any attachments, may contain proprietary, confidential or privileged information for the sole use of the intended recipient(s). You are hereby notified that any unauthorized disclosure, copying, distribution, or use of this message is prohibited. If you have received this message in error, please immediately notify the sender by reply e-mail and delete it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Un-Sysplex a zOS System
Mark Jacobs - Listserv wrote: >We're in a parallel sysplex, sharing most everything, and need to begin >planning activities to remove one system from the sysplex, while continuing to >use it to run a subset of our current workload. Why? You lose many benefits of being in a SysPlex, but do you have workload/performance problems? Do you have applications being migrated off mainframe? Alternative. Create a NEW Sysplex and build up your new LPAR inside it. >Some of the things we need to consider are; If you want to move a LPAR off the Sysplex, consider isolating and duplicate everything. > * PDS/e Sharing > * Catalogs (we're ECS shared now) No sharing of catalogs. Just that unless you like taking risks. > * Shared DASD You can share DASD and its contents, but just make sure allocation/deletion of datasets are limited/restricted. Say you create a dsn A.B.C in one Sysplex, then you cannot delete it in other Sysplex or LPAR outside the original Sysplex. > * RACF Database Sharing (Sysplex Enabled) Do not share RACF DB outside a Sysplex. Turn of sharing completely and only enable that for remaining LPARs inside the Sysplex. You will need a separate ICHRDSNT module for each LPAR. Also, consider separate naming standards for each LPAR inside/outside your Sysplex. > * JES2 Checkpoint in CF You have enough volsers for all the duplicate datasets? You need a set of Checkpoint for each unshared JES2 datasets. The same goes for HSM/SMS/SMF/Automation software/Tape Management system/etc. > * ZFS File Systems? (This system is not in a shared OMVS Environment) Consider creating the zFS for each LPAR without sharing of course. >I'd like people to shoot things at me that I might have missed while I keep on >looking myself. Good luck. You will need it. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Un-Sysplex a zOS System
My easy guesses 1) Prepping to sell off a business unit 2) separation dev/test from prod or some version of a compliance separation Not so serious guess 3) manager subscribes to PHB (pointy hair boss) Magazine and thinks that 1 less system will make sysplex lighter Out there.. maybe 4) some weird contractual agreement Rob Schramm On Wed, Aug 29, 2018, 6:15 PM Steve Smith wrote: > I don't claim the experience to understand *all* the ramifications, but > Jerry's idea is the first thing that occurred to me. > > sas > > > On 8/29/2018 17:34, Jerry Whitteridge wrote: > > I agree with Skip - the risk in pulling apart a Sysplex is high, where to > > > > stand up a new stand-alone system will ensure the isolation required. I'd > > > > build a new system and move the work as needed to it. > > > > > > > > Jerry Whitteridge > > > > Delivery Manager / Mainframe Architect > > > > GTS - Safeway Account > > > > 602 527 4871 Mobile > > > > jerry.whitteri...@ibm.com > > > > > > > > IBM Services > > > > > ...further snipped mainly because various email processing has turned it > into garbage. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Rob Schramm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Un-Sysplex a zOS System
I don't claim the experience to understand *all* the ramifications, but Jerry's idea is the first thing that occurred to me. sas On 8/29/2018 17:34, Jerry Whitteridge wrote: I agree with Skip - the risk in pulling apart a Sysplex is high, where to stand up a new stand-alone system will ensure the isolation required. I'd build a new system and move the work as needed to it. Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services ...further snipped mainly because various email processing has turned it into garbage. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Un-Sysplex a zOS System
I agree with Skip - the risk in pulling apart a Sysplex is high, where to stand up a new stand-alone system will ensure the isolation required. I'd build a new system and move the work as needed to it. Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services IBM Mainframe Discussion List wrote on 08/29/2018 02:14:37 PM: > From: Jesse 1 Robinson > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 08/29/2018 02:15 PM > Subject: Re: Un-Sysplex a zOS System > Sent by: IBM Mainframe Discussion List > > The issues listed in the original post plus those suggested by > others are potentially *very* serious. I have to ask what benefits > are expected that would justify the risk. Surely sysplex overhead > alone would not be worth damaging a catalog for example. Whose idea is this? > > . > . > 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] On Behalf Of Scott Barry > Sent: Wednesday, August 29, 2018 1:08 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Un-Sysplex a zOS System > > On Wed, 29 Aug 2018 13:57:14 -0400, Mark Jacobs - Listserv > wrote: > > >We're in a parallel sysplex, sharing most everything, and need to > begin planning activities to remove one system from the sysplex, > while continuing to use it to run a subset of our current workload. > > > >Some of the things we need to consider are; > > > > * PDS/e Sharing > > * Catalogs (we're ECS shared now) > > * Shared DASD > > * RACF Database Sharing (Sysplex Enabled) > > * JES2 Checkpoint in CF > > * ZFS File Systems? (This system is not in a shared OMVS Environment) > > > >I'd like people to shoot things at me that I might have missed > while I keep on looking myself. > > > >TIA, > > > >Mark Jacobs > >Time Customer Service > > > Could be a consideration to review/verify - software (contractual > language) licensing, also previous-condition with "shared" system > dependency, then no longer accessible after un-Sysplex? > > Scott Barry > SBBWorks, Inc. > > > -- > 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: Un-Sysplex a zOS System
The issues listed in the original post plus those suggested by others are potentially *very* serious. I have to ask what benefits are expected that would justify the risk. Surely sysplex overhead alone would not be worth damaging a catalog for example. Whose idea is this? . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Barry Sent: Wednesday, August 29, 2018 1:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Un-Sysplex a zOS System On Wed, 29 Aug 2018 13:57:14 -0400, Mark Jacobs - Listserv wrote: >We're in a parallel sysplex, sharing most everything, and need to begin >planning activities to remove one system from the sysplex, while continuing to >use it to run a subset of our current workload. > >Some of the things we need to consider are; > > * PDS/e Sharing > * Catalogs (we're ECS shared now) > * Shared DASD > * RACF Database Sharing (Sysplex Enabled) > * JES2 Checkpoint in CF > * ZFS File Systems? (This system is not in a shared OMVS Environment) > >I'd like people to shoot things at me that I might have missed while I keep on >looking myself. > >TIA, > >Mark Jacobs >Time Customer Service Could be a consideration to review/verify - software (contractual language) licensing, also previous-condition with "shared" system dependency, then no longer accessible after un-Sysplex? Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Un-Sysplex a zOS System
On Wed, 29 Aug 2018 13:57:14 -0400, Mark Jacobs - Listserv wrote: >We're in a parallel sysplex, sharing most everything, and need to begin >planning activities to remove one system from the sysplex, while continuing to >use it to run a subset of our current workload. > >Some of the things we need to consider are; > > * PDS/e Sharing > * Catalogs (we're ECS shared now) > * Shared DASD > * RACF Database Sharing (Sysplex Enabled) > * JES2 Checkpoint in CF > * ZFS File Systems? (This system is not in a shared OMVS Environment) > >I'd like people to shoot things at me that I might have missed while I keep on >looking myself. > >TIA, > >Mark Jacobs >Time Customer Service Could be a consideration to review/verify - software (contractual language) licensing, also previous-condition with "shared" system dependency, then no longer accessible after un-Sysplex? Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Un-Sysplex a zOS System
A little free thinking on my part... All XCF type data sets DFSMS datasets, archiver? DR backup and restore? Tape? ICSF Security rules, security propagation or separation, scheduler and automation, dasd naming SMF processing Monthly reporting for ibm Jes2 to jes2 shipping of jobs and output? Change control - application code, duplicates of anything shared, promotion to multi-environment, data movement between sysplex and non-sysplex Change control for sysprog and promotion of fixes Change IPL doc for operations HTH, Rob On Wed, Aug 29, 2018, 2:16 PM Cameron Conacher wrote: > If you are dropping an LPAR, maybe there are CICSPLEX considerations? > If your CICSPLEX runs in some number of CICS regions and half are in one > LOAR and half in another, then half of them go away because of dropping the > LPAR and you might no longer have an effective CICSPLEX. I mean if the > remaining LPAR hosting your CICSPLEX CICS regions were to fail you would > have no CICS availability. > You probably already considered this. > > Sent from my iPhone > > > On Aug 29, 2018, at 1:57 PM, Mark Jacobs - Listserv < > mark.jac...@custserv.com> wrote: > > > > We're in a parallel sysplex, sharing most everything, and need to begin > planning activities to remove one system from the sysplex, while continuing > to use it to run a subset of our current workload. > > > > Some of the things we need to consider are; > > > > * PDS/e Sharing > > * Catalogs (we're ECS shared now) > > * Shared DASD > > * RACF Database Sharing (Sysplex Enabled) > > * JES2 Checkpoint in CF > > * ZFS File Systems? (This system is not in a shared OMVS Environment) > > > > I'd like people to shoot things at me that I might have missed while I > keep on looking myself. > > > > TIA, > > > > Mark Jacobs > > Time Customer Service > > > > This electronic message, including any attachments, may contain > proprietary, confidential or privileged information for the sole use of the > intended recipient(s). You are hereby notified that any unauthorized > disclosure, copying, distribution, or use of this message is prohibited. If > you have received this message in error, please immediately notify the > sender by reply e-mail and delete it. > > > > -- > > 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 > -- Rob Schramm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Un-Sysplex a zOS System
If you are dropping an LPAR, maybe there are CICSPLEX considerations? If your CICSPLEX runs in some number of CICS regions and half are in one LOAR and half in another, then half of them go away because of dropping the LPAR and you might no longer have an effective CICSPLEX. I mean if the remaining LPAR hosting your CICSPLEX CICS regions were to fail you would have no CICS availability. You probably already considered this. Sent from my iPhone > On Aug 29, 2018, at 1:57 PM, Mark Jacobs - Listserv > wrote: > > We're in a parallel sysplex, sharing most everything, and need to begin > planning activities to remove one system from the sysplex, while continuing > to use it to run a subset of our current workload. > > Some of the things we need to consider are; > > * PDS/e Sharing > * Catalogs (we're ECS shared now) > * Shared DASD > * RACF Database Sharing (Sysplex Enabled) > * JES2 Checkpoint in CF > * ZFS File Systems? (This system is not in a shared OMVS Environment) > > I'd like people to shoot things at me that I might have missed while I keep > on looking myself. > > TIA, > > Mark Jacobs > Time Customer Service > > This electronic message, including any attachments, may contain proprietary, > confidential or privileged information for the sole use of the intended > recipient(s). You are hereby notified that any unauthorized disclosure, > copying, distribution, or use of this message is prohibited. If you have > received this message in error, please immediately notify the sender by reply > e-mail and delete it. > > -- > 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
Un-Sysplex a zOS System
We're in a parallel sysplex, sharing most everything, and need to begin planning activities to remove one system from the sysplex, while continuing to use it to run a subset of our current workload. Some of the things we need to consider are; * PDS/e Sharing * Catalogs (we're ECS shared now) * Shared DASD * RACF Database Sharing (Sysplex Enabled) * JES2 Checkpoint in CF * ZFS File Systems? (This system is not in a shared OMVS Environment) I'd like people to shoot things at me that I might have missed while I keep on looking myself. TIA, Mark Jacobs Time Customer Service This electronic message, including any attachments, may contain proprietary, confidential or privileged information for the sole use of the intended recipient(s). You are hereby notified that any unauthorized disclosure, copying, distribution, or use of this message is prohibited. If you have received this message in error, please immediately notify the sender by reply e-mail and delete it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
To avoid misunderstandings: n*z/OS + m*CF = Parallel Syplex, and
n=1...32, m=1...16.
I don't know what "most people" interpret, and without some sociological
survey. My survey told me that no one of my family members, neighbours
or local shop seller do understand parallel sysplex as you described. ;-)
Back to technical issues - single z/OS connected to single CF *IS*
parallel sysplex. 5*z/OS + 2*CF is probably better configuration,
especially when the logical images (LPARs) are wisely spread across
several CPCs. Wisely means there no SPOFs, i.e. we should NOT place both
CFs on single CPC.
Regarding VSAM RLS - it is good and very useful for applications that
use VSAM. I migrated (to DB2 table) last VSAM file 10+ years ago and
really do not need RLS. Of course YMMV.
BTW: IMHO properly configured and tuned single-image parallel sysplex
is ~70% of work for monoplex->parallel sysplex migration. Connecting
another z/OS images is (almost) just matter of HCD and repeating
configurations steps. My €0.02
Regards
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2018-07-12 o 08:37, Timothy Sipples pisze:
Radoslaw Skorupka wrote:
RLS require Parallel Sysplex, but not everyone need it.
We should be more precise and careful, to avoid any misunderstandings. VSAM
RLS requires:
* At least one z/OS instance (let's go with exactly one in this example);
* A Coupling Facility (CF)(*), which can even be on the same physical
machine.
And that's it! You do NOT *need* two z/OS LPARs to support VSAM RLS (and
Transactional VSAM). You need two basic ingredients: z/OS (one works) and a
Coupling Facility (one works). For Transactional VSAM you also need the
z/OS DFSMStvs software license.
This IBM redbook ("VSAM Demystified") illustrates VSAM RLS in a z/OS
Monoplex in Section 5.1.4:
http://www.redbooks.ibm.com/redbooks/pdfs/sg246105.pdf
Possible formal definitions aside, most people interpret "Parallel Sysplex"
as including two or more z/OS instances, at least in normal operations. But
no, even during normal operations you only *need* one suitably configured
z/OS instance for VSAM RLS and Transactional VSAM, to be clear. There might
be other reasons to have more than one z/OS instance, but you don't need a
second z/OS instance to run these two highly useful VSAM technologies.
In this example, you, your colleagues, and management might decide,
perfectly sensibly and rationally, that a particular set of CICS
applications (let's suppose) and the services they provide are well suited
to a z/OS Monoplex. You've agreed that they can tolerate the planned
outages required for such tasks as z/OS release upgrades in that LPAR
(perhaps scheduled in conjunction with a DR rehearsal), that the unplanned
outage characteristics (which are still quite excellent, as long as the
site is available) are good enough to meet the business requirements, and
that VSAM RLS and Transactional VSAM technologies are required to make sure
that the applications are providing excellent concurrent online and batch
services, to avoid planned online outages to run batch jobs. If these
parameters meet your needs, great, you're all set. There's a wonderful,
value-packed configuration for you called a z/OS Monoplex with VSAM RLS and
Transactional VSAM. If you change your mind, and management wants a
different service level, no problem! Gracefully shift to a Parallel Sysplex
with two z/OS LPARs on one machine, as one example. Or to any of the many
other configuration options available, as/when they make sense to deliver
on particular end-to-end business service needs.
The white paper clearly describes some structures as demanding
duplexing or third CPC with failure-isolated CF.
Yes, but David Raften is only describing the technical attributes there.
He's not necessarily describing business service outcomes, which require
more analysis. A particular technical result may or may not matter in terms
of delivering on particular end-to-end business service goals. "It
depends."
(*) Which is not quite the same as saying you need a CF *engine*. The CFCC
can run on a general purpose engine, and occasionally that makes sense.
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.
==
--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem
niniejszej wiadomości lub pracownik
Re: Sysplex between two hardware
Radoslaw Skorupka wrote:
>RLS require Parallel Sysplex, but not everyone need it.
We should be more precise and careful, to avoid any misunderstandings. VSAM
RLS requires:
* At least one z/OS instance (let's go with exactly one in this example);
* A Coupling Facility (CF)(*), which can even be on the same physical
machine.
And that's it! You do NOT *need* two z/OS LPARs to support VSAM RLS (and
Transactional VSAM). You need two basic ingredients: z/OS (one works) and a
Coupling Facility (one works). For Transactional VSAM you also need the
z/OS DFSMStvs software license.
This IBM redbook ("VSAM Demystified") illustrates VSAM RLS in a z/OS
Monoplex in Section 5.1.4:
http://www.redbooks.ibm.com/redbooks/pdfs/sg246105.pdf
Possible formal definitions aside, most people interpret "Parallel Sysplex"
as including two or more z/OS instances, at least in normal operations. But
no, even during normal operations you only *need* one suitably configured
z/OS instance for VSAM RLS and Transactional VSAM, to be clear. There might
be other reasons to have more than one z/OS instance, but you don't need a
second z/OS instance to run these two highly useful VSAM technologies.
In this example, you, your colleagues, and management might decide,
perfectly sensibly and rationally, that a particular set of CICS
applications (let's suppose) and the services they provide are well suited
to a z/OS Monoplex. You've agreed that they can tolerate the planned
outages required for such tasks as z/OS release upgrades in that LPAR
(perhaps scheduled in conjunction with a DR rehearsal), that the unplanned
outage characteristics (which are still quite excellent, as long as the
site is available) are good enough to meet the business requirements, and
that VSAM RLS and Transactional VSAM technologies are required to make sure
that the applications are providing excellent concurrent online and batch
services, to avoid planned online outages to run batch jobs. If these
parameters meet your needs, great, you're all set. There's a wonderful,
value-packed configuration for you called a z/OS Monoplex with VSAM RLS and
Transactional VSAM. If you change your mind, and management wants a
different service level, no problem! Gracefully shift to a Parallel Sysplex
with two z/OS LPARs on one machine, as one example. Or to any of the many
other configuration options available, as/when they make sense to deliver
on particular end-to-end business service needs.
>The white paper clearly describes some structures as demanding
>duplexing or third CPC with failure-isolated CF.
Yes, but David Raften is only describing the technical attributes there.
He's not necessarily describing business service outcomes, which require
more analysis. A particular technical result may or may not matter in terms
of delivering on particular end-to-end business service goals. "It
depends."
(*) Which is not quite the same as saying you need a CF *engine*. The CFCC
can run on a general purpose engine, and occasionally that makes sense.
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM Z & LinuxONE,
Multi-Geography
E-Mail: sipp...@sg.ibm.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
Yes, that's true. Fortunately ICF as other specialty engines always run at full speed. That's also reason why one should not use older machines for CF. BTW: Third CPC need not be very expensive. I'm neither IBM sales guy, nor "standalone CF evnagelist", but when you buy two CPCs with CP engines you pay for MIPS then for the frame. In such deal, adding another CPC with zero MIPS can be quite inexpensive when compared to "regular" CPC. And regarding level of redundancy: it's obvious when you use spare wheel you don't have spare. It's the same with CF. AFAIK you can have up to 16 CFs in a sysplex, but usually we protect against SINGLE failure, not coordinated series of failures. That's why we carry only one spare wheel in a car (typically). Regards -- Radoslaw Skorupka Lodz, Poland W dniu 2018-07-11 o 11:34, Richards, Robert B. pisze: Just make sure that if you have a standalone CPC with CFs for that purpose that its engines are as fast as your other CPCs engines. I got into a performance problem 15 years ago when a 9674 was kept around longer that it should have been. You are only as fast as your slowest . Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Wednesday, July 11, 2018 5:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex between two hardware Maybe it's illusory, but that is in David Raften document. Obviously it's cheaper to have 2 CPCs than 3, but it is also cheaper to have 1 CPC than 2. The white paper clearly describes some structures as demanding duplexing or third CPC with failure-isolated CF. == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
Just make sure that if you have a standalone CPC with CFs for that purpose that its engines are as fast as your other CPCs engines. I got into a performance problem 15 years ago when a 9674 was kept around longer that it should have been. You are only as fast as your slowest . Bob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Wednesday, July 11, 2018 5:25 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex between two hardware Maybe it's illusory, but that is in David Raften document. Obviously it's cheaper to have 2 CPCs than 3, but it is also cheaper to have 1 CPC than 2. The white paper clearly describes some structures as demanding duplexing or third CPC with failure-isolated CF. -- Radoslaw Skorupka Lodz, Poland W dniu 2018-07-11 o 01:15, Jesse 1 Robinson pisze: > It's easy to diss a solution as 'budget' when it saves someone *else* money. > The notion that a third CEC for standalone CF is substantially better than > ICF is illusory. If you truly believe that one extra CEC is necessary, then > you really need two extra CECs for CF because there are times when you have > to take one of them down. Maybe for repair, maybe for upgrade. So you still > need a backup. > > OTOH, 'logical standalone'--interesting term--with an ICF in each z/OS CEC is > a sufficient solution. We've run this way for years and survived two separate > hard-down CEC failures with zero recovery agony. My recommendation is to run > two CECs, one substantial box to run application hosts, and a minimal > 'penalty box' just for ICFs plus a few high-cost products that bill > significantly less on a small CEC. With proper structure duplexing, you have > extraordinary redundancy at a reasonable cost. > > . > . > 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of R.S. > Sent: Tuesday, July 10, 2018 3:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Sysplex between two hardware > > W dniu 2018-07-10 o 06:56, Timothy Sipples pisze: >> I should also respond to this part: >> >> Radoslaw Skorupka wrote: >>> ...for availability reasons one should avoid having CF and z/OS LPAR >>> on the same hardware, which means >> That's not phrased as IBM would phase it, and it's not correct as written. >> >> Even when there's some merit in physically separating the CF, the >> physical separation need only be between that CF and the particular >> z/OS Parallel Sysplex it serves. Having other z/OS LPARs, even LPARs >> that are participating in other Parallel Sysplexes, on the same >> machine as the CF is consistent with IBM's recommendations here. >> >> David Raften has published a whitepaper (updated in May, 2018) that >> explains the various CF configuration options. The direct link to the >> current edition is here: >> >> https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw01971usen/zsw01971u >> sen-.pdf > [...] > > I quickly browsed the document and found confirmation what I learned several > years ago. > That means: > Yes, you need either standalone CF (*see note) or CF structure duplexing! > This is required for *some* structures, but ...it is. David Rften call it > structures which /require failure independence/. > > Note: Standalone CF should be understood here as LOGICAL stand alone CF. > IBM-MIAN do not allo pictures, so I'll try to describe it: > SYSPLEX PROD: > z/OS 1 in CPC A, z/OS 2 in CPC B, and CF2 in CPC B or A. And CF1 in CPC C. > Three CPCs. > However CPC C may be used for other purpose, i.e. for test LPARs. > Anything but z/OS image belonging to the sysplex PROD. > > There is also two-CPC configuration > z/OS 1 + CF1 in CPC A, z/OS 2 + CF2 in CPC B and *some structures are > duplexed*. > What I heard unofficially from IBM-ers is such configuration is "budget" > read: when you cannot afford good one. > And the link between CFs should be really local (short). > > > Note2: it is also possible to build a configuration without dedicated > (logical stand alone) CF and without duplexing. Your choice. > However it is NOT resistant to all possible (single) failures. Yes, it > is still better than parallel sysplex with single CF, but still > vulnerable to some failures. > == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do
Re: Sysplex between two hardware
W dniu 2018-07-11 o 09:41, Timothy Sipples pisze: J.O.Skip Robinson wrote: It's easy to diss a solution as 'budget' when it saves someone *else* money. I quite agree. As it happens, I'm quite fond of the single machine z/OS Parallel Sysplex configuration that David also describes. I wish more installations without Parallel Sysplex would adopt it in order to reduce or eliminate most planned and unplanned outages (for the part of their business services relying on IBM Z resources). The single machine z/OS Parallel Sysplex is a terrific value and quite easy to implement. For some odd reason there's a misconception that if you want to upgrade from PLEXCFG=XCFLOCAL or PLEXCFG=MONOPLEX that you must add another machine. No, that's not correct. Moreover, you can run terrifically useful z/OS features such as VSAM RLS and Transactional VSAM even in a PLEXCFG=MONOPLEX mode with one z/OS LPAR (or one z/OS guest in z/VM). That's another popular misconception. Within z/OS Parallel Sysplex configurations you get to decide which subsystems and applications to protect, and how. As one example, you might decide to implement MQ shared queues but otherwise not do much else. Messages can then still be received and queued for processing, even when the only instance of a particular application (or whole LPAR) is offline for maintenance or some other purpose. If "Yes, I've got your message, and I'll get to it soon" is good enough to meet the business requirements between 3:00 a.m. and 4:00 a.m. every third Sunday of the month, or whatever, FINE! There are all kinds of really interesting configuration choices available to cater to particular business service objectives, and it's wonderful to have the flexibility. It's important to have some basic familiarity with these various options if you have a role in advising on configurations. Timothy, It's 90% off-topic, but 99% right. The missing 1% is about XCFLOCAL and MONOPLEX mess. What misconception do you mean? Monoplex does not require (does not use) CF at all. It is not the same thing as single-image parallel sysplex, which require CF. Failure isolation is another issue. RLS require Parallel Sysplex, but not everyone need it. Regards -- Radoslaw Skorupka Lodz, Poland == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
Maybe it's illusory, but that is in David Raften document. Obviously it's cheaper to have 2 CPCs than 3, but it is also cheaper to have 1 CPC than 2. The white paper clearly describes some structures as demanding duplexing or third CPC with failure-isolated CF. -- Radoslaw Skorupka Lodz, Poland W dniu 2018-07-11 o 01:15, Jesse 1 Robinson pisze: It's easy to diss a solution as 'budget' when it saves someone *else* money. The notion that a third CEC for standalone CF is substantially better than ICF is illusory. If you truly believe that one extra CEC is necessary, then you really need two extra CECs for CF because there are times when you have to take one of them down. Maybe for repair, maybe for upgrade. So you still need a backup. OTOH, 'logical standalone'--interesting term--with an ICF in each z/OS CEC is a sufficient solution. We've run this way for years and survived two separate hard-down CEC failures with zero recovery agony. My recommendation is to run two CECs, one substantial box to run application hosts, and a minimal 'penalty box' just for ICFs plus a few high-cost products that bill significantly less on a small CEC. With proper structure duplexing, you have extraordinary redundancy at a reasonable cost. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Tuesday, July 10, 2018 3:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Sysplex between two hardware W dniu 2018-07-10 o 06:56, Timothy Sipples pisze: I should also respond to this part: Radoslaw Skorupka wrote: ...for availability reasons one should avoid having CF and z/OS LPAR on the same hardware, which means That's not phrased as IBM would phase it, and it's not correct as written. Even when there's some merit in physically separating the CF, the physical separation need only be between that CF and the particular z/OS Parallel Sysplex it serves. Having other z/OS LPARs, even LPARs that are participating in other Parallel Sysplexes, on the same machine as the CF is consistent with IBM's recommendations here. David Raften has published a whitepaper (updated in May, 2018) that explains the various CF configuration options. The direct link to the current edition is here: https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw01971usen/zsw01971u sen-.pdf [...] I quickly browsed the document and found confirmation what I learned several years ago. That means: Yes, you need either standalone CF (*see note) or CF structure duplexing! This is required for *some* structures, but ...it is. David Rften call it structures which /require failure independence/. Note: Standalone CF should be understood here as LOGICAL stand alone CF. IBM-MIAN do not allo pictures, so I'll try to describe it: SYSPLEX PROD: z/OS 1 in CPC A, z/OS 2 in CPC B, and CF2 in CPC B or A. And CF1 in CPC C. Three CPCs. However CPC C may be used for other purpose, i.e. for test LPARs. Anything but z/OS image belonging to the sysplex PROD. There is also two-CPC configuration z/OS 1 + CF1 in CPC A, z/OS 2 + CF2 in CPC B and *some structures are duplexed*. What I heard unofficially from IBM-ers is such configuration is "budget" read: when you cannot afford good one. And the link between CFs should be really local (short). Note2: it is also possible to build a configuration without dedicated (logical stand alone) CF and without duplexing. Your choice. However it is NOT resistant to all possible (single) failures. Yes, it is still better than parallel sysplex with single CF, but still vulnerable to some failures. == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other simila
Re: Sysplex between two hardware
J.O.Skip Robinson wrote: >It's easy to diss a solution as 'budget' when it saves >someone *else* money. I quite agree. As it happens, I'm quite fond of the single machine z/OS Parallel Sysplex configuration that David also describes. I wish more installations without Parallel Sysplex would adopt it in order to reduce or eliminate most planned and unplanned outages (for the part of their business services relying on IBM Z resources). The single machine z/OS Parallel Sysplex is a terrific value and quite easy to implement. For some odd reason there's a misconception that if you want to upgrade from PLEXCFG=XCFLOCAL or PLEXCFG=MONOPLEX that you must add another machine. No, that's not correct. Moreover, you can run terrifically useful z/OS features such as VSAM RLS and Transactional VSAM even in a PLEXCFG=MONOPLEX mode with one z/OS LPAR (or one z/OS guest in z/VM). That's another popular misconception. Within z/OS Parallel Sysplex configurations you get to decide which subsystems and applications to protect, and how. As one example, you might decide to implement MQ shared queues but otherwise not do much else. Messages can then still be received and queued for processing, even when the only instance of a particular application (or whole LPAR) is offline for maintenance or some other purpose. If "Yes, I've got your message, and I'll get to it soon" is good enough to meet the business requirements between 3:00 a.m. and 4:00 a.m. every third Sunday of the month, or whatever, FINE! There are all kinds of really interesting configuration choices available to cater to particular business service objectives, and it's wonderful to have the flexibility. It's important to have some basic familiarity with these various options if you have a role in advising on configurations. Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, Multi-Geography E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
It's easy to diss a solution as 'budget' when it saves someone *else* money. The notion that a third CEC for standalone CF is substantially better than ICF is illusory. If you truly believe that one extra CEC is necessary, then you really need two extra CECs for CF because there are times when you have to take one of them down. Maybe for repair, maybe for upgrade. So you still need a backup. OTOH, 'logical standalone'--interesting term--with an ICF in each z/OS CEC is a sufficient solution. We've run this way for years and survived two separate hard-down CEC failures with zero recovery agony. My recommendation is to run two CECs, one substantial box to run application hosts, and a minimal 'penalty box' just for ICFs plus a few high-cost products that bill significantly less on a small CEC. With proper structure duplexing, you have extraordinary redundancy at a reasonable cost. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Tuesday, July 10, 2018 3:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Sysplex between two hardware W dniu 2018-07-10 o 06:56, Timothy Sipples pisze: > I should also respond to this part: > > Radoslaw Skorupka wrote: >> ...for availability reasons one should avoid having CF and z/OS LPAR >> on the same hardware, which means > That's not phrased as IBM would phase it, and it's not correct as written. > > Even when there's some merit in physically separating the CF, the > physical separation need only be between that CF and the particular > z/OS Parallel Sysplex it serves. Having other z/OS LPARs, even LPARs > that are participating in other Parallel Sysplexes, on the same > machine as the CF is consistent with IBM's recommendations here. > > David Raften has published a whitepaper (updated in May, 2018) that > explains the various CF configuration options. The direct link to the > current edition is here: > > https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw01971usen/zsw01971u > sen-.pdf [...] I quickly browsed the document and found confirmation what I learned several years ago. That means: Yes, you need either standalone CF (*see note) or CF structure duplexing! This is required for *some* structures, but ...it is. David Rften call it structures which /require failure independence/. Note: Standalone CF should be understood here as LOGICAL stand alone CF. IBM-MIAN do not allo pictures, so I'll try to describe it: SYSPLEX PROD: z/OS 1 in CPC A, z/OS 2 in CPC B, and CF2 in CPC B or A. And CF1 in CPC C. Three CPCs. However CPC C may be used for other purpose, i.e. for test LPARs. Anything but z/OS image belonging to the sysplex PROD. There is also two-CPC configuration z/OS 1 + CF1 in CPC A, z/OS 2 + CF2 in CPC B and *some structures are duplexed*. What I heard unofficially from IBM-ers is such configuration is "budget" read: when you cannot afford good one. And the link between CFs should be really local (short). Note2: it is also possible to build a configuration without dedicated (logical stand alone) CF and without duplexing. Your choice. However it is NOT resistant to all possible (single) failures. Yes, it is still better than parallel sysplex with single CF, but still vulnerable to some failures. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
W dniu 2018-07-10 o 06:56, Timothy Sipples pisze: I should also respond to this part: Radoslaw Skorupka wrote: ...for availability reasons one should avoid having CF and z/OS LPAR on the same hardware, which means That's not phrased as IBM would phase it, and it's not correct as written. Even when there's some merit in physically separating the CF, the physical separation need only be between that CF and the particular z/OS Parallel Sysplex it serves. Having other z/OS LPARs, even LPARs that are participating in other Parallel Sysplexes, on the same machine as the CF is consistent with IBM's recommendations here. David Raften has published a whitepaper (updated in May, 2018) that explains the various CF configuration options. The direct link to the current edition is here: https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw01971usen/zsw01971usen-.pdf [...] I quickly browsed the document and found confirmation what I learned several years ago. That means: Yes, you need either standalone CF (*see note) or CF structure duplexing! This is required for *some* structures, but ...it is. David Rften call it structures which /require failure independence/. Note: Standalone CF should be understood here as LOGICAL stand alone CF. IBM-MIAN do not allo pictures, so I'll try to describe it: SYSPLEX PROD: z/OS 1 in CPC A, z/OS 2 in CPC B, and CF2 in CPC B or A. And CF1 in CPC C. Three CPCs. However CPC C may be used for other purpose, i.e. for test LPARs. Anything but z/OS image belonging to the sysplex PROD. There is also two-CPC configuration z/OS 1 + CF1 in CPC A, z/OS 2 + CF2 in CPC B and *some structures are duplexed*. What I heard unofficially from IBM-ers is such configuration is "budget" read: when you cannot afford good one. And the link between CFs should be really local (short). Note2: it is also possible to build a configuration without dedicated (logical stand alone) CF and without duplexing. Your choice. However it is NOT resistant to all possible (single) failures. Yes, it is still better than parallel sysplex with single CF, but still vulnerable to some failures. -- Radoslaw Skorupka Lodz, Poland == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
Thanks. I wasn't, in that post, intending to talk about Duplexing performance. Merely how I know about deactivated LPARs from RMF SMF - in case anybody wondered. (In recent engagements I've used the deactivated LPARs' names and locations to drive brief discussions on Availability setup etc.) It's possible you'll like this one, though I don't think it helps you with Performance all that much: https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/coupling_facility_duplexing_reporting_warm_over?lang=en And it's (almost) time I wrote about Async CF Duplexing - which might possibly be helpful to you. Cheers, Martin Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Ravi Gaur To: IBM-MAIN@LISTSERV.UA.EDU Date: 10/07/2018 09:35 Subject:Re: Sysplex between two hardware Sent by:IBM Mainframe Discussion List Martin, thanks I time to time read your blogs very useful however one you pasted for the deactivated lpar's doesn't have much on the performance side ...anyway yes we have LOCK1 duplex...here's an example from our dev partitions. STRNAME: Dxxx_LOCK1 STATUS: REASON SPECIFIED WITH REBUILD START: POLICY-INITIATED DUPLEXING REBUILD METHOD: SYSTEM-MANAGED AUTO VERSION: D290AFB4 34496191 PHASE: DUPLEX ESTABLISHED EVENT MANAGEMENT: MESSAGE-BASED TYPE: LOCK POLICY INFORMATION: POLICY SIZE: 310 M POLICY INITSIZE: 256 M POLICY MINSIZE : 256 M FULLTHRESHOLD : 80 ALLOWAUTOALT : YES REBUILD PERCENT: 1 DUPLEX : ENABLED ALLOWREALLOCATE: YES PREFERENCE LIST: CxxECC1 CxxECC1 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
Martin, thanks I time to time read your blogs very useful however one you pasted for the deactivated lpar's doesn't have much on the performance side ...anyway yes we have LOCK1 duplex...here's an example from our dev partitions. STRNAME: Dxxx_LOCK1 STATUS: REASON SPECIFIED WITH REBUILD START: POLICY-INITIATED DUPLEXING REBUILD METHOD: SYSTEM-MANAGED AUTO VERSION: D290AFB4 34496191 PHASE: DUPLEX ESTABLISHED EVENT MANAGEMENT: MESSAGE-BASED TYPE: LOCK POLICY INFORMATION: POLICY SIZE: 310 M POLICY INITSIZE: 256 M POLICY MINSIZE : 256 M FULLTHRESHOLD : 80 ALLOWAUTOALT : YES REBUILD PERCENT: 1 DUPLEX : ENABLED ALLOWREALLOCATE: YES PREFERENCE LIST: CxxECC1 CxxECC1 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
A common pattern (and I often see the inactive LPARs in RMF* SMF) but tell me: Do you duplex DB2 LOCK1? And how is that working out performancewise? * I wrote about how to do this in https://www.ibm.com/developerworks/community/blogs/MartinPacker/entry/lpars_what_s_in_a_name?lang=en in 2014. Cheers, Martin Sent from my iPad > On 10 Jul 2018, at 08:58, Ravi Gaur wrote: > > We took an approach where for each plex we had CF defined on two cec's as > that make sense : > > 1. Systems defined in the plex are defined on both CEC ...i.e. Say we have > plex of 4 systems (SYS1,SYS2,SYS3,SYS4), each with 2 systems on one CEC1(SYS1 > & SYS2 Active(Normal running) the rest 2 in Inactive state on CEC1 (SYS3 & > SYS4) , similar definition goes other way which is CEC2(SYS3 & SYS4 > Active(normal running) & rest 2 in inactive state on CEC2(SYS1 & SYS2) > This provide resiliency in terms of whole CEC Going down ...Now both have CF > Definition for the Plex on both CEC which provide resiliency for the CF as > well with Structures defined in duplex mode ...This we have been running for > years and provide us various benefits example say we are applying or doing > microcode upgrade or for various other reason require structures to move > around ...those all features can be exploited when we have structures defined > in the duplex mode with hardware split over two separate physical box > So simple rule and policy and commonsense work here > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
We took an approach where for each plex we had CF defined on two cec's as that make sense : 1. Systems defined in the plex are defined on both CEC ...i.e. Say we have plex of 4 systems (SYS1,SYS2,SYS3,SYS4), each with 2 systems on one CEC1(SYS1 & SYS2 Active(Normal running) the rest 2 in Inactive state on CEC1 (SYS3 & SYS4) , similar definition goes other way which is CEC2(SYS3 & SYS4 Active(normal running) & rest 2 in inactive state on CEC2(SYS1 & SYS2) This provide resiliency in terms of whole CEC Going down ...Now both have CF Definition for the Plex on both CEC which provide resiliency for the CF as well with Structures defined in duplex mode ...This we have been running for years and provide us various benefits example say we are applying or doing microcode upgrade or for various other reason require structures to move around ...those all features can be exploited when we have structures defined in the duplex mode with hardware split over two separate physical box So simple rule and policy and commonsense work here -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
Dear All I am receiving lot of great responses and I should be back on Mondays. Apologise for not responding. Peter On Tue 10 Jul, 2018, 10:24 AM Vernooij, Kees (ITOPT1) - KLM, < kees.verno...@klm.com> wrote: > Well, we don't disagree much, except that that in case of a CF failure, we > decided take the (few seconds) structure recovery delays and not have the > duplexing overhead. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Jesse 1 Robinson > > Sent: 09 July, 2018 18:07 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Sysplex between two hardware > > > > I stand by my original reply. All you need is an ICF LPAR in each CEC > > and physical links to connect the CECs, together with full CF structure > > duplexing. We have run this way for decades. Suffered two (!) CEC > > failures over the years. After repairing the failed CEC, we resumed > > normal operation with *no* recovery actions needed because all sensitive > > structures were duplexed in the non-failing CEC. > > > > Our standalone CFs went away with the 9674. > > > > . > > . > > 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Vernooij, Kees (ITOPT1) - KLM > > Sent: Monday, July 09, 2018 8:08 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: Sysplex between two hardware > > > > That was my point: you don't miss a thing. > > You are fully redundant with CFs in each CPC. > > And since the latest MQ update, all applications are capable of > > recovering their structures, so recovery is guaranteed in case of a CF > > failure. > > > > Kees. > > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > > On Behalf Of Allan Staller > > > Sent: 09 July, 2018 16:33 > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Sysplex between two hardware > > > > > > That configuration is perfectly valid. You are merely missing some(but > > > not all) redundancy and recovery options. > > > > > > -Original Message- > > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > > On Behalf Of R.S. > > > Sent: Monday, July 9, 2018 9:20 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Sysplex between two hardware > > > > > > W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze: > > > > The essence of the matter is to ensure that the selected > > > > configuration > > > meets the availability objectives of the business services supported > > > by the sysplex. One must consider the service restoration objectives > > > for the business services in light of the potential failures that can > > > occur for a potential choice of configuration. There are many > > > possibilities and different installations will of course make > > > different choices based on their own business objectives. Choices of > > > standalone CF, or structure duplexing, and the like are really all > > > talking about different ways of solving the "failure isolation" issue > > > (wherein we might be concerned about the time to restore the business > > > service if we simultaneously lose the data in the CF along with the > > > system that produced that data). Each choice has its own advantages > > > and disadvantages; choose the one that's right for you. > > > > --Mark Brooks > > > > --z/OS Sysplex Development > > > > > > > > > > However "option c", that means we don't have standalone CF and we do > > > not duplex CF structures is not proper one, is it? > > > > > > Regards > > > -- > > > Radoslaw Skorupka > > > Lodz, Poland > > > > > > -- > > 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. T
Re: Sysplex between two hardware
Well, we don't disagree much, except that that in case of a CF failure, we decided take the (few seconds) structure recovery delays and not have the duplexing overhead. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jesse 1 Robinson > Sent: 09 July, 2018 18:07 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sysplex between two hardware > > I stand by my original reply. All you need is an ICF LPAR in each CEC > and physical links to connect the CECs, together with full CF structure > duplexing. We have run this way for decades. Suffered two (!) CEC > failures over the years. After repairing the failed CEC, we resumed > normal operation with *no* recovery actions needed because all sensitive > structures were duplexed in the non-failing CEC. > > Our standalone CFs went away with the 9674. > > . > . > 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Vernooij, Kees (ITOPT1) - KLM > Sent: Monday, July 09, 2018 8:08 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Sysplex between two hardware > > That was my point: you don't miss a thing. > You are fully redundant with CFs in each CPC. > And since the latest MQ update, all applications are capable of > recovering their structures, so recovery is guaranteed in case of a CF > failure. > > Kees. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Allan Staller > > Sent: 09 July, 2018 16:33 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Sysplex between two hardware > > > > That configuration is perfectly valid. You are merely missing some(but > > not all) redundancy and recovery options. > > > > -Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of R.S. > > Sent: Monday, July 9, 2018 9:20 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Sysplex between two hardware > > > > W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze: > > > The essence of the matter is to ensure that the selected > > > configuration > > meets the availability objectives of the business services supported > > by the sysplex. One must consider the service restoration objectives > > for the business services in light of the potential failures that can > > occur for a potential choice of configuration. There are many > > possibilities and different installations will of course make > > different choices based on their own business objectives. Choices of > > standalone CF, or structure duplexing, and the like are really all > > talking about different ways of solving the "failure isolation" issue > > (wherein we might be concerned about the time to restore the business > > service if we simultaneously lose the data in the CF along with the > > system that produced that data). Each choice has its own advantages > > and disadvantages; choose the one that's right for you. > > > --Mark Brooks > > > --z/OS Sysplex Development > > > > > > > However "option c", that means we don't have standalone CF and we do > > not duplex CF structures is not proper one, is it? > > > > Regards > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > -- > 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: Sysplex between two hardware
I should also respond to this part: Radoslaw Skorupka wrote: >...for availability reasons one should avoid having CF >and z/OS LPAR on the same hardware, which means That's not phrased as IBM would phase it, and it's not correct as written. Even when there's some merit in physically separating the CF, the physical separation need only be between that CF and the particular z/OS Parallel Sysplex it serves. Having other z/OS LPARs, even LPARs that are participating in other Parallel Sysplexes, on the same machine as the CF is consistent with IBM's recommendations here. David Raften has published a whitepaper (updated in May, 2018) that explains the various CF configuration options. The direct link to the current edition is here: https://public.dhe.ibm.com/common/ssi/ecm/zs/en/zsw01971usen/zsw01971usen-.pdf If you're reading this post substantially later than July, 2018, then please check first to see whether there's yet another updated edition. David discusses what I just described, the "Logical Stand-Alone CF" configuration, starting on page 9 of that whitepaper. Just because something has merit doesn't automatically mean it has merit for the next available increment of resources (budget, effort, etc.) I always try to approach business risk reduction holistically, in end-to-end business service terms starting with the most critical business services. If adopting a stand-alone CF configuration is the highest, next best use of available resources within that end-to-end service context, great. And isn't it wonderful how much flexibility you have with these technologies, to craft (and re-craft) the most appropriate configurations for the desired business outcomes? Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, Multi-Geography E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
I stand by my original reply. All you need is an ICF LPAR in each CEC and physical links to connect the CECs, together with full CF structure duplexing. We have run this way for decades. Suffered two (!) CEC failures over the years. After repairing the failed CEC, we resumed normal operation with *no* recovery actions needed because all sensitive structures were duplexed in the non-failing CEC. Our standalone CFs went away with the 9674. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, Kees (ITOPT1) - KLM Sent: Monday, July 09, 2018 8:08 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Sysplex between two hardware That was my point: you don't miss a thing. You are fully redundant with CFs in each CPC. And since the latest MQ update, all applications are capable of recovering their structures, so recovery is guaranteed in case of a CF failure. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Allan Staller > Sent: 09 July, 2018 16:33 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sysplex between two hardware > > That configuration is perfectly valid. You are merely missing some(but > not all) redundancy and recovery options. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of R.S. > Sent: Monday, July 9, 2018 9:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sysplex between two hardware > > W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze: > > The essence of the matter is to ensure that the selected > > configuration > meets the availability objectives of the business services supported > by the sysplex. One must consider the service restoration objectives > for the business services in light of the potential failures that can > occur for a potential choice of configuration. There are many > possibilities and different installations will of course make > different choices based on their own business objectives. Choices of > standalone CF, or structure duplexing, and the like are really all > talking about different ways of solving the "failure isolation" issue > (wherein we might be concerned about the time to restore the business > service if we simultaneously lose the data in the CF along with the > system that produced that data). Each choice has its own advantages > and disadvantages; choose the one that's right for you. > > --Mark Brooks > > --z/OS Sysplex Development > > > > However "option c", that means we don't have standalone CF and we do > not duplex CF structures is not proper one, is it? > > Regards > -- > Radoslaw Skorupka > Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
That was my point: you don't miss a thing. You are fully redundant with CFs in each CPC. And since the latest MQ update, all applications are capable of recovering their structures, so recovery is guaranteed in case of a CF failure. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Allan Staller > Sent: 09 July, 2018 16:33 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sysplex between two hardware > > That configuration is perfectly valid. You are merely missing some(but > not all) redundancy and recovery options. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of R.S. > Sent: Monday, July 9, 2018 9:20 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sysplex between two hardware > > W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze: > > The essence of the matter is to ensure that the selected configuration > meets the availability objectives of the business services supported by > the sysplex. One must consider the service restoration objectives for > the business services in light of the potential failures that can occur > for a potential choice of configuration. There are many possibilities > and different installations will of course make different choices based > on their own business objectives. Choices of standalone CF, or > structure duplexing, and the like are really all talking about different > ways of solving the "failure isolation" issue (wherein we might be > concerned about the time to restore the business service if we > simultaneously lose the data in the CF along with the system that > produced that data). Each choice has its own advantages and > disadvantages; choose the one that's right for you. > > --Mark Brooks > > --z/OS Sysplex Development > > > > However "option c", that means we don't have standalone CF and we do not > duplex CF structures is not proper one, is it? > > Regards > -- > Radoslaw Skorupka > Lodz, Poland > > > > > == > > > -- > Treść tej wiadomości może zawierać informacje prawnie chronione Banku > przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być > jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie > jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do > jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, > kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze > jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę > wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając > odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej > kopie wydrukowane lub zapisane na dysku. > > This e-mail may contain legally privileged information of the Bank and > is intended solely for business use of the addressee. This e-mail may > only be received by the addressee and may not be disclosed to any third > parties. If you are not the intended addressee of this e-mail or the > employee authorized to forward it to the addressee, be advised that any > dissemination, copying, distribution or any other similar activity is > legally prohibited and may be punishable. If you received this e-mail by > mistake please advise the sender immediately by using the reply facility > in your e-mail software and delete permanently this e-mail including any > copies of it either printed or saved to hard drive. > > mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, > https://apac01.safelinks.protection.outlook.com/?url=www.mBank.plda > ta=02%7C01%7Callan.staller%40HCL.COM%7C10622a536f78423874c708d5e5a72f4d% > 7C189de737c93a4f5a8b686f4ca9941912%7C0%7C1%7C636667428590770229sdat > a=eg%2FISBQY4%2BT0T%2BRPr%2FPulpGdLql5wRKMACmRqT4VxsQ%3Dreserved=0, > e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział > Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS > 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. > kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 > złotych. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > > > > ---
Re: Sysplex between two hardware
That configuration is perfectly valid. You are merely missing some(but not all) redundancy and recovery options. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, July 9, 2018 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex between two hardware W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze: > The essence of the matter is to ensure that the selected configuration meets > the availability objectives of the business services supported by the > sysplex. One must consider the service restoration objectives for the > business services in light of the potential failures that can occur for a > potential choice of configuration. There are many possibilities and > different installations will of course make different choices based on their > own business objectives. Choices of standalone CF, or structure duplexing, > and the like are really all talking about different ways of solving the > "failure isolation" issue (wherein we might be concerned about the time to > restore the business service if we simultaneously lose the data in the CF > along with the system that produced that data). Each choice has its own > advantages and disadvantages; choose the one that's right for you. > --Mark Brooks > --z/OS Sysplex Development > However "option c", that means we don't have standalone CF and we do not duplex CF structures is not proper one, is it? Regards -- Radoslaw Skorupka Lodz, Poland == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, https://apac01.safelinks.protection.outlook.com/?url=www.mBank.pldata=02%7C01%7Callan.staller%40HCL.COM%7C10622a536f78423874c708d5e5a72f4d%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C1%7C636667428590770229sdata=eg%2FISBQY4%2BT0T%2BRPr%2FPulpGdLql5wRKMACmRqT4VxsQ%3Dreserved=0, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych. -- 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 re
Re: Sysplex between two hardware
W dniu 2018-07-09 o 15:41, Mark A. Brooks pisze: The essence of the matter is to ensure that the selected configuration meets the availability objectives of the business services supported by the sysplex. One must consider the service restoration objectives for the business services in light of the potential failures that can occur for a potential choice of configuration. There are many possibilities and different installations will of course make different choices based on their own business objectives. Choices of standalone CF, or structure duplexing, and the like are really all talking about different ways of solving the "failure isolation" issue (wherein we might be concerned about the time to restore the business service if we simultaneously lose the data in the CF along with the system that produced that data). Each choice has its own advantages and disadvantages; choose the one that's right for you. --Mark Brooks --z/OS Sysplex Development However "option c", that means we don't have standalone CF and we do not duplex CF structures is not proper one, is it? Regards -- Radoslaw Skorupka Lodz, Poland == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
The essence of the matter is to ensure that the selected configuration meets the availability objectives of the business services supported by the sysplex. One must consider the service restoration objectives for the business services in light of the potential failures that can occur for a potential choice of configuration. There are many possibilities and different installations will of course make different choices based on their own business objectives. Choices of standalone CF, or structure duplexing, and the like are really all talking about different ways of solving the "failure isolation" issue (wherein we might be concerned about the time to restore the business service if we simultaneously lose the data in the CF along with the system that produced that data). Each choice has its own advantages and disadvantages; choose the one that's right for you. --Mark Brooks --z/OS Sysplex Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of R.S. > Sent: 09 July, 2018 14:26 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sysplex between two hardware > > W dniu 2018-07-09 o 13:12, Vernooij, Kees (ITOPT1) - KLM pisze: > >> -Original Message- > >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On > >> Behalf Of R.S. > >> Sent: 09 July, 2018 12:47 > >> To: IBM-MAIN@LISTSERV.UA.EDU > >> Subject: Re: Sysplex between two hardware > >> > >> W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze: > >>> We all have lots of questions about your goals here, but the short > >> answer to your question is Yes, sysplex is the answer. I assume that > >> your two boxes are already connected in some way as to share access > to > >> data. Turning such a configuration into a sysplex may require some > >> additional hardware, but not a lot. > >>> -- If you want a full-function parallel sysplex, you would need to > >> create an internal coupling facility LPAR (ICF) in each CEC. > >>> -- You would need CF links to connect each ICF to the opposite CEC. > >>> > >>> -- I think you would also need server timing protocol (STP) to keep > >> clocks in synch; I have not tried running without STP. > >> > >> STP (or earlier sysplex timer) is mandatory for sysplex, even for > basic > >> sysplex. > >> For production parallel sysplex it is good idea to have standalone > CF. > >> > >> -- > >> Radoslaw Skorupka > >> Lodz, Poland > >> > >> > > In this case: yes, but to be precise: not if you run a sysplex on 1 > box. The required 'common time source' can then be the time of that > machine. > > I thought the recommendation of a standalone CF was not current > anymore. > > Well, I was suggested by the topic - "two different hardware". > Regarding CF and availability - for availability reasons one should > avoid having CF and z/OS LPAR on the same hardware, which means: > a) at least 3 CPCs (of course CF-only box is much cheaper) > b) use CF structures replication which gives some performance penalty, > especially for non-local distances. > > Regards > -- > Radoslaw Skorupka > Lodz, Poland > I disagree with the statement " avoid having CF and z/OS LPAR on the same hardware" Avoiding SPOFs can well be done by z/OS LPARs on both CPCs and 2 CFs on each CPC. The need for " CF structures replication", I suppose you mean System-Managed CF Structure Duplexing, is not evident to me either. Since the last upgrade of MQ, every structure owner is perfectly able to recover its structures into another CF after a CF failure. I don't see much benefit in it, but I see the disadvantages you mention. Kees. 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: Sysplex between two hardware
STP (or earlier sysplex timer) is mandatory for sysplex, even for basic sysplex. For production parallel sysplex it is good idea to have standalone CF. Not if entire sysplex is in one box. If that is the case, SYSPLEX time is not needed. As long as all participants use the same time source, all will be well. The issue requiring an ETR is synchronization/tolerization for XCF. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Monday, July 9, 2018 5:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex between two hardware W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze: > We all have lots of questions about your goals here, but the short answer to > your question is Yes, sysplex is the answer. I assume that your two boxes are > already connected in some way as to share access to data. Turning such a > configuration into a sysplex may require some additional hardware, but not a > lot. > > -- If you want a full-function parallel sysplex, you would need to create an > internal coupling facility LPAR (ICF) in each CEC. > > -- You would need CF links to connect each ICF to the opposite CEC. > > -- I think you would also need server timing protocol (STP) to keep clocks in > synch; I have not tried running without STP. STP (or earlier sysplex timer) is mandatory for sysplex, even for basic sysplex. For production parallel sysplex it is good idea to have standalone CF. -- Radoslaw Skorupka Lodz, Poland == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, https://apac01.safelinks.protection.outlook.com/?url=www.mBank.pldata=02%7C01%7Callan.staller%40HCL.COM%7Ca337fe0b86b840b524f408d5e58954cd%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C1%7C636667300404700814sdata=pf0btoRfi3YbUVX3SPfjI0C%2B%2FTvkSY8yfb8TZDefjXg%3Dreserved=0, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych. -- 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 prohi
Re: Sysplex between two hardware
W dniu 2018-07-09 o 13:12, Vernooij, Kees (ITOPT1) - KLM pisze: -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: 09 July, 2018 12:47 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Sysplex between two hardware W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze: We all have lots of questions about your goals here, but the short answer to your question is Yes, sysplex is the answer. I assume that your two boxes are already connected in some way as to share access to data. Turning such a configuration into a sysplex may require some additional hardware, but not a lot. -- If you want a full-function parallel sysplex, you would need to create an internal coupling facility LPAR (ICF) in each CEC. -- You would need CF links to connect each ICF to the opposite CEC. -- I think you would also need server timing protocol (STP) to keep clocks in synch; I have not tried running without STP. STP (or earlier sysplex timer) is mandatory for sysplex, even for basic sysplex. For production parallel sysplex it is good idea to have standalone CF. -- Radoslaw Skorupka Lodz, Poland In this case: yes, but to be precise: not if you run a sysplex on 1 box. The required 'common time source' can then be the time of that machine. I thought the recommendation of a standalone CF was not current anymore. Well, I was suggested by the topic - "two different hardware". Regarding CF and availability - for availability reasons one should avoid having CF and z/OS LPAR on the same hardware, which means: a) at least 3 CPCs (of course CF-only box is much cheaper) b) use CF structures replication which gives some performance penalty, especially for non-local distances. Regards -- Radoslaw Skorupka Lodz, Poland == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of R.S. > Sent: 09 July, 2018 12:47 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Sysplex between two hardware > > W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze: > > We all have lots of questions about your goals here, but the short > answer to your question is Yes, sysplex is the answer. I assume that > your two boxes are already connected in some way as to share access to > data. Turning such a configuration into a sysplex may require some > additional hardware, but not a lot. > > > > -- If you want a full-function parallel sysplex, you would need to > create an internal coupling facility LPAR (ICF) in each CEC. > > > > -- You would need CF links to connect each ICF to the opposite CEC. > > > > -- I think you would also need server timing protocol (STP) to keep > clocks in synch; I have not tried running without STP. > > STP (or earlier sysplex timer) is mandatory for sysplex, even for basic > sysplex. > For production parallel sysplex it is good idea to have standalone CF. > > -- > Radoslaw Skorupka > Lodz, Poland > > In this case: yes, but to be precise: not if you run a sysplex on 1 box. The required 'common time source' can then be the time of that machine. I thought the recommendation of a standalone CF was not current anymore. Kees. 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: Sysplex between two hardware
W dniu 2018-07-06 o 18:22, Jesse 1 Robinson pisze: We all have lots of questions about your goals here, but the short answer to your question is Yes, sysplex is the answer. I assume that your two boxes are already connected in some way as to share access to data. Turning such a configuration into a sysplex may require some additional hardware, but not a lot. -- If you want a full-function parallel sysplex, you would need to create an internal coupling facility LPAR (ICF) in each CEC. -- You would need CF links to connect each ICF to the opposite CEC. -- I think you would also need server timing protocol (STP) to keep clocks in synch; I have not tried running without STP. STP (or earlier sysplex timer) is mandatory for sysplex, even for basic sysplex. For production parallel sysplex it is good idea to have standalone CF. -- Radoslaw Skorupka Lodz, Poland == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
We all have lots of questions about your goals here, but the short answer to your question is Yes, sysplex is the answer. I assume that your two boxes are already connected in some way as to share access to data. Turning such a configuration into a sysplex may require some additional hardware, but not a lot. -- If you want a full-function parallel sysplex, you would need to create an internal coupling facility LPAR (ICF) in each CEC. -- You would need CF links to connect each ICF to the opposite CEC. -- I think you would also need server timing protocol (STP) to keep clocks in synch; I have not tried running without STP. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Timothy Sipples Sent: Friday, July 06, 2018 5:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Sysplex between two hardware Peter wrote: >We are looking up for a solution where we need a LPAR to have a hot standby >in other LPAR running in a different machine . >As we are trying to create a sysplex relationship between two LPARS running >in a different machines . >Apology for my ignorance and is it possible ? Yes, it's certainly possible and common. Here are a couple questions: 1. How far apart (in fiber distance) are these two physical machines? 2. What workload types would you like to configure across the two LPARs? Examples: MQ, Db2, CICS, IMS TM, IMS DB, WebSphere Application Server? 3. What goal(s) are you trying to accomplish? Are you trying to improve service levels, for example? Or perhaps trying to move workloads from one machine to another while minimizing (or eliminating) an outage? Something else? Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, Multi-Geography E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
Peter wrote: >We are looking up for a solution where we need a LPAR to have a hot standby >in other LPAR running in a different machine . >As we are trying to create a sysplex relationship between two LPARS running >in a different machines . >Apology for my ignorance and is it possible ? Yes, it's certainly possible and common. Here are a couple questions: 1. How far apart (in fiber distance) are these two physical machines? 2. What workload types would you like to configure across the two LPARs? Examples: MQ, Db2, CICS, IMS TM, IMS DB, WebSphere Application Server? 3. What goal(s) are you trying to accomplish? Are you trying to improve service levels, for example? Or perhaps trying to move workloads from one machine to another while minimizing (or eliminating) an outage? Something else? Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE, Multi-Geography E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sysplex between two hardware
Peter, What is your question exactly? If you MEAN a "hot standby" - which I understand to mean a system that is IPL'd but not being used, but could take on workload from a currently active and used system, I'd say that's not a SYSPLEX, that's a disaster recovery scenario. If you are trying to connect two ACTIVE and USED LPARS on different machines, that may or may not share worload, then that could be a SHAMPLEX, a SYSPLEX, possibly a parallel SYSPLEX or even a GLOBALLY DISPERSED PARALLEL SYSPLEX. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Sysplex between two hardware
Hi We are looking up for a solution where we need a LPAR to have a hot standby in other LPAR running in a different machine . As we are trying to create a sysplex relationship between two LPARS running in a different machines . Apology for my ignorance and is it possible ? Peter -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF on a Sysplex??
Generic profiles had become a standard here years before we cloned the first RACF data base. Went so far as to create a still existing usermod to the RACF ISPF app that inserts 'Generic' on the main data set profile panels. One would have to go out of the way to create a discrete profile. I saw a few over the years, but only a handful of dogies. A discrete profile would be very problematic with a cloned data base. They are recognized only by a flag in the VTOC. With generics, cloning is not a major effort. BTW, as far as eventual cleanup of unnecessary profile, it doesn't really matter very much. What you need to do is make sure that a commonly named resource A.B.C has the appropriate access rules in both data bases. That matters. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, Vignesh Sent: Friday, May 18, 2018 8:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: [EXTERNAL] Re: RACF on a Sysplex?? Hi Skip, Any scars from not doing so? – Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Saturday 19-May-2018 03:17 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: RACF on a Sysplex?? One sort of obvious point. Before cloning your RACF data base make sure that *all* data set profiles are generic. Convert any that are not. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Thursday, May 03, 2018 3:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF on a Sysplex?? My client has a mixture of things, but nothing is ever shared with a sandbox LPAR - not even via RRSF "one way". It really doesn't seem dangerous to do it one way, but I still prefer to isolate things in a sandbox as completely as possible. One business unit with 2 large sysplexes has separate RACF databases, but RRSF keeps things in sync. Both have sysplex communications enabled in the DSNT and CF structures. Another business unit has one RACF database shared between 2 sysplexes. MII is the integrity manager and SYSZRACF is excluded, so the DB is protected with RESERVEs. Another business unit has a 2 system basic sysplex and is in GRS ring mode, RACF DB is shared between both. I just checked and SYSZRACF is converted to a global ENQ. Another business unit has a prod / devl LPAR (both monoplexes). They share a RACF DB. Since there is no GRS ring, the DB is protected with RESERVE. There is a sandbox version of this business unit also, but it has its own RACF DB. There are also 2 sandbox parallel sysplexes each with 2 LPARs that are "clones" of the first 2 environments I wrote about - one with GRS, the other with MII. Both those sysplexes have their own RACF DBs, have sysplex communications enabled in the DSNT and CF structures. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: RACF on a Sysplex??
Hi Skip, Any scars from not doing so? – Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Saturday 19-May-2018 03:17 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: RACF on a Sysplex?? One sort of obvious point. Before cloning your RACF data base make sure that *all* data set profiles are generic. Convert any that are not. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Thursday, May 03, 2018 3:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF on a Sysplex?? My client has a mixture of things, but nothing is ever shared with a sandbox LPAR - not even via RRSF "one way". It really doesn't seem dangerous to do it one way, but I still prefer to isolate things in a sandbox as completely as possible. One business unit with 2 large sysplexes has separate RACF databases, but RRSF keeps things in sync. Both have sysplex communications enabled in the DSNT and CF structures. Another business unit has one RACF database shared between 2 sysplexes. MII is the integrity manager and SYSZRACF is excluded, so the DB is protected with RESERVEs. Another business unit has a 2 system basic sysplex and is in GRS ring mode, RACF DB is shared between both. I just checked and SYSZRACF is converted to a global ENQ. Another business unit has a prod / devl LPAR (both monoplexes). They share a RACF DB. Since there is no GRS ring, the DB is protected with RESERVE. There is a sandbox version of this business unit also, but it has its own RACF DB. There are also 2 sandbox parallel sysplexes each with 2 LPARs that are "clones" of the first 2 environments I wrote about - one with GRS, the other with MII. Both those sysplexes have their own RACF DBs, have sysplex communications enabled in the DSNT and CF structures. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF on a Sysplex??
One sort of obvious point. Before cloning your RACF data base make sure that *all* data set profiles are generic. Convert any that are not. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Thursday, May 03, 2018 3:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF on a Sysplex?? My client has a mixture of things, but nothing is ever shared with a sandbox LPAR - not even via RRSF "one way". It really doesn't seem dangerous to do it one way, but I still prefer to isolate things in a sandbox as completely as possible. One business unit with 2 large sysplexes has separate RACF databases, but RRSF keeps things in sync. Both have sysplex communications enabled in the DSNT and CF structures. Another business unit has one RACF database shared between 2 sysplexes. MII is the integrity manager and SYSZRACF is excluded, so the DB is protected with RESERVEs. Another business unit has a 2 system basic sysplex and is in GRS ring mode, RACF DB is shared between both. I just checked and SYSZRACF is converted to a global ENQ. Another business unit has a prod / devl LPAR (both monoplexes). They share a RACF DB. Since there is no GRS ring, the DB is protected with RESERVE. There is a sandbox version of this business unit also, but it has its own RACF DB. There are also 2 sandbox parallel sysplexes each with 2 LPARs that are "clones" of the first 2 environments I wrote about - one with GRS, the other with MII. Both those sysplexes have their own RACF DBs, have sysplex communications enabled in the DSNT and CF structures. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF on a Sysplex??
My client has a mixture of things, but nothing is ever shared with a sandbox LPAR - not even via RRSF "one way". It really doesn't seem dangerous to do it one way, but I still prefer to isolate things in a sandbox as completely as possible. One business unit with 2 large sysplexes has separate RACF databases, but RRSF keeps things in sync. Both have sysplex communications enabled in the DSNT and CF structures. Another business unit has one RACF database shared between 2 sysplexes. MII is the integrity manager and SYSZRACF is excluded, so the DB is protected with RESERVEs. Another business unit has a 2 system basic sysplex and is in GRS ring mode, RACF DB is shared between both. I just checked and SYSZRACF is converted to a global ENQ. Another business unit has a prod / devl LPAR (both monoplexes). They share a RACF DB. Since there is no GRS ring, the DB is protected with RESERVE. There is a sandbox version of this business unit also, but it has its own RACF DB. There are also 2 sandbox parallel sysplexes each with 2 LPARs that are "clones" of the first 2 environments I wrote about - one with GRS, the other with MII. Both those sysplexes have their own RACF DBs, have sysplex communications enabled in the DSNT and CF structures. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF on a Sysplex??
fred glenlake wrote: >We are going from one production lpar and one test lpar to two sysplexs, one >plex for production, one plex for test. Currently the RACF databases are >shared (yeah not ideal) but they will be split (prod and test on their own >databases) once we are sysplexed. >In preparation for the split and the new sysplexes I want to split up the >databases ahead of time. I am new to sysplexes so excuse the silly questions. >Currently my primary and backup RACF databases are on DASD, shared DASD >between prod and test. I am going to move them to non-shared DASD so prod >has its own databases and test has its own. In a Sysplex should the RACF >databases still reside on DASD that both sides of the sysplexes share (so both >prod lpars in the plex) or should they reside in the coupling facility or ?? Wait a moment please. First thing first - Do NOT share any RACF DBs across two or more Sysplexes. Ensure one and each Sysplex has its own set of RACF DBs. Each LPARs inside the Sysplex can share that RACF DB or just use its own RACF DB. I recommend that ONE RACF DB is used by all LPARs inside a Sysplex. From what you said, I believe the safest way is - Make an exact copy of the RACF DBs to be used on the other Sysplex. Say you have two RACF DBs (Primary and Backup) on Volser A and B. Copy them to Volser C and D and ensure that one Sysplex is using A and B and another Sysplex is using C and D. In this way you can have 'prod has its own databases and test has its own.' Then when everything is fine and you have IPLed and verified each Sysplex is using its own RACF DBs, now you can get rid of unneeded profiles as needed. About 'splitting' - IBM is using the word 'splitting' for RACF DB in another, but strange way. Let me explain. In your way of 'splitting', do not use IRRUT400 to do a 'split'. That type of 'split' by using IRRUT400 is just to spread out your profiles amongst more than one datasets inside a RACF DB, but all these datasets are used as ONE RACF DB (inside a Sysplex). That type of split is more for performance and resizing. In your scenario, the only way to 'split' is to make identical copy and then at each Sysplex, you can get rid of unneeded profiles from a LPAR inside that Sysplex. Say you have ids Prod1 and Test1 on both copies. Now you delete Prod1 on the test Sysplex RACF DB and also delete Test1 on the Prod RACF DB. When everything is in order and you can verify each Sysplex has its own RACF DBs, then you can setup your XCF so the XCF structures can be used. If you need guidance, please e-mail me privately or you can post on RACF-L for more guidance. >Are there any tools that will help me get to my end state, split up the >databases, report on the databases, etc.?? Normally I just use the RACF >utilities ICH* but perhaps other sites use different tools I could look >into. zSecure (and Vanguard) can help you there, but to do make copies and setting up the ICHRDSNT and other modules, you need RACF utilities like IRRMIN00 (for templates), IRRUT200 (for making exact copies), IRRUT400 (to re-org the RACF DB indexes during copy), IRRDBU00 (for RACF DB unloads and reporting). Just ensure that all Volsers used by RACF are Non-SMS Volsers (DSORG=PSU) and of course not shared by both Sysplexes. For clarification: I have two Sysplexes. Prod and Sandbox. Each Sysplex has numerous LPARs, but each Sysplex has its own RACF DBs (Primary and Backup). These sets are on different Non-SMS Volsers and are not shared amongst the Sysplex. Each Sysplex RACF DBs are cataloged in its own Sysplex Master Catalogs. Each Sysplex has its own ICHRDSNT module. Think about 'isolating' or think about putting each Sysplex in separate prison cells where nothing is shared at all and you're a heavy handed guard taking no bribes at all. ;-) >Any suggestions, comments are most welcome. Post your questions on RACF-L. I'll check you out there. ;-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Fw: RACF on a Sysplex??
We have separate DB's for each Sysplex BUT keep them in sync using RRSAF so password changes and profile updates flow from the initial system to all the others. In the case of the Sandbox Sysplex we allow updates IN but not OUT - allowing us to test RACF changes in the Sandbox Sysplex and not propagate to the other Sysplexes. This does mean that you need to maintain a consistent naming convention where Prod is Prod and Dev is Dev across the enterprise (e.g. Don't reuse Prod DS name in Dev and grant different accesses because its Dev. Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services > From: fred glenlake <fred.glenl...@outlook.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 05/03/2018 09:19 AM > Subject: RACF on a Sysplex?? > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > Hello, > > We are going from one production lpar and one test lpar to two > sysplexs, one plex for production, one plex for test. Currently > the RACF databases are shared (yeah not ideal) but they will be > split (prod and test on their own databases) once we are sysplexed. > > In preparation for the split and the new sysplexes I want to split > up the databases ahead of time. I am new to sysplexes so excuse > the silly questions. > > Currently my primary and backup RACF databases are on DASD, shared > DASD between prod and test. I am going to move them to non-shared > DASD so prod has its own databases and test has its own. In a > Sysplex should the RACF databases still reside on DASD that both > sides of the sysplexes share (so both prod lpars in the plex) or > should they reside in the coupling facility or ?? > > Are there any tools that will help me get to my end state, split up > the databases, report on the databases, etc.?? Normally I just use > the RACF utilities ICH* but perhaps other sites use different > tools I could look into. > > Any suggestions, comments are most welcome. > > FredG. > > > -- > 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: RACF on a Sysplex??
I would do the split post sysplex. Make a copy of production to be used by the test sysplex. Get to the two sysplex mode. Then do the cleanup. Remember, you scope of sharing is SYSPLEX. Do not cross sysplex boundaries. You will (most likely) be very sorry if you do. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of fred glenlake Sent: Thursday, May 3, 2018 11:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RACF on a Sysplex?? Hello, We are going from one production lpar and one test lpar to two sysplexs, one plex for production, one plex for test. Currently the RACF databases are shared (yeah not ideal) but they will be split (prod and test on their own databases) once we are sysplexed. In preparation for the split and the new sysplexes I want to split up the databases ahead of time. I am new to sysplexes so excuse the silly questions. Currently my primary and backup RACF databases are on DASD, shared DASD between prod and test. I am going to move them to non-shared DASD so prod has its own databases and test has its own. In a Sysplex should the RACF databases still reside on DASD that both sides of the sysplexes share (so both prod lpars in the plex) or should they reside in the coupling facility or ?? Are there any tools that will help me get to my end state, split up the databases, report on the databases, etc.?? Normally I just use the RACF utilities ICH* but perhaps other sites use different tools I could look into. Any suggestions, comments are most welcome. FredG. -- 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: RACF on a Sysplex??
If you have not joined, there is a RACF List that you might like to also ask this question. To join, if you have not done so, go to this URL RACFhttp://www.listserv.uga.edu/archives/racf-l.html Lizette > -Original Message- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of > fred glenlake > Sent: Thursday, May 03, 2018 9:19 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: RACF on a Sysplex?? > > Hello, > > We are going from one production lpar and one test lpar to two sysplexs, one > plex for production, one plex for test. Currently the RACF databases are > shared (yeah not ideal) but they will be split (prod and test on their own > databases) once we are sysplexed. > > In preparation for the split and the new sysplexes I want to split up the > databases ahead of time. I am new to sysplexes so excuse the silly > questions. > > Currently my primary and backup RACF databases are on DASD, shared DASD > between prod and test. I am going to move them to non-shared DASD so prod > has its own databases and test has its own. In a Sysplex should the RACF > databases still reside on DASD that both sides of the sysplexes share (so > both prod lpars in the plex) or should they reside in the coupling facility > or ?? > > Are there any tools that will help me get to my end state, split up the > databases, report on the databases, etc.?? Normally I just use the RACF > utilities ICH* but perhaps other sites use different tools I could look > into. > > Any suggestions, comments are most welcome. > > FredG. > > > -- > 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
RACF on a Sysplex??
Hello, We are going from one production lpar and one test lpar to two sysplexs, one plex for production, one plex for test. Currently the RACF databases are shared (yeah not ideal) but they will be split (prod and test on their own databases) once we are sysplexed. In preparation for the split and the new sysplexes I want to split up the databases ahead of time. I am new to sysplexes so excuse the silly questions. Currently my primary and backup RACF databases are on DASD, shared DASD between prod and test. I am going to move them to non-shared DASD so prod has its own databases and test has its own. In a Sysplex should the RACF databases still reside on DASD that both sides of the sysplexes share (so both prod lpars in the plex) or should they reside in the coupling facility or ?? Are there any tools that will help me get to my end state, split up the databases, report on the databases, etc.?? Normally I just use the RACF utilities ICH* but perhaps other sites use different tools I could look into. Any suggestions, comments are most welcome. FredG. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX Hung
This looks like a problem we had some time ago, although it was part of a much more complex outage. The problem was a power failure (Murphy during actions on the power infra) in one site of the 2 site 9-LPAR sysplex. Several things like automatic recovery action (sysplex partitioning etc) were as expected, but one thing was unexplainable: We have 2 GDPS K systems in our 9-LPAR sysplex, and the surviving part of the sysplex was hung. We had message: .HASP292 MEMBER MVSS -- JES2 IS WAITING FOR RESPONSE TO WRITE TO CKPT1 SYS3.JES2.HASPCKPT ON SSYS39 This is a GDPS K-system, with a private single JES2, with its private DASD, with no other LPAR accessing it, so there should be no one accessing its CKPT. This system also reported that IXC431I GROUP SYSWLM MEMBER MVSS JOB WLM was stalled, but with no indication of the causer of the stall. Then another LPAR, which also hung, was partitioned out of the sysplex and the hang situation was solved. We cannot explain a) what was delaying JES2 on the K system b) why it was solved by partitioning another production LPAR out of the sysplex. Apparently there was some (JES2?) connection between these LPARs. I found XCF Group SYSJES, that was connected by all LPARs in the sysplex, in spite of the fact that the K-Systems run their own single JES2 and are not part of the JES2 MAS of the Production LPARs. There is very little information about this XCF Group. We are in the process of submitting all info to IBM to find the cause of this unexpected JES2 hang, which seems as unexplainable as yours. We run z/OS 2.2. Grtn, Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Salah Balboul > Sent: 19 April, 2018 22:37 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SYSPLEX Hung > > nothing in the syslog prior to this indicates any issues. All running > fine. > > Yes we have an automation tool. > > Yes, I will place the CKPT1 on the CF. > > Thanks > > -- > 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: SYSPLEX Hung
MASDEF DORMANCY=(100,500), HOLD=60, LOCKOUT=1000,SYNCTOL=120. That what I have. Been like this for 11 month. Not convinced this is a JES2 problem. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX Hung
nothing in the syslog prior to this indicates any issues. All running fine. Yes we have an automation tool. Yes, I will place the CKPT1 on the CF. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX Hung
MASDEF=100 (1 second). MASDEF= will cause a long hang on a shared JES2 checkpoint volume that is shared with another system. On Thu, Apr 19, 2018 at 9:48 AM, Salah Balboul <balbo...@att.net> wrote: > Hi, > > For the past week we've had 2 crashes due to one LPAR being hung in a two > SYSPLEX LPAR causing sympathy sickness. > > In both cases the indication is $HASP263 message (Checkpoint lock), followed > by *MASTER* pending on the JES2 CKPT volume. > > Finally IXC426D to partition the sick LPAR out. > > We do not have an SFM policy in effect, no changes done or maintenance > applied. > > The problem LPAR SYSLOG stops recording approx 10-12 prior to IXC426D > message. NO indication of any issues on problem LPAR. > > I wonder if anyone has seen this. > > I don't think JES2 is causing this, it is a victim. > > Thoughts? > > Thanks > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX Hung
hindsight I agree the D, GRS,C command maybe would have helped, but I suspect a *MASTER* start pending on a CKPT volume would indicate a process outside of the plex or maybe an operator command, or maybe a dynamic IOS change that wanted that volume reserved. Lizette has some good suggestions, I've had an issue like this when working for an outsourcer, we had 16 system in a plex from a 9 engine CP to a UNI processor in the same plex, and the sysplex designer had an SFM policy built that was not designed correctly and all systems were weighted the same, the UNI processor would not and could not manage the IXC messaging, also we were in a GRS ring configuration which made things worse. so this leads to another question, MIM or GRS? RING or STAR? Carmen Vitullo - Original Message - From: "Salah Balboul" <balbo...@att.net> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, April 19, 2018 1:18:12 PM Subject: Re: SYSPLEX Hung Yes. Shared DASD within the SYSPLEX/ RMF ENQ report shows nothing that would indicate an ENQ on JES2 CKPT by some other ASID. -- 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: SYSPLEX Hung
Without the SAD it's all going to be speculation. Have you setup AUTOIPL in DIAGxx to automatically take the SAD if the system fails? AUTOIPL SADMP(7B97,SYSC) MVS(*964C,79A222 ) as an example Salah Balboul<mailto:balbo...@att.net> April 19, 2018 at 2:18 PM Yes. Shared DASD within the SYSPLEX/ RMF ENQ report shows nothing that would indicate an ENQ on JES2 CKPT by some other ASID. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message: INFO IBM-MAIN Please be alert for any emails that may ask you for login information or directs you to login via a link. If you believe this message is a phish or aren't sure whether this message is trustworthy, please send the original message as an attachment to 'phish...@meredith.com<mailto:phish...@meredith.com>'. -- Mark Jacobs Time Customer Service Global Technology Services The standard you walk past is the standard you accept. Lt. Gen. David Morrison This electronic message, including any attachments, may contain proprietary, confidential or privileged information for the sole use of the intended recipient(s). You are hereby notified that any unauthorized disclosure, copying, distribution, or use of this message is prohibited. If you have received this message in error, please immediately notify the sender by reply e-mail and delete it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX Hung
What was in syslog in and around the HASP CKPT Lock message occurred? Do you have an automation tool that could monitor for it and issue commands? DS Q,,, D GRS,DEV=... And so forth? It sounds like a process is locking the volume that the ckpt is on rather than the ckpt dataset. Is it possible to place CKPT1 into a CF and leave CKPT2 on DASD? Might reduce your issues. Lizette > -Original Message- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of > Salah Balboul > Sent: Thursday, April 19, 2018 11:18 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: SYSPLEX Hung > > Yes. Shared DASD within the SYSPLEX/ RMF ENQ report shows nothing that would > indicate an ENQ on JES2 CKPT by some other ASID. > > -- > 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: SYSPLEX Hung
Yes. Shared DASD within the SYSPLEX/ RMF ENQ report shows nothing that would indicate an ENQ on JES2 CKPT by some other ASID. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX Hung
The OP could also try D GRS,C on the surviving system. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Thursday, April 19, 2018 1:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SYSPLEX Hung not sure if this would help, since I suspect maybe JES2 was a victim, of a deadly embrace. since you didn't get a chance to take a SADMP the RMF ENQ report may help diagnose an ENQ, or RESERVE issue. I'd like to also assume all shared DASD is within the same SYSPLEX? Carmen Vitullo - Original Message - From: "Salah Balboul" <balbo...@att.net> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, April 19, 2018 11:55:37 AM Subject: Re: SYSPLEX Hung In JES MAS, yes. CKPT on DASD. Nothing but ckpt on each DASD. -- 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 ::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: SYSPLEX Hung
not sure if this would help, since I suspect maybe JES2 was a victim, of a deadly embrace. since you didn't get a chance to take a SADMP the RMF ENQ report may help diagnose an ENQ, or RESERVE issue. I'd like to also assume all shared DASD is within the same SYSPLEX? Carmen Vitullo - Original Message - From: "Salah Balboul" <balbo...@att.net> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, April 19, 2018 11:55:37 AM Subject: Re: SYSPLEX Hung In JES MAS, yes. CKPT on DASD. Nothing but ckpt on each DASD. -- 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: SYSPLEX Hung
OPS didn't. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX Hung
In JES MAS, yes. CKPT on DASD. Nothing but ckpt on each DASD. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYSPLEX Hung
So, you are in a JES2 MAS? and CKPT's are on DASD, I'm hoping on a volume with nothing else on the volume, or is one CKPT on the CF? SFM policy's can save your loved LPARS, it's not a big deal defining one, just make sure you weight them correctly and update the policy to your needs. Carmen Vitullo - Original Message - From: "Salah Balboul" <balbo...@att.net> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, April 19, 2018 9:48:11 AM Subject: SYSPLEX Hung Hi, For the past week we've had 2 crashes due to one LPAR being hung in a two SYSPLEX LPAR causing sympathy sickness. In both cases the indication is $HASP263 message (Checkpoint lock), followed by *MASTER* pending on the JES2 CKPT volume. Finally IXC426D to partition the sick LPAR out. We do not have an SFM policy in effect, no changes done or maintenance applied. The problem LPAR SYSLOG stops recording approx 10-12 prior to IXC426D message. NO indication of any issues on problem LPAR. I wonder if anyone has seen this. I don't think JES2 is causing this, it is a victim. Thoughts? Thanks -- 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: SYSPLEX Hung
I have seen this happen with an extreme mismatch in LPAR weights. Check your MASDEF parameters. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Salah Balboul Sent: Thursday, April 19, 2018 9:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: SYSPLEX Hung Hi, For the past week we've had 2 crashes due to one LPAR being hung in a two SYSPLEX LPAR causing sympathy sickness. In both cases the indication is $HASP263 message (Checkpoint lock), followed by *MASTER* pending on the JES2 CKPT volume. Finally IXC426D to partition the sick LPAR out. We do not have an SFM policy in effect, no changes done or maintenance applied. The problem LPAR SYSLOG stops recording approx 10-12 prior to IXC426D message. NO indication of any issues on problem LPAR. I wonder if anyone has seen this. I don't think JES2 is causing this, it is a victim. Thoughts? Thanks -- 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: SYSPLEX Hung
Have you taken a SAD of the failed system? Mark Jacobs Salah Balboul<mailto:balbo...@att.net> April 19, 2018 at 10:48 AM Hi, For the past week we've had 2 crashes due to one LPAR being hung in a two SYSPLEX LPAR causing sympathy sickness. In both cases the indication is $HASP263 message (Checkpoint lock), followed by *MASTER* pending on the JES2 CKPT volume. Finally IXC426D to partition the sick LPAR out. We do not have an SFM policy in effect, no changes done or maintenance applied. The problem LPAR SYSLOG stops recording approx 10-12 prior to IXC426D message. NO indication of any issues on problem LPAR. I wonder if anyone has seen this. I don't think JES2 is causing this, it is a victim. Thoughts? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message: INFO IBM-MAIN Please be alert for any emails that may ask you for login information or directs you to login via a link. If you believe this message is a phish or aren't sure whether this message is trustworthy, please send the original message as an attachment to 'phish...@meredith.com<mailto:phish...@meredith.com>'. This electronic message, including any attachments, may contain proprietary, confidential or privileged information for the sole use of the intended recipient(s). You are hereby notified that any unauthorized disclosure, copying, distribution, or use of this message is prohibited. If you have received this message in error, please immediately notify the sender by reply e-mail and delete it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SYSPLEX Hung
Hi, For the past week we've had 2 crashes due to one LPAR being hung in a two SYSPLEX LPAR causing sympathy sickness. In both cases the indication is $HASP263 message (Checkpoint lock), followed by *MASTER* pending on the JES2 CKPT volume. Finally IXC426D to partition the sick LPAR out. We do not have an SFM policy in effect, no changes done or maintenance applied. The problem LPAR SYSLOG stops recording approx 10-12 prior to IXC426D message. NO indication of any issues on problem LPAR. I wonder if anyone has seen this. I don't think JES2 is causing this, it is a victim. Thoughts? Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sharing across two sysplex
On TWS one nit: You can't have the hot standby be in another plex as it communicates with the active controller using XCF. Probably not a show stopper. Martin Packer zChampion, Systems Investigator & Performance Troubleshooter, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2 Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Jesse 1 Robinson <jesse1.robin...@sce.com> To: IBM-MAIN@LISTSERV.UA.EDU Date: 23/03/2018 16:20 Subject:Re: Sharing across two sysplex Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> We have several sysplexes around the enterprise. Some resources are 'sharable', some not. A. Can we use a unique TWS controller to Schedule jobs on two? I don't know whether you can, but you don't need to. We have one 'TWS controller' for the whole enterprise; it controls everything. From the LPAR where we run the controller, most jobs get submitted to run on other systems/nodes. We also submit jobs to midrange (Unix). B. Can we use RACF RRSF to propagate our pwd over IP between them? We have used RRSF between sysplexes for decades. We happen to use APPC for the purpose, but I don't see why IP would not work. Just be aware the AFAIK *all* RACF values will be propagated, not just passwords. I would seriously question whether you want all userids from production to be replicated on dev. That's a business decision, not a technical one. C. Can we share dasd (write one side at a time, not pdse) with GRS (not MIM)? Absolutely not. Don't even consider it. You will go down in flames. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Fagen Sent: Tuesday, March 13, 2018 7:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Sharing across two sysplex Caught this on the newsgroup, not the LISTSERV: -- jean.b...@ca-attica.fr Hello. We are in the process to separate our current SYSPLEX in two : 1. for the production 2. for the dev/qualifications. A. Can we use an unique TWS controller to Schedule jobs on two ? B. Can we use RACF RRSF to propagate our pwd over IP between them ? C. Can we share dasd (write one side at a time, not pdse) with GRS (not MIM) ? Many Thank's - Answers: A. Yes, but there are recovery considerations. Have a look at https://urldefense.proofpoint.com/v2/url?u=http-3A__ibmsystemsmag.com_mainframe_administrator_tivoli_all-2Dschedules-2C-2Dall-2Dthe-2Dtime_=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ=SACkHo1IhhsLKFBRHQpeYGu7NlAm6NPhl86H1_9b7wo=y2iyJMpqwmErtFWlbl8FjYjOo-QM6oWsSz0JTm49K8s= B. Yes, but there are operational differences. Have a look at http://www.redbooks.ibm.com/abstracts/sg248041.html?Open C. That's a nuanced question. Can you share DASD between sysplexes? Sure. Can you count on the data on the DASD being maintained with integrity with only GRS, probably not. Without something like MIM, you will need to use some other form of serialization that spans the sysplexes. The only thing I'm aware of is to use hardware RESERVE/RELEASE, which is fraught with its own set of management issues. You can search this group for probably dozens of discussions on the advantages/disadvantages of a hardware vs. software solution. Do you have a need to share tapes and tape drives? Another set of things to think about Scott Fagen CPO - 21st Century Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sharing across two sysplex
We have several sysplexes around the enterprise. Some resources are 'sharable', some not. A. Can we use a unique TWS controller to Schedule jobs on two? I don't know whether you can, but you don't need to. We have one 'TWS controller' for the whole enterprise; it controls everything. From the LPAR where we run the controller, most jobs get submitted to run on other systems/nodes. We also submit jobs to midrange (Unix). B. Can we use RACF RRSF to propagate our pwd over IP between them? We have used RRSF between sysplexes for decades. We happen to use APPC for the purpose, but I don't see why IP would not work. Just be aware the AFAIK *all* RACF values will be propagated, not just passwords. I would seriously question whether you want all userids from production to be replicated on dev. That's a business decision, not a technical one. C. Can we share dasd (write one side at a time, not pdse) with GRS (not MIM)? Absolutely not. Don't even consider it. You will go down in flames. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Scott Fagen Sent: Tuesday, March 13, 2018 7:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Sharing across two sysplex Caught this on the newsgroup, not the LISTSERV: -- jean.b...@ca-attica.fr Hello. We are in the process to separate our current SYSPLEX in two : 1. for the production 2. for the dev/qualifications. A. Can we use an unique TWS controller to Schedule jobs on two ? B. Can we use RACF RRSF to propagate our pwd over IP between them ? C. Can we share dasd (write one side at a time, not pdse) with GRS (not MIM) ? Many Thank's - Answers: A. Yes, but there are recovery considerations. Have a look at http://ibmsystemsmag.com/mainframe/administrator/tivoli/all-schedules,-all-the-time/ B. Yes, but there are operational differences. Have a look at http://www.redbooks.ibm.com/abstracts/sg248041.html?Open C. That's a nuanced question. Can you share DASD between sysplexes? Sure. Can you count on the data on the DASD being maintained with integrity with only GRS, probably not. Without something like MIM, you will need to use some other form of serialization that spans the sysplexes. The only thing I'm aware of is to use hardware RESERVE/RELEASE, which is fraught with its own set of management issues. You can search this group for probably dozens of discussions on the advantages/disadvantages of a hardware vs. software solution. Do you have a need to share tapes and tape drives? Another set of things to think about Scott Fagen CPO - 21st Century Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: how do you handle shared ZFS in a sysplex
Thanks David that makes sense, and that's what I'm leaning towards. I had to make some concessions with some products, I was forced to create a symlink on the sysplex root because of how the users accessed some ISV products, so my symlink to a system specific filesystem for example '/web' links to /$SYSTEM/local/web so it removed this issues I'm was having with /usr/lpp (that was the old mount point) So, if I understand correctly you create a symlink for an ISV filesystem pointing to /$SYSTEM/usr/lpp ? something like ln -s /$SYSTEM/usr/lpp/RTCHIN /RTCHIN this would help if this works correctly... It's been hard to convince the team to allow me to remove the system specific filesystem that are identical and create one PLEX wide filesystem mounted @ //usr/lpp I think that would help greatly. my current structure. rwxrwxrwx 1 CPV8281 OMVSGRP 20 Mar 11 21:02 abinitio -> /SYSA/local/a binitio rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 bin -> $VERSION/bin rwxrwxrwx 1 CPV8281 OMVSGRP 9 Nov 14 10:33 cai -> /SYST/cai rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 dev -> $SYSNAME/dev rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 etc -> $SYSNAME/etc rwxrwxrwx 1 CPV8281 OMVSGRP 21 Mar 11 10:42 ftp -> /PLEX1/usr/local/ tp/ rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 lib -> $VERSION/lib rwxrwxrwx 1 CPV8281 OMVSGRP 21 Mar 13 07:58 nfs -> /PLEX1/usr/local/ fs/ rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 opt -> $VERSION/opt rwxrwxrwx 1 CPV8281 OMVSGRP 16 Sep 26 08:20 samples -> $VERSION/samp es rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 tmp -> $SYSNAME/tmp r-xr-xr-x 1664 CPV8281 TTY 0 Mar 16 08:53 u rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 usr -> $VERSION/usr rwxrwxrwx 1 CPV8281 OMVSGRP 12 Sep 26 08:20 var -> $SYSNAME/var rwxrwxrwx 1 CPV8281 OMVSGRP 15 Mar 11 06:57 web -> /SYSA/local/web SYSA:CPV8281:/ > let me know if I'm understanding you correcly thanks for your help Carmen Vitullo - Original Message - From: "David Jousma" <01a0403c5dc1-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, March 16, 2018 8:51:36 AM Subject: Re: how do you handle shared ZFS in a sysplex Yea, it gets a little complicated for the non-sysres stuff. We are shared ZFS across the sysplex. We do have a couple of one-off's in /usr/lpp/ as well. So, a couple of observations I made. You have two types of filesystems. 1) those that are shared across the sysplex, 2) those that are "system/environment" specific. We have SYSRES ZFS shared as part of $VERSION for all systems running on the same SYSRES, we also do a similar process for ISV ZFS, using system symbol. For stuff that wants to be in the shared space, like /usr/lpp but really isn’t a part of that, I use symbolic links in /usr/lpp to resolve to a location outside of that filesystem. In my case it's to a directory location that resides in a system specific filesystem. It could just as easily be in some other shared part of the directory tree however. TEC1:$ ls -al total 640 drwxr-xr-x 40 P0SJR OMVSGRP 8192 Oct 25 14:52 . drwxr-xr-x 10 P0SJR OMVSGRP 8192 Oct 25 14:51 .. drwxr-xr-x 9 P0SJR OMVSGRP 8192 Jan 4 10:13 IBM drwxr-xr-x 3 P0SJR OMVSGRP 8192 Apr 27 2017 NFS drwxr-xr-x 11 P0SJR OMVSGRP 8192 Dec 15 08:22 Printsrv drwxr-xr-x 3 P0SJR OMVSGRP 8192 Oct 20 17:34 TWS lrwxrwxrwx 1 P0SJR OMVSGRP 13 Oct 25 14:52 aqt -> /opt/fitb/aqt drwxr-xr-x 7 P0SJR OMVSGRP 8192 Oct 25 15:31 bcp drwxr-xr-x 8 P0SJR OMVSGRP 8192 Apr 27 2017 booksrv drwxr-xr-x 9 P0SJR OMVSGRP 8192 Apr 27 2017 cbclib lrwxrwxrwx 1 P0SJR OMVSGRP 16 Oct 25 14:52 cicsts -> /opt/fitb/cicsts drwxr-xr-x 6 P0SJR OMVSGRP 8192 Nov 13 2015 cobol I hope this helps. Feel free to contact me off-list if you want to compare notes. We've been in shared ZFS for a few years now, and while a lot of things to think of in the beginning, its been very easy to handle going forward. _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Friday, March 16, 2018 8:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: how do you handle shared ZFS in a sysplex **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I finally was able to migrate all HFS's to ZFS's, then design a shared ZFS environment with a sysplex root, version root and system(s) root. to facilitate this environment I IPL'd each LPAR from the same SYSRES and shared parmlib using symbols for system specific parms. What I'm wondering, is we have some products that are mounted @ /usr/lpp/, this of course is r
Re: how do you handle shared ZFS in a sysplex
Yea, it gets a little complicated for the non-sysres stuff. We are shared ZFS across the sysplex. We do have a couple of one-off's in /usr/lpp/ as well. So, a couple of observations I made. You have two types of filesystems. 1) those that are shared across the sysplex, 2) those that are "system/environment" specific. We have SYSRES ZFS shared as part of $VERSION for all systems running on the same SYSRES, we also do a similar process for ISV ZFS, using system symbol. For stuff that wants to be in the shared space, like /usr/lpp but really isn’t a part of that, I use symbolic links in /usr/lpp to resolve to a location outside of that filesystem. In my case it's to a directory location that resides in a system specific filesystem. It could just as easily be in some other shared part of the directory tree however. TEC1:$ ls -al total 640 drwxr-xr-x 40 P0SJROMVSGRP 8192 Oct 25 14:52 . drwxr-xr-x 10 P0SJROMVSGRP 8192 Oct 25 14:51 .. drwxr-xr-x 9 P0SJROMVSGRP 8192 Jan 4 10:13 IBM drwxr-xr-x 3 P0SJROMVSGRP 8192 Apr 27 2017 NFS drwxr-xr-x 11 P0SJROMVSGRP 8192 Dec 15 08:22 Printsrv drwxr-xr-x 3 P0SJROMVSGRP 8192 Oct 20 17:34 TWS lrwxrwxrwx 1 P0SJROMVSGRP 13 Oct 25 14:52 aqt -> /opt/fitb/aqt drwxr-xr-x 7 P0SJROMVSGRP 8192 Oct 25 15:31 bcp drwxr-xr-x 8 P0SJROMVSGRP 8192 Apr 27 2017 booksrv drwxr-xr-x 9 P0SJROMVSGRP 8192 Apr 27 2017 cbclib lrwxrwxrwx 1 P0SJROMVSGRP 16 Oct 25 14:52 cicsts -> /opt/fitb/cicsts drwxr-xr-x 6 P0SJROMVSGRP 8192 Nov 13 2015 cobol I hope this helps. Feel free to contact me off-list if you want to compare notes. We've been in shared ZFS for a few years now, and while a lot of things to think of in the beginning, its been very easy to handle going forward. _ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Friday, March 16, 2018 8:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: how do you handle shared ZFS in a sysplex **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I finally was able to migrate all HFS's to ZFS's, then design a shared ZFS environment with a sysplex root, version root and system(s) root. to facilitate this environment I IPL'd each LPAR from the same SYSRES and shared parmlib using symbols for system specific parms. What I'm wondering, is we have some products that are mounted @ /usr/lpp/, this of course is resolved to $VERSION/usr/lpp, someone had installed a product there and had 3 different filesystem mounts, one for each system, it works OK, until I had to IPL one system from a different sysres, the filesystem from the other 2 systems mounted @ /usr/lpp were unmounted and the new version file system was mounted from the system I IPL'd. because of this fact, batch processing that needed that filesystem on the OTHER systems failed looking for the original $VERSION/usr/lpp. maybe not such a clear explanation but I'm wondering what other do in this case. I forced the team to move any file systems that need to be shared to //. and products filesystems that need to be system specific mounted @ /$SYSTEM/. but I'm having an issue moving forward, and I think I'm going to have a problem when I migrate maint around the plex with a new sysres, will I? Any help would be greatly appreciated. -- 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 compu
how do you handle shared ZFS in a sysplex
I finally was able to migrate all HFS's to ZFS's, then design a shared ZFS environment with a sysplex root, version root and system(s) root. to facilitate this environment I IPL'd each LPAR from the same SYSRES and shared parmlib using symbols for system specific parms. What I'm wondering, is we have some products that are mounted @ /usr/lpp/, this of course is resolved to $VERSION/usr/lpp, someone had installed a product there and had 3 different filesystem mounts, one for each system, it works OK, until I had to IPL one system from a different sysres, the filesystem from the other 2 systems mounted @ /usr/lpp were unmounted and the new version file system was mounted from the system I IPL'd. because of this fact, batch processing that needed that filesystem on the OTHER systems failed looking for the original $VERSION/usr/lpp. maybe not such a clear explanation but I'm wondering what other do in this case. I forced the team to move any file systems that need to be shared to //. and products filesystems that need to be system specific mounted @ /$SYSTEM/. but I'm having an issue moving forward, and I think I'm going to have a problem when I migrate maint around the plex with a new sysres, will I? Any help would be greatly appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Sharing across two sysplex
Caught this on the newsgroup, not the LISTSERV: -- jean.b...@ca-attica.fr Hello. We are in the process to separate our current SYSPLEX in two : 1. for the production 2. for the dev/qualifications. A. Can we use an unique TWS controller to Schedule jobs on two ? B. Can we use RACF RRSF to propagate our pwd over IP between them ? C. Can we share dasd (write one side at a time, not pdse) with GRS (not MIM) ? Many Thank's - Answers: A. Yes, but there are recovery considerations. Have a look at http://ibmsystemsmag.com/mainframe/administrator/tivoli/all-schedules,-all-the-time/ B. Yes, but there are operational differences. Have a look at http://www.redbooks.ibm.com/abstracts/sg248041.html?Open C. That's a nuanced question. Can you share DASD between sysplexes? Sure. Can you count on the data on the DASD being maintained with integrity with only GRS, probably not. Without something like MIM, you will need to use some other form of serialization that spans the sysplexes. The only thing I'm aware of is to use hardware RESERVE/RELEASE, which is fraught with its own set of management issues. You can search this group for probably dozens of discussions on the advantages/disadvantages of a hardware vs. software solution. Do you have a need to share tapes and tape drives? Another set of things to think about Scott Fagen CPO - 21st Century Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Setting up a new parallel sysplex
I know this is not OP's first bronco ride in a sysplex rodeo, but I have a few more suggestions. -- Create a new unique name for the combined sysplex. -- Pick one (least critical) system and start there as the first member of the new sysplex. -- Once the new sysplex is running with this one member, add in a second member. -- Continue until all desired members have joined the new sysplex. -- All along the way make extensive use of symbolics in names. One suggestion for DSN is the suffix '$SYS'. '$SYS' (or whatever you choose) is a kind of marker that several similar data sets exist in the sysplex with identifying the owning member. . . 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 [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of fred glenlake Sent: Tuesday, February 06, 2018 8:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Setting up a new parallel sysplex Hi Kees and Allan, Thank you both for your suggestions. I greatly appreciate all the input I am receiving as I get through the "Insomnia Cure"I mean the IBM Red Book on Setting up a Sysplex. I will definitely include your input in my notes I am making as I read through the book. Fred G. From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Vernooij, Kees (ITOPT1) - KLM <kees.verno...@klm.com> Sent: February 6, 2018 8:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Setting up a new parallel sysplex In addition to that, if you are implementing LOGGER CF Logstreams: beware if you read about putting more than 1 Logstream in a CF structure. As I understand, these are old recommendations and it is often difficult to convert them to 1 Logstream per CF structure. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Allan Staller > Sent: 06 February, 2018 14:46 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Setting up a new parallel sysplex > > I would attempt to make any decisions regarding the CFRM policy first. > This is the one act with the most potential for "harm". > > Decide which structures you will want in the CF (GRS, JES,..) and > use CFSIZER to obtain sizing estimates. > (shared spool vs. multi-jesplex).. HSM is of particular interest since > it requires reconfiguration to run properly in a multi-image > environment. > Alter the CF LPAR(s) accordingly and then generate a new CFRM policy. > > Then proceed w/"sysplexification" of each component. > > This would also be a great time to review "new" features introduced in > earlier releases of z/OS for inclusion. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Fred Glenlake > Sent: Monday, February 5, 2018 3:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Setting up a new parallel sysplex > > Thank you Mr. Staller for the manual recommendation, I have downloaded > it (another 500+ pages of fun reading), and Yes TEST TEST TEST is > definitely the plan. > > Thank you Mr. Robinson for your input. I am a relatively new hire (6 > months) and I am still discovering where my predecessors hid all the > skeletons. However what I have learned thus far leads me to believe my > site has a fairly good unique naming convention and standards so I am > hoping adding a new lpar and merging it with the existing production > lpar should not have issues with duplicate names. If you or anyone > else could suggest a sequence of events to follow to get from "see > spot run/bronzeplex" sysplex to full parallel sysplex that would be greatly > appreciated. Not messing up what is already there in the current > coupling datasets and defining new ones to house all the new > structures I would think would be up near the very beginning of the process of > defining a new parallel sysplex. I need to make sure we have enough > memory available to house the new couple datasets in the coupling > facility. > > My own planning is to go through the process using our sandbox lpar > first and joining it with another test lpar before even considering > trying this out with the real production lpar. (Again thank you Mr. > Staller for the TEST TEST TEST advice, it was already carved in stone > in my hard head). > > I appreciate your advice and suggestions very much. > > Thank you again, > > Fred G. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Setting up a new parallel sysplex
Hi Kees and Allan, Thank you both for your suggestions. I greatly appreciate all the input I am receiving as I get through the "Insomnia Cure"I mean the IBM Red Book on Setting up a Sysplex. I will definitely include your input in my notes I am making as I read through the book. Fred G. From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Vernooij, Kees (ITOPT1) - KLM <kees.verno...@klm.com> Sent: February 6, 2018 8:56 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Setting up a new parallel sysplex In addition to that, if you are implementing LOGGER CF Logstreams: beware if you read about putting more than 1 Logstream in a CF structure. As I understand, these are old recommendations and it is often difficult to convert them to 1 Logstream per CF structure. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Allan Staller > Sent: 06 February, 2018 14:46 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Setting up a new parallel sysplex > > I would attempt to make any decisions regarding the CFRM policy first. > This is the one act with the most potential for "harm". > > Decide which structures you will want in the CF (GRS, JES,..) and > use CFSIZER to obtain sizing estimates. > (shared spool vs. multi-jesplex).. HSM is of particular interest since > it requires reconfiguration to run properly in a multi-image > environment. > Alter the CF LPAR(s) accordingly and then generate a new CFRM policy. > > Then proceed w/"sysplexification" of each component. > > This would also be a great time to review "new" features introduced in > earlier releases of z/OS for inclusion. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Fred Glenlake > Sent: Monday, February 5, 2018 3:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Setting up a new parallel sysplex > > Thank you Mr. Staller for the manual recommendation, I have downloaded > it (another 500+ pages of fun reading), and Yes TEST TEST TEST is > definitely the plan. > > Thank you Mr. Robinson for your input. I am a relatively new hire (6 > months) and I am still discovering where my predecessors hid all the > skeletons. However what I have learned thus far leads me to believe my > site has a fairly good unique naming convention and standards so I am > hoping adding a new lpar and merging it with the existing production > lpar should not have issues with duplicate names. If you or anyone > else could suggest a sequence of events to follow to get from "see spot > run/bronzeplex" sysplex to full parallel sysplex that would be greatly > appreciated. Not messing up what is already there in the current > coupling datasets and defining new ones to house all the new structures > I would think would be up near the very beginning of the process of > defining a new parallel sysplex. I need to make sure we have enough > memory available to house the new couple datasets in the coupling > facility. > > My own planning is to go through the process using our sandbox lpar > first and joining it with another test lpar before even considering > trying this out with the real production lpar. (Again thank you Mr. > Staller for the TEST TEST TEST advice, it was already carved in stone in > my hard head). > > I appreciate your advice and suggestions very much. > > Thank you again, > > Fred G. > > -- > 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,
Re: Setting up a new parallel sysplex
In addition to that, if you are implementing LOGGER CF Logstreams: beware if you read about putting more than 1 Logstream in a CF structure. As I understand, these are old recommendations and it is often difficult to convert them to 1 Logstream per CF structure. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Allan Staller > Sent: 06 February, 2018 14:46 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Setting up a new parallel sysplex > > I would attempt to make any decisions regarding the CFRM policy first. > This is the one act with the most potential for "harm". > > Decide which structures you will want in the CF (GRS, JES,..) and > use CFSIZER to obtain sizing estimates. > (shared spool vs. multi-jesplex).. HSM is of particular interest since > it requires reconfiguration to run properly in a multi-image > environment. > Alter the CF LPAR(s) accordingly and then generate a new CFRM policy. > > Then proceed w/"sysplexification" of each component. > > This would also be a great time to review "new" features introduced in > earlier releases of z/OS for inclusion. > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Fred Glenlake > Sent: Monday, February 5, 2018 3:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Setting up a new parallel sysplex > > Thank you Mr. Staller for the manual recommendation, I have downloaded > it (another 500+ pages of fun reading), and Yes TEST TEST TEST is > definitely the plan. > > Thank you Mr. Robinson for your input. I am a relatively new hire (6 > months) and I am still discovering where my predecessors hid all the > skeletons. However what I have learned thus far leads me to believe my > site has a fairly good unique naming convention and standards so I am > hoping adding a new lpar and merging it with the existing production > lpar should not have issues with duplicate names. If you or anyone > else could suggest a sequence of events to follow to get from "see spot > run/bronzeplex" sysplex to full parallel sysplex that would be greatly > appreciated. Not messing up what is already there in the current > coupling datasets and defining new ones to house all the new structures > I would think would be up near the very beginning of the process of > defining a new parallel sysplex. I need to make sure we have enough > memory available to house the new couple datasets in the coupling > facility. > > My own planning is to go through the process using our sandbox lpar > first and joining it with another test lpar before even considering > trying this out with the real production lpar. (Again thank you Mr. > Staller for the TEST TEST TEST advice, it was already carved in stone in > my hard head). > > I appreciate your advice and suggestions very much. > > Thank you again, > > Fred G. > > -- > 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. > > >
Re: Setting up a new parallel sysplex
I would attempt to make any decisions regarding the CFRM policy first. This is the one act with the most potential for "harm". Decide which structures you will want in the CF (GRS, JES,..) and use CFSIZER to obtain sizing estimates. (shared spool vs. multi-jesplex).. HSM is of particular interest since it requires reconfiguration to run properly in a multi-image environment. Alter the CF LPAR(s) accordingly and then generate a new CFRM policy. Then proceed w/"sysplexification" of each component. This would also be a great time to review "new" features introduced in earlier releases of z/OS for inclusion. HTH, -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Fred Glenlake Sent: Monday, February 5, 2018 3:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Setting up a new parallel sysplex Thank you Mr. Staller for the manual recommendation, I have downloaded it (another 500+ pages of fun reading), and Yes TEST TEST TEST is definitely the plan. Thank you Mr. Robinson for your input. I am a relatively new hire (6 months) and I am still discovering where my predecessors hid all the skeletons. However what I have learned thus far leads me to believe my site has a fairly good unique naming convention and standards so I am hoping adding a new lpar and merging it with the existing production lpar should not have issues with duplicate names. If you or anyone else could suggest a sequence of events to follow to get from "see spot run/bronzeplex" sysplex to full parallel sysplex that would be greatly appreciated. Not messing up what is already there in the current coupling datasets and defining new ones to house all the new structures I would think would be up near the very beginning of the process of defining a new parallel sysplex. I need to make sure we have enough memory available to house the new couple datasets in the coupling facility. My own planning is to go through the process using our sandbox lpar first and joining it with another test lpar before even considering trying this out with the real production lpar. (Again thank you Mr. Staller for the TEST TEST TEST advice, it was already carved in stone in my hard head). I appreciate your advice and suggestions very much. Thank you again, Fred G. -- 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: Setting up a new parallel sysplex
Thank you Mr. Staller for the manual recommendation, I have downloaded it (another 500+ pages of fun reading), and Yes TEST TEST TEST is definitely the plan. Thank you Mr. Robinson for your input. I am a relatively new hire (6 months) and I am still discovering where my predecessors hid all the skeletons. However what I have learned thus far leads me to believe my site has a fairly good unique naming convention and standards so I am hoping adding a new lpar and merging it with the existing production lpar should not have issues with duplicate names. If you or anyone else could suggest a sequence of events to follow to get from "see spot run/bronzeplex" sysplex to full parallel sysplex that would be greatly appreciated. Not messing up what is already there in the current coupling datasets and defining new ones to house all the new structures I would think would be up near the very beginning of the process of defining a new parallel sysplex. I need to make sure we have enough memory available to house the new couple datasets in the coupling facility. My own planning is to go through the process using our sandbox lpar first and joining it with another test lpar before even considering trying this out with the real production lpar. (Again thank you Mr. Staller for the TEST TEST TEST advice, it was already carved in stone in my hard head). I appreciate your advice and suggestions very much. Thank you again, Fred G. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
