Starting the application and entering debugging commands

You must carry out the following steps if you want to start an application in the dialog for debugging purposes:

1. Open a $DIALOG session and start your UTM application in the dialog task. Do this just like for live operation but do not start the application, just load it with LOAD-EXECUTABLE-PROGRAM. The corresponding window will be called the task window in the following. LOAD-EXECUTABLE-PROGRAM loads all statically linked programs. If, for example, you want to test a program unit for a Start-Exit, you can now enter the corresponding test commands.

2. Start the program with %RESUME. openUTM now reads the start parameters and loads all the programs in load modules that were generated with LOAD-MODE=STARTUP. This also includes shareable components (LOAD-MODE=(POOL/POOL,STARTUP).
   To avoid entering the start parameters manually you best execute steps 1 and 2 by using a procedure.

3. Press the K2 key so that the program is aborted and you can enter debugging commands.
   The K2 key does not take effect until the UTM task is in the non-privileged state of BS2000 (TU). This may not be the case until you have executed step 4.

4. Connect to your UTM application via a UTM client and, if necessary, sign on at the UTM application via a user ID. Next start a program unit or make your first user input.

5. Now you have to acknowledge in the task window that you want to enter cammands (CMD0170 DO YOU WANT TO INSERT COMMANDS? REPLY (Y=YES; N=NO)?).

   If you want to debug using symbols and the LSD information is not statically linked to the program, then you must assign the libraries that contain the LSD information with %SYMLIB symlib1, symlib2 ...
   If you use variable names with uppercase and lowercase letters in your program (C/C++ program units) and you want to refer to these names, then you must change the predefined settings for AID using the %AID LOW command.

   Now you can enter your debugging commands in the task window, for example to set a breakpoint, see the AID user guides.

   You resume execution of the UTM application program with RESUME-PROGRAM.

   Please note that load modules generated with LOAD-MODE=ONCALL are not loaded until they are called in a task. Only then can you enter debugging commands for these programs.

6. After the dialog step has been processed, the UTM client receives the response to your input just like in live operation.

If you want to start an additional dialog task, then you need to repeat steps 1 and 2, then enter something from the UTM client and then carry out the actions in step 4 again. If you have specified "TASKS=1" in the start parameters, then you will need to increase the number of tasks via administrative measures first, otherwise start error 31 will occur. Please note that if you are testing in dialog mode then the second task is a UTM system process

and that it may therefore be necessary to start three work processes. For testing in dialog mode, it is consequently recommendable to generate the application without UTM system processes (MAX SYSTEM-TASKS=0).

Please note that you cannot start any batch tasks afterwards.

The required AID commands can be inserted in the start procedure to prevent having to repeatedly enter the commands (the breakpoints must be set for each task) when debugging in multitasking mode.

You can connect additional UTM clients to your UTM application at any time, regardless of how many tasks the application runs with.

Notes

The following special points arise when an application is started in the dialog:

• The KDCS call PEND ER does not terminate the program. Thus, the program is not reloaded either. The user exit SHUT is not called. If you want to continue debugging with a newly loaded program, you have to terminate and restart the program yourself. If you are working with one task only, program termination also causes the application to terminate.

• BS2000 system does not give openUTM dialog tasks priority over other timesharing tasks. The tasks do not run as TP tasks, but as normal dialog tasks. The cache memory is not made resident (see the openUTM manual “Generating Applications”).

• It is not possible to exchange the application program via the administration.However, single LLM’s can be exchanged (see "Exchanging program units" (Preparations for debugging in the dialog)).

• The TASKS= start parameter only sets the upper limit of the number of tasks, but does not cause the follow-up task to be started. Every task started allocates a timesharing task on the BS2000 system.

• The command KDCAPPL TASKS=n also does not cause the start of follw-up tasks but only allows you to do so maunally. Further information is contained in the openUTM manual “Generating Applications”.

• You should analyze or save (recatalog) a UTM dump before the next start since the dump file can otherwise be overwritten.