Re: Going in circles on applying PTF's

[Pete Helgren <Pete@xxxxxxxxxx>]

Thanks Scott,

I ran through Rob's suggestions and found nothing out of the ordinary.  
Last IPL was normal, set to a B side IPL (to answer Kirk's question).  I 
have tried both a manual and unattended IPL.  I have the same group of 
about a half dozen PTF's that are referenced, both ones that haven't 
applied and the list of "required" PTF's.  What I need to do at this 
point is work that list, identify what is required for reach one and 
figure out what is "missing" or out of whack for each one,  I am sure 
there is probably just one that is causing the jam.  I just have to 
figure each one's requirements and make sure they are met.

Eventually, I'll figure it out.  The system is fine and operational, I 
just would like to make sure all is well before the next round of PTF's.

Pete


Ingvaldson, Scott wrote:
> It is most definitely not a chicken or egg thing.  In general these
> circumstances occur due to some combination of hit or miss application
> of PTFs, PTFs loaded but not applied, application of PTFs individually
> or by individual LPP, abnormal IPLs, etc.
>
> Follow Rob's advice first: ensure that you have a "normal" IPL.  Then
> load the full cume (in this case C7282540) using GO PTF option 8, Prompt
> for media - 3=Multiple volume sets and *SERVICE
>
> This will (hopefully) ensure that all of your PTFs are at a consistent
> code level, including any downloaded PTFs.  With any luck they will
> apply on the next IPL.
>
> If that doesn't work follow Chuck's advice.  Most likely culprits are
> probably superceding PTFs that may have gotten manually loaded before a
> pre or co-req PTF (for a different PTF) was applied.  The indication of
> this would be: If MF41996 cannot be applied until MF37752 and MF38777
> are applied, check the status of MF37752 and MF38777.  If either of
> those are in Superceded status you'll need to check the status of the
> PTF that supercedes those.  According to the cover letters, MF37752 and
> MF38777 are co-reqs of MF41996, but MF41996 is not required for either
> MF37752 or MF38777.
>
> Regards,
>
> Scott Ingvaldson
> Senior IBM Support Specialist
> Fiserv Midwest
>
>
> -----Original Message-----
> From: Pete Helgren [mailto:Pete@xxxxxxxxxx] 
> Sent: Friday, December 14, 2007 10:38 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: Going in circles on applying PTF's
>
> I been working this kind of logic.  I assume that the first instance of
> a "not applied" would be the logical bottleneck since theoretically the
> apply chain has to start somewhere and I would assume the apply process
> is smart enough to know which one has to be applied in order for others
> to follow.  In this case I have one PTF that appears to fail on apply
> first, yet seems to have dependencies on PTF's that are dependent on it.
> So it appears to be a chicken or egg thing.
>
> Rob posted some detailed instructions that I am going to wade through.  
> I'll see if I can get the logjam to move.
>
> Pete
>
>
> CRPence wrote:
>   
> >    Some thoughts; no time to test...
> >
> >    Given PTF sequence [aka chain] of supersedes A->B->C, I believe
> >     
> that...
>   
> >    If a PTF D requires that PTF B is perm applied, then if the PTF 
> > status of B is /superseded/, then [code changes active only since] PTF
> >     
>
>   
> > B is not yet permanently applied.  Thus for PTF D to apply, the PTF C 
> > must be permanently applied, in order to satisfy the requirement that 
> > B is perm applied.  So if PTF B is part of a cumulative with PTF D, 
> > but PTF C was loaded and applied as part of some other PTF activity 
> > prior to a delayed IPL for APYPTF LICPGM(PRODUCT) SELECT(*ALL) 
> > DELAYED(*YES) IPLAPY(*YES *APYPERM), then that /superseded/ case can
> >     
> transpire.
>   
> >    How I go about investigating apply issues...
> >
> >    Go LICPGM option 50, specifying a time since starting to apply PTFs
> >     
>
>   
> > should enable review for any errors that may have been overlooked in 
> > the apply.  Going back to post-apply of last successful cumulative and
> >     
>
>   
> > review for activity naming a PTF named in a pre-requisite might 
> > identify activity that gave origin to the conundrum.
> >
> >    Review the spooled SCPF joblog from the IPL that did the PTF apply 
> > activity, scanning from the beginning looking for Escape messages for 
> > PTF activity [range CPF35xx and CPF36xx ?; search 'Escape' in 
> > USEnglish joblogs], and then according to 'see prior messages' on any 
> > PTF error condition, refer back or up to prior messages to see what 
> > the diagnostic condition that was logged, which effected the exception
> >     
>
>   
> > condition being logged.  The first failure in a product [used to] 
> > terminates all further PTF activity for the rest of the product[; now
> >     
> more persevering, IIRC].
>   
> >   To get the spooled SCPF joblog, I use:
> >     WRKSPLF SELECT(QSYS *N *N SCPF) JOB(*ALL)
> >
> > Regards, Chuck
> >   
> >     
>
>
>