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
00005C QLEAWI QSYS *STMT
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
rcMCH3402
CEE9901 Escape 30 01/02/13 13:57:43.967688 QLEAWI QSYS
*STMT QSZSTPRD QSYS 0779
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:
msgCPF9999 F/QMHUNMSG *FC
rcCEE9901 T/QSZSTPRD x/0779
CPF9999 Escape 40 01/02/13 13:57:43.967840 QMHUNMSG
*N QSZSTPRD QSYS 0779
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
http://www-912.ibm.com/s_dir/SLKBase.nsf/1ac66549a21402188625680b0002037e/80d74c0524e44d8786256dd900569112?OpenDocument&ExpandSection=-1
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:
http://forums.zend.com/viewtopic.php?f=113&p=116388
midrange.com
