System integration

The architecture of openUTM on BS2000 systems is suited to the architecture of BS2000 systems and the openNetworking communication system.

openUTM can run without restrictions on systems with /390 architecture and on systems with x86 architecture.

UTM system code

The system code of a UTM application (the monitor) runs as part of the operating system primarily in privileged status (TPR) and uses central BS2000 and openNetworking functions.

The system code is protected by the operating system and is therefore secured against overwriting by program units.

The UTM system code is implemented as a separate subsystem (UTM) of the operating system. The system administrator can use DSSM to load this subsystem in the system memory.

The UTM system code calls the operating system functions via an adaptation module. Each version of openUTM includes adaptation modules for several BS2000 operating system versions: the correct module is loaded when the subsystem is started. This solution enables any version of openUTM to run on several operating system versions of BS2000. This also allows you to migrate your UTM applications to a later version of BS2000 operating system.

If a number of UTM applications exist in a BS2000 system, then the UTM system code is only loaded once in the BS2000 system. The entire UTM system code, including the UTM-D modules, is loaded as a subsystem of the BS2000 operating system. The system administrator uses statements for the UTM subsystem to define the time at which the UTM system code is to be loaded. If further UTM applications are started in the BS2000 system, these also use the system code already loaded. However, each UTM application is managed by openUTM using separate application tables, so that the UTM applications run fully independently of each other.

Subsystems and system functions used by the UTM system code

The UTM system code uses a range of internal system interfaces and subsystems:

• functions for requesting and releasing internal system storage areas (memory management)

• functions for job management and serialization (bourses)

• functions for managing the resources of an application (name manager)

• timer functions for monitoring resource utilization and time-driven messages

• functions of BS2000 subsystem management (DSSM) for loading and unloading the UTM system code and to start the UTM-SM2 subsystem when necessary

• data management system with the access methods UPAM and SAM

• BCAM for communicating with applications and communication partners

• VTSU for editing the messages to and from terminals

• SOC-TP when openUTM is to communicate with socket partners

• RSO (remote SPOOL output) for supporting RSO printers (see "BS2000-specific functions")

• OSS and CMX for distributed processing via OSI TP

• SAT for logging security-related UTM events

Running several versions of openUTM in parallel

It is possible to load several versions of openUTM in parallel and use them concurrently on the same BS2000 system.

This function offers considerable advantages, particularly when you are migrating to a new openUTM version. While an existing version is still being used, you can try out individual UTM applications on the successor version of openUTM. This means that you can perform step-by-step testing and migration of a number of UTM applications from one openUTM version to another on the same system.

Interfaces and components used by the main routine

In addition to the internal system interfaces, a UTM application in non-privileged processor state (TU) has interfaces to the format handling system FHS, to external resource managers such as data storage or database systems, and to the runtime systems of the programming languages used. The connections to these products are likewise technically separate and are implemented via neutral interfaces:

IUTMDB	Interface for coordination with external resource managers such as data storage or database systems. All resource managers that have an IUTMDB connection module are served in a uniform way via this interface (e.g. LEASY, SESAM or UDS).
XA	Interface to connect external resource managers such as Oracle. The XA interface is an X/Open standard.
IUTMFORM IUTMHLL	As an interface to the FHS formatting system. Uniform interface to the runtime systems of the individual programming languages.
ILCS	(Inter Language Communication Services) Interface to the language-independent runtime system CRTE (common runtime environment).

The program units access the functions via the program interfaces of openUTM, i.e. via theX/Open interfaces CPI-C and XATMI or via the KDCS interface (German standard).

UTM modules and utility programs as LLMs

The following components of openUTM are shipped as LLMs:

• UTM system modules

• UTM-ROOT code

• administration program

• all utility programs

• KDCUPD modules

This means that source corrections can be supplied if there is an error in a module. The module itself can then simply be replaced.

UTM utilities are loaded from a library when they are called.

You can find more information on UTM modules and utility programs in the openUTM manual “Generating Applications” and in the openUTM manual “Using UTM Applications on BS2000 Systems”.

Overview: Interfaces of openUTM

Figure 40: openUTM interfaces to other system components