On 04 Jan 2013 09:59, Scott Schollenberger wrote:

The SCPF spool file shows multiple error messages [Repeats over and over]:

msgMCH3402 F/AiUpcallProgram x/005C
T/QLEAWI TM/QLEPM TP/Q LE leActivationInit stmt/181

MCH3402 Escape 40 01/02/13 13:57:43.967456< allProgram
From Program . . . . . . . : AiUpcallProgram
To module . . . . . . . . . : QLEPM
To procedure . . . . . . . : Q LE leActivationInit
Statement . . . . . . . . . : 181

The ILE default exception handler for an unmonitored exception for an apparent CALLX MI instruction:

msgCEE9901 F/QLEAWI FM/QLEDEH FP/Q LE leDefaultEh stmt/205

CEE9901 Escape 30 01/02/13 13:57:43.967688 QLEAWI QSYS
From module . . . . . . . . : QLEDEH
From procedure . . . . . . : Q LE leDefaultEh
Statement . . . . . . . . . : 205

That generic\default handler then bubbles-up as the OS Function Check unmonitored exception handler:

rcCEE9901 T/QSZSTPRD x/0779

CPF9999 Escape 40 01/02/13 13:57:43.967840 QMHUNMSG

Because the MCH3402 was issued /from/ the Activation\Invocation component AI, that implies that the caller QSZSTPRD [Software Resource component SZ] passed a pointer to a previously deleted object. Thus the problem is either that the called object was deleted, or that the pointer [likely stored; e.g. in the system EPT or a similar storage location] to the object was not properly updated to the replacement [for the deleted] object. The pointer _could_ be a parameter I suppose, instead of an executable, but I typically would expect the latter. So whatever the OPM program QSZSTPRD calls at instruction x/0779 [presumably AiUpcallProgram implements the CALLX method; there are AiUpcallProcedure and AiUpcallFunction as well] is not invoked either because the pointer to the executable points to a previously deleted executable, or possibly a pointer passed as a parameter is failing a validation due to the pointer to the object passed refers to a previously deleted object, or the [based] storage used for a parameter or the pointer to the called object was previously deleted.

If the latter was origin, then the QSZSTPRD probably has a defect for not first verifying the existence of the object in which the pointer was stored. By reading some other stuff on the web, I encountered a reference to the "Registered Application Information Repository" (RAIR) which might be a source of some stored pointers or parameter data.? If so, I am not sure if this is something that could have been corrected [before pwrdwn\IPL by] using the same instructions found in the following document, or perhaps using some similar supported invocation of the QSZRECOV [SZ Recovery program]? Of course to have known for sure, the obvious need to first have been in contact with a service provider to have investigated the originally experienced problem before attempting resolution by IPL:
IBM i Support: Software Technical Document : 322875898

FWiW the information in the quoted message suggests that the failure at IPL was consistent with the problem occurring while the system was active prior to the PwrDwn to start that IPL; i.e. the IPL errors seem consistent with the below request and its failure as recorded in an earlier message:

wrkobjpdm attnlib /* fails with: */
;; msgMCH3402 T/QLEAWI stmt/0181

FWiW the same failing instruction within the LIC AI was recorded in a message on a Zend forum, but still I am not clear if the reference is a stored pointer as a parameter or the called object; seems however that the more likely case is for storage _for_ a parameter rather than a pointer _as_ a parameter:

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page