openUTM always uses a transaction code to call a program unit. However, the program unit is not loaded each time it is called, instead a program copy in virtual memory processes unrelated jobs in sequence. In practice this means that there may be a switch to another process following a PEND, with the result that the subsequent program unit runs in another process and may therefore be confronted by another data environment.
A UTM program unit must therefore be serially reusable, i.e. it must be a reentrant program:
program-specific data must be set to its initial status at the beginning of the program unit run
a program-specific data field may only be read if it has already been written in the same program unit run.
openUTM simplifies the programming of reentrant programs for you. It provides a special program unit-specific storage area (SPAB see "Standard primary working area (SPAB)") which is managed by openUTM. If you use this storage area for all variable data, openUTM automatically ensures that your programs are reentrant.
What this means for COBOL program units is that variables in the WORKING STORAGE SECTION must be installed again when calling the program unit, assuming they have been defined in an earlier program unit run. For C/C++ this applies to the variables with the storage class attribute static or extern and to those with an external connection (global module variables without a storage class attribute). For variables whose scope applies to more than one process (i.e. which lie in shared memory) at least write access to such variables must be serialized. However, the variables mentioned above can be used without restrictions for read-only access.
For C and C++, variables with the storage class attribute auto or register can be used without problems. They must, however, be defined before reading.