Re: Opinions/experience on sharing catalogs outside plex
What's magic? Some missionaries were confronted by a group of hostile locals. Things were looking grim. One quick thinker pulled out a lighter, held it high, and flicked it on. Animosity melted into awestruck admiration...It was the first time they had ever seen a Zippo light on the first try. When I joined SCE in the mid-90s, tape was already being shared between data centers. There was production in both sites. Tape was bus-and-tag, yet every drive in both centers was usable by every LPAR in both centers. In order to manage the drives, MIA was employed to control online/offline on demand. MIA required control data sets shared by all LPARs in both centers. The tape technology was STK, whose HSC software also required shared control files. Channel extension was used for both tape and control data sets. Technology progressed. First to ESCON, then to FICON. Channel extension moved to DWDM. The number of tape drives increased from a handful of physical units in the 80s/90s to a *huge* number of virtual ones. Still we kept MIA because--why not. Tape--now Oracle--still need shared control data sets. A tiny handful of disk volumes held all and only these shared control data sets and the ICF catalog that described them. Today we are moving to (now) Dell DLm tape. All virtual, all managed by RMM and for the first time OAM. We have so many virtual drives that we can segregate by sysplex. No more need for MIA. OAM is a different animal that does need shared data sets. Again, I would not advocate sharing catalogs outside a sysplex, but it's not a show stopper either. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Wednesday, May 27, 2020 4:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Opinions/experience on sharing catalogs outside plex CAUTION EXTERNAL EMAIL Not magic, but also not STK/Sun/Oracle. STK tape world is significantly different from IBM tapes. There are also other players (EMC DLM, etc.) which follow way similar to IBM, but all of them are defined as MTL (Manual Tape Library). Few differences between STK and IBM: IBM provide all necessary software components in z/OS base. No need to add/buy/install anything else. STK require its own software suite, many components are in the suite. Some of them depend on configuration. Communication host-ATL. Control path for IBM is embedded in data path (FICON). For STK ATL the control path is over IP. For older STK ATL there was coax connection required (big pain nowadays!) which meant it was like coax-attached terminal. However communication to VSM (STK virtual tape) is over FICON. Virtual tapes. Data are stored on some disk array, however VTS emulate whole library, so theoretically you can move your VTS and attach it to installed from sratch host and you can access data. In STK world data are still on disk (SVAA), but virtual volume definitions are kept on the host. So, you need working STK software *and* proper control data set to access data. Because of differences DFSMS recognize IBM ATL and that is important for ACS routines, storage classes, etc. Everything is in DFSMS. For STK most definitions are in SMC/HSC software components configuration. From system point of view usually you define some esoterics in IODF. -- Radoslaw Skorupka Lodz, Poland W dniu 27.05.2020 o 03:32, Ken Smith pisze: > *totally different technology...* > > Magic? > > On Tue, May 26, 2020 at 5:11 PM Jesse 1 Robinson > > wrote: > >> I'm not advocating this practice. Just saying that we did it for 25 >> years without a failure. We're now moving to totally different >> technology where such action is not even in the picture. >> >> . >> . >> J.O.Skip Robinson >> Southern California Edison Company >> Electric Dragon Team Paddler >> SHARE MVS Program Co-Manager >> 323-715-0595 Mobile >> 626-543-6132 Office ⇐=== NEW >> robin...@sce.com >> >> -Original Message- >> From: IBM Mainframe Discussion List On >> Behalf Of R.S. >> Sent: Monday, May 25, 2020 5:53 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: (External):Re: Opinions/experience on sharing catalogs >> outside plex >> >> CAUTION EXTERNAL EMAIL >> >> Skip, >> In the past I implemented STK tapes, the largest tape system in >> Poland at the time. Interesting job. :-) It seems, you shared control >> datasets between datacenters. Assuming your second datacenter is for >> disaster recovery, you had single point of failure. Catalog is not >> important there, but availability of datasets is. How could you work >> with tapes in case the d
Re: Opinions/experience on sharing catalogs outside plex
Not magic, but also not STK/Sun/Oracle. STK tape world is significantly different from IBM tapes. There are also other players (EMC DLM, etc.) which follow way similar to IBM, but all of them are defined as MTL (Manual Tape Library). Few differences between STK and IBM: IBM provide all necessary software components in z/OS base. No need to add/buy/install anything else. STK require its own software suite, many components are in the suite. Some of them depend on configuration. Communication host-ATL. Control path for IBM is embedded in data path (FICON). For STK ATL the control path is over IP. For older STK ATL there was coax connection required (big pain nowadays!) which meant it was like coax-attached terminal. However communication to VSM (STK virtual tape) is over FICON. Virtual tapes. Data are stored on some disk array, however VTS emulate whole library, so theoretically you can move your VTS and attach it to installed from sratch host and you can access data. In STK world data are still on disk (SVAA), but virtual volume definitions are kept on the host. So, you need working STK software *and* proper control data set to access data. Because of differences DFSMS recognize IBM ATL and that is important for ACS routines, storage classes, etc. Everything is in DFSMS. For STK most definitions are in SMC/HSC software components configuration. From system point of view usually you define some esoterics in IODF. -- Radoslaw Skorupka Lodz, Poland W dniu 27.05.2020 o 03:32, Ken Smith pisze: *totally different technology...* Magic? On Tue, May 26, 2020 at 5:11 PM Jesse 1 Robinson wrote: I'm not advocating this practice. Just saying that we did it for 25 years without a failure. We're now moving to totally different technology where such action is not even in the picture. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Monday, May 25, 2020 5:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Opinions/experience on sharing catalogs outside plex CAUTION EXTERNAL EMAIL Skip, In the past I implemented STK tapes, the largest tape system in Poland at the time. Interesting job. :-) It seems, you shared control datasets between datacenters. Assuming your second datacenter is for disaster recovery, you had single point of failure. Catalog is not important there, but availability of datasets is. How could you work with tapes in case the datasets are lost due to catastrophe of primary DC? IMHO the only way was to have remote copy of control datasets. Last, but not least, as far as I remember the datasets were very specific - they have (had?) hardcoded both volume labels and device numbers. While remote copy replicate volume label, the dev num is IODF dependend. There was a method for that, I forgot details. Other method could be a trick with duplicate device numbers. -- Radoslaw Skorupka Lodz, Poland W dniu 24.05.2020 o 21:29, Jesse 1 Robinson pisze: Until recently, we shared a catalog not only across sysplexes but between data centers. All because of tape. We had STK virtual tape (in both data centers) supported by MIA (Multi Image Allocation). These products require control data sets shared among all exploiting systems. We could have managed with uncataloged data sets, but that was deemed riskier in the long run than a shared catalog. The only entries in the catalog were for tape management data sets. We never had a catastrophe. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Monday, April 20, 2020 7:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Opinions/experience on sharing catalogs outside plex CAUTION EXTERNAL EMAIL Well, it is not good idea, but sometimes even such idea is better than nothing. What's important the risk covers THIS catalog only, not whole world. And yes, this catalog and shared datasets should be shared without "sysplex features" like changes is serialization. RESERVE should be used here or CA-MIM should be used, but the last one is add-on tool. BTW: BCS can be defined with SHR(3 4) or SHR(3 3). For this case it has to be SHR(3 4). AFAIK it is alterable. Again: small activity is your friend here. Small number of datasets cataloged in the BCS is good here. Potential problems with the BCS will not affect other BCSes. I use it for years (with limited activity). Mostly PS files and some VSAM. No problems observed. Caution: PDSE *will* break despite of way how catalog is shared. No help from CA-MIM, AFAIK. Observed many times educated many guys who used PDSE f
Re: Opinions/experience on sharing catalogs outside plex
*totally different technology...* Magic? On Tue, May 26, 2020 at 5:11 PM Jesse 1 Robinson wrote: > I'm not advocating this practice. Just saying that we did it for 25 years > without a failure. We're now moving to totally different technology where > such action is not even in the picture. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of R.S. > Sent: Monday, May 25, 2020 5:53 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Opinions/experience on sharing catalogs outside > plex > > CAUTION EXTERNAL EMAIL > > Skip, > In the past I implemented STK tapes, the largest tape system in Poland at > the time. Interesting job. :-) It seems, you shared control datasets > between datacenters. Assuming your second datacenter is for disaster > recovery, you had single point of failure. Catalog is not important there, > but availability of datasets is. How could you work with tapes in case the > datasets are lost due to catastrophe of primary DC? > IMHO the only way was to have remote copy of control datasets. Last, but > not least, as far as I remember the datasets were very specific - they have > (had?) hardcoded both volume labels and device numbers. While remote copy > replicate volume label, the dev num is IODF dependend. There was a method > for that, I forgot details. Other method could be a trick with duplicate > device numbers. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 24.05.2020 o 21:29, Jesse 1 Robinson pisze: > > Until recently, we shared a catalog not only across sysplexes but > > between data centers. All because of tape. We had STK virtual tape (in > > both data centers) supported by MIA (Multi Image Allocation). These > > products require control data sets shared among all exploiting > > systems. We could have managed with uncataloged data sets, but that > > was deemed riskier in the long run than a shared catalog. The only > > entries in the catalog were for tape management data sets. We never > > had a catastrophe. > > > > . > > . > > J.O.Skip Robinson > > Southern California Edison Company > > Electric Dragon Team Paddler > > SHARE MVS Program Co-Manager > > 323-715-0595 Mobile > > 626-543-6132 Office ⇐=== NEW > > robin...@sce.com > > > > -Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of R.S. > > Sent: Monday, April 20, 2020 7:42 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: Opinions/experience on sharing catalogs > > outside plex > > > > CAUTION EXTERNAL EMAIL > > > > Well, it is not good idea, but sometimes even such idea is better than > nothing. > > What's important the risk covers THIS catalog only, not whole world. > > > > And yes, this catalog and shared datasets should be shared without > "sysplex features" like changes is serialization. RESERVE should be used > here or CA-MIM should be used, but the last one is add-on tool. > > > > BTW: BCS can be defined with SHR(3 4) or SHR(3 3). For this case it has > to be SHR(3 4). AFAIK it is alterable. > > > > Again: small activity is your friend here. Small number of datasets > cataloged in the BCS is good here. Potential problems with the BCS will not > affect other BCSes. > > > > I use it for years (with limited activity). Mostly PS files and some > VSAM. No problems observed. > > Caution: PDSE *will* break despite of way how catalog is shared. No help > from CA-MIM, AFAIK. Observed many times educated many guys who used PDSE > for sharing. > > > > -- > > Radoslaw Skorupka > > Lodz, Poland > > > > > > > > > > > > > > W dniu 20.04.2020 o 14:45, Allan Staller pisze: > >> Yes, it can be done. I reiterate, IMO, this is most likely not a good > idea. > >> In order to accomplish this safely, you also need to regress GRS to > pre-GRS functionality. > >> Everything affecting this catalog must be handled w/Reserve/Release, > >> and not normal processing VSAM Sharoptions for the catalog need to be > changed. IIRC when I "undid" this the catalog hand Shareoptions (2,3) (or > was it 4,3?). > >> This option tells z/OS that the user is responsible for Catalog > seriailization. > >> SYSDSN, SYSIGGV2, SYSVTOC, SYSZVSAM (?) and the SPF* queues need to be > excluded from GRS processing. &
Re: Opinions/experience on sharing catalogs outside plex
I'm not advocating this practice. Just saying that we did it for 25 years without a failure. We're now moving to totally different technology where such action is not even in the picture. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Monday, May 25, 2020 5:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Opinions/experience on sharing catalogs outside plex CAUTION EXTERNAL EMAIL Skip, In the past I implemented STK tapes, the largest tape system in Poland at the time. Interesting job. :-) It seems, you shared control datasets between datacenters. Assuming your second datacenter is for disaster recovery, you had single point of failure. Catalog is not important there, but availability of datasets is. How could you work with tapes in case the datasets are lost due to catastrophe of primary DC? IMHO the only way was to have remote copy of control datasets. Last, but not least, as far as I remember the datasets were very specific - they have (had?) hardcoded both volume labels and device numbers. While remote copy replicate volume label, the dev num is IODF dependend. There was a method for that, I forgot details. Other method could be a trick with duplicate device numbers. -- Radoslaw Skorupka Lodz, Poland W dniu 24.05.2020 o 21:29, Jesse 1 Robinson pisze: > Until recently, we shared a catalog not only across sysplexes but > between data centers. All because of tape. We had STK virtual tape (in > both data centers) supported by MIA (Multi Image Allocation). These > products require control data sets shared among all exploiting > systems. We could have managed with uncataloged data sets, but that > was deemed riskier in the long run than a shared catalog. The only > entries in the catalog were for tape management data sets. We never > had a catastrophe. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > R.S. > Sent: Monday, April 20, 2020 7:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Opinions/experience on sharing catalogs > outside plex > > CAUTION EXTERNAL EMAIL > > Well, it is not good idea, but sometimes even such idea is better than > nothing. > What's important the risk covers THIS catalog only, not whole world. > > And yes, this catalog and shared datasets should be shared without "sysplex > features" like changes is serialization. RESERVE should be used here or > CA-MIM should be used, but the last one is add-on tool. > > BTW: BCS can be defined with SHR(3 4) or SHR(3 3). For this case it has to be > SHR(3 4). AFAIK it is alterable. > > Again: small activity is your friend here. Small number of datasets cataloged > in the BCS is good here. Potential problems with the BCS will not affect > other BCSes. > > I use it for years (with limited activity). Mostly PS files and some VSAM. No > problems observed. > Caution: PDSE *will* break despite of way how catalog is shared. No help from > CA-MIM, AFAIK. Observed many times educated many guys who used PDSE for > sharing. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 20.04.2020 o 14:45, Allan Staller pisze: >> Yes, it can be done. I reiterate, IMO, this is most likely not a good idea. >> In order to accomplish this safely, you also need to regress GRS to pre-GRS >> functionality. >> Everything affecting this catalog must be handled w/Reserve/Release, >> and not normal processing VSAM Sharoptions for the catalog need to be >> changed. IIRC when I "undid" this the catalog hand Shareoptions (2,3) (or >> was it 4,3?). >> This option tells z/OS that the user is responsible for Catalog >> seriailization. >> SYSDSN, SYSIGGV2, SYSVTOC, SYSZVSAM (?) and the SPF* queues need to be >> excluded from GRS processing. >> >> In my case that led to various deadly embraces that usually led to manual >> intervention. >> >> My $0.02 USD on this is: Why point the shotgun at your foot? >> >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of >> R.S. >> Sent: Monday, April 20, 2020 3:45 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Opinions/experience on sharing catalogs outside plex >> >> [CAUTION: This Email is from outside the Organization. Do not click
Re: Opinions/experience on sharing catalogs outside plex
Skip, In the past I implemented STK tapes, the largest tape system in Poland at the time. Interesting job. :-) It seems, you shared control datasets between datacenters. Assuming your second datacenter is for disaster recovery, you had single point of failure. Catalog is not important there, but availability of datasets is. How could you work with tapes in case the datasets are lost due to catastrophe of primary DC? IMHO the only way was to have remote copy of control datasets. Last, but not least, as far as I remember the datasets were very specific - they have (had?) hardcoded both volume labels and device numbers. While remote copy replicate volume label, the dev num is IODF dependend. There was a method for that, I forgot details. Other method could be a trick with duplicate device numbers. -- Radoslaw Skorupka Lodz, Poland W dniu 24.05.2020 o 21:29, Jesse 1 Robinson pisze: Until recently, we shared a catalog not only across sysplexes but between data centers. All because of tape. We had STK virtual tape (in both data centers) supported by MIA (Multi Image Allocation). These products require control data sets shared among all exploiting systems. We could have managed with uncataloged data sets, but that was deemed riskier in the long run than a shared catalog. The only entries in the catalog were for tape management data sets. We never had a catastrophe. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Monday, April 20, 2020 7:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Opinions/experience on sharing catalogs outside plex CAUTION EXTERNAL EMAIL Well, it is not good idea, but sometimes even such idea is better than nothing. What's important the risk covers THIS catalog only, not whole world. And yes, this catalog and shared datasets should be shared without "sysplex features" like changes is serialization. RESERVE should be used here or CA-MIM should be used, but the last one is add-on tool. BTW: BCS can be defined with SHR(3 4) or SHR(3 3). For this case it has to be SHR(3 4). AFAIK it is alterable. Again: small activity is your friend here. Small number of datasets cataloged in the BCS is good here. Potential problems with the BCS will not affect other BCSes. I use it for years (with limited activity). Mostly PS files and some VSAM. No problems observed. Caution: PDSE *will* break despite of way how catalog is shared. No help from CA-MIM, AFAIK. Observed many times educated many guys who used PDSE for sharing. -- Radoslaw Skorupka Lodz, Poland W dniu 20.04.2020 o 14:45, Allan Staller pisze: Yes, it can be done. I reiterate, IMO, this is most likely not a good idea. In order to accomplish this safely, you also need to regress GRS to pre-GRS functionality. Everything affecting this catalog must be handled w/Reserve/Release, and not normal processing VSAM Sharoptions for the catalog need to be changed. IIRC when I "undid" this the catalog hand Shareoptions (2,3) (or was it 4,3?). This option tells z/OS that the user is responsible for Catalog seriailization. SYSDSN, SYSIGGV2, SYSVTOC, SYSZVSAM (?) and the SPF* queues need to be excluded from GRS processing. In my case that led to various deadly embraces that usually led to manual intervention. My $0.02 USD on this is: Why point the shotgun at your foot? -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Monday, April 20, 2020 3:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Opinions/experience on sharing catalogs outside plex [CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.] W dniu 09.04.2020 o 02:11, Rob Schramm pisze: I am considering sharing some usercats outside of a sysplex. What I can find is that sysiggv2 must be kept as a reserve to do so. Looking for others that have had to do this. One question I had was, what happens on a ispf 3.4 when the data set is part of the catalog but exists in another system? Ief238d? My €0.02 1. You can share catalogs between sysplexes. Note: we mean BCS, which is usually called catalog. 2. The less activity on the BCS the better. 3. The above means: 3.1. Avoid keeping non-shared datasets in the BCS. Use another BCS for that. 3.2. It is not bad idea to have multiple "small" shared BCSes. 4. You cannot use any sophisticated catalog sharing features like RLS or ECS. Regarding you last question: I understand it as you have entry in the BCS, but the dataset reside on volume which is not share, that mean it is unavailable for one system. It's nothing exotic. It's like orphan catalog entry, which sometimes may happen even without BCS sharing (usually as result of human e
Re: Opinions/experience on sharing catalogs outside plex
Until recently, we shared a catalog not only across sysplexes but between data centers. All because of tape. We had STK virtual tape (in both data centers) supported by MIA (Multi Image Allocation). These products require control data sets shared among all exploiting systems. We could have managed with uncataloged data sets, but that was deemed riskier in the long run than a shared catalog. The only entries in the catalog were for tape management data sets. We never had a catastrophe. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Monday, April 20, 2020 7:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Opinions/experience on sharing catalogs outside plex CAUTION EXTERNAL EMAIL Well, it is not good idea, but sometimes even such idea is better than nothing. What's important the risk covers THIS catalog only, not whole world. And yes, this catalog and shared datasets should be shared without "sysplex features" like changes is serialization. RESERVE should be used here or CA-MIM should be used, but the last one is add-on tool. BTW: BCS can be defined with SHR(3 4) or SHR(3 3). For this case it has to be SHR(3 4). AFAIK it is alterable. Again: small activity is your friend here. Small number of datasets cataloged in the BCS is good here. Potential problems with the BCS will not affect other BCSes. I use it for years (with limited activity). Mostly PS files and some VSAM. No problems observed. Caution: PDSE *will* break despite of way how catalog is shared. No help from CA-MIM, AFAIK. Observed many times educated many guys who used PDSE for sharing. -- Radoslaw Skorupka Lodz, Poland W dniu 20.04.2020 o 14:45, Allan Staller pisze: > Yes, it can be done. I reiterate, IMO, this is most likely not a good idea. > In order to accomplish this safely, you also need to regress GRS to pre-GRS > functionality. > Everything affecting this catalog must be handled w/Reserve/Release, > and not normal processing VSAM Sharoptions for the catalog need to be > changed. IIRC when I "undid" this the catalog hand Shareoptions (2,3) (or was > it 4,3?). > This option tells z/OS that the user is responsible for Catalog > seriailization. > SYSDSN, SYSIGGV2, SYSVTOC, SYSZVSAM (?) and the SPF* queues need to be > excluded from GRS processing. > > In my case that led to various deadly embraces that usually led to manual > intervention. > > My $0.02 USD on this is: Why point the shotgun at your foot? > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > R.S. > Sent: Monday, April 20, 2020 3:45 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Opinions/experience on sharing catalogs outside plex > > [CAUTION: This Email is from outside the Organization. Do not click > links or open attachments unless you trust the sender.] > > W dniu 09.04.2020 o 02:11, Rob Schramm pisze: >> I am considering sharing some usercats outside of a sysplex. What I >> can find is that sysiggv2 must be kept as a reserve to do so. >> >> Looking for others that have had to do this. >> >> One question I had was, what happens on a ispf 3.4 when the data set >> is part of the catalog but exists in another system? Ief238d? > My €0.02 > > 1. You can share catalogs between sysplexes. Note: we mean BCS, which is > usually called catalog. > 2. The less activity on the BCS the better. > 3. The above means: > 3.1. Avoid keeping non-shared datasets in the BCS. Use another BCS for that. > 3.2. It is not bad idea to have multiple "small" shared BCSes. > 4. You cannot use any sophisticated catalog sharing features like RLS or ECS. > > Regarding you last question: I understand it as you have entry in the BCS, > but the dataset reside on volume which is not share, that mean it is > unavailable for one system. It's nothing exotic. It's like orphan catalog > entry, which sometimes may happen even without BCS sharing (usually as result > of human error). > However that also means the sharing is not done correctly. The best scenario > is when all datasets cataloged in shared BCS reside on volumes which are also > shared. Preferably the BCS is also on the volume from that group. > Keep it simple. > > -- > Radoslaw Skorupka > Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Opinions/experience on sharing catalogs outside plex
Well, it is not good idea, but sometimes even such idea is better than nothing. What's important the risk covers THIS catalog only, not whole world. And yes, this catalog and shared datasets should be shared without "sysplex features" like changes is serialization. RESERVE should be used here or CA-MIM should be used, but the last one is add-on tool. BTW: BCS can be defined with SHR(3 4) or SHR(3 3). For this case it has to be SHR(3 4). AFAIK it is alterable. Again: small activity is your friend here. Small number of datasets cataloged in the BCS is good here. Potential problems with the BCS will not affect other BCSes. I use it for years (with limited activity). Mostly PS files and some VSAM. No problems observed. Caution: PDSE *will* break despite of way how catalog is shared. No help from CA-MIM, AFAIK. Observed many times educated many guys who used PDSE for sharing. -- Radoslaw Skorupka Lodz, Poland W dniu 20.04.2020 o 14:45, Allan Staller pisze: Yes, it can be done. I reiterate, IMO, this is most likely not a good idea. In order to accomplish this safely, you also need to regress GRS to pre-GRS functionality. Everything affecting this catalog must be handled w/Reserve/Release, and not normal processing VSAM Sharoptions for the catalog need to be changed. IIRC when I "undid" this the catalog hand Shareoptions (2,3) (or was it 4,3?). This option tells z/OS that the user is responsible for Catalog seriailization. SYSDSN, SYSIGGV2, SYSVTOC, SYSZVSAM (?) and the SPF* queues need to be excluded from GRS processing. In my case that led to various deadly embraces that usually led to manual intervention. My $0.02 USD on this is: Why point the shotgun at your foot? -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Monday, April 20, 2020 3:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Opinions/experience on sharing catalogs outside plex [CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.] W dniu 09.04.2020 o 02:11, Rob Schramm pisze: I am considering sharing some usercats outside of a sysplex. What I can find is that sysiggv2 must be kept as a reserve to do so. Looking for others that have had to do this. One question I had was, what happens on a ispf 3.4 when the data set is part of the catalog but exists in another system? Ief238d? My €0.02 1. You can share catalogs between sysplexes. Note: we mean BCS, which is usually called catalog. 2. The less activity on the BCS the better. 3. The above means: 3.1. Avoid keeping non-shared datasets in the BCS. Use another BCS for that. 3.2. It is not bad idea to have multiple "small" shared BCSes. 4. You cannot use any sophisticated catalog sharing features like RLS or ECS. Regarding you last question: I understand it as you have entry in the BCS, but the dataset reside on volume which is not share, that mean it is unavailable for one system. It's nothing exotic. It's like orphan catalog entry, which sometimes may happen even without BCS sharing (usually as result of human error). However that also means the sharing is not done correctly. The best scenario is when all datasets cataloged in shared BCS reside on volumes which are also shared. Preferably the BCS is also on the volume from that group. Keep it simple. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. 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, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP
Re: Opinions/experience on sharing catalogs outside plex
The OP did not mention CA-MIM. That will handle the issue. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Vernooij, Kees (ITOP NM) - KLM Sent: Monday, April 20, 2020 7:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Opinions/experience on sharing catalogs outside plex [CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.] 2 notes: You need not regress to pre-GRS, you need to regress to pre-Hyperswap, which required the elimination of Reserves by converting them to global enqueus with GRS. CA-MIM provided (when we used it) GRS functionality across Sysplexes. Kees. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: 20 April 2020 14:45 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Opinions/experience on sharing catalogs outside plex Yes, it can be done. I reiterate, IMO, this is most likely not a good idea. In order to accomplish this safely, you also need to regress GRS to pre-GRS functionality. Everything affecting this catalog must be handled w/Reserve/Release, and not normal processing VSAM Sharoptions for the catalog need to be changed. IIRC when I "undid" this the catalog hand Shareoptions (2,3) (or was it 4,3?). This option tells z/OS that the user is responsible for Catalog seriailization. SYSDSN, SYSIGGV2, SYSVTOC, SYSZVSAM (?) and the SPF* queues need to be excluded from GRS processing. In my case that led to various deadly embraces that usually led to manual intervention. My $0.02 USD on this is: Why point the shotgun at your foot? -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Monday, April 20, 2020 3:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Opinions/experience on sharing catalogs outside plex [CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.] W dniu 09.04.2020 o 02:11, Rob Schramm pisze: > I am considering sharing some usercats outside of a sysplex. What I > can find is that sysiggv2 must be kept as a reserve to do so. > > Looking for others that have had to do this. > > One question I had was, what happens on a ispf 3.4 when the data set > is part of the catalog but exists in another system? Ief238d? My €0.02 1. You can share catalogs between sysplexes. Note: we mean BCS, which is usually called catalog. 2. The less activity on the BCS the better. 3. The above means: 3.1. Avoid keeping non-shared datasets in the BCS. Use another BCS for that. 3.2. It is not bad idea to have multiple "small" shared BCSes. 4. You cannot use any sophisticated catalog sharing features like RLS or ECS. Regarding you last question: I understand it as you have entry in the BCS, but the dataset reside on volume which is not share, that mean it is unavailable for one system. It's nothing exotic. It's like orphan catalog entry, which sometimes may happen even without BCS sharing (usually as result of human error). However that also means the sharing is not done correctly. The best scenario is when all datasets cataloged in shared BCS reside on volumes which are also shared. Preferably the BCS is also on the volume from that group. Keep it simple. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mbank.pl%2Fdata=02%7C01%7Callan.staller%40HCL.COM%7Cffa4bd2b6c084d5c34e108d7e52a5288%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637229842282834595sdata=fdI7BLtaR60WFeKQ8hscysetzWAiiMyYSqHcWMr2%2B4g%3Dreserved=0, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Sena
Re: Opinions/experience on sharing catalogs outside plex
2 notes: You need not regress to pre-GRS, you need to regress to pre-Hyperswap, which required the elimination of Reserves by converting them to global enqueus with GRS. CA-MIM provided (when we used it) GRS functionality across Sysplexes. Kees. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Allan Staller Sent: 20 April 2020 14:45 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Opinions/experience on sharing catalogs outside plex Yes, it can be done. I reiterate, IMO, this is most likely not a good idea. In order to accomplish this safely, you also need to regress GRS to pre-GRS functionality. Everything affecting this catalog must be handled w/Reserve/Release, and not normal processing VSAM Sharoptions for the catalog need to be changed. IIRC when I "undid" this the catalog hand Shareoptions (2,3) (or was it 4,3?). This option tells z/OS that the user is responsible for Catalog seriailization. SYSDSN, SYSIGGV2, SYSVTOC, SYSZVSAM (?) and the SPF* queues need to be excluded from GRS processing. In my case that led to various deadly embraces that usually led to manual intervention. My $0.02 USD on this is: Why point the shotgun at your foot? -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Monday, April 20, 2020 3:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Opinions/experience on sharing catalogs outside plex [CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.] W dniu 09.04.2020 o 02:11, Rob Schramm pisze: > I am considering sharing some usercats outside of a sysplex. What I > can find is that sysiggv2 must be kept as a reserve to do so. > > Looking for others that have had to do this. > > One question I had was, what happens on a ispf 3.4 when the data set > is part of the catalog but exists in another system? Ief238d? My €0.02 1. You can share catalogs between sysplexes. Note: we mean BCS, which is usually called catalog. 2. The less activity on the BCS the better. 3. The above means: 3.1. Avoid keeping non-shared datasets in the BCS. Use another BCS for that. 3.2. It is not bad idea to have multiple "small" shared BCSes. 4. You cannot use any sophisticated catalog sharing features like RLS or ECS. Regarding you last question: I understand it as you have entry in the BCS, but the dataset reside on volume which is not share, that mean it is unavailable for one system. It's nothing exotic. It's like orphan catalog entry, which sometimes may happen even without BCS sharing (usually as result of human error). However that also means the sharing is not done correctly. The best scenario is when all datasets cataloged in shared BCS reside on volumes which are also shared. Preferably the BCS is also on the volume from that group. Keep it simple. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mbank.pl%2Fdata=02%7C01%7Callan.staller%40HCL.COM%7C713bf3ba05ee48822fd708d7e5074106%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637229691688462036sdata=yVU69jxSqL3eUaQBzQrjAJf41Ro%2FWUQ12ueSnw0%2Fhu0%3Dreserved=0, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mbank.pl%2Fdata=02%7C01%7Callan.staller%40HCL.COM%7C713bf3ba05ee48822fd708d7e5074106%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637229691688462036sdata=yVU69jxSqL3eUaQBzQrjAJf41Ro%2FWUQ12ueSnw0%2Fhu0%3Dreserved=0, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National
Re: Opinions/experience on sharing catalogs outside plex
Yes, it can be done. I reiterate, IMO, this is most likely not a good idea. In order to accomplish this safely, you also need to regress GRS to pre-GRS functionality. Everything affecting this catalog must be handled w/Reserve/Release, and not normal processing VSAM Sharoptions for the catalog need to be changed. IIRC when I "undid" this the catalog hand Shareoptions (2,3) (or was it 4,3?). This option tells z/OS that the user is responsible for Catalog seriailization. SYSDSN, SYSIGGV2, SYSVTOC, SYSZVSAM (?) and the SPF* queues need to be excluded from GRS processing. In my case that led to various deadly embraces that usually led to manual intervention. My $0.02 USD on this is: Why point the shotgun at your foot? -Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Sent: Monday, April 20, 2020 3:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Opinions/experience on sharing catalogs outside plex [CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.] W dniu 09.04.2020 o 02:11, Rob Schramm pisze: > I am considering sharing some usercats outside of a sysplex. What I > can find is that sysiggv2 must be kept as a reserve to do so. > > Looking for others that have had to do this. > > One question I had was, what happens on a ispf 3.4 when the data set > is part of the catalog but exists in another system? Ief238d? My €0.02 1. You can share catalogs between sysplexes. Note: we mean BCS, which is usually called catalog. 2. The less activity on the BCS the better. 3. The above means: 3.1. Avoid keeping non-shared datasets in the BCS. Use another BCS for that. 3.2. It is not bad idea to have multiple "small" shared BCSes. 4. You cannot use any sophisticated catalog sharing features like RLS or ECS. Regarding you last question: I understand it as you have entry in the BCS, but the dataset reside on volume which is not share, that mean it is unavailable for one system. It's nothing exotic. It's like orphan catalog entry, which sometimes may happen even without BCS sharing (usually as result of human error). However that also means the sharing is not done correctly. The best scenario is when all datasets cataloged in shared BCS reside on volumes which are also shared. Preferably the BCS is also on the volume from that group. Keep it simple. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mbank.pl%2Fdata=02%7C01%7Callan.staller%40HCL.COM%7C713bf3ba05ee48822fd708d7e5074106%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637229691688462036sdata=yVU69jxSqL3eUaQBzQrjAJf41Ro%2FWUQ12ueSnw0%2Fhu0%3Dreserved=0, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mbank.pl%2Fdata=02%7C01%7Callan.staller%40HCL.COM%7C713bf3ba05ee48822fd708d7e5074106%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637229691688462036sdata=yVU69jxSqL3eUaQBzQrjAJf41Ro%2FWUQ12ueSnw0%2Fhu0%3Dreserved=0, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and int
Re: Opinions/experience on sharing catalogs outside plex
W dniu 09.04.2020 o 02:11, Rob Schramm pisze: I am considering sharing some usercats outside of a sysplex. What I can find is that sysiggv2 must be kept as a reserve to do so. Looking for others that have had to do this. One question I had was, what happens on a ispf 3.4 when the data set is part of the catalog but exists in another system? Ief238d? My €0.02 1. You can share catalogs between sysplexes. Note: we mean BCS, which is usually called catalog. 2. The less activity on the BCS the better. 3. The above means: 3.1. Avoid keeping non-shared datasets in the BCS. Use another BCS for that. 3.2. It is not bad idea to have multiple "small" shared BCSes. 4. You cannot use any sophisticated catalog sharing features like RLS or ECS. Regarding you last question: I understand it as you have entry in the BCS, but the dataset reside on volume which is not share, that mean it is unavailable for one system. It's nothing exotic. It's like orphan catalog entry, which sometimes may happen even without BCS sharing (usually as result of human error). However that also means the sharing is not done correctly. The best scenario is when all datasets cataloged in shared BCS reside on volumes which are also shared. Preferably the BCS is also on the volume from that group. Keep it simple. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. 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, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Opinions/experience on sharing catalogs outside plex
Don’t forget Hyperswap either if you are running that. IBM recommends no reserves for that. On Thu, Apr 9, 2020 at 8:41 AM Allan Staller wrote: > All around, this is a really really bad idea. I understand you may not > have a choice. > Don’t forget: > > VSAM shareoptions > SYSVSAM resource > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Rob Schramm > Sent: Wednesday, April 8, 2020 7:11 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Opinions/experience on sharing catalogs outside plex > > [CAUTION: This Email is from outside the Organization. Do not click links > or open attachments unless you trust the sender.] > > I am considering sharing some usercats outside of a sysplex. What I can > find is that sysiggv2 must be kept as a reserve to do so. > > Looking for others that have had to do this. > > One question I had was, what happens on a ispf 3.4 when the data set is > part of the catalog but exists in another system? Ief238d? > > Thanks, > > Rob Schramm > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ::DISCLAIMER:: > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain > viruses in transmission. The e mail and its contents (with or without > referred errors) shall therefore not attach any liability on the originator > or HCL or its affiliates. Views or opinions, if any, presented in this > email are solely those of the author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of reproduction, > dissemination, copying, disclosure, modification, distribution and / or > publication of this message without the prior written consent of authorized > representative of HCL is strictly prohibited. If you have received this > email in error please delete it and notify the sender immediately. Before > opening any email and/or attachments, please check them for viruses and > other defects. > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Opinions/experience on sharing catalogs outside plex
All around, this is a really really bad idea. I understand you may not have a choice. Don’t forget: VSAM shareoptions SYSVSAM resource -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rob Schramm Sent: Wednesday, April 8, 2020 7:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Opinions/experience on sharing catalogs outside plex [CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.] I am considering sharing some usercats outside of a sysplex. What I can find is that sysiggv2 must be kept as a reserve to do so. Looking for others that have had to do this. One question I had was, what happens on a ispf 3.4 when the data set is part of the catalog but exists in another system? Ief238d? Thanks, Rob Schramm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Opinions/experience on sharing catalogs outside plex
Rob, We do something similar with our SMF data offloads that are only processed on one sysplex. Take a look at info APAR II14297 for recommendations. Regards, Tom -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Schramm Sent: Wednesday, April 08, 2020 8:11 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Opinions/experience on sharing catalogs outside plex This email originated from outside of the organization. I am considering sharing some usercats outside of a sysplex. What I can find is that sysiggv2 must be kept as a reserve to do so. Looking for others that have had to do this. One question I had was, what happens on a ispf 3.4 when the data set is part of the catalog but exists in another system? Ief238d? Thanks, Rob Schramm -- 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: Opinions/experience on sharing catalogs outside plex
Do you use ECS or VLF catalog caching? That sounds like a road to problems. Kees. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rob Schramm Sent: 09 April 2020 02:11 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Opinions/experience on sharing catalogs outside plex I am considering sharing some usercats outside of a sysplex. What I can find is that sysiggv2 must be kept as a reserve to do so. Looking for others that have had to do this. One question I had was, what happens on a ispf 3.4 when the data set is part of the catalog but exists in another system? Ief238d? Thanks, Rob Schramm -- 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: Opinions/experience on sharing catalogs outside plex
Rob, The manual, "MVS Planning: Global Resource Serialization" SA23-1389-30 has information on sharing catalogs. SYSIGGV2 needs to use reserves. However, I think you also need to use reserves on SYSZVVDS and SYSVTOC. From memory (rather distant and not always reliable) there is also an IMS Qname that needs to be added to the list, but only if you use IMS. As for your ISPF question, I am unclear of the situation you describe. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: www.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rob Schramm Sent: 09 April 2020 01:11 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [IBM-MAIN] Opinions/experience on sharing catalogs outside plex I am considering sharing some usercats outside of a sysplex. What I can find is that sysiggv2 must be kept as a reserve to do so. Looking for others that have had to do this. One question I had was, what happens on a ispf 3.4 when the data set is part of the catalog but exists in another system? Ief238d? Thanks, Rob Schramm -- 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: Opinions/experience on sharing catalogs outside plex
Sharing catalogs outside of the sysplex (i.e. with connected LPARs that just "happen" to not be in the sysplex), is perfectly fine as long as you remember that it's impossible for them to share the information stored in the CF's, so if you cache the catalog(s) in the CF you will need to stop doing that. Otherwise there is no real danger involved and in fact it is done all the time. I can't stress enough though that you can't treat it like all of your plexed systems are able to cache it in the CF and the "other" LPAR will magically get that cache somehow, because it will not. Now, assuming you don't mind having a slight bit more overhead by not caching the catalog(s) in the CF, you should have no problems. Also, it's normally a really good idea if you are going to share your catalogs, that you share them all. Unless you are very regimented (and careful), because you could end up with some issues (data management wise), where some datasets are cataloged and some are not, this can be a real issue with SMS dataset and also when you run your tape management processes, so unless you are careful, sharing just a subset is pretty dreadful. So, either share them all, or don't share any. As long as you aren't caching them (in the CF structures) you will be fine. People do this all the time where they have a sysplex and a test or sandbox system or they have LPARs that they are trying to combine. It's just like running several LPARs on the same BOX that are not SYSPLEXed, it works fine. Just remember that the DASD needs to be shared and there will be reserves, (but they are catalogs so it's minor and not many). It's also a good idea when sharing DASD at all to have GRS involved (or MIM). Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Opinions/experience on sharing catalogs outside plex
Sounds like a bad idea to me. You can't guarantee the integrity of the user catalogues. Can you set up the external systems as NJE nodes and get them to submit jobs to your sysplex instead? Ant. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rob Schramm Sent: Thursday, 9 April 2020 9:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Opinions/experience on sharing catalogs outside plex I am considering sharing some usercats outside of a sysplex. What I can find is that sysiggv2 must be kept as a reserve to do so. Looking for others that have had to do this. One question I had was, what happens on a ispf 3.4 when the data set is part of the catalog but exists in another system? Ief238d? Thanks, Rob Schramm -- 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
Opinions/experience on sharing catalogs outside plex
I am considering sharing some usercats outside of a sysplex. What I can find is that sysiggv2 must be kept as a reserve to do so. Looking for others that have had to do this. One question I had was, what happens on a ispf 3.4 when the data set is part of the catalog but exists in another system? Ief238d? Thanks, Rob Schramm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
