I'm working on setting up a CTC-only Basic Sysplex (not Parallel, no-CF's). From what I read, basic plexes don't scale well, as ENQs have to go around to each system, which may be why your IBM guy advised against it.
Ken This is from z/OS 1.13 DFSMS Using data Sets SC26-7410-11 https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.idad400/d4322.htm%23d4322 Choosing Volumes for PDSEs in a Sysplex PDSEs are designed to be shared within a sysplex. When choosing volumes for PDSEs in a sysplex, be sure to follow these rules: - The volume serials for volumes that contain PDSEs must be unique within a sysplex. - A volume that contains PDSEs must not be open from more than one GRS complex at a time. - If PDSE extended sharing is active, a volume that contains a PDSE cannot be accessed from more than one sysplex at a time. In this context, a sysplex is all systems that can connect in a single XCF group, and a GRS complex is all the systems in a GRS configuration. A sysplex never spans more than one GRS complex. Note: for extended sharing, a PDSE can only be shared by the members of a GRS complex that are also members of the same sysplex. For example: in a six-system GRS complex, with four of the systems within the sysplex and two which are not, PDSEs can have extended sharing between the four members of the sysplex, but not the other two, non-sysplex systems. See z/OS MVS Planning: Global Resource Serialization <https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ieag400/iea2g4a1.htm?lang=en-us> for more information about the configurations that make up a GRS complex. If these volume assignment rules are not followed for PDSEs in a sysplex, data set accessibility or integrity may be impacted. On Mon, Apr 4, 2016 at 1:46 PM, Dyck, Lionel B. (TRA) <lionel.d...@va.gov> wrote: > Thank you - I've come to the conclusion that we should be in a single > sysplex so we have grs protecting every device. Now the discussion begins > :-) > > > -------------------------------------------------------------------------- > Lionel B. Dyck (Contractor) > Mainframe Systems Programmer > Enterprise Infrastructure Support (Station 200) (005OP6.3.10) > VA OI&T Service Delivery & Engineering > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Joseph W Gentile > Sent: Monday, April 04, 2016 12:41 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [EXTERNAL] Re: Advice needed - GRS across 2 sysplexes with shared > dasd > > Hello Lionel, > > Regarding your OP, GRS ENQs are generally obtained at the GRS complex > level, by various operating system programs and other applications that do > I/O. GRS only knows about its own complex, not another GRS complex. In your > description it sounds like you have two GRS complexes one for prod and one > for test. The GRS complex usually matches the Sysplex unless you are using > GRS Ring with GRS managed CTCs. The two complexes do not communicate ENQs > between one another. If the two complexes collide on the same resource, > data corruption can occur. Some resources can be safely shared outside the > complex by using RESERVE. You can code the RNLs to exclude a resource from > global processing and thus propagate the HW RESERVE. But not all > applications doing I/O use RESERVE so this method is not sufficient > protection, unless you know the resource is protected by RESERVE from > product documentation. A CATALOG is one of those resources you can > serialize with RESERVE and here is an info APAR that explains how to code > your RNLs for that: > http://www-01.ibm.com/support/docview.wss?uid=isg1II14297. Note that only > protects the catalog from corruption and not the datasets themselves. > RESERVE has its own risks, particularly a higher chance for contention, > because only one system can own the RESERVE (which locks the whole volume) > at a time. > > -Joe > > Joe Gentile > z/OS GRS Lead > jwgen...@us.ibm.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
