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

[Robert Clay <zreclay@xxxxxxxxx>]

Thanks, Chuck

If I understand correctly, I could

APYPTF LICPGM(*ALL) APY(*PERM) DELAYED(*IMMDLY) IPLAPY(*YES *APYPERM)

Then, I could proceed with installing the Cumulative/Group PTFs *IMMDLY 
with no immediate IPL.

After Sunday's scheduled backup/IPL, then they should all apply properly?


"Contrariwise, if it was so, it might be; and if it were so, it would 
be; but as it isn't, it ain't. That's logic."--Tweedledee

On 04/19/2013 12:57 PM, CRPence wrote:
>   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?