Re: V7R1 PTF's - If you're doing them: READ THIS

On 2/24/11 8:07 PM, DrFranken wrote:

<<SNIP>>

"a suggestion to one customer to apply the PTF immediate as
circumvention, might not be generally appropriate response for all
at the same release. IMO more should be know about origin before
any recommendations should be made generally for consumption by
others..."

While some may misread this as some clown claiming to be an oddly
named doctor suggesting a PTF out of the blue for everyone on a
particular release because it fixed his problem, this is absolutely
not the case.

I do not view you as a clown, if even you are concerned with what I think.

This PTF is recommended by Rochester. This hang has
affected a number of shops already and will affect more, THEY
guarantee it. I suggested that if this is true, this PTF should be
widely publicized. Rochester responded: "YES We agree and are working
on ways to do that." I then suggested that publicizing this fix on
the widely popular Midrange-L. It was agreed this was a GOOD idea. I
did so to PREVENT problems.

I did not see a PSP entry, so any urgency seemed counter to what I would expect. While I respect the poster, the content was what made me question the recommendation. I had seen many poor recommendations from IBM support over the years. In fact I was often under threat of this or that for "publicly correcting" the advice of support personnel with safer and more intelligent recommendations.... as if presenting a united front in providing poor or wrong responses was more important than admitting to mistakes in advice and then correcting them. A recommendation to apply a specific PTF as DELAYED(*NO) for an APAR with text that seemed most likely to describe new function versus either a preventive or providing some corrective effect to any specific error, seemed suspect.

I am offended to find that the first response to a suggestion that
may help many people prevent their systems from locking during a PTF
apply is a counter recommendation that suggesting such a thing in the
first place is poor judgment or a generally bad idea.

Easily offended I guess ;-) I clearly placed "FWiW" both before and after the text about possible applicability to others, plus made clear that I could not access the PTF information, as well as having described that what else I had available to review was limited. My misinterpretation of the given recommendation was IMO reasonable, for a lack of specifics. The above text describing a specific conversation with IBM support goes a long way to clarify why the posting was made; had that been included in the original post, I probably would have not replied\commented. The OP could have been sent from support personnel sitting in Rochester, as originally written, and I would have wondered and commented similarly. Now that more details have been shared, I have a better feeling about the recommendation. :-)

P.S. After a hard shutdown of the partition and a manual IPL to
dedicated system there are no SCPF joblogs with messages beyond the
apply phase. There are no errors there. After the final messages there
the system IPLed to apply the PTFs. The system did indeed hang on C900
2967 and was applying PTF 54 of 177 at the time. Hard to tell if the CPU
was pegged but disks were doing absolutely nothing and according to IBM
would have continued at that pace 'forever'.

An incomplete IPL and the next successful IPL share the same SCPF job message queue, and thus the same QPJOBLOG which can only be spooled after the completion of an IPL [as a post-IPL phase of processing]. No messages logged is less typical in my recollection [supporting code in the IPL path] for a non-loop hang than for error message(s) preceding a hang\wait during PTF apply, but entirely possible.

Regards, Chuck

On 2/24/2011 9:33 PM, CRPence wrote:

On 2/24/11 1:31 PM, DrFranken wrote:

There is an isssssue with IBM i 7.1 current PTFs. The specific
problem has not be revealed however the symptom is that during
the IPL to apply them the system will stop at C900 2967,
'forever'.

SRCC9002967 is a PTF apply phase of the IPL. A "stop" at an IPL
phase could be with a "CPU pegged", "no CPU", or intermittent CPU
[possibly consistent on intervals]. Most typically the origin for
a full stop with no CPU would be for the SCPF job going into MSGW
status due to an improperly coded PTF-exit program; i.e. a program
which does not have a global monitor for CPF9999 [or CPF0000] to
prevent the the language-specific global handler from handling the
unmonitored exception.

In that and other scenarios, the spooled SCPF joblog from the last
[the successful] IPL after the failed IPL will contain the
error(s) which led to the IPL hang\wait [less likely for a loop]
condition. Thus if anyone has experienced the failure, likely the
origin is as clear as the joblog in which the failure transpired;
the problem will be "revealed". WRKSPLF SELECT(QSYS *N *N SCPF) /*
and possibly also WRKJOB jobnbr/QSYS/SCPF OPTION(*SPLF) for the
specific job number for the QPJOBLOG found by the WRKSPLF request
*/

Perhaps the relevant errors from such a SCPF joblog be made
available here [midrange.com].?

To avoid such a 'forever' stoppage you must download, load, and
apply IMMEDIATE, PTF SI42712.

If the preventive is known, and by that PTF SI42712 being applied
using DELAYED(*NO), then likely that PTF itself is at fault; i.e.
that PTF, when applied DELAYED(*YES), has a code path which fails
to complete an operation properly. Of course it could be that there
is nothing wrong specifically with the PTF or an exit program of
the PTF, but in the use of a feature which is not [yet] available
during the IPL; e.g. some SQL which is not [yet] supported at IPL
[either for hang conditions or extremely long waits], which at
least in the past had included definitional activity for
constraints, triggers, long names, and others. At one time, any SQL
was poorly supported at IPL because not even the implicit CONNECT
was allowed to complete, and then only to database *N, but after a
long delay [90-120 seconds?] for each.

The PTF can not be searched on the web presently nor can I access
a copy on the IBM i software support portal, and even if I could,
there is no information logged about what the PTF includes even
when the APAR and PTF are both visible on the support pages. The
DSPPTF details on a system with the PTF loaded or applied [not
permanently.?] will show what is included.

This PTF is NOT on a Cume or HIPER at this time.

FWiW... And probably if that PTF is the source of the problem,
then recommending anyone to do anything with that PTF is
potentially problematic. That if the PTF can be applied
successfully only *IMMEDiately, and the PTF is not on a [group,]
cumulative or HIPer, then probably almost nobody has ordered the
PTF. The PTF may have since been blocked from ordering [i.e. marked
defective], so calling attention to the PTF [if not already blocked
from ordering] would increase the likelihood that someone would
order and either be unable to obtain or might apply [possibly also
misreading the implication that only immediate-apply is OK] the PTF
delayed... and thus experience the problem being warned of. Or if
that PTF is merely impacted by some other defect or restriction,
such that marking that PTF defective is not entirely appropriate,
the PTF may remain available to be ordered pending investigation of
what is the true origin; thus a suggestion to one customer to apply
the PTF immediate as circumvention, might not be generally
appropriate response for all at the same release. IMO more should
be know about origin before any recommendations should be made
generally, for consumption by others. Again, FWiW.

<<SNIP>>