Notes on the DYNAMIC clause (COBOL85)
The DYNAMIC clause should not be used in load modules that are to be exchanged, because the working storage space allocated dynamically by this clause would not be released again when exchange takes place.
When exchanging load modules which make use of the dynamic allocation of working storage, memory overflow errors can occur.
Programming program units with COBOL2000
The lifetime of the objects is limited to one program unit run. At the PEND call, all objects created in a program unit run are therefore released by the runtime system. This also applies in the case of PEND variants without a change of process.
Object references therefore cannot be preserved after the end of a program unit run in order to be passed on to follow-up program units. In other words, they cannot be preserved in UTM storage areas either.
All LLMs that contain, use or inherit COBOL2000 modules with class definitions must always be replaced together with the modified class definition. In other words, if a class definition changes, all users of this class and the classes derived from it and their users must be replaced together with the modified class definition.
Compiling COBOL program units
COBOL program units can be compiled with COBOL85 or COBOL2000 (see the "COBOL85 User Guide" or "COBOL2000 User Guide").
You must specify the following COMOPT parameter TRUNCATE-LITERAL=NO when compiling a UTM program unit. The COMOPT parameter TRUNCATE-LITERAL=NO is no longer described for COBOL85 as of V1.2. In the interests of compatibility, COBOL85 nevertheless still supports it. When compiling a UTM program unit with COBOL85, it continues to be mandatory to specify TRUNCATE-LITERAL=NO.
COBOL85 then issues a message informing you that the parameter does not conform to the ANS85 standard; this does not, however, affect the compiler run.
When compiling with COBOL2000 you must specify the COMOPT parameter MARK-LAST-PARAMETER=YES.
Using shareable code
If you are intending to load COBOL program units and make them shareable, you must specify the following option when compiling them:
*COMOPT GENERATE-SHARED-CODE=YES
The shareable code does not necessarily have to be stored in a separate object module: it can also be stored together with the non-shareable part in a link and load module (LLM), which is subdivided into a public slice and a private slice. To do this you must specify the compiler option
COMOPTGEN-LLM=YES.
The shareable program units only need to be loaded once for all tasks in the application(s). In the memory used locally by the task, all you then have to do is load the non-shareable parts.
openUTM offers a variety of ways of loading shareable objects:
as a non-privileged subsystem,
in a common memory pool in the user storage area (class 6 memory).
For further information on how to compile shareable code, refer to the manual for your compiler. The openUTM manual “Using UTM Applications on BS2000 Systems” provides a detailed explanation of how to link and load shareable code.
Generating formats with IFG
The manual “IFG for FHS” offers in-depth information on how to generate formats using the IFG. If these formats are to be generated for use in conjunction with openUTM, please note the following points:
The format name must not be more than 7 characters long.
In the user profile you must select "Structure of the data transfer area"
for #formats: separate attribute blocks and field contents
for *formats: non-aligned, without attribute fields
for +formats: non-aligned, with attribute fields
For * and + formats you declare two addressing aids, one each for input and output. You must also define a prefix for each addressing aid. The following example shows how addressing aids can be used:
LINKAGE SECTION. COPY KCKBC. 05 KBPROGAREA PIC X(100). COPY KCPAC. 03 NB-EINGABE. COPY IFORMA-LIB. 03 NB-AUSGABE. COPY OFORMA-LIB.where FORMA is the format name defined with IFG, I is the prefix for input and O the prefix for output. When using this format, you specify the format name for MPUT, FPUT or DPUT calls in the field KCMF as “*FORMA” (for addressing aids without attribute fields) and as “+FORMA” (for addressing aids with attribute fields).
When defining addressing aids, please note that, in the case of + and * formats, openUTM removes the transaction code from the message at the start of the service for MGETs and FGETs (unless an INPUT exit explicitly prevents it from doing so). If the first field in the format contains the transaction code, provision must be made for this in addressing aids for input formatting. The example below suggests one way of doing this for a *format or a +format:
LINKAGE SECTION. . COPY KCPAC. 03 NB. 05 TACA PIC X(002). 1) 05 TAC PIC X(008). 05 DATEN PIC X(220). 03 FILLER REDEFINES NB. COPY FORMA-LIB. . MOVE MGET TO KCOP. . IF KCKNZVG = "F" THEN CALL "KDCS" USING KCPAC, DATEN (Service start) ELSE CALL "KDCS" USING KCPAC, NB (During service) END-IF.
1) This field is mandatory for +formats but must be omitted for *formats.
When preparing to implement these addressing aids, the formats are to be stored in the formats library. This name should be specified in the FHS start parameters.
Extended line mode
The COPY element TIAMCTRC is available for work in extended line mode, but is not supplied with openUTM. This COPY member contains the data structure LINE-MODE-CONTROL-CHARACTERS with the symbolic names of the control characters. TIAMCTRC can be copied to the WORKING-STORAGE SECTION.