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
