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:

1. Make sure that the program you want to debug is compiled with debug views, as discussed earlier.
2. 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.
3. Type STRSRVJOB and press F4. Type the job’s user, name, and number in the appropriate parameters and press Enter.
4. Back in the command line, type STRDBG <program name>. When the source is displayed, press F12 to continue.
5. 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.
6. We’re almost there! Type DSPMODSRC to access the module’s source and press Enter.
7. When your source is displayed, set your breakpoints. Press F12 when you’re done, and then press F12 again to end the command entry.
8. You should be back at the Start Serviced Jobscreen. Simply press Enter to continue.
9. 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.
10. 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:

RPG Academy: Debug Done Right - Introducing the ILE Debugger

RPG Academy: Debug Done Right - Choosing the Right Debug View

RPG Academy: Debug Done Right - Encrypting Your Debugging Views

RPG Academy: Debug Done Right - Starting a Debug Session

RPG Academy: Debug Done Right - Working with Breakpoints

RPG Academy: Debug Done Right - Working with Watch Conditions

RPG Academy: Debug Done Right - A Step-by-Step Debug Session, Part 1

RPG Academy: Debug Done Right - A Step-by-Step Debug Session, Part 2 

RPG Academy: Debug Done Right - You Can Debug Anything!

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.

Rafael Victória-Pereira has more than 20 years of IBM i experience as a programmer, analyst, and manager. Over that period, he has been an active voice in the IBM i community, encouraging and helping programmers transition to ILE and free-format RPG. Rafael has written more than 100 technical articles about topics ranging from interfaces (the topic for his first book, Flexible Input, Dazzling Output with IBM i) to modern RPG and SQL in his popular RPG Academy and SQL 101 series on mcpressonline.com and in his books Evolve Your RPG Coding and SQL for IBM i: A Database Modernization Guide. Rafael writes in an easy-to-read, practical style that is highly popular with his audience of IBM technology professionals.

Rafael is the Deputy IT Director - Infrastructures and Services at the Luis Simões Group in Portugal. His areas of expertise include programming in the IBM i native languages (RPG, CL, and DB2 SQL) and in "modern" programming languages, such as Java, C#, and Python, as well as project management and consultancy.

---

MC Press books written by Rafael Victória-Pereira available now on the MC Press Bookstore.

		Evolve Your RPG Coding: Move from OPM to ILE...and Beyond Transition to modern RPG programming with this step-by-step guide through ILE and free-format RPG, SQL, and modernization techniques. List Price $79.95 Now On Sale
		Flexible Input, Dazzling Output with IBM i Uncover easier, more flexible ways to get data into your system, plus some methods for exporting and presenting the vital business data it contains. List Price $79.95 Now On Sale
		SQL for IBM i: A Database Modernization Guide Learn how to use SQL’s capabilities to modernize and enhance your IBM i database. List Price $79.95 Now On Sale