|
Those PTFs not applied with that most recent request can still be
scheduled for a delayed permanent apply for the upcoming IPL. And
FWiW if the upcoming PTFs have included any supersedes to those, they
will get perm applied anyhow, even without any actions. Just repeat
the APYPTF, but this time using DELAYED(*IMMDLY) or DELAYED(*YES).
Even without an additional APYPTF request, the lack of a few PTFs
not applied is unlikely to be an issue. The /recommendation/ to
perm-apply PTFs is not a statement that intends to suggest one is
automatically /screwed/ if that operation has not completed before the
upcoming PTF work. It merely means that, to both reduce time for that
activity on the upcoming PTF work and to minimize the possibility that
the limits will be exceeded for the load and application of PTFs, the
perm apply processing is probably a good idea. And AFaIK the limits
are effectively only for load and application of the LIC PTFs, due to
link loader size limitations; i.e. for other PTF processing, the
effective equivalent limit would be the overall storage of the system
ASP.?
As far as impact for performance on other work... Then like with
any other work done synchronous to a request issued in a job, either
route the job to establish the desired Work Management setup, or
change the job to have the desired WM attributes to perform the work
with minimal impact to other work on the system. For example, use
SBMJOB to request that the work be done at a defaulted batch priority,
or issue CHGJOB RUNPTY(55) to ensure the upcoming interactive request
is run as prioritized lower than work being done as default batch
activity.
Regards, Chuck
On 19 Apr 2013 08:45, Robert Clay wrote:
I went ahead with it as DELAY(*NO) before your post came through.
It took 33 minutes and resulted in these messages:
Delayed PTF 5761SS1-SI34991 not permanently applied.
<<SNIPped ...>>
Delayed PTF 5761SS1-SI47322 not permanently applied.
PTF SI42485 not applied permanently.PTF SI38286 required.
<<SNIPped ...>>
PTF SI47296 not applied permanently.PTF SI47322 required.
Delayed PTF 5761SS1-SI34991 not permanently applied.
<<SNIPped ...>>
Delayed PTF 5761SS1-SI47322 not permanently applied.
Am I screwed for installing the Cumulative/Group PTFs this weekend
since I only get the one IPL window?
On 04/19/2013 11:25 AM, Pete Massiello - ML wrote:
No, you should either use DELAY(*YES) or my preference is
DELAY(*IMMDLY). I don't use DELAY(*NO) because then some PTFs might
not be able to be put on right now. With *IMMDLY, you get the best
of both worlds. Those than can be done now are applied perm, and
then those that can't are done at IPL, but you have redcued your IPL
window by getting the ones you can on now.
Robert Clay on Friday, April 19, 2013 10:35 AM wrote:
So, will command
APYPTF LICPGM(*ALL) APY(*PERM) DELAYED(*NO)
be sufficient? Will it impact performance (this is our main
production LPAR). Any idea how long it will take?
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
