On 02 May 2012 14:44, John Rusling wrote:
I did get dsplog to reveal this -
CPF1164 00 COMPLETION Job 812082/UROPER/CNSRDC9 ended on 05/01/12 at 16:13:24; .889 seconds used; end code 0
CNSRDC9 UROPER 812082 QWTMCEOJ 0000 05/01/12 16:13:24.379108 UROPER
As the job is no longer in the system, because it "thinks" it ran normally
I can't do the dspjoblog against it as Chuck suggested but I did post the
spool files generated yesterday.
QPDSPJOB1 spool file -
http://code.midrange.com/e48c1a3d72.html
QPDSPJOB2 spool file -
http://code.midrange.com/d446885f24.html
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
midrange.com
