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

Chuck,

While I generally understand your need to pontificate your knowledge of the system, Larry is one of the most skilled IBM i hardware and system administrators in the world, outside of IBM. We can find plenty of references both inside and outside of IBM to back that up. For you to immediately question his report, given the knowledge, advise, help, etc that Larry has given not only to this list but nearly anyone that asks for it is insulting to anyone that knows Larry.

Your analysis may be accurate, but in the long run not relevant because none of it matters. What does matter is the landmine that could be stepped on if this PTF is not applied. Larry reported it to this group within hours of learning the problem, then testing the solution. Had there been more relevant information to convey, he would have.

While Larry's sarcastic style may not be yours, the bottom line is it was reported completely, accurately, and more importantly immediately. Your comments did not add to the problem solution, only cast your own doubts as to the validity of Larry's report and reputation furthermore impeaching IBM Rochester's solution.

A bit of introspection is called for in this case, and in my view an apology.

Jim Oberholtzer
CEO/Chief Technical Architect
Agile Technology Architects, LLC


On 2/24/2011 8: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