Re: Parallel Sysplex split
But for any future dynamic activations, I darn well better be cataloged and at IPL time. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Tuesday, February 17, 2015 11:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: Parallel Sysplex split That's not true in our case. We share the IODF between two sysplexes, it is cataloged in a user catalog that is connected to the master catalogs of all systems in both sysplexes. For the purpose of the IPL, the IODF does not need to be cataloged at all. You designate the IODF volume via its unit address in the LOADPARM (pos. 1-4). The DSN of the IODF to be used is then specified in the LOADxx member (suffix specified via LOADPARM, pos. 5-6). The LOADxx member is searched in SYSx.IPLPARM (x=0, 1, ..., 9) or SYS1.PARMLIB on the IODF volume and finally in SYS1.PARMLIB on the IPL volume. No catalog is involved in all of this. -- Peter Hunkeler -- 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: Parallel Sysplex split
That's why it is good idea to have small shared usercat with yourHLQ.IODFnn cataloged. Both usercat and IODFs on shared volume. -- Radoslaw Skorupka Lodz, Poland W dniu 2015-02-18 o 09:52, Gibney, Dave pisze: But for any future dynamic activations, I darn well better be cataloged and at IPL time. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Tuesday, February 17, 2015 11:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: Parallel Sysplex split That's not true in our case. We share the IODF between two sysplexes, it is cataloged in a user catalog that is connected to the master catalogs of all systems in both sysplexes. For the purpose of the IPL, the IODF does not need to be cataloged at all. You designate the IODF volume via its unit address in the LOADPARM (pos. 1-4). The DSN of the IODF to be used is then specified in the LOADxx member (suffix specified via LOADPARM, pos. 5-6). The LOADxx member is searched in SYSx.IPLPARM (x=0, 1, ..., 9) or SYS1.PARMLIB on the IODF volume and finally in SYS1.PARMLIB on the IPL volume. No catalog is involved in all of this. -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc 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.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2015 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.840.228 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parallel Sysplex split
There is a tool around somewhere, called FTPB (FTP in Batch). It does this in batch, surrounded by an ISPF application which lets you selects datasets/groups and destinations. We adapted it to our needs and send everything forth and back over the big walls separating our sysplexes. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of J O Skip Robinson Sent: 18 February, 2015 17:34 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Parallel Sysplex split DSS/FTP is a perfectly respectable way to migrate an IODF around the enterprise. We happen to use the 'native' mechanism described in SAMPLIB member CBDSEXPU. This entails a batch job that sends the IODF from the source system to the target system. All you need is NJE. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Wednesday, February 18, 2015 8:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Parallel Sysplex split Same here. No reason to share that stuff. Just use DFDSS, dump the IODF, FTP it to the other locations, and restore it. _ Dave Jousma Assistant Vice President, Mainframe Engineering 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 J O Skip Robinson Sent: Wednesday, February 18, 2015 10:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Parallel Sysplex split Catalog is not an issue (except that IODF should be cataloged somewhere), but location is. The PDS containing LOADxx must be on the same volume as the IODF. Let's call that IPLPARM. Sharing IODF means also sharing IPLPARM. It does not get edited very often, but putting it outside of GRS introduces some risk. If IPLPARM gets damaged, you're pretty much SOL for every system that shares it. We have seven sysplexes. Almost nothing is shared across boundaries, including IODF and IPLPARM. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Tuesday, February 17, 2015 11:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: Parallel Sysplex split That's not true in our case. We share the IODF between two sysplexes, it is cataloged in a user catalog that is connected to the master catalogs of all systems in both sysplexes. For the purpose of the IPL, the IODF does not need to be cataloged at all. You designate the IODF volume via its unit address in the LOADPARM (pos. 1-4). The DSN of the IODF to be used is then specified in the LOADxx member (suffix specified via LOADPARM, pos. 5-6). The LOADxx member is searched in SYSx.IPLPARM (x=0, 1, ..., 9) or SYS1.PARMLIB on the IODF volume and finally in SYS1.PARMLIB on the IPL volume. No catalog is involved in all of this. -- Peter Hunkeler -- 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: Parallel Sysplex split
On 02/17/2015 03:58 AM, Jaco Kruger wrote: The following components are shared between Development and Production environments The following components are not shared between Development and Production environments Jaco, it's not clear from your post if these passages describe the current=before-split actual state or the future=after-split desired state. As others have mentioned, if this is desired state you can't do (all of) that... or where you sort of can, it's not the commonly held meaning of sharing (more on that below, using zWLM as an example). Looking at the Merging doc is a good choice. To the degree the whys are described in there, look for cases where it's not merely which systems force the change, but which _work_. zWLM example (disclaimer: in a prior life, I was one of the lead perpetrators of goal mode, starting with WSM, but I've been out of that group for 10 years). Velocity goals are intimately dependent on the volume of work, number of CPUs, etc.; see my CMG95 paper for gory details. Regardless of goal type, if you have service classes that before-split run work from both production and development, splitting that workload (which you have no choice in, once you split the sysplex ... WLM doesn't cross sysplex boundaries, period) means that the subset of the workload characterization data each after-split WLM instance sees will be different. Potentially very different. Thus, policy goals will need to be adjusted. The degree of pain associated with this very much depends on the degree to which your before-split policy already separates production and devt work in to distinct service classes. If the before-split policy pretty much partitions work already, then it's only cross-service class effects coupled with how much of the machine is available to any given class/period that dominates. If they're all mashed together today, its hard to say much more than things will change; if you can partition their reporting before hand, that will help. But you should plan on watching prod Very Carefully after the split to see where goals need to be adjusted, in any case, unless you're system is fundamentally unconstrained. If your policy goals don't work as desired when it IS constrained, you have an upstream problem. Crazy example: if your prod work was all discretionary (below dev), and system CPU is 50%, you might never notice. If something starts looping and the CPU is now at 100%, you Will notice. The only sort of cross-sysplex WLM thing you can do is about managing the service definition, not what happens at run time. You can, if you want, use a single service definition master copy that you clone across all these (2, here) sysplexes; basically, edit the master whereever it is, export it to a file, move/copy the file (clone it), import it in the other sysplexes. Some people do that; you generally set up service classes and classification rules so that any given sysplex only runs work in its subset of the classes. Having extra classes that never receive work in a given sysplex causes minimal overhead. Other more complicated (more shared) svdefs can be created, but I doubt anyone outside of WLM devt could actually manage it effectively... just too easy to make a mistake. If, in your dev/prod case, dev is just a mirror of prod used as a staging area (same work, running in same srvclasses, just with looser goals), then the master svdef makes good sense - you can keep the classification rules identical, and just have separate policies activated for dev vs prod. Be wary of creep though - often when dev starts out as a mirrored staging area for prod, over time it gets other work dumped in there never intended to hit prod, i.e. it drifts away from being a simple mirror/staging area. The further it drifts, the less a shared svdef makes sense. -- John Arwe IBM z/VM OpenStack and zKVM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parallel Sysplex split
Catalog is not an issue (except that IODF should be cataloged somewhere), but location is. The PDS containing LOADxx must be on the same volume as the IODF. Let's call that IPLPARM. Sharing IODF means also sharing IPLPARM. It does not get edited very often, but putting it outside of GRS introduces some risk. If IPLPARM gets damaged, you're pretty much SOL for every system that shares it. We have seven sysplexes. Almost nothing is shared across boundaries, including IODF and IPLPARM. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Tuesday, February 17, 2015 11:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: Parallel Sysplex split That's not true in our case. We share the IODF between two sysplexes, it is cataloged in a user catalog that is connected to the master catalogs of all systems in both sysplexes. For the purpose of the IPL, the IODF does not need to be cataloged at all. You designate the IODF volume via its unit address in the LOADPARM (pos. 1-4). The DSN of the IODF to be used is then specified in the LOADxx member (suffix specified via LOADPARM, pos. 5-6). The LOADxx member is searched in SYSx.IPLPARM (x=0, 1, ..., 9) or SYS1.PARMLIB on the IODF volume and finally in SYS1.PARMLIB on the IPL volume. No catalog is involved in all of this. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parallel Sysplex split
Same here. No reason to share that stuff. Just use DFDSS, dump the IODF, FTP it to the other locations, and restore it. _ Dave Jousma Assistant Vice President, Mainframe Engineering 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 J O Skip Robinson Sent: Wednesday, February 18, 2015 10:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Parallel Sysplex split Catalog is not an issue (except that IODF should be cataloged somewhere), but location is. The PDS containing LOADxx must be on the same volume as the IODF. Let's call that IPLPARM. Sharing IODF means also sharing IPLPARM. It does not get edited very often, but putting it outside of GRS introduces some risk. If IPLPARM gets damaged, you're pretty much SOL for every system that shares it. We have seven sysplexes. Almost nothing is shared across boundaries, including IODF and IPLPARM. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Tuesday, February 17, 2015 11:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: Parallel Sysplex split That's not true in our case. We share the IODF between two sysplexes, it is cataloged in a user catalog that is connected to the master catalogs of all systems in both sysplexes. For the purpose of the IPL, the IODF does not need to be cataloged at all. You designate the IODF volume via its unit address in the LOADPARM (pos. 1-4). The DSN of the IODF to be used is then specified in the LOADxx member (suffix specified via LOADPARM, pos. 5-6). The LOADxx member is searched in SYSx.IPLPARM (x=0, 1, ..., 9) or SYS1.PARMLIB on the IODF volume and finally in SYS1.PARMLIB on the IPL volume. No catalog is involved in all of this. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parallel Sysplex split
DSS/FTP is a perfectly respectable way to migrate an IODF around the enterprise. We happen to use the 'native' mechanism described in SAMPLIB member CBDSEXPU. This entails a batch job that sends the IODF from the source system to the target system. All you need is NJE. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Wednesday, February 18, 2015 8:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Parallel Sysplex split Same here. No reason to share that stuff. Just use DFDSS, dump the IODF, FTP it to the other locations, and restore it. _ Dave Jousma Assistant Vice President, Mainframe Engineering 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 J O Skip Robinson Sent: Wednesday, February 18, 2015 10:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Parallel Sysplex split Catalog is not an issue (except that IODF should be cataloged somewhere), but location is. The PDS containing LOADxx must be on the same volume as the IODF. Let's call that IPLPARM. Sharing IODF means also sharing IPLPARM. It does not get edited very often, but putting it outside of GRS introduces some risk. If IPLPARM gets damaged, you're pretty much SOL for every system that shares it. We have seven sysplexes. Almost nothing is shared across boundaries, including IODF and IPLPARM. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Tuesday, February 17, 2015 11:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: AW: Re: Parallel Sysplex split That's not true in our case. We share the IODF between two sysplexes, it is cataloged in a user catalog that is connected to the master catalogs of all systems in both sysplexes. For the purpose of the IPL, the IODF does not need to be cataloged at all. You designate the IODF volume via its unit address in the LOADPARM (pos. 1-4). The DSN of the IODF to be used is then specified in the LOADxx member (suffix specified via LOADPARM, pos. 5-6). The LOADxx member is searched in SYSx.IPLPARM (x=0, 1, ..., 9) or SYS1.PARMLIB on the IODF volume and finally in SYS1.PARMLIB on the IPL volume. No catalog is involved in all of this. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Parallel Sysplex split
That's not true in our case. We share the IODF between two sysplexes, it is cataloged in a user catalog that is connected to the master catalogs of all systems in both sysplexes. For the purpose of the IPL, the IODF does not need to be cataloged at all. You designate the IODF volume via its unit address in the LOADPARM (pos. 1-4). The DSN of the IODF to be used is then specified in the LOADxx member (suffix specified via LOADPARM, pos. 5-6). The LOADxx member is searched in SYSx.IPLPARM (x=0, 1, ..., 9) or SYS1.PARMLIB on the IODF volume and finally in SYS1.PARMLIB on the IPL volume. No catalog is involved in all of this. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parallel Sysplex split
A more pointed question.. do you need to share the usercat between plexes? REPRO/MERGECAT or one of the Catalog vendors can split the USERCAT. Seems like you would need a pretty good reason to attempt to continue to share. Dave's right.. there are items in your share list that are not eligible for sharing. It wasn't clear if you are sharing those items between plexes today? I am assuming that you already have a single system that you can IPL outside of the current production plex. If not, I would start there and work through each item. Guidelines... If the item is XCF/XES or GRS dependent or PDSE, then sharing is probably bad. Read-only items are usually (such a grey area) a safe bet to share (within reason). Add another config to your IODF that has all production volumes offline at IPL (hopefully they are in nice easy ranges... but I am guessing not) On the RACF side.. are you planning to propagate security rules? If so.. there is more work to do.. if not, there is more work to do. I am guessing that your TSO users are going to be duplicated.. so it would mean some sort of cloning/segregation of data sets Change management.. always a fun one for considering splitting plexes Break/fix process? If the prod data has to be loaded into DEV for some reason... - just make sure you pick a some typical scenarios and logically follow them from beginning to end. Encryption keys that might be in ICSF? or RACF combined with ICSF? Did you cover tapes yet? Automation rules... Schedulers that use sysplex services to post events between dev and prod. There is a lot of sharing between systems prod and dev.. which is why it is easy to forget seemingly insignificant items from the list. Rob Schramm Rob Schramm Senior Systems Consultant On Tue, Feb 17, 2015 at 10:30 AM, Vernooij, CP (ITOPT1) - KLM kees.verno...@klm.com wrote: Only if this volume is not under GDPS hiperswap. If it is, all reserves must be converted. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Doug Henry Sent: 17 February, 2015 16:24 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Parallel Sysplex split On Tue, 17 Feb 2015 14:26:14 +, Staller, Allan allan.stal...@kbmg.com wrote: snip - There is some User Catalogs that are being shared between the Development and Production environment /snip You cannot share catalogs across a sysplex boundary! This will cause bad things to happen. BTDTGTTS!. I presume (not using it) that ECS and RLS have the same limitation. Actually you can share a user catalog across sysplex boundary. We do this for a low utilized catalog. See II14297: CATALOG AND GRS CONFIGURATIONS. You will need to read it very carefully. This catalog volume is the only on that we do not convert reserves to global enqueues. Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parallel Sysplex split
Hi, We are in the process of cleaning up all the shared User catalogs and volumes so that no data is shared. We plan however to share the IODF among the different SYSPLEX environments. We will create seperate CF Development LPARs and share it using WEIGHTs with the Production CF LPARs. Regards Jaco Kruger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parallel Sysplex split
Each sysplex will need its own copy of the IODF for IPL purposes. snip We are in the process of cleaning up all the shared User catalogs and volumes so that no data is shared. We plan however to share the IODF among the different SYSPLEX environments. We will create seperate CF Development LPARs and share it using WEIGHTs with the Production CF LPARs. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parallel Sysplex split
Only if this volume is not under GDPS hiperswap. If it is, all reserves must be converted. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Doug Henry Sent: 17 February, 2015 16:24 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Parallel Sysplex split On Tue, 17 Feb 2015 14:26:14 +, Staller, Allan allan.stal...@kbmg.com wrote: snip - There is some User Catalogs that are being shared between the Development and Production environment /snip You cannot share catalogs across a sysplex boundary! This will cause bad things to happen. BTDTGTTS!. I presume (not using it) that ECS and RLS have the same limitation. Actually you can share a user catalog across sysplex boundary. We do this for a low utilized catalog. See II14297: CATALOG AND GRS CONFIGURATIONS. You will need to read it very carefully. This catalog volume is the only on that we do not convert reserves to global enqueues. Doug -- 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: Parallel Sysplex split
That's not true in our case. We share the IODF between two sysplexes, it is cataloged in a user catalog that is connected to the master catalogs of all systems in both sysplexes. We have a couple very limited use catalogs for that kind of system resource - SMPE zones for example. Of course, they're used just by Tech so if somebody does something silly we know who to wave our arms at. Thomas Ambros zEnterprise Operating Systems zEnterprise Systems Management 518-436-6433 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Staller, Allan Sent: Tuesday, February 17, 2015 09:28 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Parallel Sysplex split Each sysplex will need its own copy of the IODF for IPL purposes. snip We are in the process of cleaning up all the shared User catalogs and volumes so that no data is shared. We plan however to share the IODF among the different SYSPLEX environments. We will create seperate CF Development LPARs and share it using WEIGHTs with the Production CF LPARs. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act. You may not directly or indirectly reuse or redisclose such information for any purpose other than to provide the services for which you are receiving the information. 127 Public Square, Cleveland, OH 44114 If you prefer not to receive future e-mail offers for products or services from Key send an e-mail to mailto:dnereque...@key.com with 'No Promotional E-mails' in the SUBJECT line. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parallel Sysplex split
On Tue, 17 Feb 2015 14:26:14 +, Staller, Allan allan.stal...@kbmg.com wrote: snip - There is some User Catalogs that are being shared between the Development and Production environment /snip You cannot share catalogs across a sysplex boundary! This will cause bad things to happen. BTDTGTTS!. I presume (not using it) that ECS and RLS have the same limitation. Actually you can share a user catalog across sysplex boundary. We do this for a low utilized catalog. See II14297: CATALOG AND GRS CONFIGURATIONS. You will need to read it very carefully. This catalog volume is the only on that we do not convert reserves to global enqueues. Doug -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parallel Sysplex split
snip - There is some User Catalogs that are being shared between the Development and Production environment /snip You cannot share catalogs across a sysplex boundary! This will cause bad things to happen. BTDTGTTS!. I presume (not using it) that ECS and RLS have the same limitation. In general, sharing across a sysplex boundary is a bad thing and extreme caution must used.. However, it's not my dog! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Parallel Sysplex split
Good morning, Currently, the Production Parallel Sysplex environment consist of all the Development and Production LPARs, which is distributed across 2 mainframes. Each mainframe contains a Production Coupling Facility(CF) LPAR. We will remove the Development LPARs from the Production Sysplex and add it to a new Development Sysplex. The following components are shared between Development and Production environments - DASD - All the z/OS volumes are accessible from all LPARs. Only volumes pertaining to an specific environment is ONLINE, e.g. only Production related volumes are ONLINE in the Production environment. - There is a number of volumes that is shared between the Development and Production environment - ECS - GRS - I/O gen - WLM - ZFS The following components are not shared between Development and Production environments - CATALOG - Each environment has its own Master Catalog - There is some User Catalogs that are being shared between the Development and Production environment - JES2 - DFSMS - DFSMShsm - DFSMSrmm - VSAM/RLS The Control data set are shared The CF lock structure is shared The CF cache structures are unique - RACF - TCP/IP - VTAM We have reviewed the different components, performed the required cleanups and setup documentation with proposed actions. We do however have some questions - What are the gotchas that we need to look out for ? - What will be the best approach to initialize the VSAM/RLS environment in the new Development Sysplex environment ? - Once the Development LPARs have been shut down, do we need to perform any task on the Production Sysplex environment to ensure that the IPL of the Development environment into the Development Sysplex will not cause any problems for the Production Sysplex ? - We found little information regarding the split of a Parallel Sysplex. We used the redbook Merging Systems into a Sysplex as a reference, although it does not contain information regarding the split of a Sysplex. Is there any documentation available that has more information ? Regards Jaco Kruger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parallel Sysplex split
You are also going to lose the ability to share these as well: In fact, don't try to share anything. Build a large wall between the sysplexes, which can only be crossed by an FTP or similar application. Lastly, you don’t mention it, but your comments lead me to believe that you might be expecting to share the same CF lpars. You need separate CF's for DEV vs PROD as well. _ However, you don't need exta ICF's. You can run your DEV CFs shared on the CPs or shared with your Prod CFs on the ICFs. Both configurations have their performance pro's and con's, it depends on your needs. Kees. Dave Jousma Assistant Vice President, Mainframe Engineering 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 Jaco Kruger Sent: Tuesday, February 17, 2015 3:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Parallel Sysplex split Good morning, Currently, the Production Parallel Sysplex environment consist of all the Development and Production LPARs, which is distributed across 2 mainframes. Each mainframe contains a Production Coupling Facility(CF) LPAR. We will remove the Development LPARs from the Production Sysplex and add it to a new Development Sysplex. The following components are shared between Development and Production environments - DASD - All the z/OS volumes are accessible from all LPARs. Only volumes pertaining to an specific environment is ONLINE, e.g. only Production related volumes are ONLINE in the Production environment. - There is a number of volumes that is shared between the Development and Production environment - ECS - GRS - I/O gen - WLM - ZFS The following components are not shared between Development and Production environments - CATALOG - Each environment has its own Master Catalog - There is some User Catalogs that are being shared between the Development and Production environment - JES2 - DFSMS - DFSMShsm - DFSMSrmm - VSAM/RLS The Control data set are shared The CF lock structure is shared The CF cache structures are unique - RACF - TCP/IP - VTAM We have reviewed the different components, performed the required cleanups and setup documentation with proposed actions. We do however have some questions - What are the gotchas that we need to look out for ? - What will be the best approach to initialize the VSAM/RLS environment in the new Development Sysplex environment ? - Once the Development LPARs have been shut down, do we need to perform any task on the Production Sysplex environment to ensure that the IPL of the Development environment into the Development Sysplex will not cause any problems for the Production Sysplex ? - We found little information regarding the split of a Parallel Sysplex. We used the redbook Merging Systems into a Sysplex as a reference, although it does not contain information regarding the split of a Sysplex. Is there any documentation available that has more information ? Regards Jaco Kruger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For 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
Re: Parallel Sysplex split
You are also going to lose the ability to share these as well: - ECS - GRS - WLM - ZFS - There is a number of volumes that is shared between the Development and Production environment The caveat on this is that you can't reliably share these outside of GRS. Many do it to allow sysprog access to move stuff around, but I wouldn’t actively share volumes without GRS. Certainly not PDSE datasets, they are guaranteed to get corrupted. Then you go on to say: The following components are not shared between Development and Production environments - CATALOG - Each environment has its own Master Catalog - There is some User Catalogs that are being shared between the Development and Production environment really shouldn’t do this without GRS - JES2 - DFSMS - DFSMShsm - DFSMSrmm - VSAM/RLS The Control data set are shared Cant share this outside of sysplex The CF lock structure is shared Cant share this outside of sysplex The CF cache structures are unique - RACF - TCP/IP - VTAM Lastly, you don’t mention it, but your comments lead me to believe that you might be expecting to share the same CF lpars. You need separate CF's for DEV vs PROD as well. _ Dave Jousma Assistant Vice President, Mainframe Engineering 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 Jaco Kruger Sent: Tuesday, February 17, 2015 3:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Parallel Sysplex split Good morning, Currently, the Production Parallel Sysplex environment consist of all the Development and Production LPARs, which is distributed across 2 mainframes. Each mainframe contains a Production Coupling Facility(CF) LPAR. We will remove the Development LPARs from the Production Sysplex and add it to a new Development Sysplex. The following components are shared between Development and Production environments - DASD - All the z/OS volumes are accessible from all LPARs. Only volumes pertaining to an specific environment is ONLINE, e.g. only Production related volumes are ONLINE in the Production environment. - There is a number of volumes that is shared between the Development and Production environment - ECS - GRS - I/O gen - WLM - ZFS The following components are not shared between Development and Production environments - CATALOG - Each environment has its own Master Catalog - There is some User Catalogs that are being shared between the Development and Production environment - JES2 - DFSMS - DFSMShsm - DFSMSrmm - VSAM/RLS The Control data set are shared The CF lock structure is shared The CF cache structures are unique - RACF - TCP/IP - VTAM We have reviewed the different components, performed the required cleanups and setup documentation with proposed actions. We do however have some questions - What are the gotchas that we need to look out for ? - What will be the best approach to initialize the VSAM/RLS environment in the new Development Sysplex environment ? - Once the Development LPARs have been shut down, do we need to perform any task on the Production Sysplex environment to ensure that the IPL of the Development environment into the Development Sysplex will not cause any problems for the Production Sysplex ? - We found little information regarding the split of a Parallel Sysplex. We used the redbook Merging Systems into a Sysplex as a reference, although it does not contain information regarding the split of a Sysplex. Is there any documentation available that has more information ? Regards Jaco Kruger -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions
