On 10-Feb-2015 14:51 -0600, Steinmetz, Paul wrote:
I'd like to IPL to apply all pending (100 - 200) PTFs, excluding:
SI55602 Save file only None
SI55522 Superseded None
1) Would it be better to delete and reorder after the IPL?
The absolute safest would be to ensure the PTF does not exist on the
system; that Display PTF (DSPPTF) on both of the above PTF identifiers
gives a "not found" error. I have experienced being in charge of
loading and applying some PTFs, and just before my starting the
end-system\power-down to effect the IPL, someone had used a utility to
/push/ a PTF to the system; because the utility was lazily coded to
apply generically, instead of applying only the PTF that had been sent,
the PTFs that had previously been omitted by my request were suddenly
included and applied during the IPL :-(
Obviously if the PTF load\apply work is completed on the console
after the system is in restricted state and the activity is restricted
to just the one person managing the PTFs, or if the verification of what
the IPL should effect with regard to those PTF is done after the system
is in restricted state immediately before the PWRDWNSYS request
[implying the system remained in restricted state in control of the one
system-operator until being powered down], then the /safety/ has been
ensured without the need to purge the PTF from the system [to prevent
any unwanted\accidental load or apply].
Even after my negative experience, I was not overly paranoid such
that I would be so careful as to /batten down the hatches/ to ensure
that particular PTFs were not\never-again accidentally installed; even
with mistakes or accidents, given the issue were not an accidental
perm-applied PTF, the recovery would never require more than an extra
IPL to effect the Remove PTF (RMVPTF) after reviewing the history of PTF
activity. As such, I would still be satisfied with just choosing the
other option:
OR
2) Should I somehow omit these from being loaded/applied?
The Apply PTF (APYPTF) request should have no effect re the status of
those PTFs, according to their current status. Easy enough to review
the status of those PTFs, again, after a generic Apply SELECT(*ALL)
request. And if the Apply request explicitly names only those "pending"
PTFs by name using that PTF Numbers To Select (SELECT) parameter, then
conspicuously, such a post-apply review would seem unnecessary. Yet the
APYPTF command also offers the PTF Numbers To Omit (OMIT) parameter, on
which both could be explicitly specified to further ensure the
apply-action would not get modified:
OMIT(SI55602 SI55522)
A post-apply and pre-pwrdwn review of the status of those PTFs is
still an option, if any nagging doubts persist, about the effects of the
prior Apply activity.
If however the "pending" PTFs are first to be generically loaded from
*SERVICE and the PTF SI55602 is there [IIRC the visibility of the PTF
implies that the PTF is _in_ *SERVICE], then the action of the second
option [2)] should be pursued; minimally, explicitly verify the
apply-directive of the PTF, and if necessary change\reset the
apply-directive to ensure that PTF will *not* be applied during the IPL.
If only the specific list of "pending" PTFs that should be applied are
to be chosen selectively instead of generically, then simply omitting
those PTF identifiers from the SELECT() parameter should be sufficient.
Again, there is no harm in reviewing the status of the PTFs again,
immediately before the pwrdwn for the IPL, to ensure the apply actions
just established [nor any actions taken by anybody else] have changed.
midrange.com
