I support a single global and multiple maintenance targets / dlib zones for several companies. I have my zone options set to NOPURGE so I never purge during accept. After ACCEPT is done for all the environments, I simply run an SMP/E REJECT in purge mode:
SET BOUNDARY (GLOBAL). REJECT PURGE (AAAD101,BBBD101,CCCD101). -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:[email protected] Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ On Wed, 25 Feb 2015 20:53:22 +0000, Pommier, Rex <[email protected]> wrote: >Yup, that's how I do my pre-accept backup. > >Rex > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[email protected]] On >Behalf Of CM Poncelet >Sent: Wednesday, February 25, 2015 2:33 PM >To: [email protected] >Subject: Re: setting up a new, improved SMP/E environment > >FWIW Run an ADRDSSU backup of your whole SMP/E environment to a GDG on >CART (or to wherever else), run whatever APPLY/ACCEPTs (or vice versa in >IMS) and check that. If all OK then NAPWAD. Else restore your earlier >SMP/E environment from ADRDSSU backup on GDG and try again (or try >something else). But always ADRDSSU backup your SMP/E environment >beforehand. CP > >Pommier, Rex wrote: > >>Gil, >> >>In the scenario you mention below, there would be 3 different DLIB zones, so >>the PROD DLIB wouldn't be at a higher level than the PROD TARGET zone. If it >>were me I wouldn't bother with having 3 DLIB zones, I would have a single >>DLIB and not do any ACCEPTs until after the maintenance was applied across >>all the target zones. >> >>Like you, I don't especially care for not being able to back a PTF out once >>it has been accepted, but I guess that's part of the downside of trying to >>remain backwards compatible until the invention of the wheel. :-) Hence my >>backing up of the entire environment before doing an accept. >> >>Rex >> >> >> >>-----Original Message----- >>From: IBM Mainframe Discussion List [mailto:[email protected]] On >>Behalf Of Paul Gilmartin >>Sent: Wednesday, February 25, 2015 11:19 AM >>To: [email protected] >>Subject: Re: setting up a new, improved SMP/E environment >> >>On 2015-02-25, at 09:06, Staller, Allan wrote: >> >> >> >>>There are operands on the accept command that should allow the many-to-one >>>relationship between target and dlib zones. IIRC, the command is accept >>>nopurge (haven't looked it up recently). >>>The accept would be run 3 times. Twice w/nopurge and once with no operand to >>>clear the global zone. >>> >>> >>> >>So the sequence is: >> >> APPLY MAINT >> >> ACCEPT NOPURGE >> >> APPLY DEV >> >> ACCEPT NOPURGE >> >> APPLY PROD >> >> ACCEPT PURGE >> >>Are there no adverse consequences of having the DLIB zone at a higher service >>level than the PROD target, a transient state between steps? >> >>Given the large capacity and low price of modern DASD (and that SMP/E now >>supports multiple SMPPTS (am I correct?), circumventing the archaic limits >>on PDE(E) size), how valuable is PURGE? I could envision a problem's >>appearing only after ACCEPT; RESTORE is not possible (bad design, IMO). >>If the GLOBAL were entire, one could define a new target/DLIB pair and >>iteratively bisect the service stream to find the troublesome PTF. Or, >>install ab ovo and APPLY selectively -- I can do that hourly during >>development >>testing (but it's a small product). >> >>VMSES/E makes this easier by having no analogue of a DLIB zone. A programmer >>can peel off onion layers iteratively to get to any desired earlier level. >> >>-- gil >> >>---------------------------------------------------------------------- >>For IBM-MAIN subscribe / signoff / archive access instructions, >>send email to [email protected] with the message: INFO IBM-MAIN >> >>The information contained in this message is confidential, protected from >>disclosure and may be legally privileged. If the reader of this message is >>not the intended recipient or an employee or agent responsible for delivering >>this message to the intended recipient, you are hereby notified that any >>disclosure, distribution, copying, or any action taken or action omitted in >>reliance on it, is strictly prohibited and may be unlawful. If you have >>received this communication in error, please notify us immediately by >>replying to this message and destroy the material in its entirety, whether in >>electronic or hard copy format. Thank you. >> >>---------------------------------------------------------------------- >>For IBM-MAIN subscribe / signoff / archive access instructions, >>send email to [email protected] with the message: INFO IBM-MAIN >> >> >> >> > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN > >The information contained in this message is confidential, protected from >disclosure and may be legally privileged. If the reader of this message is >not the intended recipient or an employee or agent responsible for delivering >this message to the intended recipient, you are hereby notified that any >disclosure, distribution, copying, or any action taken or action omitted in >reliance on it, is strictly prohibited and may be unlawful. If you have >received this communication in error, please notify us immediately by replying >to this message and destroy the material in its entirety, whether in >electronic or hard copy format. Thank you. > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
