You may say I left the best for last. Here’s how to do something impossible for the “old” ISDB: debug batch jobs!
One of the main advantages of the ILE debugger over its older brother, the ISDB, is the ability to debug batch jobs. Over the last TechTips, I’ve shown a few other functionalities that are way better than what the ISDB has to offer, and most of them are easy to use. Unfortunately, debugging a batch job is not as simple as debugging an interactive job; you need to take some additional steps to “catch” the batch-running program in the right moment. Here’s a step-by-step guide:
- Make sure that the program you want to debug is compiled with debug views, as discussed earlier.
- Submit the job that calls the program you want to debug with HOLD(*YES). This will allow you to make note of the job’s user, name, and number, which you’ll need for the next step.
- Type STRSRVJOB and press F4. Type the job’s user, name, and number in the appropriate parameters and press Enter.
- Back in the command line, type STRDBG <program name>. When the source is displayed, press F12 to continue.
- Now release the submitted job, using the RLSJOB, WRKSBMJOB, or WRKUSRJOB commands. The Start Serviced Jobscreen will be displayed; press F10 to access a command line.
- We’re almost there! Type DSPMODSRC to access the module’s source and press Enter.
- When your source is displayed, set your breakpoints. Press F12 when you’re done, and then press F12 again to end the command entry.
- You should be back at the Start Serviced Jobscreen. Simply press Enter to continue.
- The batch program will run until it reaches one of the breakpoints. From here, you can debug it interactively, as shown earlier in this subseries.
- When the batch job ends, type ENDDBG to end the debug session and ENDSRVJOB to end the remote job service operation.
The novelty here is the Start Service Job (STRSVRJOB) command. This command starts the remote service operation for a specified job (other than the job issuing the command) so that other service commands can be entered to service the specified job. It acts as a proxy, allowing you to interact with another job. In this particular setting, I’m using it to debug a batch job, but it can be used to debug other interactive jobs as well. Any dump, debug, and trace commands can be run in that job until service operation ends.
As you’ve seen in the steps, the service operation continues until the End Service Job (ENDSRVJOB) command is executed. Also, note that some special authorities are required to use these commands. Your profile must have QPGMR, QSYSOPR, QSRV, or QSRVBAS authority. Additionally, if the job being serviced is not running under your profile, you need to have *USE authority to the user profile of that job.
This topic is the last of the Debug Done Right subseries. Even thought it was not a very long subseries, I think it’s a good idea to have a quick recap.
“Debug Done Right” Recap
This subseries kicked off with a simple comparison between ISDB and the new debugger:
- The ILE debugger is easier to use, quicker, and less resource-consuming than ISDB.
- ISDB is limited to OPM programs and interactive jobs, while the new debugger allows you to debug OPM and ILE programs, running interactively or in batch.
Then, it discussed the different debug views. They’re listed below, in increasing order of debug information available:
- *NONE—No debug information is stored, so it’s not possible to debug the object.
- *STMT—Minimal information is stored. Debug is possible using a compile listing with the statement numbers.
- *SOURCE—Almost source-like information is available, but the copy members are not copied to the debug information.
- *COPY—The same as *SOURCE, with the addition of the copy members.
- *LIST—This is the most complete and flexible debug view, my favorite. It is customizable via the OPTION parameter.
- *All—All of the previously listed views are stored in the object, and it’s possible to choose which to use at debug time.
The newly introduced Debug Encryption Key (DBGENCKEY) command was presented next, and its usage was discussed in detail. Note that this parameter is only available for V7.1 or newer releases.
A brief overview of the debug session navigational commands and function keys was presented. A complete list is available in the downloadable source code.
The breakpoint concept, in its conditional and unconditional forms, was explained, as well as the debug commands and function keys associated with it. In a nutshell, an unconditional breakpoint will always stop execution when it reaches the statement in which the breakpoint resides, relinquishing control to the programmer, while a conditional breakpoint will stop only if the simple condition used to create it is satisfied. Note that composed conditions, resorting to AND/OR operators, are not allowed. The watch condition has some similarities to a conditional breakpoint, but it doesn’t reside in any particular statement; instead, it’s triggered by changes in the contents of the variable over which it was defined.
The series’ last two TechTips explained how to debug interactive and batch jobs. Debugging a batch job requires a slightly elaborate process, but once you understand and get the hang of it, it’s actually quite simple.
For your convenience, here’s a list of the previous article in the series, in the order in which they appeared:
That’s all for now! As usual, feel free to post your comments in the section below or in the usual forums where these articles pop up.