Re: separate SMPe environments
I prefer a shared global zone, but that's problematical if you have to rework sysmods. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Giannelli [billgianne...@gmail.com] Sent: Monday, March 27, 2023 5:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: separate SMPe environments Another stupid SMPe question. Currently, we have one CSI with one target and one dlib. (I inherited this). I want to setup at least another target and dlib zones for a "before" maintenance level. Might you ever consider creating a whole new csi for that or just as normal have different zones under 1 csi? thanks Bill -- 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: separate SMPe environments
On Mon, 27 Mar 2023 16:43:46 -0500, Bill Giannelli wrote: >Another stupid SMPe question. >Currently, we have one CSI with one target and one dlib. (I inherited this). I >want to setup at least another target and dlib zones for a "before" >maintenance level. >Might you ever consider creating a whole new csi for that or just as normal >have different zones under 1 csi? >thanks >Bill > I have always kept separate target zones that match each sysres set. So I clone the zone and sysres at the same time. The SMP/E zones and maintenance sysres set are shared, but each sysplex has it's own run time sysres sets that get used for cloning. So I can tell you at any point of time what maintenance level or specific PTFs are IPLed into any number of systems in a large environment with different sysplexes and while I can't remember having to do it "forever", you can also apply an emergency fix to a zone that matches a running sysres set in an emergency.For one client I have 2 separate maintenance target zones that support different usermods for different companies, but still a single global zone. So I do have apply maintenance twice and accept it twice, but I only have to receive it once. Still, each cloned sysres set gets a cloned target zone with it. At one time I also cloned the DLIB zones when I was in a smaller environment but there really is no need to do that and I haven't done that for years. Typically I don't accept maintenance until it has been running in production for 9-12 months and it would just be a lot of extra DASD allocated for that purpose that I don't need. ACCEPT doesn't apply to the running systems, so I don't see any advantage nor reason to have a bunch of cloned DLIB zones and DLIB volumes matching all those zones. One DLIB zone per maintenance target zone is enough. Best Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
We run with multiple maintenance levels, and clone to active environments as required. 1. multiple GLOBAL zones - one per product subsystem, some for specific vendors, and others as required. 2. each global zone has multiple target/dlib sets. 3. multiple maintenance target/dlib sets, with a unique HLQ, not SYS%, so that enqueues are never a problem. 4. multiple IPL volume target sets, with one DLIB set per base product level. 5. dynamically generated jobstreams to clone from a maintenance/IPL set to an IPL set, either local or remote. 6. dynamically generated joibstreams to handle changes required when doing upgrade or backout of a new iPL set. currently using 6xMod27 target and 6xMod27 DLIB volumes per set. Have z/OS 2.3 and z/OS 2.4 configurations active running with 6xMod54 volumes for SMPE Global zone support datasets including SMPPTS. Target/DLIB SMPE datasets reside on matching target/dlib volume, names matching VOLSER for unqueueness. All local system changes are coded in USERMODs tied to maintenance environment cycle. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
I honestly had never considered doing it this way (build one environment and then clone the updated copies), I always cloned and then updated that clone, but it makes sense that this would work just as well. It might even be more effective, although I my way has the advantage of being able to fall back both SMP/e and clone wise, whereas I think having just one service area would mean no SMP/e fallback (without a lot of work). I'll have to give this a try one time and see how it goes. Brian On Fri, 12 Jun 2020 08:53:32 -0400, Kurt Quackenbush wrote: >On 6/11/2020 11:38 AM, Bill Giannelli wrote: >> I want to setup separate SMPe environments, say 3 for different maintenance >> levels. One matching production then 2 others for maintenance levels "coming >> next". My question is, when I what to update my PROD environment with one of >> the other maintenance levels, do I need to go thru receive, apply, accept >> that I would have done in the "prior" SMPe environment? Or is there a >> quicker way to "synch" up the 2 environments? > >As many have already suggested, you should consider updating one SMP/E >environment with RECEIVE and APPLY, then clone this environment to >create or replace others. There are many existing variations on the >mechanics of this clone process. > >If you do not already have an SMP/E environment cloning process that you >like in place, you should take a look at z/OSMF Software Management. It >provides a Deploy operation that will clone your SMP/E environment, >taking care of renaming data sets, zones, updating DDDEF entries, etc. > >Kurt Quackenbush -- IBM, SMP/E Development >Chuck Norris never uses CHECK when he applies PTFs. > >-- >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: Separate SMPe environments for maintenance levels
On 6/11/2020 11:38 AM, Bill Giannelli wrote: I want to setup separate SMPe environments, say 3 for different maintenance levels. One matching production then 2 others for maintenance levels "coming next". My question is, when I what to update my PROD environment with one of the other maintenance levels, do I need to go thru receive, apply, accept that I would have done in the "prior" SMPe environment? Or is there a quicker way to "synch" up the 2 environments? As many have already suggested, you should consider updating one SMP/E environment with RECEIVE and APPLY, then clone this environment to create or replace others. There are many existing variations on the mechanics of this clone process. If you do not already have an SMP/E environment cloning process that you like in place, you should take a look at z/OSMF Software Management. It provides a Deploy operation that will clone your SMP/E environment, taking care of renaming data sets, zones, updating DDDEF entries, etc. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
I always use a single shared GLOBAL zone and multiple targets. It's much simpler to keep track of and the only problem I have ever run into is a site the IBM ran an audit on and they wanted to know why they had 8 LPARs but 24 target|dlib zones. Apparently IBM doesn't do it that way. Aside from that little episode it has worked out quite well, and it allows me a great deal of flexibility if I ever had to fall back to something. If you are short on DASD or TAPE, you probably wouldn't want to keep them all around. I try to keep 3 copies of everything if I can though. I also have all datasets cataloged to ** for the res and symbolics for the dlib volume(s) and secondary res (which I need for some sites), and take care to make sure I keep the IEASYMxx under control. I maintain a large number of sites in that way and I have no problems with them at all. I have a series of CLONE jobs that I run for each upgrade tath copy the packs, duplicate and update the DDDEFs, etc. but I think most people do that as well. The SMPe volume(s) which are normally SMS controlled (but not always) tend to get large, but controllable. As someone else mentioned, the naming conventions for the OMVS datasets is very important, and you need to have a way to identify them quickly and easily. They should have both the system identifier and the lpar identifier (unless they are shared) in the dataset name. You have 44 characters, and there is no reason to get stingy with using them. It is very important that you establish a method of operation and stick with it, and document, document, document (then document some more). Brian On Thu, 11 Jun 2020 15:57:41 +, Seymour J Metz wrote: >I would go for a shared GLOBAL and 3 TARGET/DLIB pairs. I would use REPORT >SYSMOD to help keep them in synch. Of course, often there are installation >standards in place as to maintenance methodology, and you can't change things >without getting the appropriate approval. > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >Bill Giannelli [billgianne...@gmail.com] >Sent: Thursday, June 11, 2020 11:38 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Separate SMPe environments for maintenance levels > >I want to setup separate SMPe environments, say 3 for different maintenance >levels. One matching production then 2 others for maintenance levels "coming >next". My question is, when I what to update my PROD environment with one of >the other maintenance levels, do I need to go thru receive, apply, accept that >I would have done in the "prior" SMPe environment? Or is there a quicker way >to "synch" up the 2 environments? >thanks >Bill > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
I see bookkeeping issue to ensure that you IPL each LPAR from the correct volume and to ensure that you install serive in the correct zone, but what is the synchronization issue with rotating among a set of TARGET/DLIB zones and associated volumes? Oh, there is a detail that I left out; the HFS and zFS naming convention should be tied to the symbols set from the IPL volser. Cloning the target volumes without cloning the target zone means that you can't install service on it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Allan Staller [allan.stal...@hcl.com] Sent: Thursday, June 11, 2020 2:26 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Separate SMPe environments for maintenance levels You still end up with a major syncing problem using either Shmuel's or my previous suggestion. I personally have 1 set of target zones and a "canned" job to build an new sysres from scratch using the SMP/E targets as the source. I am happy to share the JCL if you would like. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Thursday, June 11, 2020 11:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Separate SMPe environments for maintenance levels [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] So I've been reviewing the options you all have so kindly shares zonecopy, zonemerge, zoneexportand it seems obvious you need to be careful of the DDDEFs and renaming of datasets. If not careful you can really screw up and overlay one environment. While simplistic and perhaps slightly more work.I am wondering if one "safe" way is to simply re-receive and re-apply the maintenance on the next environment when needed? thanks Bill -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
Whether or not your methodology involves copying libraries or zones, you have to be careful of everything. Every strategy has risks that you need to address. There is no need to re-receive anything. You should, however, frequently receive the HOLDATA. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Giannelli [billgianne...@gmail.com] Sent: Thursday, June 11, 2020 12:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Separate SMPe environments for maintenance levels So I've been reviewing the options you all have so kindly shares zonecopy, zonemerge, zoneexportand it seems obvious you need to be careful of the DDDEFs and renaming of datasets. If not careful you can really screw up and overlay one environment. While simplistic and perhaps slightly more work.I am wondering if one "safe" way is to simply re-receive and re-apply the maintenance on the next environment when needed? thanks Bill -- 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: Separate SMPe environments for maintenance levels
There are several strategies. I'd advice you to use a symbol to select the default DB2. The key, however, is that whatever approach you use you think through and document all the issues. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Giannelli [billgianne...@gmail.com] Sent: Thursday, June 11, 2020 3:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Separate SMPe environments for maintenance levels So this is for DB2 software. Distribution libraries are *.AD* Target libraries are *.SD*. So I would create a second target zone a define datasets and DDDEFs for say "*.target2.SD*" ? -- 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: Separate SMPe environments for maintenance levels
So this is for DB2 software. Distribution libraries are *.AD* Target libraries are *.SD*. So I would create a second target zone a define datasets and DDDEFs for say "*.target2.SD*" ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
You still end up with a major syncing problem using either Shmuel's or my previous suggestion. I personally have 1 set of target zones and a "canned" job to build an new sysres from scratch using the SMP/E targets as the source. I am happy to share the JCL if you would like. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Thursday, June 11, 2020 11:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Separate SMPe environments for maintenance levels [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] So I've been reviewing the options you all have so kindly shares zonecopy, zonemerge, zoneexportand it seems obvious you need to be careful of the DDDEFs and renaming of datasets. If not careful you can really screw up and overlay one environment. While simplistic and perhaps slightly more work.I am wondering if one "safe" way is to simply re-receive and re-apply the maintenance on the next environment when needed? thanks Bill -- 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: Separate SMPe environments for maintenance levels
Not sure I remember the details. I worked with one ex-sysprog that cloned the SMP/E target environment to the sysres for documentation purposes (1980's.) ZoneCopy should do a lot of what you seem to be looking for. I (personally do not think that is the way to go. My suggestion is One global zone A set of target zones One Dlib zone. The apply/accept processing would need to be repeated for each target zone. Accept processing for all except the last target zone will need the NOPURGE (?) operand. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Bill Giannelli Sent: Thursday, June 11, 2020 10:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Separate SMPe environments for maintenance levels [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] I want to setup separate SMPe environments, say 3 for different maintenance levels. One matching production then 2 others for maintenance levels "coming next". My question is, when I what to update my PROD environment with one of the other maintenance levels, do I need to go thru receive, apply, accept that I would have done in the "prior" SMPe environment? Or is there a quicker way to "synch" up the 2 environments? thanks Bill -- 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: Separate SMPe environments for maintenance levels
On Thu, 11 Jun 2020 11:40:47 -0500, Bill Giannelli wrote: >So I've been reviewing the options you all have so kindly shares zonecopy, >zonemerge, zoneexportand it seems obvious you need to be careful of the >DDDEFs and renaming of datasets. If not careful you can really screw up and >overlay one environment. >While simplistic and perhaps slightly more work.I am wondering if one >"safe" way is to simply re-receive and re-apply the maintenance on the next >environment when needed? That does not make it any safer. Each target and distribution zone will still have to have the correct DDDEFs. JCL symbols can be your friend in setting up the jobs to do all of this. Test your process carefully. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
If you stay current on HOLDDATA, which you should, then conditions will have changed between the two sequences. You are not actually recreating your tested maintenance environment into your production. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Bill Giannelli > Sent: Thursday, June 11, 2020 9:41 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Separate SMPe environments for maintenance levels > > So I've been reviewing the options you all have so kindly shares zonecopy, > zonemerge, zoneexportand it seems obvious you need to be careful of > the DDDEFs and renaming of datasets. If not careful you can really screw up > and overlay one environment. > While simplistic and perhaps slightly more work.I am wondering if one > "safe" way is to simply re-receive and re-apply the maintenance on the next > environment when needed? > thanks > Bill > > -- > 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: Separate SMPe environments for maintenance levels
So I've been reviewing the options you all have so kindly shares zonecopy, zonemerge, zoneexportand it seems obvious you need to be careful of the DDDEFs and renaming of datasets. If not careful you can really screw up and overlay one environment. While simplistic and perhaps slightly more work.I am wondering if one "safe" way is to simply re-receive and re-apply the maintenance on the next environment when needed? thanks Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
I prefer to have a rotating list of TARGET/DLIB pairs, with symbols keyed to
the IPL volser. When I want to promote a configuration from, e.g., TEST to QA,
I just IPL.
Note that whatever methodology you you, there will be some bookkeeping
associated with it, and cutting corners can be fatal.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of
Jousma, David [01a0403c5dc1-dmarc-requ...@listserv.ua.edu]
Sent: Thursday, June 11, 2020 12:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Separate SMPe environments for maintenance levels
I do a similar process. One global zone for a z/os ver.rel, a "maintenance
zone", and then a target zone that matches every active SYSRES in my
environment. One DLIB zone.Maintenance is only actively applied to the
maintenance zone, and when ready to promote that level into use, I have a set
of standard cloning jobs that copies the actual sysres to the new SYSRES with
appropriate renameu (sysres volser is a part of ZFS container names), copy the
SMPE support datasets with renames, and SMPE ZONECOPY from the maintenance zone
to a new target zone named to match the sysres describes, and then appropriate
zone edits to change dddef volser's/pathnames to match the sysres.
This way, you are only every applying maintenance once, you have a target zone
that matches the running sysres in the event a fix needs to be applied, etc.
Accept processing only occurs AFTER the last system in my complex is running
that level of maintenance.
SET BDY () .
ZCOPY () INTO() .
SET BDY() .
ZEDIT DDDEF .
CHANGE VOLUME(,
) .
CHANGE PATH('/'*,
'/'*).
CHANGE DA(SMPE.,
SMPE.).
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
ENDZONEEDIT .
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
From: "Bill Giannelli"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, June 11, 2020 10:38:23 AM
Subject: Separate SMPe environments for maintenance levels
I want to setup separate SMPe environments, say 3 for different maintenance
levels. One matching production then 2 others for maintenance levels "coming
next". My question is, when I what to update my PROD environment with one of
the other maintenance levels, do I need to go thru receive, apply, accept that
I would have done in the "prior" SMPe environment? Or is there a quicker way to
"synch" up the 2 environments?
thanks
Bill
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
I do a similar process. One global zone for a z/os ver.rel, a "maintenance
zone", and then a target zone that matches every active SYSRES in my
environment. One DLIB zone.Maintenance is only actively applied to the
maintenance zone, and when ready to promote that level into use, I have a set
of standard cloning jobs that copies the actual sysres to the new SYSRES with
appropriate renameu (sysres volser is a part of ZFS container names), copy the
SMPE support datasets with renames, and SMPE ZONECOPY from the maintenance zone
to a new target zone named to match the sysres describes, and then appropriate
zone edits to change dddef volser's/pathnames to match the sysres.
This way, you are only every applying maintenance once, you have a target zone
that matches the running sysres in the event a fix needs to be applied, etc.
Accept processing only occurs AFTER the last system in my complex is running
that level of maintenance.
SET BDY () .
ZCOPY () INTO() .
SET BDY() .
ZEDIT DDDEF .
CHANGE VOLUME(,
) .
CHANGE PATH('/'*,
'/'*).
CHANGE DA(SMPE.,
SMPE.).
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
CHANGE DA(SMPE.,
SMPE.) .
ENDZONEEDIT .
_
Dave Jousma
AVP | Manager, Systems Engineering
Fifth Third Bank | 1830 East Paris Ave, SE | MD RSCB2H | Grand Rapids, MI
49546
616.653.8429 | fax: 616.653.2717
From: "Bill Giannelli"
To: IBM-MAIN@LISTSERV.UA.EDU
Sent: Thursday, June 11, 2020 10:38:23 AM
Subject: Separate SMPe environments for maintenance levels
I want to setup separate SMPe environments, say 3 for different maintenance
levels. One matching production then 2 others for maintenance levels "coming
next". My question is, when I what to update my PROD environment with one of
the other maintenance levels, do I need to go thru receive, apply, accept that
I would have done in the "prior" SMPe environment? Or is there a quicker way to
"synch" up the 2 environments?
thanks
Bill
This e-mail transmission contains information that is confidential and may be
privileged. It is intended only for the addressee(s) named above. If you
receive this e-mail in error, please do not read, copy or disseminate it in any
manner. If you are not the intended recipient, any disclosure, copying,
distribution or use of the contents of this information is prohibited. Please
reply to the message immediately by informing the sender that the message was
misdirected. After replying, please erase it from your computer system. Your
assistance in correcting this error is appreciated.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Separate SMPe environments for maintenance levels
I would go for a shared GLOBAL and 3 TARGET/DLIB pairs. I would use REPORT SYSMOD to help keep them in synch. Of course, often there are installation standards in place as to maintenance methodology, and you can't change things without getting the appropriate approval. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bill Giannelli [billgianne...@gmail.com] Sent: Thursday, June 11, 2020 11:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Separate SMPe environments for maintenance levels I want to setup separate SMPe environments, say 3 for different maintenance levels. One matching production then 2 others for maintenance levels "coming next". My question is, when I what to update my PROD environment with one of the other maintenance levels, do I need to go thru receive, apply, accept that I would have done in the "prior" SMPe environment? Or is there a quicker way to "synch" up the 2 environments? thanks Bill -- 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: Separate SMPe environments for maintenance levels
I've done something similar but with one global zone and 2 target zones, one for the current maint and one for the next maint - one DLIB zone, so one global, one receive, apply to tzone1 migrate, then receive more maint, accept, then apply to tzone2, something like that. if you want a totally separate SMP/E environment then you can possibly do a megezone or export import I know there are several folks that do what you are wanting to do currently. Carmen Vitullo - Original Message - From: "Bill Giannelli" To: IBM-MAIN@LISTSERV.UA.EDU Sent: Thursday, June 11, 2020 10:38:23 AM Subject: Separate SMPe environments for maintenance levels I want to setup separate SMPe environments, say 3 for different maintenance levels. One matching production then 2 others for maintenance levels "coming next". My question is, when I what to update my PROD environment with one of the other maintenance levels, do I need to go thru receive, apply, accept that I would have done in the "prior" SMPe environment? Or is there a quicker way to "synch" up the 2 environments? thanks Bill -- 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: Separate SMPe environments for maintenance levels
SMP/e ZONECOPY, UCLIN (to fix the DDDEFs), DFSMSDss to COPY and RENAME the Datasets On 2020-06-11 11:38, Bill Giannelli wrote: I want to setup separate SMPe environments, say 3 for different maintenance levels. One matching production then 2 others for maintenance levels "coming next". My question is, when I what to update my PROD environment with one of the other maintenance levels, do I need to go thru receive, apply, accept that I would have done in the "prior" SMPe environment? Or is there a quicker way to "synch" up the 2 environments? thanks Bill -- 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
