Debugging submitted batch jobs

In order to debug submitted jobs on the iSeries first submit the job with the Hold parameter set to *Yes, or submit the job to a job queue that is not attached to an active subsystem. Work with submitted jobs WRKSBMJOB to get the job number, user name, and job name.
  • STRSRVJOB job number/user/job name
  • STRDBG (Set a breakpoint at the beginning of the calculation specifications or in the *inzsr subroutine)
  • Release the submitted job.
  • When the source debug screen displays select F10=debug and then F10=Step to make the first step to the program and you can F11 to display variables, F10 step through statements, F6 to set additional breakpoints, etc.
  • When the job finishes;
One alternative to the service job method is to call the normally submitted program interactively from a command line while passing entry parameters.

Start debug as you normally would for an interactive program. For simplicity sake, say the entry parameters are company, vendor, and order number;

call mypgm parm('CO1' 'VENDOR45-678' '12345678-1')

One reason this method is effective is that even if the parameters are not exact the called program will not "error out" unless and until any of the passed parameters are actually used. If the breakpoints happen before the entry field is actually referenced the debug will continue unabated.

This method can be problematic if the parameters are complex. For example passing large data structures can be virtually impossible to emulate from a command line.

Fortunately, coding prototypes and procedure interfaces (PR and PI in the D specs) instead of the older *Entry adds flexibility to parameter handling and strengthens debugging. Parameters can be defined as "optionally passed", or have variable sizes, or be passed as a "constant" meaning the calling program is not allowed to change the value of the parameter. The subject of parameter passing and prototyping looks like an excellent topic for a future article!