Retrieve error message in RPG

25 pts.
Tags:
iSeries
RPGLE
V5R4
I have an interactive RPGLE program ,PGMA, that calls another RPG program, RPG3P, based on a parameter and that job is not interactive. If RPG3P aborts how can I find out what the error mesage was? The job log does not give enough information to help find the problem.

Software/Hardware used:
V5R4

Answer Wiki

Thanks. We'll let you know when a new response is added.

If PGMA calls RPG3P then is still interactive, and you should see the message in your joblog.
If PGMA does a SBMJOB of RPG3P, or RPG3P submits a different job then you have created a 2nd job that would be batch.
I will assume the second.
The Batch job should have a message in QSYSOPR unless you are doing a MONMSG or using SYSRPLL to automatically answer the message.
You need to change the logging level in your batch job to LOG(4 00 *SECLVL) LOGCLPGM(*YES)
You can either do that on the SBMJOB command or change it while it is running or in the job queue.
Then it should produce enough information in your joblog to tell you what is going on.

====================================================================

Messages sent to a program message queue can be retrieved from a job’s external message queue if the message was promoted to the external message queue. However, if the message was received and removed, then it is gone and cannot be retrieved.

If RPG3P is no longer in the call stack, then its program message queue no longer exists. Even if the message was not removed, if it wasn’t promoted, it won’t be available. “Standard error” routines commonly handle promotion of messages in order to avoid losing them.

Also, a job might abort from an exception, but no message was ever sent. (E.g., an API may return an exception message identifier in the error code data structure — there is no message in the program message queue nor the job message queue unless the caller of the API puts a message there.)

Determining the cause will require knowing how the programming detects and handles exceptions. Most often, the exception will appear in the job external message queue (often called the “joblog”).

Note that it might be better not to specify LOGCLPGM(*YES). There might be no CL in the job. There might be a lot of CL executed in a loop so that the CL requests overwhelm all other messages. CL programs might be compiled as LOGCLPGM(*NO). Just keep in mind that it might or might not be appropriate.

Tom

Discuss This Question: 5  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    > ...and that job is not interactive. That seems to indicate that PGMA doesn't call RPG3P. Instead, it makes it seem like PGMA submits a batch job that calls RPG3P. The spooled joblog of that batch job doesn't give you enough information to learn why the abort happened. Does that describe your situation? If not, can you tell us more? Tom
    125,585 pointsBadges:
    report
  • Old2new
    I'm sorry if my question was a little confusing. Below is parts of the CL (EDPROC) that is called interactively and the RPG program that it calls to run a third job job. The called job at (A) can be RPG or CL. I would like to be able to get enough info to determine the cause of a problem if the called program at (A) aborts. EDPROC (CLLE program) call pgm(eod_job_P) parm('CMLSTSPEC ' &testout) -------------------------------------------------------------------- EOD_JOB_P (RPGLE program) d eod_job_p pi d pgmname 10a const d status 1a options(*nopass) d brl 1a options(*nopass) d whs 1 0 options(*nopass) eodjobnam = pgmname; exsr RunTheJob; if PassStatus; status = WrkStatus; ENDIF; return; //----------------------------------------------------------- begsr RunTheJob; /end-free c call(e) eodjobnam (A) /free select; when %status = 202 or %status = 231 or %status = 232; wrkstatus = 'H'; exsr senderrmsg; when %status = 211; wrkstatus = 'I'; exsr senderrmsg; other; wrkstatus = 'C'; // Completed endsl; endsr; //---------------------------------------------------------------------- begsr senderrmsg; select; when wrkstatus = 'H'; // Called Job Failed/Halted cmd = teststatus+'-EDPROC Called Program '+%trim(eodjobnam)+ ' failed for branch '+wrkbrl+%char(wrkwhs)+'. Examine + the job log before answering. Job Stopped. + Status = H'; exsr email; exsr errlog; when wrkstatus = 'I'; // Error Calling program cmd = teststatus+'-EDPROC Error calling program '+%trim(eodjobnam)+ ' for branch '+wrkbrl+%char(wrkwhs)+'. Job Stopped. + Status = I'; exsr email; exsr errlog; endsl; endsr;
    25 pointsBadges:
    report
  • CharlieBrowne
    That job is running interactive. You should be able use DEBUG to step into it and determine error. also if you CHGJOB LOG(4 00 *SECLVL) LOGCLPGM(*YES) you should get all the information you need.
    41,370 pointsBadges:
    report
  • TomLiotta
    Given everything so far, CharlieBrowne is right. Everything should be visible in the interactive joblog when EDPROC ends. A DSPJOBLOG command at that point should show everything. (Assuming that CMLSTSPEC put messages into the joblog and that other programming that's left out didn't remove the messages.) You might get by with:
    call pgm(eod_job_P) parm(’CMLSTSPEC ‘ &testout)
    if ( &testout *eq 'H' *or &testout *eq 'I' )  do
       DSPJOBLOG  OUTPUT(*PRINT)
    enddo
    
    Whether anything gets spooled or not will depend on how the job logging levels are set and how messages are handled in the programming. (I wouldn't expect them to be removed.) The logging level might be set automatically. However, you might not want to trust that. You can put:
    CHGJOB LOG(4 00 *SECLVL)
    call pgm(eod_job_P) parm(’CMLSTSPEC ‘ &testout)
    
    to set the level before calling eod_job_P. That sets the level so that DSPJOBLOG is more sure to have something useful to print. (Add [LOGCLPGM(*YES)] to the CHGJOB command if you need to see any CL commands that might be in there.) What is the purpose of the eod_job_P program? It doesn't seem to do anything that couldn't be done directly in EDPROC. Tom
    125,585 pointsBadges:
    report
  • Old2new
    Tom and Charlie, Thank you for your feedback. I will use these ideas.
    25 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following