Re: Remove a system from a SYSPLEX but keep it in the GRS ring
> "(in XCFLOCAL mode)" I am pretty sure XCFLOCAL will not work in the GRSPLEX. I believe the doc states that the system must be a MONOPLEX for GRS to be active. If you want this rescue system to be XCFLOCAL, you will have to keep it outside of a GRSPLEX, and then risk lockout or corruption due to RESERVE or invalid sharing. This is not my recommendation, unless the system is down all of the time, except for real rescue attempts. > "run with CLOCKxx set to ETRMODE=NO?" I believe this will work for the MONOPLEX system but I have not actually tried this. Our MONOPLEXes are still using the ETR. regards, Joe D'Alessandro -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Remove a system from a SYSPLEX but keep it in the GRS ring
On Wednesday, September 5, 2012 2:53:45 AM UTC+10, Joe D'Alessandro wrote: > We have done this to two 3-system parallel sysplexes. One system was removed > from each 3-system sysplex and the removed systems were each defined as a > monoplex and rejoined to their former partners in a GRSPLEX. So we now have > two GRSPLEXes: each with a 2-system parallel sysplex GRS'd with a monoplex. > > > > The complications were few but could be significant depending on your site. > The clients only had one issue, and that was due to PDSE sharing. > > > > () We left the system names and the SMFID names the same but gave the > monoplexes new sysplex names, which affected one system component and a few > STC PROCs. > > > > () PDSE sharing had to be downgraded to NORMAL for all three systems in each > GRSPLEX, which is very problematic if the systems really share PDSEs for > UPDATE because NORMAL is very restrictive (read the PDSE Usage Guide > closely), so many PDSEs had to be cloned so that there is now one PDSE per > system (that is, for many PDSEs, we went from one PDSE for 3 systems with > ENHANCED sharing to three PDSEs, each for one system with NORMAL sharing). > Fault Analyzer PDSEs and lnklst PDSEs were the most affected. SMSPDSE1 is no > longer active with NORMAL sharing. > > > > () The GRS CTCs had to be defined as BCTC so an HCD gen was required. > > > > () ECS must be turned off so one may see a performance impact > > > > () Automatic tape sharing cannot cross the sysplex boundary so the tape > drives had to be divided, but the systems in the sysplex could still handle > their drives on their own. > > > > () Obviously, the monoplex cannot still participate in the sysplex's spool, > so you may need to setup a spool and NJE. Depending on how you submit jobs, > this may or may not become another issue (like, for a scheduler or restart > subsystem). > > > > () Some components that use XCF must be reconfigured to use TCPIP or SNA to > communicate, like CCI and Mainview. > > > > There are other issues like BRODCAST and DAE but they are minor. The biggest > loss after PDSE sharing was in recovery. A crash or even normal shutdown > must be responded to carefully or GRS may just turn off across the remaining > GRS members. GRS can be restarted but it is not always obvious that this has > happened as message fly past. You may want to ensure that automation grabs > all the messages, if you have automation, to alert the operator and instruct > the operator how to restart GRS on the remaining members. > > > > regards, Joe D'Alessandro > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Thanks all for your useful replies. The system to be taken out of the sysplex is going to disappear soon anyway (it has no 'real' users), I just wanted to turn it into a 'rescue' system that was still part of the GRS complex. All of the GRS CTCS are defined OK, it's non-ECS and although PDSESHARING is on, I don't believe any are really shared for update. The JES spool is already separate. One other specific question relates to the CLOCK - there is a sysplex timer in use by the plexed systems (even though the images are running on the same CEC), so could the newly un-plexed system (in XCFLOCAL mode) run with CLOCKxx set to ETRMODE=NO? What I'm getting at is whether the GRS complex would be OK with two systems using a timer and one not? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Remove a system from a SYSPLEX but keep it in the GRS ring
We have done this to two 3-system parallel sysplexes. One system was removed from each 3-system sysplex and the removed systems were each defined as a monoplex and rejoined to their former partners in a GRSPLEX. So we now have two GRSPLEXes: each with a 2-system parallel sysplex GRS'd with a monoplex. The complications were few but could be significant depending on your site. The clients only had one issue, and that was due to PDSE sharing. () We left the system names and the SMFID names the same but gave the monoplexes new sysplex names, which affected one system component and a few STC PROCs. () PDSE sharing had to be downgraded to NORMAL for all three systems in each GRSPLEX, which is very problematic if the systems really share PDSEs for UPDATE because NORMAL is very restrictive (read the PDSE Usage Guide closely), so many PDSEs had to be cloned so that there is now one PDSE per system (that is, for many PDSEs, we went from one PDSE for 3 systems with ENHANCED sharing to three PDSEs, each for one system with NORMAL sharing). Fault Analyzer PDSEs and lnklst PDSEs were the most affected. SMSPDSE1 is no longer active with NORMAL sharing. () The GRS CTCs had to be defined as BCTC so an HCD gen was required. () ECS must be turned off so one may see a performance impact () Automatic tape sharing cannot cross the sysplex boundary so the tape drives had to be divided, but the systems in the sysplex could still handle their drives on their own. () Obviously, the monoplex cannot still participate in the sysplex's spool, so you may need to setup a spool and NJE. Depending on how you submit jobs, this may or may not become another issue (like, for a scheduler or restart subsystem). () Some components that use XCF must be reconfigured to use TCPIP or SNA to communicate, like CCI and Mainview. There are other issues like BRODCAST and DAE but they are minor. The biggest loss after PDSE sharing was in recovery. A crash or even normal shutdown must be responded to carefully or GRS may just turn off across the remaining GRS members. GRS can be restarted but it is not always obvious that this has happened as message fly past. You may want to ensure that automation grabs all the messages, if you have automation, to alert the operator and instruct the operator how to restart GRS on the remaining members. regards, Joe D'Alessandro -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Remove a system from a SYSPLEX but keep it in the GRS ring
If you've run for some time with these systems sysplexed, you--and your user community--may be surprised at the functionality you will lose. I'm sure that you have good business reasons for dismantling the sysplex, but there may be less disruptive alternatives. For example, some time ago we bolted together two formerly separate sysplexes. They run independently in may ways, including separate JES2 complexes and RACF data bases, but they share a common GRS environment. Now this happens to be a parallel sysplex with coupling facility, but you may have options within a basic sysplex as well. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Scott Fagen To: IBM-MAIN@LISTSERV.UA.EDU Date: 09/04/2012 08:46 AM Subject: Re: Remove a system from a SYSPLEX but keep it in the GRS ring Sent by:IBM Mainframe Discussion List It can be done, you need to define and connect CTCs between all the non-sysplex system(s) and the sysplex systems (see GRSCNFxx http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ieae200%2Fgrscnf.htm ). If you don't fully interconnect the non-sysplex system(s) with the sysplex, there is a potential for creating situations where only a subset (or none) of the complex will continue when a system leaves the ring (you can read about that in Planning: GRS, http://publib.boulder.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.ieag400/oldsplx.htm#oldsplx ). Adding non-sysplex systems to the GRS complex also turns off a bunch of sysplex-exclusive goodies while those systems are active in the GRS complex, e.g. fully automated recovery from system failures and dynamic RNL changes, implying you have to design and implement local processes to deal with those events. Scott Fagen Chief Architect - Mainframe CA Technologies On Tue, 4 Sep 2012 16:12:03 +1000, Gregory Peck (CITEC) wrote: -snip- >Any real world experiences on bringing up a system that was previously part of a basic SYSPLEX, >whilst keeping it in the same GRS ring as the other SYSPLEX members? -snip- >Any obvious gotchas from the GRS point of view? > >Thanks, >Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Remove a system from a SYSPLEX but keep it in the GRS ring
It can be done, you need to define and connect CTCs between all the non-sysplex system(s) and the sysplex systems (see GRSCNFxx http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.ieae200%2Fgrscnf.htm). If you don't fully interconnect the non-sysplex system(s) with the sysplex, there is a potential for creating situations where only a subset (or none) of the complex will continue when a system leaves the ring (you can read about that in Planning: GRS, http://publib.boulder.ibm.com/infocenter/zos/v1r12/topic/com.ibm.zos.r12.ieag400/oldsplx.htm#oldsplx). Adding non-sysplex systems to the GRS complex also turns off a bunch of sysplex-exclusive goodies while those systems are active in the GRS complex, e.g. fully automated recovery from system failures and dynamic RNL changes, implying you have to design and implement local processes to deal with those events. Scott Fagen Chief Architect - Mainframe CA Technologies On Tue, 4 Sep 2012 16:12:03 +1000, Gregory Peck (CITEC) wrote: -snip- >Any real world experiences on bringing up a system that was previously part of >a basic SYSPLEX, >whilst keeping it in the same GRS ring as the other SYSPLEX members? -snip- >Any obvious gotchas from the GRS point of view? > >Thanks, >Greg > > > > >* Disclaimer * > >The contents of this electronic message and any attachments are intended only >for the addressee and may contain privileged or confidential information. They >may only be used for the purposes for which they were supplied. If you are not >the addressee, you are notified that any transmission, distribution, >downloading, printing or photocopying of the contents of this message or >attachments is strictly prohibited. The privilege of confidentiality attached >to this message and attachments is not waived, lost or destroyed by reason of >mistaken delivery to you. If you receive this message in error please notify >the sender by return e-mail or telephone. > >Please note: the Department of Science, Information Technology, Innovation and >the Arts carries out automatic software scanning, filtering and blocking of >E-mails and attachments (including emails of a personal nature) for detection >of viruses, malicious code, SPAM, executable programs or content it deems >unacceptable. All reasonable precautions will be taken to respect the privacy >of individuals in accordance with the Information Privacy Act 2009 (Qld). >Personal information will only be used for official purposes, e.g. monitoring >Departmental Personnel's compliance with Departmental Policies. Personal >information will not be divulged or disclosed to others, unless authorised or >required by Departmental Policy and/or law. > > >-- >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: Remove a system from a SYSPLEX but keep it in the GRS ring
It is possible, according to: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2g490/3.2.2 Note: Global resource serialization ring complexes can contain XCFLOCAL, MONOPLEX, or systems that are part of a multisystem sysplex. However, only one multisystem sysplex can exist in any global resource serialization complex. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Staller, Allan > Sent: Tuesday, September 04, 2012 9:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Remove a system from a SYSPLEX but keep it in the GRS ring > > AFAIK, this will not work. Proceed at your own risk. The issue is GRS > communication between the XCFLOCAL (or MONOPLEX) and SYSPLEX. > > If you have MIA/MIM from CA, this (again AFAIK) will allow what you > have described. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Remove a system from a SYSPLEX but keep it in the GRS ring
AFAIK, this will not work. Proceed at your own risk. The issue is GRS communication between the XCFLOCAL (or MONOPLEX) and SYSPLEX. If you have MIA/MIM from CA, this (again AFAIK) will allow what you have described. Any real world experiences on bringing up a system that was previously part of a basic SYSPLEX, whilst keeping it in the same GRS ring as the other SYSPLEX members? The idea is to bring up this system in XCFLOCAL mode, but I'd still like to have it in the same GRS ring as before (for access to the shared DASD). I'm aware of the SYSPLEX bits in ICHRDSNT - they won't be an issue as a different RACF database will be used. Any obvious gotchas from the GRS point of view? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Remove a system from a SYSPLEX but keep it in the GRS ring
Hi, Any real world experiences on bringing up a system that was previously part of a basic SYSPLEX, whilst keeping it in the same GRS ring as the other SYSPLEX members? The idea is to bring up this system in XCFLOCAL mode, but I'd still like to have it in the same GRS ring as before (for access to the shared DASD). I'm aware of the SYSPLEX bits in ICHRDSNT - they won't be an issue as a different RACF database will be used. Any obvious gotchas from the GRS point of view? Thanks, Greg * Disclaimer * The contents of this electronic message and any attachments are intended only for the addressee and may contain privileged or confidential information. They may only be used for the purposes for which they were supplied. If you are not the addressee, you are notified that any transmission, distribution, downloading, printing or photocopying of the contents of this message or attachments is strictly prohibited. The privilege of confidentiality attached to this message and attachments is not waived, lost or destroyed by reason of mistaken delivery to you. If you receive this message in error please notify the sender by return e-mail or telephone. Please note: the Department of Science, Information Technology, Innovation and the Arts carries out automatic software scanning, filtering and blocking of E-mails and attachments (including emails of a personal nature) for detection of viruses, malicious code, SPAM, executable programs or content it deems unacceptable. All reasonable precautions will be taken to respect the privacy of individuals in accordance with the Information Privacy Act 2009 (Qld). Personal information will only be used for official purposes, e.g. monitoring Departmental Personnel's compliance with Departmental Policies. Personal information will not be divulged or disclosed to others, unless authorised or required by Departmental Policy and/or law. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
