A term in italic font means that it is explained somewhere else in the glossary.
abnormal termination of a UTM application
Termination of a UTM application, where the KDCFILE is not updated. Abnormal termination is caused by a serious error, such as a crashed computer or an error in the system software. If you then restart the application, openUTM carries out a warm start.
abstract syntax (OSI)
Abstract syntax is defined as the set of formally described data types which can be exchanged between applications via OSI TP. Abstract syntax is independent of the hardware and programming language used.
acceptor (CPI-C)
The communication partners in a conversation are referred to as the initiator and the acceptor. The acceptor accepts the conversation initiated by the initiator with Accept_Conversation.
access list
An access list defines the authorization for access to a particular service, TAC queue or USER queue. An access list is defined as a key set and contains one or more key codes, each of which represent a role in the application. Users or LTERMs or (OSI) LPAPs can only access the service or TAC queue/USER queue when the corresponding roles have been assigned to them (i.e. when their key set and the access list contain at least one common key code).
access point (OSI)
See service access point.
ACID properties
Acronym for the fundamental properties of transactions: atomicity, consistency, isolation and durability.
administration
Administration and control of a UTM application by an administrator or an administration program.
administration command
Commands used by the administrator of a UTM application to carry out administration functions for this application. The administration commands are implemented in the form of transaction codes.
administration journal
See cluster administration journal.
administration program
Program unit containing calls to the program interface for administration. This can be either the standard administration program KDCADM that is supplied with openUTM or a program written by the user.
administrator
User who possesses administration authorization.
AES
AES (Advanced Encryption Standard) is the current symmetric encryption standarddefined by the National Institute of Standards and Technology (NIST) and based on the Rijndael algorithm developed at the University of Leuven (Belgium). If the AES method is used, the UPIC client generates an AES key for each session.
Apache Axis
Apache Axis (Apache eXtensible Interaction System) is a SOAP engine for the design of Web services and client applications. There are implementations in C++ and Java.
Apache Tomcat
Apache Tomcat provides an environment for the execution of Java code on Web servers. It was developed as part of the Apache Software Foundation's Jakarta project. It consists of a servlet container written in Java which can use the JSP Jasper compiler to convert JavaServer pages into servlets and run them. It also provides a fully featured HTTP server.
application cold start
See cold start.
application context (OSI)
The application context is the set of rules designed to govern communication between two applications. This includes, for instance, abstract syntaxes and any assigned transfer syntaxes.
application entity (OSI)
An application entity (AE) represents all the aspects of a real application which are relevant to communications. An application entity is identified by a globally unique name (“globally” is used here in its literal sense, i.e. worldwide), the application entity title (AET). Every application entity represents precisely one application process. One application process can encompass several application entities.
application entity qualifier (OSI)
Component of the application entity title. The application entity qualifier identifies a service access point within an application. The structure of an application entity qualifier can vary. openUTM supports the type “number”.
application entity title (OSI)
An application entity title is a globally unique name for an application entity (“globally” is used here in its literal sense, i.e. worldwide). It is made up of the application process title of the relevant application process and the application entity qualifier.
application information
This is the entire set of data used by the UTM application. The information comprises memory areas and messages of the UTM application including the data currently shown on the screen. If operation of the UTM application is coordinated with a database system, the data stored in the database also forms part of the application information.
application process (OSI)
The application process represents an application in the OSI reference model. It is uniquely identified globally by the application process title.
application process title (OSI)
According to the OSI standard, the application process title (APT) is used for the unique identification of applications on a global (i.e. worldwide) basis. The structure of an application process title can vary. openUTM supports the type Object Identifier.
application program
An application program is the core component of a UTM application. It comprises the main routine KDCROOT and any program units and processes all jobs sent to a UTM application.
application restart
see warm start
application service element (OSI)
An application service element (ASE) represents a functional group of the application layer (layer 7) of the OSI reference model.
application warm start
see warm start.
association (OSI)
An association is a communication relationship between two application entities. The term “association” corresponds to the term session in LU6.1.
asynchronous conversation
CPI-C conversation where only the initiator is permitted to send. An asynchronous transaction code for the acceptor must have been generated in the UTM application.
asynchronous job
Job carried out by the job submitter at a later time. openUTM includes message queuing functions for processing asynchronous jobs (see UTM-controlled queue and service-controlled queue). An asynchronous job is described by the asynchronous message, the recipient and, where applicable, the required execution time. If the recipient is a terminal, a printer or a transport system application, the asynchronous job is a queued output job. If the recipient is an asynchronous service of the same application or a remote application, the job is a background job. Asynchronous jobs can be time-driven jobs or can be integrated in a job complex.
asynchronous message
Asynchronous messages are messages directed to a message queue. They are stored temporarily by the local UTM application and then further processed regardless of the job submitter. Distinctions are drawn between the following types of asynchronous messages, depending on the recipient:
In the case of asynchronous messages to a UTM-controlled queue, all further processing is controlled by openUTM. This type includes messages that start a local or remote asynchronous service (see also background job) and messages sent for output on a terminal, a printer or a transport system application (see also queued output job).
In the case of asynchronous messages to a service-controlled queue, further processing is controlled by a service of the application. This type includes messages to a TAC queue, messages to a USER queue and messages to a temporary queue. The USER queue and the temporary queue must belong to the local application, whereas the TAC queue can be in both the local application and the remote application.
asynchronous program
Program unit started by a background job.
asynchronous service (KDCS)
Service which processes a background job. Processing is carried out independently of the job submitter. An asynchronous service can comprise one or more program units/transactions. It is started via an asynchronous transaction code.
audit (BS2000 systems)
During execution of a UTM application, UTM events which are of relevance in terms of security can be logged by SAT for auditing purposes.
authentication
See system access control.
authorization
See data access control.
Axis
See Apache Axis.
background job
Background jobs are asynchronous jobs destined for an asynchronous service of the current application or of a remote application. Background jobs are particularly suitable for time-intensive processing or processing which is not time-critical and where the results do not directly influence the current dialog.
basic format
Format in which terminal users can make all entries required to start a service.
basic job
Asynchronous job in a job complex.
browsing asynchronous messages
A service sequentially reads the asynchronous messages in a service-controlled queue. The messages are not locked while they are being read and they remain in the queue after they have been read. This means that they can be read simultaneously by different services.
bypass mode (BS2000 systems)
Operating mode of a printer connected locally to a terminal. In bypass mode, any asynchronous message sent to the printer is sent to the terminal and then redirected to the printer by the terminal without being displayed on screen.
cache
Used for buffering application data for all the processes of a UTM application.
The cache is used to optimize access to the page pool and, in the case of UTM cluster applications, the cluster page pool.
CCR (Commitment, Concurrency and Recovery)
CCR is an Application Service Element (ASE) defined by OSI used for OSI TP communication which contains the protocol elements (services) related to the beginning and end (commit or rollback) of a transaction. CCR supports the two-phase commitment.
CCS name (BS2000 systems)
See coded character set name.
client
Clients of a UTM application can be:
terminals
UPIC client programs
transport system applications (e.g. DCAM, PDN, CMX, socket applications or UTM applications which have been generated as transport system applications).
Clients are connected to the UTM application via LTERM partners.
Note: UTM clients which use the OpenCPIC carrier system are treated just like OSI TP partners.
client side of a conversation
This term has been superseded by initiator.
cluster
A number of computers connected over a fast network and which in many cases can be seen as a single computer externally. The objective of clustering is generally to increase the computing capacity or availability in comparison with a single computer.
cluster administration journal
The cluster administration journal consists of:
two log files with the extensions JRN1 and JRN2 for global administration actions,
the JKAA file which contains a copy of the KDCS Application Area (KAA). Administrative changes that are no longer present in the two log files are taken over from this copy.
The administration journal files serve to pass on to the other node applications those administrative actions that are to apply throughout the cluster to all node applications in a UTM cluster application.
cluster configuration file
File containing the central configuration data of a UTM cluster application. The cluster configuration file is created using the UTM generation tool KDCDEF.
cluster filebase
Filename prefix or directory name for the UTM cluster files.
cluster GSSB file
File used to administer GSSBs in a UTM cluster application. The cluster GSSB file is created using the UTM generation tool KDCDEF.
cluster lock file
File in a UTM cluster application used to manage cross-node locks of user data areas.
cluster page pool
The cluster page pool consists of an administration file and up to 10 files containing a UTM cluster application’s user data that is available globally in the cluster (service data including LSSB, GSSB and ULS). The cluster page pool is created using the UTM generation tool KDCDEF.
cluster start serialization file
Lock file used to serialize the start-up of individual node applications (only on Unix, Linux and Windows systems).
cluster ULS file
File used to administer the ULS areas of a UTM cluster application. The cluster ULS file is created using the UTM generation tool KDCDEF.
cluster user file
File containing the user management data of a UTM cluster application. The cluster user file is created using the UTM generation tool KDCDEF.
coded character set name (BS2000 systems)
If the product XHCS (eXtended Host Code Support) is used, each character set used is uniquely identified by a coded character set name (abbreviation: “CCS name” or “CCSN”).
cold start
Start of a UTM application after the application terminates normally (normal termination) or after a new generation (see also warm start).
communication area (KDCS)
KDCS primary storage area, secured by transaction logging and which contains service-specific data. The communication area comprises 3 parts:
the KB header with general service data
the KB return area for returning values to KDCS calls
the KB program area for exchanging data between UTM program units within a single service.
communication end point
see transport system end point
communication resource manager
In distributed systems, communication resource managers (CRMs) control communication between the application programs. openUTM provides CRMs for the international OSI TP standard, for the LU6.1 industry standard and for the proprietary openUTM protocol UPIC.
configuration
Sum of all the properties of a UTM application. The configuration describes:
application parameters and operating parameters
the objects of an application and the properties of these objects. Objects can be program units and transaction codes, communication partners, printers, user IDs, etc.
defined measures for controlling data and system access.
The configuration of a UTM application is defined at generation time (static configuration) and can be changed dynamically by the administrator (while the application is running, dynamic configuration). The configuration is stored in the KDCFILE.
confirmation job
Component of a job complex where the confirmation job is assigned to the basic job. There are positive and negative confirmation jobs. If the basic job returns a positive result, the positive confirmation job is activated, otherwise, the negative confirmation job is activated.
connection bundle
see LTERM bundle.
connection user ID
User ID under which a TS application or a UPIC client is signed on at the UTM application directly after the connection has been established. The following applies, depending on the client (= LTERM partner) generation:
The connection user ID is the same as the USER in the LTERM statement (explicit connection user ID). An explicit connection user ID must be generated with a USER statement and cannot be used as a “genuine” user ID.
The connection user ID is the same as the LTERM partner (implicit connection user ID) if no USER was specified in the LTERM statement or if an LTERM pool has been generated.
In a UTM cluster application, the service belonging to a connection user ID (RESTART=YES in LTERM or USER) is bound to the connection and is therefore local to the node.
A connection user ID generated with RESTART=YES can have a separate service in each node application.
contention loser
Every connection between two partners is managed by one of the partners. The partner that manages the connection is known as the contention winner. The other partner is the contention loser.
contention winner
A connection's contention winner is responsible for managing the connection. Jobs can be started by the contention winner or by the contention loser. If a conflict occurs, i.e. if both partners in the communication want to start a job at the same time, then the job stemming from the contention winner uses the connection.
conversation
In CPI-C, communication between two CPI-C application programs is referred to as a conversation. The communication partners in a conversation are referred to as the initiator and the acceptor.
conversation ID
CPI-C assigns a local conversation ID to each conversation, i.e. the initiator and acceptor each have their own conversation ID. The conversation ID uniquely assigns each CPI-C call in a program to a conversation.
CPI-C
CPI-C (Common Programming Interface for Communication) is a program interface for program-to-program communication in open networks standardized by X/Open and CIW (CPI-C Implementor's Workshop).
The CPI-C implemented in openUTM complies with X/Open’s CPI-C V2.0 CAE Specification. The interface is available in COBOL and C. In openUTM, CPI-C can communicate via the OSI TP, LU6.1 and UPIC protocols and with openUTM-LU62.
Cross Coupled System / XCS
Cluster of BS2000 computers with the Highly Integrated System Complex Multiple System Control Facility (HIPLEX® MSCF).
data access control
In data access control openUTM checks whether the communication partner is authorized to access a particular object belonging to the application. The access rights are defined as part of the configuration.
data space (BS2000 systems)
Virtual address space of BS2000 which can be employed in its entirety by the user. Only data and programs stored as data can be addressed in a data space; no program code can be executed.
dead letter queue
The dead letter queue is a TAC queue which has the fixed name KDCDLETQ.
It is always available to save queued messages sent to transaction codes, TAC queues, LPAP or OSI-LPAP partners but which could not be processed. The saving of queued messages in the dead letter queue can be activated or deactivated for each message destination individually using the TAC, LPAP or OSI-LPAP statement's DEAD-LETTER-Q parameter.
DES
DES (Data Encryption Standard) is an international standard for encrypting data. One key is used in this method for encoding and decoding. If the DES method is used, the UPIC client generates a DES key for each session.
dialog conversation
CPI-C conversation in which both the initiator and the acceptor are permitted to send. A dialog transaction code for the acceptor must have been generated in the UTM application.
dialog job, interactive job
Job which starts a dialog service. The job can be issued by a client or, when two servers communicate with each other (server-server communication), by a different application.
dialog message
A message which requires a response or which is itself a response to a request. The request and the response both take place within a single service. The request and reply together form a dialog step.
dialog program
Program unit which partially or completely processes a dialog step.
dialog service
Service which processes a job interactively (synchronously) in conjunction with the job submitter (client or another server application) . A dialog service processes dialog messages received from the job submitter and generates dialog messages to be sent to the job submitter. A dialog service comprises at least one transaction. In general, a dialog service encompasses at least one dialog step. Exception: in the event of service chaining, it is possible for more than one service to comprise a dialog step.
dialog step
A dialog step starts when a dialog message is received by the UTM application. It ends when the UTM application responds.
dialog terminal process (Unix , Linux and Windows systems)
A dialog terminal process connects a terminal of a Unix, Linux or Windows system with the work processes of the UTM application. Dialog terminal processes are started either when the user enters utmdtp or via the LOGIN shell. A separate dialog terminal process is required for each terminal to be connected to a UTM application.
distributed processing
Processing of dialog jobs by several different applications or the transfer of background jobs to another application. The higher-level protocols LU6.1 and OSI TP are used for distributed processing. openUTM-LU62 also permits distributed processing with LU6.2 partners. A distinction is made between distributed processing with distributed transactions (transaction logging across different applications) and distributed processing without distributed transactions (local transaction logging only). Distributed processing is also known as server-server communication.
distributed transaction
Transaction which encompasses more than one application and is executed in several different (sub-)transactions in distributed systems.
distributed transaction processing
Distributed processing with distributed transactions.
dynamic configuration
Changes to the configuration made by the administrator. UTM objects such as program units, transaction codes, clients, LU6.1 connections, printers or user IDs can be added, modified or in some cases deleted from the configuration while the application is running. To do this, it is necessary to create separate administration programs which use the functions of the program interface for administration. The WinAdmin administration program or the WebAdmin administration program can be used to do this, or separate administration programs must be created that utilize the functions of the administration program interface.
encryption level
The encryption level specifies if and to what extent a client message and password are to be encrypted.
event-driven service
This term has been superseded by event service.
event exit
Routine in an application program which is started automatically whenever certain events occur (e.g. when a process is started, when a service is terminated). Unlike event services, an event exit must not contain any KDCS, CPI-C or XATMI calls.
event function
Collective term for event exits and event services.
event service
Service started when certain events occur, e.g. when certain UTM messages are issued. The program units for event-driven services must contain KDCS calls.
filebase
UTM application filebase
On BS2000 systems, filebase is the prefix for the KDCFILE, the user log file USLOG and the system log file SYSLOG.
On Unix, Linux and Windows systems, filebase is the name of the directory under which the KDCFILE, the user log file USLOG, the system log file SYSLOG and other files relating to the UTM application are stored.
Functional Unit (FU)
A subset of the OSI TP protocol providing a particular functionality. The OSI TP protocol is divided into the following functional units:
Dialog
Shared Control
Polarized Control
Handshake
Commit
Chained Transactions
Unchained Transactions
Recovery
Manufacturers implementing OSI TP need not include all functional units, but can concentrate on a subset instead. Communications between applications of two different OSI TP implementations is only possible if the included functional units are compatible with each other.
generation
See UTM generation.
global secondary storage area
See secondary storage area.
hardcopy mode
Operating mode of a printer connected locally to a terminal. Any message which is displayed on screen will also be sent to the printer.
heterogeneous link
In the case of server-server communication: a link between a UTM application and a non-UTM application, e.g. a CICS or TUXEDO application.
Highly Integrated System Complex / HIPLEX ®
Product family for implementing an operating, load sharing and availability cluster made up of a number of BS2000 servers.
HIPLEX ® MSCF
(MSCF = Multiple System Control Facility)
Provides the infrastructure and basic functions for distributed applications with HIPLEX®.
homogeneous link
In the case of server-server communication: a link between two UTM applications. It is of no significance whether the applications are running on the same operating system platforms or on different platforms.
inbound conversation (CPI-C)
See incoming conversation.
incoming conversation (CPI-C)
A conversation in which the local CPI-C program is the acceptor is referred to as an incoming conversation. In the X/Open specification, the term “inbound conversation” is used synonymously with “incoming conversation”.
initial KDCFILE
In a UTM cluster application, this is the KDCFILE generated by KDCDEF and which must be copied for each node application before the node applications are started.
initiator (CPI-C)
The communication partners in a conversation are referred to as the initiator and the acceptor. The initiator sets up the conversation with the CPI-C calls Initialize_Conversation and Allocate.
insert
Field in a message text in which openUTM enters current values.
inverse KDCDEF
A function which uses the dynamically adapted configuration data in the KDCFILE to generate control statements for a KDCDEF run. An inverse KDCDEF can be started “offline” under KDCDEF or “online” via the program interface for administration.
IUTMDB
Interface used for the coordinated interaction with resource managers on BS2000 systems. This includes data repositories (LEASY) and data base systems (SESAM/SQL, UDS/SQL).
JConnect client
Designation for clients based on the product openUTM-JConnect. The communication with the UTM application is carried out via the UPIC protocol .
JDK
Java Development Kit
Standard development environment from Oracle Corporation for the development of Java applications.
job
Request for a service provided by a UTM application. The request is issued by specifying a transaction code. See also: queued output job, dialog job, background job, job complex.
job complex
Job complexes are used to assign confirmation jobs to asynchronous jobs. An asynchronous job within a job complex is referred to as a basic job.
job-receiving service (KDCS)
A job-receiving service is a service started by a job-submitting service of another server application.
job-submitting service (KDCS)
A job-submitting service is a service which requests another service from a different server application (job-receiving service) in order to process a job.
KDCADM
Standard administration program supplied with openUTM. KDCADM provides administration functions which are called with transaction codes (administration commands).
KDCDEF
UTM tool for the generation of UTM applications. KDCDEF uses the configuration information in the KDCDEF control statements to create the UTM objects KDC FILE and the ROOT table sources for the main routine KDCROOT.
In UTM cluster applications, KDCDEF also creates the cluster configuration file, the cluster user file, the cluster page pool, the cluster GSSB file and the cluster ULS file.
KDCFILE
One or more files containing data required for a UTM application to run. The KDCFILE is created with the UTM generation tool KDCDEF. Among other things, it contains the configuration of the application.
KDCROOT
Main routine of an application program which forms the link between the program units and the UTM system code. KDCROOT is linked with the program units to form the application program.
KDCS message area
For KDCS calls: buffer area in which messages or data for openUTM or for the program unit are made available.
KDCS parameter area
See parameter area.
KDCS program interface
Universal UTM program interface compliant with the national DIN 66 265 standard and which includes some extensions. KDCS (compatible data communications interface) allows dialog services to be created, for instance, and permits the use of message queuing functions. In addition, KDCS provides calls for distributed processing.
Kerberos
Kerberos is a standardized network authentication protocol (RFC1510) based on encryption procedures in which no passwords are sent to the network in clear text.
Kerberos principal
Owner of a key.
Kerberos uses symmetrical encryption, i.e. all the keys are present at two locations, namely with the key owner (principal) and the KDC (Key Distribution Center).
key code
Code that represents specific access authorization or a specific role. Several key codes are grouped into a key set .
key set
Group of one or more key codes under a particular a name. A key set defines authorization within the framework of the authorization concept used (lock/key code concept or access list concept). A key set can be assigned to a user ID , an LTERM partner an (OSI) LPAP partner , a service or a TAC queue.
linkage program
See KDCROOT.
local secondary storage area
See secondary storage area.
Log4j
Log4j is part of the Apache Jakarta project. Log4j provides information for logging information (runtime information, trace records, etc.) and configuring the log output. WS4UTM uses the software product Log4j for trace and logging functionality.
lock code
Code protecting an LTERM partner or transaction code against unauthorized access. Access is only possible if the key set of the accesser contains the appropriate key code (lock/key code concept).
logging process
Process in Unix, Linux and Windows systems that controls the logging of account records or monitoring data.
LPAP bundle
LPAP bundles allow messages to be distributed to LPAP partners across several partner applications. If a UTM application has to exchange a very large number of messages with a partner application then load distribution may be improved by starting multiple instances of the partner application and distributing the messages across the individual instances. In an LPAP bundle, openUTM is responsible for distributing the messages to the partner application instances. An LPAP bundle consists of a master LPAP and multiple slave LPAPs. The slave LPAPs are assigned to the master LPAP on UTM generation. LPAP bundles exist for both the OSI TP protocol and the LU6.1 protocol.
LPAP partner
In the case of distributed processing via the LU6.1 protocol, an LPAP partner for each partner application must be configured in the local application. The LPAP partner represents the partner application in the local application. During communication, the partner application is addressed by the name of the assigned LPAP partner and not by the application name or address.
LTERM bundle
An LTERM bundle (connection bundle) consists of a master LTERM and multiple slave LTERMs. An LTERM bundle (connection bundle) allows you to distribute queued messages to a logical partner application evenly across multiple parallel connections.
LTERM group
An LTERM group consists of one or more alias LTERMs, the group LTERMs and a primary LTERM. In an LTERM group, you assign multiple LTERMs to a connection.
LTERM partner
LTERM partners must be configured in the application if you want to connect clients or printers to a UTM application. A client or printer can only be connected if an LTERM partner with the appropriate properties is assigned to it. This assignment is generally made in the configuration, but can also be made dynamically using terminal pools.
LTERM pool
The TPOOL statement allows you to define a pool of LTERM partners instead of issuing one LTERM and one PTERM statement for each client. If a client establishes a connection via an LTERM pool, an LTERM partner is assigned to it dynamically from the pool.
LU6.1
Device-independent data exchange protocol (industrial standard) for transaction-oriented server-server communication.
LU6.1-LPAP bundle
LPAP bundle for LU6.1 partner applications.
LU6.1 partner
Partner of the UTM application that communicates with the UTM application via the LU6.1 protocol.
Examples of this type of partner are:
a UTM application that communicates via LU6.1
an application in the IBM environment (e.g. CICS, IMS or TXSeries) that communicates via LU6.1
main process (Unix /Linux / Windows systems)
Process which starts the UTM application. It starts the work processes, the UTM system processes, printer processes, network processes, logging process and the timer process and monitors the UTM application.
main routine KDCROOT
See KDCROOT.
management unit
SE Servers component; in combination with the SE Manager, permits centralized, web-based management of all the units of an SE server.
message definition file
The message definition file is supplied with openUTM and, by default, contains the UTM message texts in German and English together with the definitions of the message properties. Users can take this file as a basis for their own message modules.
message destination
Output medium for a message. Possible message destinations for a message from the openUTM transaction monitor include, for instance, terminals, TS applications, the event service MSGTAC, the system log file SYSLOG or TAC queues, asynchronous TACs, USER queues, SYSOUT/SYSLST or stderr/stdout.
The message destinations for the messages of the UTM tools are SYSOUT/SYSLST and stderr/stdout.
message queue
Queue in which specific messages are kept with transaction management until further processed. A distinction is drawn between service-controlled queues and UTM-controlled queues, depending on who monitors further processing.
message queuing
Message queuing (MQ) is a form of communication in which the messages are exchanged via intermediate queues rather than directly. The sender and recipient can be separated in space or time. The transfer of the message is independent of whether a network connection is available at the time or not. In openUTM there are UTM-controlled queues and service-controlled queues.
message segment
The KDCS interface makes it possible to structure messages by means of individual messages segments, which are then transmitted to the communication partner as a whole message.
MSGTAC
Special event service that processes messages with the message destination MSGTAC by means of a program. MSGTAC is an asynchronous service and is created by the operator of the application.
multiplex connection (BS2000 systems)
Special method offered by OMNIS to connect terminals to a UTM application. A multiplex connection enables several terminals to share a single transport connection.
multi-step service (KDCS)
Service carried out in a number of dialog steps.
multi-step transaction
Transaction which comprises more than one processing step.
Network File System/Service / NFS
Allows Unix systems to access file systems across the network.
network process (Unix / Linux / Windows systems)
A process in a UTM application for connection to the network.
network selector
The network selector identifies a service access point to the network layer of the OSI reference model in the local system.
node
Individual computer of a cluster.
node application
UTM application that is executed on an individual node as part of a UTM cluster application.
node bound service
A node bound service belonging to a user can only be continued at the node application at which the user was last signed on. The following services are always node bound:
Services that have started communications with a job receiver via LU6.1 or OSI TP and for which the job-receiving service has not yet been terminated
Inserted services in a service stack
Services that have completed a SESAM transaction
In addition, a user’s service is node bound as long as the user is signed-on at a node application.
node filebase
Filename prefix or directory name for the node application's KDCFILE, user log file and system log file.
node recovery
If a node application terminates abnormally and no rapid warm start of the application is possible on its associated node computer then it is possible to perform a node recovery for this node on another node in the UTM cluster. In this way, it is possible to release locks resulting from the failed node application in order to prevent unnecessary impairments to the running UTM cluster application.
normal termination of a UTM application
Controlled termination of a UTM application. Among other things, this means that the administration data in the KDCFILE are updated. The administrator initiates normal termination (e.g. with KDCSHUT N). After a normal termination, openUTM carries out any subsequent start as a cold start.
object identifier
An object identifier is an identifier for objects in an OSI environment which is unique throughout the world. An object identifier comprises a sequence of integers which represent a path in a tree structure.
OMNIS (BS2000 systems)
OMNIS is a “session manager” which lets you set up connections from one terminal to a number of partners in a network concurrently OMNIS also allows you to work with multiplex connections.
online import
In a UTM cluster application, online import refers to the import of application data from a normally terminated node application into a running node application.
online update
In a UTM cluster application, online update refers to a change to the application configuration or the application program or the use of a new UTM revision level while a UTM cluster application is running.
open terminal pool
Terminal pool which is not restricted to clients of a single computer or particular type. Any client for which no computer- or type-specific terminal pool has been generated can connect to this terminal pool.
OpenCPIC
Carrier system for UTM clients that use the OSI TP protocol.
OpenCPIC client
OSI TP partner application with the OpenCPIC carrier system.
openSM2
The openSM2 product line offers a consistent solution for the enterprise-wide performance management of server and storage systems. openSM2 offers the acquisition of monitoring data, online monitoring and offline evaluation.
openUTM cluster
From the perspective of UPIC clients, not from the perspective of the server:Combination of several node applications of a UTM cluster application to form one logical application that is addressed via a common symbolic destination name.
openUTM-D
openUTM-D (openUTM distributed) is a component of openUTM which allows distributed processing. openUTM-D is an integral component of openUTM.
OSI-LPAP bundle
LPAP bundle for OSI TP partner applications.
OSI-LPAP partner
OSI-LPAP partners are the addresses of the OSI TP partners generated in openUTM. In the case of distributed processing via the OSI TP protocol, an OSI-LPAP partner for each partner application must be configured in the local application. The OSI-LPAP partner represents the partner application in the local application. During communication, the partner application is addressed by the name of the assigned OSI-LPAP partner and not by the application name or address.
OSI reference model
The OSI reference model provides a framework for standardizing communications in open systems. ISO, the International Organization for Standardization, described this model in the ISO IS7498 standard. The OSI reference model divides the necessary functions for system communication into seven logical layers. These layers have clearly defined interfaces to the neighboring layers.
OSI TP
Communication protocol for distributed transaction processing defined by ISO.
OSI TP stands for Open System Interconnection Transaction Processing.
OSI TP partner
Partner of the UTM application that communicates with the UTM application via the OSI TP protocol.
Examples of such partners are:
a UTM application that communicates via OSI TP
an application in the IBM environment (e.g. CICS) that is connected via openUTM-LU62
an OpenCPIC client
applications from other TP monitors that support OSI TP
outbound conversation (CPI-C)
See outgoing conversation.
outgoing conversation (CPI-C)
A conversation in which the local CPI-C program is the initiator is referred to as an outgoing conversation. In the X/Open specification, the term “outbound conversation” is used synonymously with “outgoing conversation”.
page pool
Part of the KDCFILE in which user data is stored.
In a standalone application this data consists, for example, of dialog messages, messages sent to message queues, secondary memory areas.
In a UTM cluster application, it consists, for example, of messages to message queues, TLS.
parameter area
Data structure in which a program unit passes the operands required for a UTM call to openUTM.
partner application
Partner of a UTM application during distributed processing. Higher communication protocols are used for distributed processing (LU6.1, OSI TP or LU6.2 via the openUTM-LU62 gateway).
postselection (BS2000 systems)
Selection of logged UTM events from the SAT logging file which are to be evaluated. Selection is carried out using the SATUT tool.
prepare to commit (PTC)
Specific state of a distributed transaction
Although the end of the distributed transaction has been initiated, the system waits for the partner to confirm the end of the transaction.
preselection (BS2000 systems)
Definition of the UTM events which are to be logged for the SAT audit. Preselection is carried out with the UTM-SAT administration functions. A distinction is made between event-specific, user-specific and job-specific (TAC-specific) preselection.
presentation selector
The presentation selector identifies a service access point to the presentation layer of the OSI reference model in the local system.
primary storage area
Area in main memory to which the KDCS program unit has direct access, e.g. standard primary working area, communication area.
print administration
Functions for print control and the administration of queued output jobs, sent to a printer.
print control
openUTM functions for controlling print output.
printer control LTERM
A printer control LTERM allows a client or terminal user to connect to a UTM application. The printers assigned to the printer control LTERM can then be administered from the client program or the terminal. No administration rights are required for these functions.
printer control terminal
This term has been superseded by printer control LTERM.
printer group (Unix systems)
For each printer, a Unix system sets up one printer group by default that contains this one printer only. It is also possible to assign several printers to one printer group or to assign one printer to several different printer groups.
printer pool
Several printers assigned to the same LTERM partner.
printer process (Unix / Linux systems)
Process set up by the main process for outputting asynchronous messages to a printer group . The process exists as long as the printer group is connected to the UTM application. One printer process exists for each connected printer group.
process
The openUTM manuals use the term “process” as a collective term for processes (Unix / Linux / Windows systems) and tasks (BS2000 systems).
processing step
A processing step starts with the receipt of a dialog message sent to the UTM application by a client or another server application. The processing step ends either when a response is sent, thus also terminating the dialog step, or when a dialog message is sent to a third party.
program interface for administration
UTM program interface which helps users to create their own administration programs. Among other things, the program interface for administration provides functions for dynamic configuration, for modifying properties and application parameters and for querying information on the configuration and the current workload of the application.
program space (BS2000 systems)
Virtual address space of BS2000 which is divided into memory classes and in which both executable programs and pure data are addressed.
program unit
UTM services are implemented in the form of one or more program units. The program units are components of the application program. Depending on the employed API, they may have to contain KDCS, XATMI or CPIC calls. They can be addressed using transaction codes. Several different transaction codes can be assigned to a single program unit.
queue
See message queue.
queued output job
Queued output jobs are asynchronous jobs which output a message, such as a document, to a printer, a terminal or a transport system application.
Queued output jobs are processed by UTM system functions exclusively, i.e. it is not necessary to create program units to process them.
Quick Start Kit
A sample application supplied with openUTM (Windows systems).
redelivery
Repeated delivery of an asynchronous message that could not be processed correctly because, for example, the transaction was rolled back or the asynchronous service was terminated abnormally. The message is returned to the message queue and can then be read and/or processed again.
reentrant program
Program whose code is not altered when it runs. On BS2000 systems this constitutes a prerequisite for using shared code.
request
Request from a client or another server for a service function.
requestor
In XATMI, the term requestor refers to an application which calls a service.
resource manager
Resource managers (RMs) manage data resources. Database systems are examples of resource managers. openUTM, however, also provides its own resource managers for accessing message queues, local memory areas and logging files, for instance. Applications access RMs via special resource manager interfaces. In the case of database systems, this will generally be SQL and in the case of openUTM RMs, it is the KDCS interface.
restart
See screen restart.
see service restart.
RFC1006
A protocol defined by the IETF (Internet Engineering Task Force) belonging to the TCP/IP family that implements the ISO transport services (transport class 0) based on TCP/IP.
RSA
Abbreviation for the inventors of the RSA encryption method (Rivest, Shamir and Adleman). This method uses a pair of keys that consists of a public key and a private key. A message is encrypted using the public key, and this message can only be decrypted using the private key. The pair of RSA keys is created by the UTM application.
SAT audit (BS2000 systems)
Audit carried out by the SAT (Security Audit Trail) component of the BS2000 software product SECOS.
screen restart
If a dialog service is interrupted, openUTM again displays the dialog message of the last completed transaction on screen when the service restarts provided that the last transaction output a message on the screen.
SE manager
Web-based graphical user interface (GUI) for the SE series of Business Servers. SE Manager runs on the management unit and permits the central operation and administration of server units (with /390 architecture and/or x86 architecture), application units (x86 architecture), net unit and peripherals.
SE server
A Business Server from Fujitsu's SE series.
secondary storage area
Memory area secured by transaction logging and which can be accessed by the KDCS program unit with special calls. Local secondary storage areas (LSSBs) are assigned to one service. Global secondary storage areas (GSSBs) can be accessed by all services in a UTM application. Other secondary storage areas include the terminal-specific long-term storage (TLS) and the user-specific long-term storage (ULS) .
selector
A selector identifies a service access point to services of one of the layers of the OSI reference model in the local system. Each selector is part of the address of the access point.
semaphore (Unix / Linux / Windows systems)
Unix, Linux and Windows systems resource used to control and synchronize processes.
server
A server is an application which provides services . The computer on which the applications are running is often also referred to as the server.
server-server communication
See distributed processing.
server side of a conversation (CPI-C)
This term has been superseded by acceptor.
service
Services process the jobs that are sent to a server application. A service of a UTM application comprises one or more transactions. The service is called with the service TAC. Services can be requested by clients or by other servers.
service access point
In the OSI reference model, a layer has access to the services of the layer below at the service access point. In the local system, the service access point is identified by a selector. During communication, the UTM application links up to a service access point. A connection is established between two service access points.
service chaining (KDCS)
When service chaining is used, a follow-up service is started without a dialog message specification after a dialog service has completed.
service-controlled queue
Message queue in which the calling and further processing of messages is controlled by services. A service must explicitly issue a KDCS call (DGET) to read the message. There are service-controlled queues in openUTM in the variants USER queue, TAC queue and temporary queue.
service restart (KDCS)
If a service is interrupted, e.g. as a result of a terminal user signing off or a UTM application being terminated, openUTM carries out a service restart. An asynchronous service is restarted or execution is continued at the most recent synchronization point, and a dialog service continues execution at the most recent synchronization point. As far as the terminal user is concerned, the service restart for a dialog service appears as a screen restart provided that a dialog message was sent to the terminal user at the last synchronization point.
service routine
See program unit.
service stacking (KDCS)
A terminal user can interrupt a running dialog service and insert a new dialog service. When the inserted service has completed, the interrupted service continues.
service TAC (KDCS)
Transaction code used to start a service .
session
Communication relationship between two addressable units in the network via the SNA protocol LU6.1 .
session selector
The session selector identifies an access point in the local system to the services of the session layer of the OSI reference model.
shared code (BS2000 systems)
Code which can be shared by several different processes.
shared memory
Virtual memory area which can be accessed by several different processes simultaneously.
shared objects (Unix / Linux / Windows systems)
Parts of the application program can be created as shared objects. These objects are linked to the application dynamically and can be replaced during live operation. Shared objects are defined with the KDCDEF statement SHARED-OBJECT.
sign-on check
See system access control.
sign-on service (KDCS)
Special dialog service for a user in which program units control how a user signs on to a UTM application.
single-step service
Dialog service which encompasses precisely one dialog step.
single-step transaction
Transaction which encompasses precisely one dialog step.
SOA
(Service-Oriented Architecture)
SOA is a system architecture concept in which functions are implemented in the form of re-usable, technically independent, loosely coupled services. Services can be called independently of the underlying implementations via interfaces which may possess public and, consequently, trusted specifications. Service interaction is performed via a communication infrastructure made available for this purpose.
SOAP
SOAP (Simple Object Access Protocol) is a protocol used to exchange data between systems and run remote procedure calls. SOAP also makes use of the services provided by other standards, XML for the representation of the data and Internet transport and application layer protocols for message transfer.
socket connection
Transport system connection that uses the socket interface. The socket interface is a standard program interface for communication via TCP/IP.
standalone application
See standalone UTM application.
standalone UTM application
Traditional UTM application that is not part of a UTM cluster application.
standard primary working area (KDCS)
Area in main memory available to all KDCS program units. The contents of the area are either undefined or occupied with a fill character when the program unit starts execution.
start format
Format output to a terminal by openUTM when a user has successfully signed on to a UTM application (except after a service restart and during sign-on via the sign-on service).
static configuration
Definition of the configuration during generation using the UTM tool KDCDEF.
SYSLOG file
See system log file.
synchronization point, consistency point
The end of a transaction. At this time, all the changes made to the application information during the transaction are saved to prevent loss in the event of a crash and are made visible to others. Any locks set during the transaction are released.
system access control
A check carried out by openUTM to determine whether a certain user ID is authorized to work with the UTM application. The authorization check is not carried out if the UTM application was generated without user IDs.
system log file
File or file generation to which openUTM logs all UTM messages for which SYSLOG has been defined as the message destination during execution of a UTM application.
TAC
See transaction code.
TAC queue
Message queue generated explicitly by means of a KDCDEF statement. A TAC queue is a service-controlled queue that can be addressed from any service using the generated name.
temporary queue
Message queue created dynamically by means of a program that can be deleted again by means of a program (see service-controlled queue).
terminal-specific long-term storage (KDCS)
Secondary storage area assigned to an LTERM, LPAP or OSI-PAP partner and which is retained after the application has terminated.
time-driven job
Job which is buffered by openUTM in a message queue up to a specific time until it is sent to the recipient. The recipient can be an asynchronous service of the same application, a TAC queue, a partner application, a terminal or a printer. Time-driven jobs can only be issued by KDCS program units.
timer process (Unix / Linux / Windows systems)
Process which accepts jobs for controlling the time at which work processes are executed. It does this by entering them in a job list and releasing them for processing after a time period defined in the job list has elapsed.
TLS termination proxy
A TLS termination proxy is a proxy server that is used to handle incoming TLS connections, decrypting the data and passing on the unencrypted request to other servers.
TNS (Unix / Linux / Windows systems)
Abbreviation for the Transport Name Service. TNS assigns a transport selector and a transport system to an application name. The application can be reached through the transport system.
Tomcat
see Apache Tomcat
transaction
Processing section within a service for which adherence to the ACID properties is guaranteed. If, during the course of a transaction, changes are made to the application information, they are either made consistently and in their entirety or not at all (all-or-nothing rule). The end of the transaction forms a synchronization point.
transaction code/TAC
Name which can be used to identify a program unit. The transaction code is assigned to the program unit during static or dynamic configuration. It is also possible to assign more than one transaction code to a program unit.
transaction rate
Number of transactions successfully executed per unit of time.
transfer syntax
With OSI TP, the data to be transferred between two computer systems is converted from the local format into transfer syntax. Transfer syntax describes the data in a neutral format which can be interpreted by all the partners involved. An Object Identifier must be assigned to each transfer syntax.
transport connection
In the OSI reference model, this is a connection between two entities of layer 4 (transport layer).
transport layer security
Transport layer security is a hybrid encryption protocol for secure data transmission in the Internet.
transport selector
The transport selector identifies a service access point to the transport layer of the OSI reference model in the local system.
transport system access point
See transport system end point.
transport system application
Application which is based directly on a transport system interface (e.g. CMX, DCAM or socket). When transport system applications are connected, the partner type APPLI or SOCKET must be specified during configuration. A transport system application cannot be integrated in a distributed transaction.
transport system end point
Client/server or server/server communication establishes a connection between two transport system end points. A transport system end point is also referred to as a local application name and is defined using the BCAMAPPL statement or MAX APPLINAME.
TS application
See transport system application.
typed buffer (XATMI)
Buffer for exchanging typed and structured data between communication partners. Typed buffers ensure that the structure of the exchanged data is known to both partners implicitly.
UPIC
Carrier system for openUTM clients. UPIC stands for Universal Programming Interface for Communication. The communication with the UTM application is carried out via the UPIC protocol.
UPIC Analyzer
Component used to analyze the UPIC communication recorded with UPIC Capture. This step is used to prepare the recording for playback using UPIC Replay.
UPIC Capture
Used to record communication between UPIC clients and UTM applications so that this can be replayed subsequently (UPIC Replay).
UPIC client
The designation for openUTM clients with the UPIC carrier system and for JConnect clients.
UPIC protocol
Protocol for the client server communication with UTM applications. The UPIC protocol is used by UPIC clients and JConnect clients.
UPIC Replay
Component used to replay the UPIC communication recorded with UPIC Capture and prepared with UPIC Analyzer.
user exit
This term has been superseded by event exit.
user ID
Identifier for a user defined in the configuration for the UTM application (with an optional password for system access control) and to whom special data access rights (system access control) have been assigned. A terminal user must specify this ID (and any password which has been assigned) when signing on to the UTM application. On BS2000 systems, system access control is also possible via Kerberos.
For other clients, the specification of a user ID is optional, see also connection user ID.
UTM applications can also be generated without user IDs.
user log file
File or file generation to which users write variable-length records with the KDCS LPUT call. The data from the KB header of the KDCS communication area is prefixed to every record. The user log file is subject to transaction management by openUTM.
USER queue
Message queue made available to every user ID by openUTM. A USER queue is a service-controlled queue and is always assigned to the relevant user ID. You can restrict the access of other UTM users to your own USER queue.
user-specific long-term storage
Secondary storage area assigned to a user ID, a session or an association and which is retained after the application has terminated.
USLOG file
See user log file.
UTM application
A UTM application provides services which process jobs from clients or other applications. openUTM is responsible for transaction logging and for managing the communication and system resources. From a technical point of view, a UTM application is a process group which forms a logical server unit at runtime.
UTM client
See client.
UTM cluster application
UTM application that has been generated for use on a cluster and that can be viewed logically as a single application.
In physical terms, a UTM cluster application is made up of several identically generated UTM applications running on the individual cluster nodes.
UTM cluster files
Blanket term for all the files that are required for the execution of a UTM cluster application on Unix, Linux and Windows systems. This includes the following files:
Cluster configuration file
Cluster user file
Files belonging to the cluster page pool
Cluster GSSB file
Cluster ULS file
Files belonging to the cluster administration journal*
Cluster lock file*
Lock file for start serialization*
The files indicated by * are created when the first node application is started. All the other files are created on generation using KDCDEF.
UTM-controlled queue
Message queues in which the calling and further processing of messages is entirely under the control of openUTM. See also asynchronous job, background job and asynchronous message.
UTM-D
See openUTM-D.
UTM-F
UTM applications can be generated as UTM-F applications (UTM fast). In the case of UTM-F applications, input from and output to hard disk is avoided in order to increase performance. This affects input and output which UTM-S uses to save user data and transaction data. Only changes to the administration data are saved.
In UTM cluster applications that are generated as UTM-F applications (APPLI-MODE=FAST), application data that is valid throughout the cluster is also saved. In this case, GSSB and ULS data is treated in exactly the same way as in UTM cluster applications generated with UTM-S. However, service data relating to users with RESTART=YES is written only when the relevant user signs off and not at the end of each transaction.
UTM generation
Static configuration of a UTM application using the UTM tool KDCDEF and creation of an application program.
UTM message
Messages are issued to UTM message destinations by the openUTM transaction monitor or by UTM tools (such as KDCDEF). A message comprises a message number and a message text, which can contain inserts with current values. Depending on the message destination, either the entire message is output or only certain parts of the message, such as the inserts).
UTM page
A UTM page is a unit of storage with a size of either 2K, 4K or 8 K. In standalone UTM applications, the size of a UTM page on generation of the UTM application can be set to 2K, 4K or 8 K. The size of a UTM page in a UTM cluster application is always 4K or 8 K. The page pool and the restart area for the KDCFILE and UTM cluster files are divided into units of the size of a UTM page.
utmpath (Unix / Linux / Windows systems)
The directory under which the openUTM components are installed is referred to as utmpath in this manual.
To ensure that openUTM runs correctly, the environment variable UTMPATH must be set to the value of utmpath. On Unix and Linux systems, you must set UTMPATH before a UTM application is started. On Windows systems UTMPATH is set in accordance with the UTM version installed most recently.
UTM-S
In the case of UTM-S applications, openUTM saves all user data as well as the administration data beyond the end of an application and any system crash which may occur. In addition, UTM-S guarantees the security and consistency of the application data in the event of any malfunction. UTM applications are usually generated as UTM-S applications (UTM secure).
UTM SAT administration (BS2000 systems)
UTM SAT administration functions control which UTM events relevant to security which occur during operation of a UTM application are to be logged by SAT. Special authorization is required for UTM SAT administration.
UTM socket protocol (USP)
Proprietary openUTM protocol above TCP/IP for the transformation of the Socket interface received byte streams in messages.
UTM system process
UTM process that is started in addition to the processes specified via the start parameters and which only handles selected jobs. UTM system processes ensure that UTM applications continue to be reactive even under very high loads.
UTM terminal
This term has been superseded by LTERM partner.
UTM tool
Program which is provided together with openUTM and which is needed for UTM specific tasks (e.g for configuring).
virtual connection
Assignment of two communication partners.
warm start
Start of a UTM-S application after it has terminated abnormally. The application information is reset to the most recent consistent state. Interrupted dialog services are rolled back to the most recent synchronization point, allowing processing to be resumed in a consistent state from this point (service restart). Interrupted asynchronous services are rolled back and restarted or restarted at the most recent synchronization point.
For UTM-F applications, only configuration data which has been dynamically changed is rolled back to the most recent consistent state after a restart due to a preceding abnormal termination.
In UTM cluster applications, the global locks applied to GSSB and ULS on abnormal termination of this node application are released. In addition, users who were signed on at this node application when the abnormal termination occurred are signed off.
WebAdmin
Web-based tool for the administration of openUTM applications via a Web browser. WebAdmin includes not only the full function scope of the administration program interface but also additional functions.
Web service
Application which runs on a Web server and is (publicly) available via a standardized, programmable interface. Web services technology makes it possible to make UTM program units available for modern Web client applications independently of the programming language in which they were developed.
WinAdmin
Java-based tool for the administration of openUTM applications via a graphical user interface. WinAdmin includes not only the full function scope of the administration program interface but also additional functions.
work process (Unix / Linux / Windows systems)
A process within which the services of a UTM application run.
workload capture & replay
Family of programs used to simulate load situations; consisting of the main components UPIC Capture, UPIC Analyzer and Upic Replay and - on Unix, Linux and Windows systems - the utility program kdcsort. Workload Capture & Replay can be used to record UPIC sessions with UTM applications, analyze these and then play them back with modified load parameters.
WS4UTM
WS4UTM (WebServices for openUTM) provides you with a convenient way of making a service of a UTM application available as a Web service.
XATMI
XATMI (X/Open Application Transaction Manager Interface) is a program interface standardized by X/Open for program-program communication in open networks.
The XATMI interface implemented in openUTM complies with X/Open’s XATMI CAE Specification. The interface is available in COBOL and C. In openUTM, XATMI can communicate via the OSI TP, LU6.1 and UPIC protocols.
XHCS (BS2000 systems)
XHCS (Extended Host Code Support) is a BS2000 software product providing support for international character sets.
XML
XML (eXtensible Markup Language) is a metalanguage standardized by the W3C (WWW Consortium) in which the interchange formats for data and the associated information can be defined.