× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.