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

"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 was NOT on the system and is not on the Cume/Hiper etc. Had it been on either of those it wouldn't likely have helped because it must be applied immediate prior to the cume/hiper etc in order to correct the hang. PTF SI42712 is *NOT* the problem it is *preventative* to the problem.

"The PTF can not be searched on the web presently nor can I access a
copy on the IBM i software support portal,"

I had no problem ordering the PTF or displaying the cover letter. The PTF is not in test mode nor marked defective. The APAR (SE46894) is also visible though it says only "Changes made for internal product maintenance."

"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. 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 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.

- Larry "DrFranken" Bolhuis


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'.


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.

The APAR Error report is innocent enough:

-----------------------------------------------
Changes made for internal product maintenance.

CORRECTION FOR APAR SE46894 :
-----------------------------
Changes complete.

Possibly a PTF for the infamous "new function" [cleverly disguised as
"maintenance"] or some underlying\pre-requisite support for a "new
function", which is being [incorrectly\improperly] delivered via PTF
instead of as part of the release. Oddly enough... Per component
5770SS1WM it seems the code may be for a Work Management related feature
rather than the DB; i.e. looks like the WM might have mimicked the
long-utilized DB subterfuge with the effectively identical APAR text.

Regards, Chuck