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
