Wednesday, June 1, 2016

Debugging a batch job

debugging a program that has been submitted to batch

It is a surprisingly common misconception that you cannot debug a program that runs in batch. While you have to perform some extra steps, which identify the job you want to debug within, the debugging interface is identical to that of a interactive debug.

To be able to run source debug, whether interactive or batch, you need to create (compile) your CLLE, RPGLE, and SQLRPGLE objects with the appropriate debug view parameter. To learn about the various debug views see the post Debug views finding your favorite.

First I need to submit the job to batch, and hold it. I can either hold the job queue the job is submitted to, or submitting the job as held using the following command:

  SBMJOB CMD(CALL PGM(TESTPGM1)) JOB(TEST1) JOBQ(QBATCH) +
           HOLD(*YES)

I need to find the job name and number of the submitted job. The easiest way I know to do this is to use the Work User Job command, WRKUSRJOB, to look at all the jobs I have submitted to job queues:

  WRKUSRJOB STATUS(*JOBQ)

The "Work with User Jobs" screen displayed, and I use option 5 to display the job's details:

                  Work with User Jobs

Type options, press Enter.
                              5=Work with

 Opt  Job         User        Type     -----Status-----
 5    TEST1       SIMON       BATCH    JOBQ     HELD

At the top of the next screen, "Work with Job" is the information I need:

                      Work with Job

Job:   TEST1          User:   SIMON          Number:   192561

At any command line I need to start the Service Job with the job's details I just discovered:

  STRSRVJOB JOB(192561/SIMON/TEST1)

Then I start debug. I want to debug TESTPGM2, which is called by TESTPGM1, the program I submitted to batch:

  STRDBG PGM(*LIBL/TESTPGM2) UPDPROD(*YES)

The debug screen is shown, but I cannot enter any break points. I press F12 to exit the debug screen and return to the command line.

I now release the job or the job queue, depending upon which I held at the start. As the released job becomes active I am presented with the following screen:

                       Start Serviced Job                           

 Job:   TEST1          User:   SIMON          Number:   192561

 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.

I press F10 and I am taken to the "Command Entry" screen (like with QCMD). On the command line I type DSPMODSRC and press Enter. The source code for the program I am debugging is displayed. I can now enter break points.

I press F3 or F12 to return to the "Command Entry" screen. And I press F3 or F12 to return to the "Start Service Job" screen. I press Enter to start the job, and I debug the program as I would an interactive program.

When I am done I must end debug and the Service Job using the following commands:

  ENDDBG
  ENDSRVJOB

Yes, it is that easy.

 

You can learn more about debugging in batch from the IBM website here.

 

This article was written for IBM i 7.2, and should work for earlier releases too.

11 comments:

  1. It is much easier to use RDI and service entry points for this purpose. If you have defined a service entry point, every time you run the batch program the batch job stops automatically and the source will be opened in the RDI Debugger.

    ReplyDelete
    Replies
    1. This is a much easier technique. In addition, service entry points can be used from the green screen debugger:
      http://www.ibmsystemsmag.com/ibmi/developer/rpg/Debugging-RPG-IV-Programs-a%E2%82%AC--The-Green-Screen-Way/?page=2

      Delete
    2. Good point Ralf.
      But Service Entry Points (SEP) came in at V5R2 back in 2002. You do not need RDi for SEPs. In STRDBG, use the sbreak command to enter a service entry point at a position in the program to be tested.

      sbreak 142 user WATSON
      sbreak 142

      Regards
      Jan

      Delete
    3. Yes, it's easier, but more expensive too...

      (I always use RDi)

      Delete
  2. Anyone can provide the guidelines for "How to debug in RDI any running batch job executed by another user profile ?
    I can debug any job that was executed from my user profile.

    ReplyDelete
    Replies
    1. In RDI SEP you choose the "User ID" but it has to be one that you are authorized to.

      Delete
  3. I always soft code the value HOLD(&HOLD) in CL and RPG programs and make the &HOLD = '*NO'. Why? So I can make the value *YES in debug and hold the job when I need to debug the batch job.

    Chris Ringer

    ReplyDelete
  4. When you find your job in WRKSBMJOB or WRKUSRJOB, 5 the job, then use opt 10 to get the job log. there is the '192561/SIMON/TEST1' all ready for you to copy and paste into your STRSRVJOB

    ReplyDelete
  5. RDi also has the ability to debug a running job. Right click on the job in the Jobs subsystem and select Debug As>IBM i Job

    ReplyDelete
  6. I have done debugging on batch job before but it is nice to have it in writing, thanks Simon.

    ReplyDelete

To prevent "comment spam" all comments are moderated.
Learn about this website's comments policy here.

Some people have reported that they cannot post a comment using certain computers and browsers. If this is you feel free to use the Contact Form to send me the comment and I will post it for you, please include the title of the post so I know which one to post the comment to.