|
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
