RE: Going in circles on applying PTF's

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