Re: Dump & Service Program Info

Debug is probably better, assuming the error could be reproduced.
Yet to have fully identified the details originally requested, i.e. to
"find out which service program procedure had the error", there should
have been a QPDSPJOB [i.e. WRKJOB OUTPUT(*PRINT) output] from the prior
failure irrespective of the existence of any QPJOBLOG.?

The parameter in the message description for MCH1210 is indeed
DMPLST(*JOB).
I've created a program and a service program to mimic the error.
But no QPDSPJOB found.

User education mostly, both how the user should respond to such error
conditions [call the help desk to request a debug assist] and [for when
assistance is not available] to first SysRqs-3 OUTPUT(*PRINT) and then
either to DSPJOBLOG OUTPUT(*PRINT) or [to remember to eventually]
SIGNOFF *LIST. I prefer a user stays logged in if possible [starting a
secondary session if necessary] because reviewing an active job is often
significantly more beneficial than working with only what was
spooled\gathered previously for a failing application in a job that is
no longer active; i.e. usually what is collected as documentation for
the failure rarely reflects the details I desire, and having the job
remain active may allow some of those details to be gathered. Objects
in QTEMP are the most typical of the missing but valuable information,
so with educating the users there may be value in suggesting also to
move objects from QTEMP into a permanent library, and in review of the
active job the ability to access those objects whereas in review of the
since-terminated job only seeing the list of objects in QTEMP as "object
deleted" messages but only if the joblog was obtained by SIGNOFF *LIST.

User education would be nice, but not always possible due to the number of
temporary users during peak season.

More defensive programming might be the better approach, as compared
with entrusting the users to do the necessary work to assist the coders
in a worthwhile manner. For the given situation, for which there was an
inquiry message due to an unmonitored condition, had the program itself
been coded to intercept the condition instead of allowing the condition
to be diagnosed by the "default handler" of the HLL run-time, then that
coded handler could have produced both joblog and dspjob output spool
files and even performed actions that would spool application-specific
details as well as to provide better notification to whomever is
responsible for the application. A handler for the application would
know of potential relevance of the objects in QTEMP and of generic or
specific data areas and whatever else might be relevant for tracking
down origins of an unexpected error, more so than any generic HLL
run-time default handler for which just a D=Dump reply might produce.
÷ More generically for inquiries, the inquiry message reply handling
exit program could enable a means to spool more details about any
default handler.
÷ More specifically for any particular errors that would be known to
be unmonitored but may still occur [e.g. the mch1210], the DMPLST [I had
mistakenly referred to below, since corrected, as DMP()] parameter of
the CHGMSGD can include more than the *JOB, and even an exit program can
be named on the DFTPGM parameter to do even more.

I'm not authorized to change the message file, but I'd like the idea to
use an exit program.
I'll have a word with the administrator...

Thanks for the information.


Rest Begards
Wim