Re: Going in circles on applying PTF's

[CRPence <crp@xxxxxxxxxxxxxxxxxxxx>]

  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