Use RDi, or one of the other graphical debuggers, to set a service entry point (SEP) for the program to debug before submitting the job. If the job is submitted through a *JOBQ that is held, the SEP can be set while the job is waiting to run.
SEPs can be set and used through green-screen interfaces, but it's harder to learn the procedures.
When using plain old green screen, STRDBG then SBREAK nnnn where nnnn is the line number. Make sure the profile you use to add the sbreak and the profile you used to call the program are the same. hope this helps.
That submitted job is a completely independent job - you will need to STRSRVJOB on it, then STRDBG and add your breakpoints. Note that any given interactive session can only be servicing one batch job at a time, so if you need to be debugging both jobs you'll need two sessions.
Permits you to enter a service entry point at a position in the program being tested. A service entry point is a type of breakpoint established in a program to facilitate the system debugger in gaining control of a spawned job. The breakpoint is only signaled when the job within which the service entry point was hit is not currently under debug.
I have used the IBM System Debug Manager for a long time. It's a Java program, and will let you set breakpoints, examine variables, etc. in a graphical environment. You can probably find it by searching the IBM site. It's very intuitive, and easy to use. In order to see the code as you debug, you'll need to compile the program with *SOURCE view. Here's a link to the IBM page, but I think you need to be a registered IBM user to get the content... https://www.ibm.com/developerworks/ibmi/library/i-debug/index.html
The Java System Debugger is very handy. I used to use it when running Windows yeasrs ago, and I use it the same now with Linux. I've never understood why it's not used by more developers.
Discuss This Question: 8 Replies