This section contains a few particularities that you should take into consideration when linking and starting UTM applications that are to be loaded into the upper address space of a XS system and that are to run in 31-bit mode. You will need to be familiar with XS programming and the use of XS.
openUTM only supports applications that:
are completely XS-compatible and run in 31-bit mode or
are not XS-compatible and are completely loaded in the lower address space (i.e. below 16 Mbyte) and run in 24-bit mode.
A UTM application can therefore only be loaded into the upper address space (>16 Mbyte) and run in 31-bit mode when all the components of the UTM application program are XS-compatible.
CAUTION!
UTM applications in “mixed mode” (i.e. applications that switch between 24-bit and 31-bit address modes) are not supported by openUTM. This means that openUTM cannot guarantee that a UTM application will run properly if a program unit that runs in 31-bit mode will dynamically load modules in 24-bit and switch to the appropriate address mode by itself when entering these modules, for example.
Compiling and linking
The following rules are to be observed when compiling and linking an XS-compatible UTM application:
All program units must be compiled with the attributes AMODE=ANY (addressing mode) and RMODE = ANY (resident mode).
When linking the UTM application, the binder checks the AMODE and RMODE attributes for all program units and sets a pseudo-RMODE for the object module of the UTM application created. The BINDER bases its setting on the “weakest” component, i.e. the module is only assigned the attribute RMODE=ANY when all components have the RMODE=ANY attribute. If a component was compiled with RMODE=24, the module is assigned RMODE=24.
The AMODE attribute is determined by the program section (CSECT) that contains the entry point of the object module.
You will find more information in the BS2000 manual “Dynamic Binder Loader / Starter”.
Particularities when starting a UTM application
Whether the UTM application is loaded into the upper or lower address space depends on the UTM application program itself and on the value of the PROGRAM-MODE parameter that you specified when calling the START-EXECUTABLE-PROGRAM command.
For PROGRAM-MODE=24 the application is loaded into the lower address space and the 24-bit mode is set.
For PROGRAM-MODE=ANY:
Whether the UTM application is loaded into the upper or lower address space and which addressing mode is set depends on the attributes AMODE and RMODE of the load module (see section "Compiling and linking").If the Binder-Loader System (BLS) detects at the start of the application that all components of the UTM application loaded at the start of the application are XS-compatible, then the UTM application is loaded into the upper address space.
If openUTM is to dynamically load a non-XS-compatible module in the start phase of an application loaded in the upper address space, then openUTM aborts the start procedure with an appropriate error message.
You should also note that no 24_bit modules (ONCALL) may be loaded dynamically during live operation by an application program that runs in the upper address space.
To ensure that a non-XS-compatible UTM application is loaded into the lower address space and runs in 24-bit mode, you need to add a MODIFY-SYMBOL-ATTRIBUTES statement with AMODE=24 when linking the UTM application.
Memory allocation of UTM applications
openUTM creates the application-specific tables and data areas (KAA, KTA, slots and UTM cache) in class 5 memory in the upper address space. Address space is therefore not taken away from UTM applications that run in the lower address space.
By means of MAX CACHE generation, the UTM cache can also be stored in one or more data spaces.
The KDCDEF, KDCDUMP and KDCUPD tools
The UTM tools KDCDEF, KDCDUMP and KDCUPD only run in the upper address space (> 16 MByte).