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.
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.
ReplyDeleteThis is a much easier technique. In addition, service entry points can be used from the green screen debugger:
Deletehttp://www.ibmsystemsmag.com/ibmi/developer/rpg/Debugging-RPG-IV-Programs-a%E2%82%AC--The-Green-Screen-Way/?page=2
Good point Ralf.
DeleteBut 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
Yes, it's easier, but more expensive too...
Delete(I always use RDi)
Anyone can provide the guidelines for "How to debug in RDI any running batch job executed by another user profile ?
ReplyDeleteI can debug any job that was executed from my user profile.
In RDI SEP you choose the "User ID" but it has to be one that you are authorized to.
DeleteThank you so much.
DeleteI 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.
ReplyDeleteChris Ringer
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
ReplyDeleteRDi 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
ReplyDeleteI have done debugging on batch job before but it is nice to have it in writing, thanks Simon.
ReplyDeleteNice one ....
ReplyDelete