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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
