Re: Share IODF in different sysplex same CPC
On Wed, 17 Jun 2015 03:37:48 -0500, Jorge Garcia wrote: I've found more information about GRS configuration between systems outsite GRS complex: http://www-01.ibm.com/support/docview.wss?uid=isg1II14297 The information APAR says there is a possible GRSRNLxx configuration. I suppose is not dangerous. It's a IBM APAR. Suppose again. That APAR is *very* specific to catalogs and the way they are processed. It is *NOT* generic for sharing outside a GRSplex. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
Hello: I've found more information about GRS configuration between systems outsite GRS complex: http://www-01.ibm.com/support/docview.wss?uid=isg1II14297 The information APAR says there is a possible GRSRNLxx configuration. I suppose is not dangerous. It's a IBM APAR. Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
Shane Ginnane wrote: The information APAR says there is a possible GRSRNLxx configuration. I suppose is not dangerous. It's a IBM APAR. Suppose again. That APAR is *very* specific to catalogs and the way they are processed. It is *NOT* generic for sharing outside a GRSplex. Shane, it is a good catch! Thanks for mentioning this. To Jorge Garcia: I would, as others suggested, recommend that you update your one IODF and copy it to other Sysplex(es). Because of the very serious scars others mentioned, I don't allow in RACF access of ALTER for datasets residing in other Syplex catalogs and volsers. Some of our usercatalogs are shared, but datasets are accessible amongst Sysplexes as long ALTER work is done on the Sysplex where that dataset is originally created. This includes IODF datasets too. You could proceed if you wish, but it is not my dog. 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: Share IODF in different sysplex same CPC
W dniu 2015-06-12 o 21:34, Gibney, David Allen,Jr pisze: Sharing without serialization can lead to errors. It's even worse with PDSE outside Sysplex On the other hand, here where there are only two of us who could possibly update the IODF (and I usually leave it to the other guy) We get away with it. But we only have four monoplexes and carefully limit sharing. I may break me, but I will rarely break the system :) If I was running a larger installation, or more sysprogs stirring the soup, I would completely agree with Skip and Tom Sharing without serialization IS insecure and MAY lead to problems. In other words no serialization does not cause problems, the problems are caused by users. IODF is very specific - only few update it, not many tasks read it and you (should) perferctly know and control who and when. PDSE is completely another story, the problems are not caused by (lack of) serialization. -- 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.pl Są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.2015 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.840.228 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
Hello: I've reviewed all the post and the best option is the HCD export/import in the productions monoplex. If all the IODFs have the same HLQ yoy can do dynamic activation and it' no necessary to do a ipl. The user catalog among sysplex is dangerous. I agree with us. Thanks for your posts!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
I think the issue is a catalog shared between PLEXs and not a catalog that is shared within a Plex. GRS maybe tricky when more than one Plex can access a catalog. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of van der Grijn, Bart (B) Sent: Friday, June 12, 2015 5:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Share IODF in different sysplex same CPC Seeing that I originally suggested using a shared catalog in this thread, I have to ask why people believe this is a dangerous setup for the topic at hand. Yes, there are potential issues with sharing catalogs, but with the suggested configuration (single dedicated volume, single HLQ, single catalog, IODF only) I'm just not seeing what the issues are. Can those that dubbed this dangerous enlighten me? We've used this setup for longer than I can remember in multiple environments and I don't recall it ever causing an issue. The advantage is that your IODF datasets are always the same across all your environments without having to rely on a manual sync-up. Note: we switch to a new IODF every time we make updates Thanks, Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jorge Garcia Sent: Friday, June 12, 2015 2:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Share IODF in different sysplex same CPC Hello: I've reviewed all the post and the best option is the HCD export/import in the productions monoplex. If all the IODFs have the same HLQ yoy can do dynamic activation and it' no necessary to do a ipl. The user catalog among sysplex is dangerous. I agree with us. Thanks for your posts!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
Seeing that I originally suggested using a shared catalog in this thread, I have to ask why people believe this is a dangerous setup for the topic at hand. Yes, there are potential issues with sharing catalogs, but with the suggested configuration (single dedicated volume, single HLQ, single catalog, IODF only) I'm just not seeing what the issues are. Can those that dubbed this dangerous enlighten me? We've used this setup for longer than I can remember in multiple environments and I don't recall it ever causing an issue. The advantage is that your IODF datasets are always the same across all your environments without having to rely on a manual sync-up. Note: we switch to a new IODF every time we make updates Thanks, Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jorge Garcia Sent: Friday, June 12, 2015 2:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Share IODF in different sysplex same CPC Hello: I've reviewed all the post and the best option is the HCD export/import in the productions monoplex. If all the IODFs have the same HLQ yoy can do dynamic activation and it' no necessary to do a ipl. The user catalog among sysplex is dangerous. I agree with us. Thanks for your posts!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
Sharing without serialization can lead to errors. It's even worse with PDSE outside Sysplex On the other hand, here where there are only two of us who could possibly update the IODF (and I usually leave it to the other guy) We get away with it. But we only have four monoplexes and carefully limit sharing. I may break me, but I will rarely break the system :) If I was running a larger installation, or more sysprogs stirring the soup, I would completely agree with Skip and Tom -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of van der Grijn, Bart (B) Sent: Friday, June 12, 2015 5:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Share IODF in different sysplex same CPC Seeing that I originally suggested using a shared catalog in this thread, I have to ask why people believe this is a dangerous setup for the topic at hand. Yes, there are potential issues with sharing catalogs, but with the suggested configuration (single dedicated volume, single HLQ, single catalog, IODF only) I'm just not seeing what the issues are. Can those that dubbed this dangerous enlighten me? We've used this setup for longer than I can remember in multiple environments and I don't recall it ever causing an issue. The advantage is that your IODF datasets are always the same across all your environments without having to rely on a manual sync-up. Note: we switch to a new IODF every time we make updates Thanks, Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jorge Garcia Sent: Friday, June 12, 2015 2:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Share IODF in different sysplex same CPC Hello: I've reviewed all the post and the best option is the HCD export/import in the productions monoplex. If all the IODFs have the same HLQ yoy can do dynamic activation and it' no necessary to do a ipl. The user catalog among sysplex is dangerous. I agree with us. Thanks for your posts!! -- 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
Share IODF in different sysplex same CPC
Hello: We are involved in a new proyect with the target of add three new system (monoplex) in our configuration. Our actual configuration is: one production sysplex with four lpar, one test sysplex with two lpars and next year another three systems in monoplex. Now, when we activate a new configuration, first build IOCDS, dynamic activation in the production sysplex and then execute a ipl in the test systems (the IODF device is the same). The test sysplex doesn't share GRS with the production sysplex and the test systems can't view the IODF dataset, but the test systems load the IODF in ipl time and works fine. Next year we want to share the same IODF all the systems, but in the new systems in monoplex can't do ipl because are production systems. Our question is. Which is the best way for transmit the production IODF to these new systems and then execute a dynamic activation?. HCD transmit?. FTP?. Another way?. Jorge Garcia Juanino Gerente sistemas z/OS ACTP – DIAC – Operación y Soporte EMEA MAPFRE Avenida del Talgo 100-103 – 3ª Planta CP 28023 Madrid Tel. 91 581 27 34, Movil 464196/618333559 jgarc...@mapfre.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
Jorge, I'm not fully understanding why you don't want to use one shared IODF, as you do today. Is it because you want to be able to do dynamic activates in these production systems (and don't today in your test system)? We put our IODFs on one dedicated volume with its own catalog. The volume and catalog are online to all systems, even though they're not all in one GRS entity (they're 3 different sysplexes with 28 different LPARs). The IODFs and the catalog are the only datasets on the volume and the catalog is used only for the IODFs. IODF Changes are dynamically activated across all environment. Some RNL excludes are needed for the volume, datasets and catalog. It's not a setup I would use for actively shared data, but it works fine for the occasional IODF update. Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jorge Garcia Sent: Thursday, June 11, 2015 6:58 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Share IODF in different sysplex same CPC Hello: We are involved in a new proyect with the target of add three new system (monoplex) in our configuration. Our actual configuration is: one production sysplex with four lpar, one test sysplex with two lpars and next year another three systems in monoplex. Now, when we activate a new configuration, first build IOCDS, dynamic activation in the production sysplex and then execute a ipl in the test systems (the IODF device is the same). The test sysplex doesn't share GRS with the production sysplex and the test systems can't view the IODF dataset, but the test systems load the IODF in ipl time and works fine. Next year we want to share the same IODF all the systems, but in the new systems in monoplex can't do ipl because are production systems. Our question is. Which is the best way for transmit the production IODF to these new systems and then execute a dynamic activation?. HCD transmit?. FTP?. Another way?. Jorge Garcia Juanino Gerente sistemas z/OS ACTP – DIAC – Operación y Soporte EMEA MAPFRE Avenida del Talgo 100-103 – 3ª Planta CP 28023 Madrid Tel. 91 581 27 34, Movil 464196/618333559 jgarc...@mapfre.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
Hi Jorge. The IODF must be *catalogued* on each system, but it doesn't have to be in the same catalog. I prefer HCD Export to transmit the IODF to the other system then HCD import it. You can also repro it to a flat file, ftp that, then repro it back out on the other system. Here's my batch export jcl. //EXPORT EXEC PGM=IKJEFT01 //HCDIODFS DD DSN=MAM.IODFA0,DISP=SHR //HCDMLOG DD DSN=MAM.HCD.MSGLOG,DISP=OLD //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * CALL 'SYS1.LINKLIB(CBDMGHCP)', + 'EXPORT,MAM,TND' MA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
In 5670874248161270.wa.jgarci12mapfre@listserv.ua.edu, on 06/11/2015 at 08:20 AM, Jorge Garcia jgarc...@mapfre.com said: Yes. Our target is to do dynamic activation in the new systems. We've seen in the Redbook HCD and Dynamic I/O reconfiguration it's not possible if you don't share the iodf user catalog. What gives you that idea? BTDT,GTTS. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
Hello Bart: Yes. Our target is to do dynamic activation in the new systems. We've seen in the Redbook HCD and Dynamic I/O reconfiguration it's not possible if you don't share the iodf user catalog. It's mandatory has the same HLQ in all systems and the only way is share a user catalog like you say. We'll create a new iodf user catalog in a volume used in all systems and with the same HLQ. With this configuration we'll be able to do dynamic activacion in all sysplex. Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
On Thu, Jun 11, 2015 at 8:20 AM, Jorge Garcia jgarc...@mapfre.com wrote: Hello Bart: Yes. Our target is to do dynamic activation in the new systems. We've seen in the Redbook HCD and Dynamic I/O reconfiguration it's not possible if you don't share the iodf user catalog. It's mandatory has the same HLQ in all systems and the only way is share a user catalog like you say. We'll create a new iodf user catalog in a volume used in all systems and with the same HLQ. With this configuration we'll be able to do dynamic activacion in all sysplex. Regards There are ways around the shared catalog requirement. What is actually required to do a dynamic activate is that the token in the active IODF in the system matches the token in the HSA. The HSA values were, at least initially, loaded from the IOCDS on the SE during a POR. Given that the IODF is just a VSAM LDS, you could do a number of things. The simplest is to make the IODF high level qualifer be 'SYS1'. There is special code in DFSMSdfp which allows you to catalog a VSAM data set which has an HLQ of SYS1 into multiple master catalogs. So you could create your IODF on a shared DASD volume with the HLQ of SYS1. and then do a DEFINE ... RECATALOG in all the other systems' master catalog(s). Another way would be to create the initial IODF as you normally do. The use IDCAMS to REPRO that IODF to a sequential data set on shared DASD. You can the do a DEFINE to create a new VSAM LDS with _any_ name you like on any other system. You then REPRO the data from the sequential unload into the new IODF data sets. You IPL the new z/OS image using this new IODF. You could then modify the IODF on that 2nd system, creating a new IODF, and do a dynamic ACTIVATE on the 2nd system. Of course, you need to copy the data back the other way. The SYS1 method is the better of the two. The problem with sharing, in your case, is the fact that not all the systems are in the same sysplex. This makes sharing dangerous if you don't take _extreme_ care. IMO, in this case, you'd need to put your IODF on a shared, non-SMS, volume and not convert specific QNAME based RESERVEs to SYSTEMS level ENQs. Or you'd need to use CA-MIM and put every system into the same MIMPLEX. This is also a bit hairy to do properly. As Shmuel indicated: Been There. Done That. Got The Scars. -- Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. My sister opened a computer store in Hawaii. She sells C shells down by the seashore. If someone tell you that nothing is impossible: Ask him to dribble a football. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
Hello John and Mary:
Our requirements are (if it's possible). Updates in one and only IODF and then
transmit it to another systems. With this option we avoid updates in two o more
IODF and we save the IODF integrity.
The share user catalog option is the fast and easy way for dynamic activation
in all systems, but It's dangerous if you aren't careful.
This should be the GRSRNLxx configuration with this option:
RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSDSN) RNAME(hlq iodf)
RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSZVVDS) RNAME(SD) RNLDEF RNL(EXCL)
TYPE(GENERIC) QNAME(SYSVTOC) RNAME(volser catalog device)
RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSIGGV2)
RNAME('iodf user catalog ')
RNLDEF RNL(EXCL) TYPE(PATTERN) QNAME(SYSIGGV2)
RNAME('iodf user catalog
')
The IODF SYS1 option and Mary option I think that it's the same. With the Mary
option you avoid DEFINE and REPRO executions. The transmit and receive option
is faster. Mary I understand that you have cataloged the same iodf HLQ in
differerents user catalogs in different systems? With the same HLQ like IOCDS
you should execute a right dynamic activacion, Is It true?
Thanks
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
Succinctly... Perform all your work in one IODF. Preferably your oldest
release of HCD among your systems to avoid trouble. Import/Export, catalog and
activate as needed.
Regards,
Kevin
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Jorge Garcia
Sent: Thursday, June 11, 2015 8:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Share IODF in different sysplex same CPC
Hello John and Mary:
Our requirements are (if it's possible). Updates in one and only IODF and then
transmit it to another systems. With this option we avoid updates in two o more
IODF and we save the IODF integrity.
The share user catalog option is the fast and easy way for dynamic activation
in all systems, but It's dangerous if you aren't careful.
This should be the GRSRNLxx configuration with this option:
RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSDSN) RNAME(hlq iodf) RNLDEF RNL(EXCL)
TYPE(GENERIC) QNAME(SYSZVVDS) RNAME(SD) RNLDEF RNL(EXCL) TYPE(GENERIC)
QNAME(SYSVTOC) RNAME(volser catalog device)
RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSIGGV2)
RNAME('iodf user catalog ')
RNLDEF RNL(EXCL) TYPE(PATTERN) QNAME(SYSIGGV2)
RNAME('iodf user catalog
')
The IODF SYS1 option and Mary option I think that it's the same. With the Mary
option you avoid DEFINE and REPRO executions. The transmit and receive option
is faster. Mary I understand that you have cataloged the same iodf HLQ in
differerents user catalogs in different systems? With the same HLQ like IOCDS
you should execute a right dynamic activacion, Is It true?
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: Share IODF in different sysplex same CPC
On 6/11/2015 11:34 AM, Jorge Garcia wrote:
Hello John and Mary:
Our requirements are (if it's possible). Updates in one and only IODF and
then transmit it to another systems. With this option we avoid updates in two o
more IODF and we save the IODF integrity.
The share user catalog option is the fast and easy way for dynamic activation
in all systems, but It's dangerous if you aren't careful.
This should be the GRSRNLxx configuration with this option:
RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSDSN) RNAME(hlq iodf)
RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSZVVDS) RNAME(SD) RNLDEF RNL(EXCL)
TYPE(GENERIC) QNAME(SYSVTOC) RNAME(volser catalog device)
RNLDEF RNL(EXCL) TYPE(SPECIFIC) QNAME(SYSIGGV2)
RNAME('iodf user catalog ')
RNLDEF RNL(EXCL) TYPE(PATTERN) QNAME(SYSIGGV2)
RNAME('iodf user catalog
')
The IODF SYS1 option and Mary option I think that it's the same. With the Mary
option you avoid DEFINE and REPRO executions. The transmit and receive option
is faster. Mary I understand that you have cataloged the same iodf HLQ in
differerents user catalogs in different systems? With the same HLQ like IOCDS
you should execute a right dynamic activacion, Is It true?
Jorge,
This is dangerous and unnecessary. You can catalog the IODF on each
separate system in the master catalog, or a user catalog shared among
systems IN THE SAME SYSPLEX. You shouldn't be sharing a user catalog
cross-sysplex.
I used to propagate IODF's with DFDSS DUMP, FTP, RESTORE, but that
failed once after working for over a year. So now I use the HCD EXPORT
and IMPORT functions, which while slower, is guaranteed to work.
Regards,
Tom Conley
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
I'm with Tom. Since the advent of IODF in the 90s, we have always given each
plex (sys- or mono-) its own copy of the IODF. Although not required, we
catalog it in master. If nothing else, you have backups in case one get marfed
or accidentally deleted.
SAMPLIB contains sample jobs to migrate an IODF. Look at members CBDS* . Simply
submit a job on the system where you manage HCD. Job1 offloads and transmits
IODF to another system over NJE, where Job2 unloads and catalogs IODF on target
system. It really is pretty fast and very reliable.
.
.
.
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 Thomas Conley
Sent: Thursday, June 11, 2015 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Share IODF in different sysplex same CPC
On 6/11/2015 11:34 AM, Jorge Garcia wrote:
Hello John and Mary:
Our requirements are (if it's possible). Updates in one and only IODF and
then transmit it to another systems. With this option we avoid updates in two
o more IODF and we save the IODF integrity.
The share user catalog option is the fast and easy way for dynamic activation
in all systems, but It's dangerous if you aren't careful.
This should be the GRSRNLxx configuration with this option:
RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSDSN) RNAME(hlq iodf) RNLDEF
RNL(EXCL) TYPE(GENERIC) QNAME(SYSZVVDS) RNAME(SD) RNLDEF RNL(EXCL)
TYPE(GENERIC) QNAME(SYSVTOC) RNAME(volser catalog device) RNLDEF RNL(EXCL)
TYPE(SPECIFIC) QNAME(SYSIGGV2)
RNAME('iodf user catalog ')
RNLDEF RNL(EXCL) TYPE(PATTERN) QNAME(SYSIGGV2)
RNAME('iodf user catalog
')
The IODF SYS1 option and Mary option I think that it's the same. With the
Mary option you avoid DEFINE and REPRO executions. The transmit and receive
option is faster. Mary I understand that you have cataloged the same iodf HLQ
in differerents user catalogs in different systems? With the same HLQ like
IOCDS you should execute a right dynamic activacion, Is It true?
Jorge,
This is dangerous and unnecessary. You can catalog the IODF on each separate
system in the master catalog, or a user catalog shared among systems IN THE
SAME SYSPLEX. You shouldn't be sharing a user catalog cross-sysplex.
I used to propagate IODF's with DFDSS DUMP, FTP, RESTORE, but that failed once
after working for over a year. So now I use the HCD EXPORT and IMPORT
functions, which while slower, is guaranteed to work.
Regards,
Tom Conley
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Share IODF in different sysplex same CPC
One more thing. ;-) Using 'native' HCD/IODF facilities guards against a
possibly fatal problem. Other software might well upload an IODF in multiple
extents. Perfectly valid for data management, and the result will work fine for
dynamic ACTIVATE. However, you cannot IPL with a multi-extent IODF. If you use
native facilities, this problem will be detected on reload and cause a non-zero
return code. That alone is worth using CBD utilities to migrate an IODF.
.
.
.
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 J O Skip Robinson
Sent: Thursday, June 11, 2015 10:14 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Share IODF in different sysplex same CPC
I'm with Tom. Since the advent of IODF in the 90s, we have always given each
plex (sys- or mono-) its own copy of the IODF. Although not required, we
catalog it in master. If nothing else, you have backups in case one get marfed
or accidentally deleted.
SAMPLIB contains sample jobs to migrate an IODF. Look at members CBDS* . Simply
submit a job on the system where you manage HCD. Job1 offloads and transmits
IODF to another system over NJE, where Job2 unloads and catalogs IODF on target
system. It really is pretty fast and very reliable.
.
.
.
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 Thomas Conley
Sent: Thursday, June 11, 2015 9:57 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Share IODF in different sysplex same CPC
On 6/11/2015 11:34 AM, Jorge Garcia wrote:
Hello John and Mary:
Our requirements are (if it's possible). Updates in one and only IODF and
then transmit it to another systems. With this option we avoid updates in two
o more IODF and we save the IODF integrity.
The share user catalog option is the fast and easy way for dynamic activation
in all systems, but It's dangerous if you aren't careful.
This should be the GRSRNLxx configuration with this option:
RNLDEF RNL(EXCL) TYPE(GENERIC) QNAME(SYSDSN) RNAME(hlq iodf) RNLDEF
RNL(EXCL) TYPE(GENERIC) QNAME(SYSZVVDS) RNAME(SD) RNLDEF RNL(EXCL)
TYPE(GENERIC) QNAME(SYSVTOC) RNAME(volser catalog device) RNLDEF RNL(EXCL)
TYPE(SPECIFIC) QNAME(SYSIGGV2)
RNAME('iodf user catalog ')
RNLDEF RNL(EXCL) TYPE(PATTERN) QNAME(SYSIGGV2)
RNAME('iodf user catalog
')
The IODF SYS1 option and Mary option I think that it's the same. With the
Mary option you avoid DEFINE and REPRO executions. The transmit and receive
option is faster. Mary I understand that you have cataloged the same iodf HLQ
in differerents user catalogs in different systems? With the same HLQ like
IOCDS you should execute a right dynamic activacion, Is It true?
Jorge,
This is dangerous and unnecessary. You can catalog the IODF on each separate
system in the master catalog, or a user catalog shared among systems IN THE
SAME SYSPLEX. You shouldn't be sharing a user catalog cross-sysplex.
I used to propagate IODF's with DFDSS DUMP, FTP, RESTORE, but that failed once
after working for over a year. So now I use the HCD EXPORT and IMPORT
functions, which while slower, is guaranteed to work.
Regards,
Tom Conley
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
