As others have pointed out, it makes RESTORE a lot harder if you never
ACCEPT PTFs.
Why? To RESTORE, SMP/E requires the needed levels of the parts to be in
the DLIBs.
Here is a simple example. Suppose you have Part A, and the DLIB level
of Part A is 001. You have installed six PTFs that replace Part A, so
now the target level of Part A is, in this example, 007. There's a
problem with the last PTF, and either the PE fix is not available or
perhaps you're not comfortable with its age. So, you want to take off
just the last PTF that replaced Part A. But, SMP/E does not have level
006 of part A in the DLIB, it has level 001. So, you must either back
off all six PTFs to back off the last one, and then put five of them
back, *or* ACCEPT the first five before backing off the sixth. In the
first case, SMP/E restores Part A back to level 001, and then updates it
to 006. In the second (after the ACCEPT for the first five PTFs), it
simply restores Part A to level 006.
Now, think about what happens with PTFs that PRE and IF other PTFs, and
those that ship overlapping multiples of some parts. This stuff can get
really complicated to untangle, fast. The RESTORE process tends to be
iterative, and can be quite time-consuming, if you never or rarely run
ACCEPT. So most thoughtful people, after seeing how this all works,
decide how far forward to ACCEPT, and when, and do it as a matter of
course to keep the plate of sticky spaghetti down to a manageable level
of complexity in case they have to RESTORE a PTF later on.
I hate stories that start with "when *I* did that," but I'll tell one
anyway. We used to ACCEPT all non-PE PTFs ahead of each preventive
service cycle, which seemed to keep it under control reasonably well
because we did it quarterly (which is now pretty much the current
recommendation, as it happens). If you do it less often, the amount of
applied but not accepted service will be greater, and the chains to be
resolved before RESTORE will be correspondingly more complex. You might
want to ACCEPT by PTF age (PUTnnnn) in that case, for example.
Other people have other strategies, but you should think about the
complexity of RESTORE preparation and the time it will take if you have
to RESTORE a PTF to resolve a severe problem. Also, not running ACCEPT
on some regular basis makes your SMPPTS data sets grow forever, though
this is a far smaller concern today than it was historically.
This is the current state of SMP/E RESTORE processing. The requirement
to "Please, *please* just let me take off this PTF and anything that
PREs or IFs it without having to figure this stuff all out" is, believe
me, *very* well understood. In other words, more RFEs won't hurt, but
neither will they help much.
Ed Jaffe wrote:
z/OS Sysprogs,
ISTR a maintenance philosophy from "eons" ago where PTFs would be
applied but never accepted.
What was the rationale for this? Does anyone still use this philosophy?
If so, why?
Thanks,
--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
