On 19-Mar-2015 09:59 -0500, David Gibbs wrote:
MCH1202 Escape 40 03/10/15 13:47:09.829038 ExSndPm 000000 QZRCSRVS QSYS *STMT
So, a symptom string might be composed as, essentially:
msgMCH1202 "Decimal data error."
F/ExSndPm x/000000
T/QZRCSRVS TM/QZRCRPC TP/CallProgram stmt/188
Nothing found obviously to be documented as a match; finding nothing
beyond what I already posted previously showing something similar, and
none of those reference any PTFs, just document the /similar/ incidents.
What was the PCML generated for the [program call method] invocation,
and what is the prototype for the procedure? That info might help a
reviewer to understand better, what processing might be failing with
that symptom.
The MCH1202 is IIRC, defined [as-shipped] to effect production of a
QPDSPJOB spool file if the condition was unmonitored; that, per the *JOB
special-value specification on the Data To Be Dumped (DMPLST) [i.e.
ADDMSGD MCH1202 DMPLST(*JOB)]. Hopefully that error was manifest as
unmonitored in the described scenario; such that if that spooled output
was generated due to an unmonitored condition, then posting that [esp.
the program stack portion] could be helpful. That effect would imply
that the condition also can be /trapped/ or just have additional
information logged on recurrence; if DMPLST(*JOB) was triggered, then
info such as the LIC job dump for which the effective LIC program stack
would be included [adding *JOBINT to the DMPLST()] thus giving other
information that might better reveal the source of the x0C02
exception\condition, and to effect trapping the condition, the Default
Program To Call (DFTPGM) parameter can assign an exit-program.
If the QPDSPJOB was not produced, thus implying the condition was
monitored, then... I wonder if the /watch/ feature could be used
instead to catch the incident within the job. While there is an
apparent asynchronous nature of the exit program being invoked via an
Event within a process /watching/ another or itself. The
sometimes-failing job presumably could be the requester of a Start Watch
(STRWCH) [e.g. STRWCH WCHMSG(MCH1202 'QZRCSRVS' *TOPGM *ESCAPE *EQ 40)
WCHJOB(*) WCHMSGQ(*JOBLOG) WCHPGM(theLib/TheExitPgm)
CALLWCHPGM(*WCHEVT)] such that the Event would be signaled within the
same process, thus enabling the exit-program to issue a DSPJOB
OUTPUT(*PRINT) along with possibly also a Dump Job Internal (DMPJOBINT)
[and Dump Job (DMPJOB)] when the message is issued and the /watched/
message-event occurs effectively simultaneously to be processed within
the same job [in effect, the exit program just gets added to the stack];
with proper care, the job could also await a reply to an inquiry before
continuing, thus allowing debug to be activated [albeit the processing
in the given scenario presumably is all just IBM OS programs for which
there are essentially no debug capabilities].? The Event Data made
available to the Watch Program [as the Exit Program] for when the Watch
Option Setting was established as *MSGID would be available for review
by the exit program, but any inputs likely would be unneeded to just
effect dumping; yet if the MCH1202 condition were more generically seen
even with the watch-selection already imposed [notably the ToPgm, the
Receiving Procedure Name additionally could be compared to the value
'CallProgram' to further ensure limiting the data collection to only the
specific incidents intended to be captured.
FWiW: I had thought about in the past, and I will mention again or
for the first time: A nice enhancement [someone might consider asking]
would be for the MsgId MCH1202 to have added, a varying length field
that exposes the data in *HEX of the bytes that can not be recognized as
valid BCD; another byte to reveal what the operation was expecting to
see, e.g. either 'P' [Packed BCD] or 'S' [Zoned BCD], could be
additionally worthwhile information added to the data elements of the
message description.
Hmmm. The instruction number showing zero has me wondering if the
error in the scenario might not arise from generated [e.g. mapping] code
rather than from an error in a specific instruction coded within the
procedure source; maybe I just do not recall correctly or something has
changed in how the error is being manifested. Short of a LIC dump of
the process at the point of failure, I doubt I could better understand
the failing scenario; I am not sure I would be able to surmise much from
any Dump Job (DMPJOB) output. If either the Watch or the Trapped
[unmonitored exception] are validated as possible, then that reveals to
the service provider how the condition could be trapped to allow for
debug of the IBM program(s); debug capable programs from IBM come in the
form of TestFix [a variant of, and delivered as, a PTF].
midrange.com
