Cloning a Sysres and ZFS
Hi, We use a process of cloning on our Dev lpar to create new Sysres before we apply maintenance, it has worked fine for Zos 1r13 but we only used HFS. We have started to use ZFS for 2r1 which is fine if the Sysres is for the same Lpar the clone process is run on but I am now cloning a Sysres for another Lpar. I can't get the ZFS datasets accessible in both master catalogs at the same time, I know now that it is because they are Vsam datasets so cannot be in 2 catalogs. I want them to be in both so I can apply maintenance on our Dev lpar rather than risk a mistake or accident causing a problem in production. Can they be in a user catalog? I know they are not now because they are used very early on in the IPL but is it an option? Is there an easy way to move ZFS datasets between 2 master catalogs? The only option I can think of at the moment is running the clone process from the current Sysres to a new one in the prod lpar so everything will be in the prod catalog. Thanks James James Chambers IT Operations & IBM Support Team Lead 56/59 St. Stephen's Green, Dublin 2 Ph: +353 1 669 5127 "BANKEMFB" made the following annotations. -- This is a confidential communication and is intended only for the addressee indicated in the message (or duly authorised to be responsible for the delivery of the message to such person). You are specifically prohibited from copying this message or delivering the same, or any part thereof, to any other person, whomsoever or howsoever, unless you receive written authorisation from us to do. If you are anyone other than the intended addressee, or person duly authorised and responsible for the delivery of this message to the intended addressee, you should destroy this message and notify us immediately. Please note that we accept no responsibility whatsoever in the event that this message or any other email message or any part thereof becomes known or is communicated to anyone other than the intended recipient or other person authorised in writing by us to receive it, howsoever arising and disclaim all liability for any losses or damage which may be sustained by any person as a result thereof. Permanent TSB plc. is regulated by the Central Bank of Ireland and is a tied Assurance Agent for Irish Life Assurance plc. Permanent TSB plc. registered in Dublin under No. 222332. Registered office is: 56-59, St. Stephen?s Green, Dublin 2, Ireland. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning a Sysres and ZFS
Hi James, We clone our sysres (maintained in sandbox) every month to generate IPL volumes for the Dev and Prod LPARs. Almost all datasets on the sysres volume are in a user catalog on that same sysres, including the VERSION zFS. We don't have a single zFS in the master catalog. We're 2.1 now, but have had this setup for a number of releases, so I don't see any reason why you would need your zFS in Master for your 1.13 systems. Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chambers, James Sent: Monday, January 18, 2016 5:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Cloning a Sysres and ZFS Hi, We use a process of cloning on our Dev lpar to create new Sysres before we apply maintenance, it has worked fine for Zos 1r13 but we only used HFS. We have started to use ZFS for 2r1 which is fine if the Sysres is for the same Lpar the clone process is run on but I am now cloning a Sysres for another Lpar. I can't get the ZFS datasets accessible in both master catalogs at the same time, I know now that it is because they are Vsam datasets so cannot be in 2 catalogs. I want them to be in both so I can apply maintenance on our Dev lpar rather than risk a mistake or accident causing a problem in production. Can they be in a user catalog? I know they are not now because they are used very early on in the IPL but is it an option? Is there an easy way to move ZFS datasets between 2 master catalogs? The only option I can think of at the moment is running the clone process from the current Sysres to a new one in the prod lpar so everything will be in the prod catalog. Thanks James James Chambers IT Operations & IBM Support Team Lead 56/59 St. Stephen's Green, Dublin 2 Ph: +353 1 669 5127 "BANKEMFB" made the following annotations. -- This is a confidential communication and is intended only for the addressee indicated in the message (or duly authorised to be responsible for the delivery of the message to such person). You are specifically prohibited from copying this message or delivering the same, or any part thereof, to any other person, whomsoever or howsoever, unless you receive written authorisation from us to do. If you are anyone other than the intended addressee, or person duly authorised and responsible for the delivery of this message to the intended addressee, you should destroy this message and notify us immediately. Please note that we accept no responsibility whatsoever in the event that this message or any other email message or any part thereof becomes known or is communicated to anyone other than the intended recipient or other person authorised in writing by us to receive it, howsoever arising and disclaim all liability for any losses or damage which may be sustained by any person as a result thereof. Permanent TSB plc. is regulated by the Central Bank of Ireland and is a tied Assurance Agent for Irish Life Assurance plc. Permanent TSB plc. registered in Dublin under No. 222332. Registered office is: 56-59, St. Stephen?s Green, Dublin 2, Ireland. == -- 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: Cloning a Sysres and ZFS
To expand on that thought a bit: - You can name the usercatalog using the volume name. - You can use SYMBOLICRELATE on DEFINE ALIAS to point to the catalog thusly named in the master catalog on the production system. - If you have more than one volume in your target volume set, you can derive system symbols for the other volumes from the system-provided &SYSR1 symbol, given that you name them in a way that makes the volume names derivable (such as ZOSR1, ZOSR2, etc.). - You can put the SMP/E CSI data set on the sysres, too, and catalog it in the same catalog. This has four benefits. First, you have the inventory matching the data sets on the same volume, so they stay in sync. Second, you can get information from the zones that match the data sets any time without worrying about selecting the "right" zones to match the system's level. Third, z/OSMF's Software Management needs the zones for reporting to help answer questions like "where do I NOT have this fix" and "when do I lose support for the products I have deployed"? Fourth, you can at need clone and install service to the production level of software without the need to have any other system available. (If you worry about updating production data sets by accident, use ZONEEDIT to point all the DDDEFs into Never-Never Land.) Also, you can use a similar technique for subsystem (e.g., DB2) data sets, except that you will need to change the symbols yourself because the system will not build them for you. Since you can use SETLOAD IEASYM and IEASYMU2 to update the active symbols on z/OS V2.1 and up, you can even dynamically switch back and forth at need. van der Grijn, Bart , B wrote: Hi James, We clone our sysres (maintained in sandbox) every month to generate IPL volumes for the Dev and Prod LPARs. Almost all datasets on the sysres volume are in a user catalog on that same sysres, including the VERSION zFS. We don't have a single zFS in the master catalog. We're 2.1 now, but have had this setup for a number of releases, so I don't see any reason why you would need your zFS in Master for your 1.13 systems. -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning a Sysres and ZFS
Hi Bart, Thanks the below is exactly what I was looking to find out. I think the reason the HFS are all in the master catalog is it worked and nobody thought to change it, now that we are converting to ZFS we need to change it. Thanks James -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of van der Grijn, Bart (B) Sent: 18 January 2016 12:35 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cloning a Sysres and ZFS Hi James, We clone our sysres (maintained in sandbox) every month to generate IPL volumes for the Dev and Prod LPARs. Almost all datasets on the sysres volume are in a user catalog on that same sysres, including the VERSION zFS. We don't have a single zFS in the master catalog. We're 2.1 now, but have had this setup for a number of releases, so I don't see any reason why you would need your zFS in Master for your 1.13 systems. Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chambers, James Sent: Monday, January 18, 2016 5:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Cloning a Sysres and ZFS Hi, We use a process of cloning on our Dev lpar to create new Sysres before we apply maintenance, it has worked fine for Zos 1r13 but we only used HFS. We have started to use ZFS for 2r1 which is fine if the Sysres is for the same Lpar the clone process is run on but I am now cloning a Sysres for another Lpar. I can't get the ZFS datasets accessible in both master catalogs at the same time, I know now that it is because they are Vsam datasets so cannot be in 2 catalogs. I want them to be in both so I can apply maintenance on our Dev lpar rather than risk a mistake or accident causing a problem in production. Can they be in a user catalog? I know they are not now because they are used very early on in the IPL but is it an option? Is there an easy way to move ZFS datasets between 2 master catalogs? The only option I can think of at the moment is running the clone process from the current Sysres to a new one in the prod lpar so everything will be in the prod catalog. Thanks James James Chambers IT Operations & IBM Support Team Lead 56/59 St. Stephen's Green, Dublin 2 Ph: +353 1 669 5127 "BANKEMFB" made the following annotations. -- This is a confidential communication and is intended only for the addressee indicated in the message (or duly authorised to be responsible for the delivery of the message to such person). You are specifically prohibited from copying this message or delivering the same, or any part thereof, to any other person, whomsoever or howsoever, unless you receive written authorisation from us to do. If you are anyone other than the intended addressee, or person duly authorised and responsible for the delivery of this message to the intended addressee, you should destroy this message and notify us immediately. Please note that we accept no responsibility whatsoever in the event that this message or any other email message or any part thereof becomes known or is communicated to anyone other than the intended recipient or other person authorised in writing by us to receive it, howsoever arising and disclaim all liability for any losses or damage which may be sustained by any person as a result thereof. Permanent TSB plc. is regulated by the Central Bank of Ireland and is a tied Assurance Agent for Irish Life Assurance plc. Permanent TSB plc. registered in Dublin under No. 222332. Registered office is: 56-59, St. Stephen?s Green, Dublin 2, Ireland. == -- 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 "BANKEMFB" made the following annotations. -- This is a confidential communication and is intended only for the addressee indicated in the message (or duly authorised to be responsible for the delivery of the message to such person). You are specifically prohibited from copying this message or delivering the same, or any part thereof, to any other person, whomsoever or howsoever, unless you receive written authorisation from us to do. If you are anyone other than the intended addressee, or person duly authorised and responsible for the delivery of this message to the intended addressee, you should destroy this message and notify us immediately. Please note that we
Re: Cloning a Sysres and ZFS
Hi John, You mention using ZONEEDIT to point the DDDEFs into Never-Never Land to stop production dataset being updated by accident. All our DDDEFs use the volume so the targets always points at the correct datasets but this doesn't work for our HFS or ZFS because they need to be mounted at /Service. We then ZONEEDIT the DDDEFs to point at /Service instead of /, this needs to be changed back to / when finished. This works but when I was starting out applying maintenance to Zos I did make a mistake and had not done the ZONEEDIT to change / to /Service and mount the HFS because it wasn't an issue for the other products I did SMPE for at the time. Is there a better way to deal with the HFS or ZFS DDDEFs? Thanks James -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Eells Sent: 18 January 2016 14:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cloning a Sysres and ZFS To expand on that thought a bit: - You can name the usercatalog using the volume name. - You can use SYMBOLICRELATE on DEFINE ALIAS to point to the catalog thusly named in the master catalog on the production system. - If you have more than one volume in your target volume set, you can derive system symbols for the other volumes from the system-provided &SYSR1 symbol, given that you name them in a way that makes the volume names derivable (such as ZOSR1, ZOSR2, etc.). - You can put the SMP/E CSI data set on the sysres, too, and catalog it in the same catalog. This has four benefits. First, you have the inventory matching the data sets on the same volume, so they stay in sync. Second, you can get information from the zones that match the data sets any time without worrying about selecting the "right" zones to match the system's level. Third, z/OSMF's Software Management needs the zones for reporting to help answer questions like "where do I NOT have this fix" and "when do I lose support for the products I have deployed"? Fourth, you can at need clone and install service to the production level of software without the need to have any other system available. (If you worry about updating production data sets by accident, use ZONEEDIT to point all the DDDEFs into Never-Never Land.) Also, you can use a similar technique for subsystem (e.g., DB2) data sets, except that you will need to change the symbols yourself because the system will not build them for you. Since you can use SETLOAD IEASYM and IEASYMU2 to update the active symbols on z/OS V2.1 and up, you can even dynamically switch back and forth at need. van der Grijn, Bart , B wrote: > Hi James, > > We clone our sysres (maintained in sandbox) every month to generate IPL > volumes for the Dev and Prod LPARs. Almost all datasets on the sysres volume > are in a user catalog on that same sysres, including the VERSION zFS. We > don't have a single zFS in the master catalog. We're 2.1 now, but have had > this setup for a number of releases, so I don't see any reason why you would > need your zFS in Master for your 1.13 systems. -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN "BANKEMFB" made the following annotations. -- This is a confidential communication and is intended only for the addressee indicated in the message (or duly authorised to be responsible for the delivery of the message to such person). You are specifically prohibited from copying this message or delivering the same, or any part thereof, to any other person, whomsoever or howsoever, unless you receive written authorisation from us to do. If you are anyone other than the intended addressee, or person duly authorised and responsible for the delivery of this message to the intended addressee, you should destroy this message and notify us immediately. Please note that we accept no responsibility whatsoever in the event that this message or any other email message or any part thereof becomes known or is communicated to anyone other than the intended recipient or other person authorised in writing by us to receive it, howsoever arising and disclaim all liability for any losses or damage which may be sustained by any person as a result thereof. Permanent TSB plc. is regulated by the Central Bank of Ireland and is a tied Assurance Agent for Irish Life Assurance plc. Permanent TSB plc. registered in Dublin under No. 222332. Registered office is: 56-59, St. Stephen?s Green, Dublin 2, Ireland. == -
Re: Cloning a Sysres and ZFS
On Mon, 18 Jan 2016 09:04:53 -0500, John Eells wrote: >- You can use SYMBOLICRELATE on DEFINE ALIAS to point to the catalog >thusly named in the master catalog on the production system. There used to be a requirement that the alias and the data set name be in the same catalog. I see in Managing Catalogs that the requirement has been lifted in z/OS 2.2 for SYMBOLICRELATE. That's something that I hadn't noticed. Thanks for calling attention to it, John. The OP is z/OS 1.13 and 2.1, though, so it doesn't help him, unless the requirement was lifted earlier and not documented until 2.2. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning a Sysres and ZFS
On Mon, 18 Jan 2016 14:41:32 +, Chambers, James wrote: >Is there a better way to deal with the HFS or ZFS DDDEFs? Include the SYSRES VOLSER as part of the dsname. When you mount it, you can use &SYSRES in the mount specification. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning a Sysres and ZFS
Hi Tom, We already include it like OMVS.RESPR1.ROOT but the DDDEF only has the path. The below shows a DDDEF taken from the apply, it still means I need to make sure I got the mount right and the ZONEEDIT unlike the standard DDDEFs that use the volser to make sure the correct dataset is updated. DDDEF NFSCUTIL PATH'/Service/usr/lpp/NFS/IBM/ and PATHHFS OMVS.RESDD2.ROOT Thanks James -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: 18 January 2016 15:46 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cloning a Sysres and ZFS On Mon, 18 Jan 2016 14:41:32 +, Chambers, James wrote: >Is there a better way to deal with the HFS or ZFS DDDEFs? Include the SYSRES VOLSER as part of the dsname. When you mount it, you can use &SYSRES in the mount specification. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN "BANKEMFB" made the following annotations. -- This is a confidential communication and is intended only for the addressee indicated in the message (or duly authorised to be responsible for the delivery of the message to such person). You are specifically prohibited from copying this message or delivering the same, or any part thereof, to any other person, whomsoever or howsoever, unless you receive written authorisation from us to do. If you are anyone other than the intended addressee, or person duly authorised and responsible for the delivery of this message to the intended addressee, you should destroy this message and notify us immediately. Please note that we accept no responsibility whatsoever in the event that this message or any other email message or any part thereof becomes known or is communicated to anyone other than the intended recipient or other person authorised in writing by us to receive it, howsoever arising and disclaim all liability for any losses or damage which may be sustained by any person as a result thereof. Permanent TSB plc. is regulated by the Central Bank of Ireland and is a tied Assurance Agent for Irish Life Assurance plc. Permanent TSB plc. registered in Dublin under No. 222332. Registered office is: 56-59, St. Stephen’s Green, Dublin 2, Ireland. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning a Sysres and ZFS
Most posts in this thread seem to support the strategy of 'cloning a running system in order to do maintenance'. For as long as I can remember, we have pursued the opposite strategy: the service environment is permanent for the life of a ServerPac and is cloned to produce running systems to populate the Enterprise. DDDEFs, once defined, are never changed; hence the chance of error is near zero. There is no overlap between service and running systems. The service environment is dump/restored to create running system(s) with identifiers like sysplex and/or sysres name embedded in the restored objects. Everything is shared within a sysplex; nothing is shared across sysplex boundaries. This strategy is probably incompatible with z/OSMF managed maintenance, but we have yet to give that a go. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile jo.skip.robin...@att.net jo.skip.robin...@gmail.com > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Chambers, James > Sent: Monday, January 18, 2016 08:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: Cloning a Sysres and ZFS > > Hi Tom, > > We already include it like OMVS.RESPR1.ROOT but the DDDEF only has the > path. The below shows a DDDEF taken from the apply, it still means I need to > make sure I got the mount right and the ZONEEDIT unlike the standard > DDDEFs that use the volser to make sure the correct dataset is updated. > > DDDEF NFSCUTIL PATH'/Service/usr/lpp/NFS/IBM/ and PATHHFS > OMVS.RESDD2.ROOT > > Thanks > > James > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Tom Marchant > Sent: 18 January 2016 15:46 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Cloning a Sysres and ZFS > > On Mon, 18 Jan 2016 14:41:32 +, Chambers, James wrote: > > >Is there a better way to deal with the HFS or ZFS DDDEFs? > > Include the SYSRES VOLSER as part of the dsname. When you mount it, you > can use &SYSRES in the mount specification. > > -- > Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning a Sysres and ZFS
We also use a form of this strategy so there is NEVER a chance the running environments get impacted. Service is applied to a static environment, and then cloned as necessary to form resvol sets. All running systems us indirect cataloging and symbolics to locate datasets as needed. Jerry Whitteridge Manager Mainframe Systems & Storage Albertsons - Safeway Inc. 925 738 9443 Corporate Tieline - 89443 If you feel in control you just aren't going fast enough. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Skip Robinson Sent: Monday, January 18, 2016 9:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cloning a Sysres and ZFS Most posts in this thread seem to support the strategy of 'cloning a running system in order to do maintenance'. For as long as I can remember, we have pursued the opposite strategy: the service environment is permanent for the life of a ServerPac and is cloned to produce running systems to populate the Enterprise. DDDEFs, once defined, are never changed; hence the chance of error is near zero. There is no overlap between service and running systems. The service environment is dump/restored to create running system(s) with identifiers like sysplex and/or sysres name embedded in the restored objects. Everything is shared within a sysplex; nothing is shared across sysplex boundaries. This strategy is probably incompatible with z/OSMF managed maintenance, but we have yet to give that a go. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile jo.skip.robin...@att.net jo.skip.robin...@gmail.com > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Chambers, James > Sent: Monday, January 18, 2016 08:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: Cloning a Sysres and ZFS > > Hi Tom, > > We already include it like OMVS.RESPR1.ROOT but the DDDEF only has the > path. The below shows a DDDEF taken from the apply, it still means I need to > make sure I got the mount right and the ZONEEDIT unlike the standard > DDDEFs that use the volser to make sure the correct dataset is updated. > > DDDEF NFSCUTIL PATH'/Service/usr/lpp/NFS/IBM/ and PATHHFS > OMVS.RESDD2.ROOT > > Thanks > > James > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Tom Marchant > Sent: 18 January 2016 15:46 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Cloning a Sysres and ZFS > > On Mon, 18 Jan 2016 14:41:32 +, Chambers, James wrote: > > >Is there a better way to deal with the HFS or ZFS DDDEFs? > > Include the SYSRES VOLSER as part of the dsname. When you mount it, you > can use &SYSRES in the mount specification. > > -- > Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning a Sysres and ZFS
Tom Marchant wrote: On Mon, 18 Jan 2016 09:04:53 -0500, John Eells wrote: - You can use SYMBOLICRELATE on DEFINE ALIAS to point to the catalog thusly named in the master catalog on the production system. There used to be a requirement that the alias and the data set name be in the same catalog. I see in Managing Catalogs that the requirement has been lifted in z/OS 2.2 for SYMBOLICRELATE. That's something that I hadn't noticed. Thanks for calling attention to it, John. The OP is z/OS 1.13 and 2.1, though, so it doesn't help him, unless the requirement was lifted earlier and not documented until 2.2. SYMBOLICRELATE was originally implemented at my request to make it easier to do subsystem software migration when I worked in ServerPac Design, some time ago. I believe the abilities to use SYMBOLICRELATE to point to a user catalog that itself resides on a volume other than the master catalog volume, and have that usercatalog point to data sets on any volume, were there from its inception many releases ago (well before z/OS V1.13). Thus, one may have: - A master catalog on volume MCAT, with a user catalog connector alias defined using SYMBOLICRELATE that points to the entry for... - A user catalog on volume UCAT, which contains entries for... - Data sets on volume ANYVOL. This does not actually conflict with the requirement you mention (and which is documented in prior levels of Access Method Services for Catalogs). The catalog entry for the user catalog and the entry for the catalog connector alias defined using SYMBOLICRELATE must indeed both be in the same catalog--namely, the master catalog. Otherwise, Catalog could not find the user catalog or relate an alias to it to begin with. I double-checked with DFSMS Catalog Development to make sure this remained true after it was originally implemented, and so far as they know, it has not changed since then. They even tried it out on a V2.1 system they have handy just to prove it worked. What did change in z/OS V2.2 is whether the catalog search was reoriented to (start with) the master catalog for data set entries that use SYMBOLICRELATE when found in user catalogs, which relieves the previously-documented restriction for *data set aliases*. This was the announcement text: "For data set aliases with symbolic-related names, the system is designed to reorient the search with the master catalog or the appropriate user catalog." Note that this change applies only to data set aliases, not usercatalog connector aliases. For a user catalog connector alias to be resolved, the entry for the user catalog itself must still also be in the master catalog. -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning a Sysres and ZFS
On Mon, 18 Jan 2016 16:03:39 +, Chambers, James wrote: >We already include it like OMVS.RESPR1.ROOT but the DDDEF only has the path. >The below shows a DDDEF taken from the >apply, it still means I need to make >sure I got the mount right and the ZONEEDIT unlike the standard DDDEFs that >use the >volser to make sure the correct dataset is updated. > >DDDEF NFSCUTIL PATH'/Service/usr/lpp/NFS/IBM/ and PATHHFS OMVS.RESDD2.ROOT > Consider something along the lines of: /Service/zos/RESDD2/usr/lpp/NFS/IBM/ in the DDDEFs. As part of your cloning process, ZONEEDIT the path names so the new path names align with the new filesystem name. Then, use UNIX automount to manage /Service/zos. Map /Service/zos/ to OMVS..ROOT. Provided the cloning process goes according to Hoyle, this will ensure consistency of maintenance between the MVS and UNIX environments. This approach was developed by another regular contributor of this list to handle a large number of target environments, but can be used in any sized shop. It is proven and reliable. Regards, Art Gutowski General Motors, LLC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning a Sysres and ZFS
Hi James You do not need to use /Service to perform mainmtenance. You can mount your maintenance target HFS/ZFS files at ANY mountpoint, just so long as your DDDEF PATH statements match. You could even create mount points as /IPLVOL - same names as your IPL volume VOLSER. Hope that helps Regards Bruce - Hi John, You mention using ZONEEDIT to point the DDDEFs into Never-Never Land to stop production dataset being updated by accident. All our DDDEFs use the volume so the targets always points at the correct datasets but this doesn't work for our HFS or ZFS because they need to be mounted at /Service. We then ZONEEDIT the DDDEFs to point at /Service instead of /, this needs to be changed back to / when finished. This works but when I was starting out applying maintenance to Zos I did make a mistake and had not done the ZONEEDIT to change / to /Service and mount the HFS because it wasn't an issue for the other products I did SMPE for at the time. Is there a better way to deal with the HFS or ZFS DDDEFs? Thanks James -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning a Sysres and ZFS
On Mon, 18 Jan 2016 18:32:28 -0500, John Eells wrote: >the abilities to use SYMBOLICRELATE to point to a user catalog >... were there >from its inception many releases ago (well before z/OS V1.13). Thanks, John. I never noticed the ability to use SYMBOLICRELATE to point to a user catalog. I see now that it is documented that way. I don't see an example if the manual of doing that, and maybe that's why I missed it. I can see now that it could be quite useful to define an alias that relates an HLQ to, for example, CATALOG.&SYSNAME..USERCAT, could be very useful indeed. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning a Sysres and ZFS
I vote for Bruce's method also. This will allow multiple versions (a maintenance version of current and the next Version release) to be mounted at the same time. Allows two people or parallel work on both systems. I even went so far as to write a REXX routine which would create the mount point if it did not exist, read the BPXPRMxx member of parmlib for all the File Systems, and mount and/or create mount point/mount the files systems for the select SYSRES set. All the DDEFs for the SYSRES set used the same path prefix '/RESVOL1' . This is easy to zoneedit after a clone also. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning a Sysres and ZFS
It's common practice for us to have at least two service levels in play at the same time. One for the 'next big thing' and one for 'keep the lights on' in the current production release. Having distinct static service environments means that nothing gets in anyone else's way. Either can be cloned and migrated independently with minimal confusion. It helps greatly to have a naming convention for 'release level' that's zapped into the system (we use a spot in NUC) for querying wherever a clone migrates. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile jo.skip.robin...@att.net jo.skip.robin...@gmail.com > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Mike Smith > Sent: Tuesday, January 19, 2016 04:18 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: Cloning a Sysres and ZFS > > I vote for Bruce's method also. This will allow multiple versions (a > maintenance > version of current and the next Version release) to be mounted at the same > time. Allows two people or parallel work on both systems. > > I even went so far as to write a REXX routine which would create the mount > point if it did not exist, read the BPXPRMxx member of parmlib for all the > File > Systems, and mount and/or create mount point/mount the files systems for the > select SYSRES set. All the DDEFs for the SYSRES set used the same path prefix > '/RESVOL1' . This is easy to zoneedit after a clone also. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cloning a Sysres and ZFS
On Tue, 19 Jan 2016 08:33:55 -0600, Bruce Hewson wrote: >You do not need to use /Service to perform mainmtenance. > >You can mount your maintenance target HFS/ZFS files at ANY mountpoint, just so >long as your DDDEF PATH statements match. > >You could even create mount points as /IPLVOL - same names as your IPL volume >VOLSER. If you want to use Automount, as we do, /IPLVOL won't do. I don't think you can automount-manage /. Even if you could, would you really want to? You can call it anything, but I recommend mounting a service fs off a subdirectory if you want to automount manage it. Art Gutowski General Motors, LLC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
