×
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 18-Mar-2015 11:44 -0500, David Gibbs wrote:
Has anyone experienced an unexpected, and intermittent, MCH1202
(Decimal Data error) when doing a PCML service program procedure
call?
The weird thing is, the error doesn't appear to be coming from a
called program ...
The following line of info is missing, but expected preceding the
following lines of the [continuation of the] quoted OP:
MCH1202 Escape ?Sev? ?DatTim? ?f/pgm? ?inst? ?t/pgm? ?toPgmLib? *STMT
To module . . . . . . . . . : QZRCRPC
To procedure . . . . . . . : CallProgram
Statement . . . . . . . . . : 188
Message . . . . : Decimal data error.
FWiW: Lacking full details, a partial symptom string is:
msgMCH1202 [???] TM/QZRCRPC TP/CallProgram stmt/188
Normally, if the the DDE were occurring in a user program, I would
expect the actual program name to be referenced in the joblog.
This is happening on 7.1.
Because the problem is manifest on the interface that invokes the
program, rather than within the called program itself, the OS programs
would need to have logged an additional message to diagnose what they
failed to invoke; typically a logging facility would record what
processing had transpired up to the point of failure.
Can the problem be recreated with debug and\or trace active? If not,
the issue might be an uninitialized storage problem; that would fit with
the "intermittent", but also makes very difficult the testing if the
problem goes away.
FWiW: Or the error could have been one that implicitly includes that
diagnostic information, such as the similar issue below [x2201 aka
MCH3401] failing to invoke, an issue for which the named SrvPgm could
not be found, and thus the Service Program that was to be invoked gets
revealed in the error message. Just as after the MCH1202, there is not
another error logged to diagnose what the failed CallProgram had
attempted to effect; although in the following scenario, the additional
message would almost seem redundant, for revealing the same information
twice [except the additional message text hopefully would be directed
more to an application programmer rather than the LIC exception message
text which is directed toward the OS programmer]. Note how that NG
posting\message included the line starting MCH#### which I suggested was
omitted from the OP here.
<
http://newsgroups.derkeiler.com/Archive/Comp/comp.sys.ibm.as400.misc/2006-08/msg00034.html>
"...
MCH3401 Escape 40 20.07.06 14:41:48,761424 ExSndPm 000000 QZRCSRVS QSYS
*STMT
To module . . . . . . . . . : QZRCRPC
To procedure . . . . . . . : CallProgram
Statement . . . . . . . . . : 148
Message . . . . : Auflösung zu Objekt QTOCECCEXT nicht möglich. Art
und Subart X'0203', Berechtigung X'0000'.
..."
midrange.com
