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
