Have you ever changed a batch program to run interactively just so you could use the debug feature on it? Have you ever pondered buying a third-party debug tool just to find those errors that inevitably show up on job logs? Have you ever stared at a program until your eyes glazed over trying to find the intermittent mystery error that keeps popping up when the third-shift operator runs the nightly batch run? If you an-swered yes to any of these questions, you should read this article.

The system debugger that comes with your AS/400 may not have all the features of some of the third-party debuggers, but it has one great advantage the others cannot claim to have-it's free.

Most AS/400 programmers know the basics of starting debug, setting breakpoints, and displaying and changing program variables. Let's skip the fundamentals and focus instead on debugging batch programs. Debugging batch jobs is not very different from the debugging you're already familiar with.

Starting the Service Job

To run debug on a batch program, you need to use a feature called a service job. Before initiating the service job, you need three components: the job name, the user, and the job number.

Finding the information is easy if the program happens to be at an error message or is already running (does the term looping sound familiar?). You can use the Work with Active Jobs (WRKACTJOB) or Work with Submitted Jobs (WRKSBMJOB) command to find the job in question. When you select the Work with Job option, you will find the three parameters you need displayed at the top of the screen as shown in 1.

Finding the information is easy if the program happens to be at an error message or is already running (does the term looping sound familiar?). You can use the Work with Active Jobs (WRKACTJOB) or Work with Submitted Jobs (WRKSBMJOB) command to find the job in question. When you select the Work with Job option, you will find the three parameters you need displayed at the top of the screen as shown in Figure 1.

If the job is already running, you need to put the job on hold using the WRKACTJOB or WRKSBMJOB panel.

On the other hand, if the job you want to debug is not already running, you need to go about it a little differently. You do not want the job to begin running until you have initiated the service job. Place the job queue on hold using the Hold Job Queue (HLDJOBQ) command and then submit the job. Placing the job queue on hold does not stop existing programs from running, but it does keep new jobs in the queue from being initiated. Use the WRKSBMJOB command to get the job identification parameters, so you can start the service job.

By now, you should have written down the job name, user, and job number. You can run the Start Service Job (STRSRVJOB) command from any workstation. If you use F4 your screen will look like 2.

By now, you should have written down the job name, user, and job number. You can run the Start Service Job (STRSRVJOB) command from any workstation. If you use F4 your screen will look like Figure 2.

Starting Debug

Now that you have started the service job, you need to put the program into debug mode. You can use the Start Debug (STRDBG) command just as if you were putting an interactive program into debug mode. However, the system won't let you add your breakpoints until the job begins.

Now it's time to release the job queue using the Release Job Queue (RLSJOBQ) command. If the job is already running, use the Release Job (RLSJOB) command. If the job has not yet started, a screen will be displayed letting you know that the serviced job is about to begin. You can expect a screen that looks something like 3.

Now it's time to release the job queue using the Release Job Queue (RLSJOBQ) command. If the job is already running, use the Release Job (RLSJOB) command. If the job has not yet started, a screen will be displayed letting you know that the serviced job is about to begin. You can expect a screen that looks something like Figure 3.

Defining Your Breakpoints

At this point, you must press F10 to get a command entry screen. You have put your program into debug, but you have not told the system where you want it to break. Use the Add Breakpoint (ADDBKP) or Add Trace (ADDTRC) command to define where you want your program to stop, just like you would if you were debugging an interactive job.

Perform the rest of the debug functions as if the program were running in an interactive job. That is all there is to it! When the job completes, you receive another break message that tells you the job being serviced has ended. (Do not confuse this with ending the service job.)

Word of Caution

You will need to end both debug and the service job, or you may encounter problems later. Use the End Debug (ENDDBG) command followed by the End Service Job (ENDSRVJOB) command.

In Summary

Although it is a little clunky, debug on the AS/400 can be an extremely useful tool if you take the time to learn it. The CL Programmer's Guide contains a useful chapter called "Testing Functions" that provides additional insights into debugging both interactive and batch jobs.

Doug Pence and Ron Hawkins have worked on IBM midrange systems for many years. Doug is the founder and Ron is the research and development manager of Computer Processing Unlimited, Inc. in San Diego, California.

REFERENCE AS/400 CL Programmer's Guide (SC21-8077-2, CD-ROM QBKA7102).

Debugging Batch Jobs

Figure 1 The Work with Job Panel

 Work with Job System: CPU Job: ATBRPT User: QPGMR Number: 541492 Select one of the following: 1. Display job status attributes 2. Display job definition attributes 3. Display job run attributes, if active 4. Work with spooled files 10. Display job log, if active or on job queue 11. Display call stack, if active 12. Work with locks, if active 13. Display library list, if active 14. Display open files, if active 15. Display file overrides, if active 16. Display commitment control status, if active More... Selection or command ===> F3=Exit F4=Prompt F9=Retrieve F12=Cancel 
 
 Debugging Batch Jobs
 
 Figure 2 Start Service Job Prompt
 
 Start Service Job (STRSRVJOB) Type choices, press Enter. Job name . . . . . . . . . . . . JOB atbrpt User . . . . . . . . . . . . . qpgmr Number . . . . . . . . . . . . 541492 Bottom F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel F13=How to use this display F24=More keys 
 
 Debugging Batch Jobs
 
 Figure 3 The Released Serviced Job Screen
 
 Start Serviced Job System: CPU Job: ATBRPT User: QPGMR Number: 541492 The serviced job has been released from the job queue. Press Enter to start the job or F10 to enter debug commands for that job. Press Enter to continue. F10=Command entry (C) COPYRIGHT IBM CORP. 1980, 1993. 

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails