Applications started in the dialog are intended exclusively for debugging purposes. The differences to applications started with ENTER-JOB or ENTER-PROCEDURE are that tasks are not automatically started afterwards and that UTM-STXIT handling can be switched off.
Symbolic debugging
If you want to carry out symbolic debugging, then you must compile the program such that the compiler creates a list for symbolic debugging (LSD). In COBOL, for example, you do this by specifying COMOPT SYMTEST=ALL.
You should not link the LSD information statically because you can load it dynamically from your module library as and when required. You can then put the debugged programs into live operation immediately.
Exchanging program units
Specifying LOAD-MODE={STARTUP | ONCALL} in the LOAD-MODULE statement can be advantageous when debugging your program units and event exits. You do not need to link the application after making a program change and recompiling.
You only have to relink the LLM that contains the modified program unit. If the LLM only consists of this program unit, then you do not have to relink. You activate the modified program unit by restarting the application or exchanging the LLM while the program is running (KDCPROG LOAD-MODULE= ..., VERS=... command) or via the program administration interface (opcode=KC_MODIFY_OBJECT) or via WinAdmin/WebAdmin.
CAUTION!
If the modified program unit is assigned to a load module generated with LOAD-MODULE=ONCALL, then the modified program unit must have a different version than the program unit loaded to date.
Parallel operation for upgrading to a new version
If you make use of parallel operation, when upgrading to a new version of UTM you can minimize the effort involved as follows:
Install the new version of UTM in addition to your current version.
Link your application program (with a different name) to the new version (see the openUTM manual “Using UTM Applications on BS2000 Systems”.
Carry out debugging in parallel with live operation.
Number of tasks during debugging
For debugging purposes, it is normally sufficient to start the application with one task only. However, certain functions of a UTM application, such as programs which use PWGT calls, can be tested only if the application is started with more than one task.
If you want to start an application interactively with two or more tasks, please note the following points:
It is not possible to start tasks in both interactive and batch mode.
Follow-up tasks cannot be started with an administration command, but only "manually" at a terminal or in a separate window.
The AID commands must be repeated for every task because you cannot determine which task of the application will process a user requirement. The required AID commands can be inserted in the start procedure to prevent having to repeatedly enter the commands when debugging in multitasking mode.
If you debug and shut down an OSI TP application in multiple dialog tasks then the application should not be started again in the same dialog tasks since this can result in start-up errors or the abnormal termination of the application.
A dialog task only works for the application as long as the program remains loaded. Following program termination, you can continue to work with the task in BS2000 timesharing mode as long as you want. If you are working with only one task, each program termination also causes the application to terminate.