openUTM writes the dumps in a file generation group (FGG) or in a normal BS2000 file (dump file). By default, the names of the dump files or of the FGG possess the following structure:
DUMP.UTM.rrrrrr.ttttff.aaaaaaaa[.iii]
If the dump was written while the application was running and the start parameter DUMP-PREFIX has been specified then the names of the dump files or of the FGG possess the following structure:
dump-prefix.rrrrrr.ttttff[.iii]
The letters mean:
dump-prefix | prefix that was specified in the start parameter DUMP-PREFIX. |
rrrrrr | ID identifying the cause of the memory dump. |
| is the task sequence number of the task which caused the dump. In the tttt = UTIL if the dump is generated in a UTM tool (KDCDEF or KDCUPD). |
| running number of the dumps generated by a task in an application if the |
| name of the application for which the dump is produced. |
iii | number of the file generation |
A file generation group is created if the dump is caused by the application being aborted. The name of the FGG depends on the task that initiated abortion of the application. For the other tasks, openUTM writes the dump information to other files of the FGG. This may not be possible in some cases. openUTM then writes the dump information of follow-up tasks to individual files and the ’ff’ count is maintained on a task-specific basis.
In some cases, openUTM may set tttt=0000, ff=00, aaaaaaaa=NONAME and, if existent, iii=000; this means that the relevant data is not available, e.g. at the start or end of a task.
You can specify the user ID to which openUTM writes a UTM dump by means of the start parameter DUMP-USERID, see the openUTM manual “Using UTM Applications on BS2000 systems”. Syntax of the start parameter:
.UTM START DUMP-USERID={ STANDARD | SYSUSER }
When STANDARD is specified (default setting), the dump files are written under the user’s own user ID (i.e. the user ID under which the UTM application is running), and under the $SYSUSER user ID when SYSUSER is specified.
Notes
If more than one task is active for the application, in the case of an application abortion the (chronological) first dump contains the reason indicating the reason for abortion (REASON). The other dumps contain a code indicating that these are follow-up dumps.
If the UTM application was started with TESTMODE=OFF, and if a PEND ER occurs with one of the following KCRCDC codes, the UTM dump is suppressed:
FH01, FH02, FR01, FR02, K301, K302, K345, K601, K602, K603, K608, KM01, KM02, KM03, KM04, KM05, KM07, KM08, KR01, KR02, KT01, KT02, KT04, KU14, XT80
If PGWT calls are permitted for the current TAC, and if the call where the error occurred was not a PEND call, the program will be loaded. In the case of the KCRCDC code K316, no UTM dump is written regardless of whether or not test mode is active.
Reducing the volume of dump information with the start parameter DUMP-CONTENT
The start parameter DUMP-CONTENT allows you to specify whether openUTM is to reduce the volume of dump information or not. In this case, reduction means that task-independent KAA memory areas (common memory pools) are only included in the dump of the task which caused the application to abort. Reducing the dump information means that the diagnostic documentation in the event of abortion of an application requires far less space. Reduction of the dump information is activated by default. The start parameter DUMP-CONTENT can be used to deactivate or reactivate reduction of the dump information as required.
Syntax of the start parameter:
.UTM START DUMP-CONTENT={ STANDARD | EXTENDED }
STANDARD | When UTM creates a dump file generation, task-independent memory areas are only contained in the dump for the first task (which caused abortion). This is generally sufficient for diagnostic purposes and is set by default. |
EXTENDED | Task-independent memory areas are contained in all the dumps of a dump file generation. You should only set this value when required to explicitly by the software support. |