Chuck,
Great! Thanks for the taking the time.
Here's a link to the *seclvl details.
http://code.midrange.com/6ffb32eaa3.html
I did notice the QCL_Function_Check_Exception_Handler you pointed
out but did not know what to make of it. Thanks for clearly
outlining that.
Later,
(backups are running)
John B
<snip>
Not that it would necessarily be relevant\helpful, but the *SECLVL details of the completion message does contain additionally, at least a secondary return\ending code and number of routing steps. FWiW, the OUTPUT parameter of DSPLOG allows alternates to just *PRINT which only gives first level.
This issue reminds me that many times I had thought that the DSPJOB taken as part of the "Dump List" information should include some details of the joblog; e.g. the effective F6=Print output for the DSPMSG of the message that gave origin. Anyone who cares might issue a Design Change Request. Instead of ever pursuing anything, I always just added a "Default program" (DFTPGM) and\or added a *JOBINT to messages I was interested in. Only now I am wondering why there is not a *JOBLOG available on the DMPLST parameter; that was always the first thing my DFTPGM would generate. Anyhow...
The first DSPJOB information suggests that the CLLE program EDPROC in library WZZZJBL0 encountered an exception that was unmonitored, and the exception message received was defined with the "Data to be dumped" set to DMPLST(*JOB). The control from the bound procedure QCL_Function_Check_Exception_Handler passes to the common default CL run-time *FC handler program QCLXERR to send the message CPA0702 to the user [or QSYSOPR]; presumably sent to *EXT for this interactive job [i.e. "Type of job"=INTER].
It appears this CLLE program EDPROC was invoked with recursion by the RPG program EDCNW1; i.e. the stack shows EDPROC calling EDCNW1 which then calls EDPROC. That may or may not be expected.?
Because the job was running with "Inquiry message reply" handling of INQMSGRPY(*SYSRPYL), both of the incidents may have been auto-replied by the system reply list; review WRKRPYLE to see the settings. If there is no explicit entry nor generic [e.g. CPA0700] reply defined that should have auto-responded, then very probably the first response was an ignore and the second was to ignore or cancel; i.e. seems unlikely that the default setup to have the message generate a dump was in effect, else a QPPGMDMP would have appeared in the list of spools, and the first reply was unlikely a retry, else the second error would presumably have looked the same instead of the apparent "percolating" of the message.
Hmmm.. The time difference from the first to the second of is small, 16:12:17 to 16:12:22, but almost seems too long to infer directly a simple percolation of the error. All that had to happen was reclaiming the *NEW\14 activation group.
Of possible note [I have never used nor paid any attention to] the "Program return code" which in this scenario is 2 in the first incident and 1 in the second. The help text suggests that if "the job contains any RPG/400, COBOL, DFU, or sort utility programs, the completion status of the last program that has finished running is shown; otherwise a value of zero is shown." The program EDCNW1 in WZZZJBL0 which was running in the *NEW\14 activation would have been the last RPG program to complete running in the second incident; that was the RC1. The prior programs in the stack would have to be reviewed for the type of program to know which had the RC2.
V7R1M0
Program Stmt Inst Module or ... ActGrp CB
QCMD QSYS 04FA Dft\01
J55DDISC WZZZJBL0 1200 0013 Dft\02
J98INITA JDFOBJ 13700 00EB Dft\02
J98INITV JDFOBJ 16500 00D3 Dft\02
P00MENU JDFOBJ 066A Dft\02
J55D0801 WZZZJBL0 J55D0801 QTEMP Dft\02 Y
Procedure: _CL_PEP
J55D0801 WZZZJBL0 700 J55D0801 QTEMP Dft\02 N
Procedure: J55D0801
// second failure popped here; called QCLXERR per normal, as below
J55D0801 WZZZJBL0 J55D0801 QTEMP Dft\02 N
Procedure: QCL_Function_Check_Exception_Handler
// first failure went here; i.e. ignore the above entry
EDPROC WZZZJBL0 EDPROC QTEMP New\14 Y
Procedure: _CL_PEP
EDPROC WZZZJBL0 64600 EDPROC QTEMP New\14 N
Procedure: EDPROC
EDCNW1 WZZZJBL0 EDCNW1 QTEMP New\14 N
Procedure: _QRNP_PEP_EDCNW1
EDPROC WZZZJBL0 EDPROC QTEMP New\14 N
Procedure: QCL_Function_Check_Exception_Handler
QCLXERR QSYS 00C6 Dft\01 N
QMHSNINQ QSYS 07DE Dft\01 N
Regards, Chuck
</snip>
midrange.com
