Running DEBUG in batch

Has anybody done this?


I wish that I could remember who showed me this technique so that I could give them credit.

DEBUG in batch is possible, but it’s unwieldy, so I never use it. The example was extracted from a Natural Conference presentation. It may be a bit dated.

In an on-line session, set up breakpoints and watchpoints, and save them as an environment.

In batch, enter test mode, load the environment, and then execute your batch program.

LOGON natlib   
TEST                              invoke test mode  
T                                 test mode on  
E                                 environment menu  
L,testenv                         load your environment  
,,batchpgm                        execute your program  
L                                 list break  
,,,,,,,,,,,,,,,%K14               exit breakpoint  
M                                 end debug  
T                                 test mode off  
.                                 exit debug  

Thanks Ralph!

I remember seeing something similar but it was too cumbersome…

Hey SAG, are you listening? :idea:

Software AG’s “ear” is the change/enhancement process. Send in your enhancement request and post its ID here if you want to encourage others to comment on it for product management’s attention.

Thanks Douglas, been there before, done that before… :roll:

Again on Debugger.

I know that I can invoke it from a module using SET CONTROL ‘<TEST’, but how can I stop it from a module without pressing PF3 on the screen?
I mean, is there an equivalent of ‘<TEST’ to end Debugger?


Hi Carlos;

No, there is no counterpart to SET CONTROL ‘<TEST’ to turn test mode off. I would guess that the original intent of the debugger was to serve as an online tool, hence, perhaps, the assumption that you would turn the debugger off while at an interrupt. Or, you could have a breakpoint (or watchpoint) which runs a command to set test mode off. Using the watchpoint, you could even use this as sort of a toggle switch. However, the debugging environment will likely now be more complicated than the program(s) you are trying to debug.

I have two ways to avoid the need for trying to use the debugger in batch. They both involve running batch jobs as online jobs.

If there is only one (or sometimes two) work files, I simply use the Stack in lieu of a workfile. works quite well. A FOR loop with a STACK DATA statement at the beginning of a program suffices to “create” a bunch of “records” for the work file. INPUT statements serve the role of READ’ing a work file.

If there are a bunch of workfiles, try the following. Change the fields that you would use in READ and WRITE workfile statements into arrays. For each workfile, create a “pointer” variable. Thus, instead of a READ WORK FILE you might have:

                   FOR #W3-POINTER = 1 TO #W3-LIMIT
                   :::  process

The problem with both techniques is that they depart from what I feel is one of the major pluses for using the debugger, namely that the code is left intact. In both these approaches you must change the code, then remember to change it back before going to production. Not pretty.


If you have access to TSO or COM-PLETE, you can read and write workfiles from online.

Entire Connection is another alternative is some cases, if you can copy the workfile to the PC - since the UPLOAD and DOWNLOAD statements are just aliases for the READ WORK/WRITE WORK statements, you may be able to minimize changes to the program.

When using online programs in batch, you can insert “%Knn” in the stream to emulate pf-key. So, if you know where you want to exit the debugger, you can add “%K3” to the input to press PF3.