Re: Dump & Service Program Info

On 17-Jun-2011 03:53 , Wim_Vandepoel@xxxxxxx wrote:

There was no job log available, so we ran the program in debug...

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.?

Is there an easy way to create an interactive job log?
I know SIGNOFF LOG(*LIST) includes the job log in the spooled
output.But I only want the ones with an error...

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.

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.

Regards, Chuck

CRPence on 16/06/2011 19:04 wrote:

The default message description for MCH1210 has DMPLST(*JOB) which
means the "unmonitored" exception would [with that msg definition
unchanged] have produced a QPDSPJOB spooled file output in the job
that received the error. In that output which is [effectively] the
WRKJOB JOB(*) SELECT(*ALL) OUTPUT(*PRINT) would include a "program
stack" which I expect should clearly identify that level of detail
for the failure.?