IBMi (AS400) fans only ' DEBUGGING - How to use the STRSRVJOB and STRDBG commands on IBMi to debug a program in another user's session

How to use the STRSRVJOB and STRDBG commands on IBMi to debug a program in another user's session.


Programming also means, always, debugging. But when a program is installed in a production environment, and an end-user calls to report an issue, sometimes it's useful to connect directly to the user's session in DEBUG mode and step through the program itself.


To do this, the STRSRVJOB command comes to our aid.

First, let me give a brief summary of what a Service Job is and what the debugging activity on IBMi entails.


Service job: In the context of IBMi (formerly known as AS/400 or iSeries) and RPG programming, a service job refers to a separate job that is started to perform specific tasks or services related to a program. These service jobs are often used for debugging, monitoring, or other specialized purposes.

Debugging: One common use of service jobs is for debugging RPG programs. When you want to debug a program interactively, you typically start a service job to run the program. This allows you to set breakpoints, inspect variables, and step through the code line by line while keeping the main job running without interruptions. The service job is responsible for executing the program in a controlled debugging environment.





The "Start Service Job (STRSRVJOB)" command is often used to initiate a service jobs for debugging

Let's see how:

program on IBMi
Scenario: a user is inside the program you see above, and the user calls me to report that the program encounters an issue.

From my session, I can activate a job and debug the user's program.

To activate the job, I need three parameters:

Job Name
User
Number

I obtain them using WRKACTJOB (contact me for detailed explanation if needed).
WRKACTJOB
In the first row of WRKACTJOB, you will find Job, User, and Number.

So, the job activation command will be:
STRSRVJOB JOB(632102/VDOTEST/AS_AF02)


Now, let's activate debugging for the program that is 'misbehaving', so to speak. The program name is P02ASF.

Here is the command:

STRDBG PGM(P02ASF) UPDPROD(*YES) OPMSRC(*YES)

STRDBG

On my terminal, the source code appears at the point where it is currently stopped.

RPG debugging
With F10, I can execute the program step by step. STRDBG provides many other options that we will explore in a new post.



That's it.


Comments

  1. In our case, we often encounter a situation when we need to debug a program (let's call it PGMB), which is launched by another program (let it be PGMA) in a separate BATCH JOB using the SBMJOB command (or, if PGMA is written in C/C++, using the function spawn.
    In this case, we launch two instances of the 5250 terminal emulator (A and B). In A we enter

    STRDBG PGMA UPDPROD(*YES)

    and then somewhere at the input of the program we put a service breakpoint:

    sbreak

    then press F12 and launch the main program

    CALL PGMA

    At the moment when PGMB starts and it reaches the established service breakpoint in the terminal A window, we will receive a corresponding notification. There, by pressing F1 we will see the full name of the job in which PGMB is running.

    Switch to the terminal B window and type there

    STRSRVJOB()

    then

    STRDBG PGMB UPDPROD(*YES)

    and we find ourselves in the place PGMB where we set the service breakpoint. A little further (at least on the next line of code) we set the usual breakpoint (F6), return to window A and press Enter to continue execution.

    Switch to window B, press F12. All. We are in debugging mode of a program running in BATCH JOB.

    ReplyDelete
    Replies
    1. Thank you so much for your useful and insightful comment on our blog article. Your input is greatly appreciated, and it's readers like you who make our content even more valuable. We look forward to hearing more from you in the future! If you have any more thoughts or questions, feel free to share them. Thanks again!

      Delete
  2. I remember the days of having to set up specialized testing environments because the tools, strdbg, strsrvjob, strisdb were insufficient to deal with complex debug requirements. But i left those all behind when RDi came along. Just set up a service entry point, and the debugger picks up when the named user starts the named program in the named library. Works for every ILE program. No matter how it is started. No matter how deep it is embedded in a complex call path. Haven't used those old tools for at least a decade.

    ReplyDelete
    Replies
    1. Thank you for sharing your experience and insights. It's incredible to see how technology has evolved over the years, making debugging and testing more efficient. I'm glad to hear that RDi has been a game-changer for you, simplifying the debugging process. Your perspective is invaluable, and I appreciate your contribution to the discussion.

      Delete

Post a Comment

Popular posts from this blog

IBMi (AS400) fans only ' Efficient WRKSPLF with WSF - How to Search string into spooled files, Sort, and Generate PDFs on IBMi

IBMi (AS400) fans only - How to Sniff User Access

IBMi (AS400) fans only ' Detecting and Handling Non-Printable Characters in DB2 SQL Using LOCATE() and REPLACE() Functions