Re: Applying PTFs *PERM prior to new Cumulative/Groups

[CRPence <CRPbottle@xxxxxxxxx>]

  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?