Glossary

application

A general name for a user-created program that is executed in an OpenTP1 system. An application that carries out user tasks is called a user application program. An application that registers a UAP in OpenTP1 and performs as a server is called a user server.

archived-journals file (or archive journal file)

A file that contains the system journals from OpenTP1 nodes. In a cluster system or parallel-processing system, the Global Archive Journal facility is used to archive the system journals from multiple OpenTP1 nodes into a single archived-journals file. This simplifies management of the nodes because the OpenTP1 administrator needs to unload this single file only, rather than each of the system journal files on each node.

See also global archive journal service.

audit log

A file containing historical information about the operations performed on OpenTP1 programs by system developers, operators, and users, together with the program behavior triggered by those operations. An audit log contains information such as what was done, when, and by whom. Thus, they can serve as reference material for auditing system usage, unauthorized access, and other such matters.

checkpoint dump

Journals periodically collected into a file during OpenTP1 operations and used to reduce recovery time. Checkpoint dumps are taken at various checkpoints. At each checkpoint, OpenTP1 saves the status of various system tables that are needed in recovery. During recovery, the information in a checkpoint dump can replace all the recovery journals from the start of online processing to the most recent checkpoint. Using a checkpoint dump and only the most recent recovery journals reduces recovery time.

client gateway program (CGW)

A program to enable OpenTP1 to access other open systems such as DCE. A CGW receives a request for a service from a UAP in OpenTP1, and it requests the same service from an open system. In an OpenTP1 system, a client gateway program is regarded as a service-providing program.

client UAP/server UAP

A client UAP requests a service, and a server UAP carries out the requested service. A client UAP can be a service-using program, service-providing program, or message-handling program. A server UAP is a service-providing program.

client user program (CUP)

A client UAP that uses the OpenTP1 client facilities provided by the product TP1/Client. These facilities include useful troubleshooting facilities: the error log facility and the UAP trace facility.

client/server

A term describing a relationship between programs. A client is a program that requests a service; a server is a program that carries out the requested service. Whether a program is functioning as a client or a server is determined by its relationship to another program.

cluster system or parallel-processing system

A system in which multiple processors, perhaps on different machines, are so connected that they can work together to provide a single service. In such a system, one logical task might be broken down into different fragments and all the fragments might be processed simultaneously on different processors. Such system configurations can provide very high performance. The product TP1/Multi supports OpenTP1 operations in a cluster system or parallel-processing system.

commit

A commit operation ensures successful completion of a transaction at a synchronization point. When a commit operation is complete (i.e., when a transaction completes synchronization point processing), the results of the transaction take effect. See also transaction and rollback.

complete recovery

Returning an entire OpenTP1 system to its former state after a system failure.

connection

A logical communication path established between an OpenTP1 system and another system. Note that some communication protocols also use the term "association" with the same meaning. In this manual, a connection is named consistently as long as the message exchange is described.

CUP

See client user program (CUP).

DAM

See direct access method file (DAM file).

deadlock

Conflict situation in which more than one UAP tries to reserve more than one resource at the same time, and each UAP continues to wait for another to release one of the resources.

direct access method file (DAM file)

OpenTP1 file accessible by the direct access method. A file can be referenced and modified using a relative block number as an access key to the data. The sequential access method can be used to reference data only.

domain

A logical division of a network. Domain management uses the domain name service (DNS) or the network information service (NIS). When performing client/server communications in a large-scale network, you can improve the efficiency of scheduling by making a domain modification to remote procedure calls of OpenTP1.

DTP

See X/Open Distributed Transaction Processing (DTP) model.

dynamic loading of service functions

A facility that dynamically loads (reads) the service functions contained in a UAP shared library. A UAP shared library is created by linking the set of UAP object files generated by compiling the UAP source files. Use of this facility enables you to add and delete service functions simply by changing the service operand of the user service definition. There is no need to change the stub or re-create the UAP executable file. Because the service functions are loaded when the UAP starts, no stub or service functions are needed to create the UAP executable file.

global archive journal service

A facility to collect system journals from OpenTP1 nodes that are used in a cluster system or parallel-processing system. This facility makes it unnecessary to unload system journals from each OpenTP1 node.

See also archived-journals file (or archive journal file).

global cache

An area used by the name service to manage service information for servers running at other nodes.

global transaction

A UAP process that performs transaction processing is called a transaction branch. Use of RPCs enables you to perform transaction processing that consists of multiple UAP processes. A set of transaction branches that consists of multiple UAP processes is called a global transaction.

A transaction branch that starts a transaction is called a root transaction branch.

host

A machine that is connected to a network and on which OpenTP1 runs. If the MultiOpenTP1 configuration is used, a host contains more than one OpenTP1 instance.

import

An operation for registering an OpenTP1 scenario template definition file in JP1/AJS2 - Scenario Operation as a scenario template.

input queue

An ordered group of MCF messages that came from other systems and that are waiting to be processed.

The TP1/Message Control product manages input queues.

inquiry-response message

A message that requires a response. See also send-only message.

The TP1/Message Control product manages inquiry-response messages.

Internode Load-Balancing facility

A facility that balances the load between nodes by placing user servers of the same service group on multiple nodes. When a service is requested, it is allocated to one of the user servers of the service group. The least-loaded node can be selected according to the scheduling of nodes.

internode shared table (IST)

A data table managed by the IST service, a facility provided by the product TP1/Shared Table Access. When the IST service is used, the user should set the name of the table in the function of the IST service. Because the internode shared table is managed by the TP1/Shared Table Access of each system, the UAP does not need to manage the node location of the internode shared table.

journal

Information about system operations. OpenTP1 obtains such information to check and record the operating status of the system, and to recover after a failure. The following journals can be obtained using OpenTP1:

journals used for a complete or partial recovery
system trace information
user-specified journals

local cache

An area used by the name service to manage service information for the servers running at the local OpenTP1 system.

logical message

A unit for messages sent between two systems. A logical message contains a set of related tasks, and consists of one or more segments.

The TP1/Message Control product manages logical messages.

logical terminal

A logical name of a communication target in a remote system. The logical name is used when a UAP sends or receives messages.

The TP1/Message Control product manages logical names.

MCF

See message control facilities (MCF).

MCF main function

A user-created main function for use with TP1/Message Control, an OpenTP1 resource manager. The main and dc_mcf_svstart() functions (described in the manual OpenTP1 Operation) are issued from the MCF main function. If a user-exit routine is included in the system, the routine's address must be set in the MCF main function. The MCF main function is written for a communication protocol, or for a service that starts applications. The main function for each MCF main function needs to be written independently.

The TP1/Message Control product manages MCF main functions.

MCF message queue

There are two kinds of MCF message queues: an input queue that stores MCF messages received via TP1/Message Control, and an output queue that stores MCF messages to be sent to other systems.

The TP1/Message Control product manages MCF message queues.

message control facilities (MCF)

The OpenTP1 facilities provided by the products TP1/Message Control, TP1/NET/Library, and the products that correspond to the relevant communication protocol. These products provide the MCF message-exchange capabilities of OpenTP1.

message handling program (MHP)

One of the OpenTP1 UAPs that is used for MCF message communication. This program is made up of service functions that receive MCF messages from other systems and a main function that organizes the service functions.

The TP1/Message Control product manages message handling programs.

message log

System management information output by OpenTP1. An MCF message log is displayed on a screen and is also written into a specified file. You can use the logcat command to edit and display the stored message log.

The message log of OpenTP1 can be reported to the application programs exclusively created in a system. The application program that has received a report can report the status of OpenTP1 to other vendors' network management systems. If a message log is reported, specify Y in the log_notify_out operand in the log service definition of OpenTP1.

message queue

See MCF message queue or MQA message queue.

message queue access (MQA)

The OpenTP1 facility provided by the product TP1/Message Queue. This product provides the MQA message-queuing capabilities of OpenTP1.

message queue interface (MQI)

An API consisting of instructions used by UAP when performing communication using message queuing. MQI is a standard API of the WebSphere MQ.

message queuing

See MQA message queuing.

message sequential number

A number assigned to each MCF message. These numbers are used to avoid resending the same MCF message or omitting messages.

The TP1/Message Control product manages message sequential numbers.

MHP

See message handling program (MHP).

MQA

See message queue access (MQA).

MQA message queue

A message-putting queue for communication using MQA message queuing. The messages put in an MQA message queue are sent by the queue manager. Depending on the MQA service definition and the argument of MQI, desired messages can be gotten regardless of the order in which they were put.

MQA message queue file

A file that stores the message queues for communication using MQA message queuing. For OpenTP1, a user should create the queue file in the OpenTP1 file system by using commands.

MQA message queuing

A message-queuing communication procedure developed by the IBM Corp. In communication using message queuing, the queue manager puts or gets the messages queued by UAPs. Therefore, UAPs are free from processing inter-system communication and handling communication errors. Since UAPs can put messages at any time, they can be used like e-mail. Access from a UAP to a queue uses Message Queue Interface (MQI), the standard application programming interface of the WebSphere MQ.

MQA service

OpenTP1 system's services necessary for communication using message queuing. The MQA service manages the message queues and UAP processes.

MQ system

A system (node) where the queue manager of message queuing exists

MQT service (message queue transfer service)

OpenTP1 system's services necessary for communication using message queuing. The MQT service manages inter-system communication by using TCP/IP protocol.

MultiOpenTP1

Enables configurations in which two OpenTP1 instances are running on one host. Each OpenTP1 is operated independently so, for example, one OpenTP1 instance can be used for actual processing and the other can be used for testing new applications.

Multiserver facility

A facility for handling more than one service request at the same time by processing the requests on more than one server process. The Multiserver facility improves the efficiency of UAP processing.

node

A host or an OpenTP1 node. See also host and OpenTP1 node.

OpenTP1 administrator

A UNIX user who administers the OpenTP1 system. An OpenTP1 administrator has the privileges required to perform important operations on OpenTP1. The user name for the OpenTP1 administrator is determined by a superuser. The user name must be password-protected.

OpenTP1 file system

The file system provided by OpenTP1. Each file in an OpenTP1 file system is called an OpenTP1 file. Data requiring a high degree of reliability can be stored in this OpenTP1 file system: for example, important user data or system journals used at recovery.

OpenTP1 home directory

The directory that stores files and directories used by OpenTP1.

In OpenTP1, the OpenTP1 home directory is managed using the DCDIR environment variable. On a machine on which OpenTP1 is installed, you can move from any directory to the OpenTP1 home directory by specifying $DCDIR.

In OpenTP1 manuals, the keyword $DCDIR/ is used to represent the OpenTP1 home directory.

OpenTP1 installation directory

The directory in which OpenTP1 is installed. The path of the OpenTP1 installation directory differs depending on the OS, as shown below.

AIX, HP-UX, and Solaris: /BeTRAN

Linux: /opt/OpenTP1

Windows: C:\OpenTP1

Note that the C:\ part may be different depending on your environment.

OpenTP1 node

OpenTP1 systems that make up a multinode area or a multinode subarea. Each OpenTP1 node is distinguished by its node identifier which is specified in the system common definition. The two OpenTP1 systems in a System Exchange configuration are regarded as one OpenTP1 node.

output queue

An ordered group of MCF messages that are waiting to be sent to other systems.

The TP1/Message Control product manages output queues.

parallel-processing system

See cluster system or parallel-processing system.

partial recovery

The process in which, when an error occurs in a UAP, the transaction being executed is canceled and all the resources related to the transaction are returned to their previous states.

process

The in-memory processing created when user servers or OpenTP1 use OS memory. To maintain performance OpenTP1 controls the number of processes.

queue group ID

An identifier for a message queue file that is used for message exchange. This ID is used with OpenTP1 commands to display the status of a queue group.

The TP1/Message Control product manages queue group IDs.

queue manager

A software product that manages MQA message queuing. A queue manager is required in a system that uses MQA message queuing to communicate. For OpenTP1, TP1/Message Queue serves as a queue manager.

real-time statistics

The statistics that can be output in real time for the entire system, for each server, and for each service are called real-time statistics. By outputting real-time statistics, you can check the operating status of the OpenTP1 system in real time, and quickly perform system operation management and error recovery.

real-time statistics service

An OpenTP1 facility for managing real-time statistics in order to check the operating status of the OpenTP1 system in real time.

remote procedure call (RPC)

A method of communicating between processes that are executing UAPs. OpenTP1 UAPs use RPCs to communicate with UAPs on other systems. When using RPCs, programmers do not need to know the network address of the target UAP.

resource manager

A generic name for facilities that manage resources. A DBMS is a resource manager.

response message

See inquiry-response message.

rollback

An operation at a synchronization point to cancel a transaction. A transaction can be rolled back in two ways: a user issues a function from an application program, or OpenTP1 stops the application that carries out the transaction.

root transaction branch

A transaction branch, which is a UAP process, that belongs to a global transaction and is where the transaction starts.

RPC

See remote procedure call (RPC).

RPC suppression list

A list containing information about the OpenTP1 nodes that have not started. This list is owned by each OpenTP1 system.

scenario

An object that associates scenario templates with jobs to execute a sequence of jobs as defined. JP1/AJS2 - Scenario Operation registers scenario templates in JP1/AJS2 as a scenario, and JP1/AJS2 executes the scenario.

scenario job

An object that associates scenario job templates with jobs to execute a sequence of jobs as defined. JP1/AJS2 - Scenario Operation uses scenario jobs. A scenario job is an object for executing the commands, shell scripts, Windows executable files, and other items defined in a scenario.

scenario job template

A part of a scenario template used by JP1/AJS2 - Scenario Operation. A scenario job template defines the commands, shell scripts, Windows executable files, and other items defined in a scenario template. In OpenTP1, scenario job templates are used when the scenario template functionality of JP1/AJS2 - Scenario Operation is used.

scenario library

A folder for managing scenario templates in JP1/AJS2 - Scenario Operation.

scenario template

A component that defines a job sequence and that can be used as a boilerplate. JP1/AJS2 - Scenario Operation uses scenario templates. In OpenTP1, scenario templates are used when the scenario template functionality of JP1/AJS2 - Scenario Operation is used.

scenario variable

A variable that is preset in a scenario and that can be changed according to the operating environment. For example, information about OpenTP1 directories may be set in scenario variables.

scheduler

One of the OpenTP1 facilities that starts and stops user servers according to changes in the load on each node. This facility improves system performance by dispersing loads across different nodes and controlling the number of processes.

send-only message

An MCF message that does not require any response. You can assign priorities to each send-only message. See also inquiry-response message.

The TP1/Message Control product manages send-only messages.

server gateway program (SGW)

A gateway program that enables OpenTP1 to access other open systems. An SGW receives requests for services from an application in an open system other than OpenTP1, and it requests the same service from OpenTP1 service-providing programs. The dc_rpc_call() function provided by TP1/Client is used to request a service. In an OpenTP1 system a server gateway program is regarded as a client user program.

server UAP

See client UAP/server UAP.

service

Procedure required to be carried out for clients in a client/server system. In C, a service is coded as C functions and the completed functions are called service functions. In COBOL, a service is coded as a subroutine and is called a service program.

service group

An OpenTP1 server UAP that provides a set of services to process requests from clients. To request a service, a service group name and a service name are specified as arguments of dc_rpc_call(). The OpenTP1 dc_rpc_call() function is used for making remote procedure calls in OpenTP1 systems.

service information prioritizing function

A function for returning service information for a specific node preferentially when the name service returns service information to the client UAP that issued a service request. The node chosen by this function for return of service information is called the priority selection node.

This function enables you to normally use the server UAP at the priority selection node and to use a different node only in the event of a failure. You can treat one server UAP as the running system and another as a standby system.

service-providing program (SPP)

An OpenTP1 UAP that can perform as a server. This program consists of service functions that provide the service requested by a client UAP, and a main function to organize the service functions.

service-using program (SUP)

An OpenTP1 UAP designed to perform as a client only. It does not contain any functions to provide services for other UAPs and it only requests services from a service-providing program.

SPP

See service-providing program (SPP).

status service

An OpenTP1 facility that manages system information, such as the operation status of UAPs.

Structured Transaction Definition Language (STDL)

A high-level language used by a UAP when performing distributed transactional communication that conforms with the Multivendor Integration Architecture (MIA) standard. The STDL specification is defined by the MIA consortium. A program coded using STDL is known as an STDL task.

stub

A program that functions as a library to support RPCs in client/server communications, which connects requests for services with the services provided by server UAPs. The stbmake command or tpstbmk command creates a stub from a RPC interface definition file that is made by a user. The stub is created as a C program. To link the stub to an executable UAP file, the stub must be compiled. The following UAPs need stubs: service-providing programs when an RPC or the XATMI interface is used, service-using programs when the XATMI interface is used, and message-handling programs. However, no stub is required if all the service functions are rolled into a UAP shared library and are loaded dynamically. A UAP shared library is created by linking the set of UAP object files generated by compiling the UAP source files.

For more details on stubs, see the OpenTP1 Programming Guide.

SUP

See service-using program (SUP).

superuser

A user with UNIX OS privilege. A superuser has access permission to all files in the UNIX file system. The user login name of a superuser is root.

synchronization point

A breakpoint between transactions. In a commit operation on a transaction; the effects of a transaction up to a synchronization point are implemented. In a rollback operation on a transaction, a transaction cannot be completed and the status of resources is returned to the same status as at the previous synchronization point.

system service

Another name for an OpenTP1 facility; a user server is another name for an OpenTP1 UAP.

table access method file (TAM file)

A file accessed by using a simple structure table that is specially created for use in OpenTP1. A table name and a key value are used to access the simple structure table. Accessing the table enables fast access for such tasks as retrieving, cancellation of retrieving, modifying, adding and deleting of records, and obtaining table information.

TAM

See table access method file (TAM file).

TCP/IP (Transmission Control Protocol/Internet Protocol)

A protocol developed by ARPANET in the Defense Advanced Research Project Agency (DARPA) project. The TCP/IP protocol is mainly used for LAN.

TP monitor

See transaction processing monitor (TP monitor).

transaction

A logical unit of operation that is regarded as a single operation. In transaction processing, each transaction ends in complete success or complete failure. For example, after a transaction, a commit operation ensures that all the file modifications required by a transaction are completed, or a rollback operation ensures that none of the file modifications are completed.

transaction branch

Each UAP process that is part of a global transaction. The transaction branch in which the global transaction starts is called a root transaction branch. See also global transaction and root transaction branch.

transactional RPC

An RPC that OpenTP1 handles as a transaction. For example, coding dc_trn_begin() before dc_rpc_call() will cause OpenTP1 to handle the dc_rpc_call() call as a transaction: the dc_rpc_call() is the transactional RPC. To become part of the transaction of a transactional RPC, a UAP process that is requested for a service must have the transaction attribute (atomic_update = Y) specified in the user service definition.

transaction manager

The OpenTP1 facility that manages and executes transactions.

transaction processing monitor (TP monitor)

Software that monitors and controls transactions. This software provides the infrastructure for constructing an online system. Major features include the communication facility for transferring data among terminals and other machines, and the recovery facility to prevent loss or mismatch of data in case of a failure.

trigger facility

A facility that notifies the local system's UAP that a message has arrived at the message queue when performing communication using MQA message queuing. The UAP assigned to receive trigger events is called a trigger monitor application.

UAP

See user application program (UAP).

uptime statistics

Information about the operation of OpenTP1 system services and user servers. Uptime statistics are used to monitor the operational status of the entire OpenTP1 system.

user application program (UAP)

A program that carries out user tasks. An OpenTP1 user server is an example of a UAP. In non-OpenTP1 systems, a UAP is often called an application program.

user exit routine

A user-coded program for making a message-exchange UAP applicable to a wider range of tasks. For example, a user exit routine can be used to determine what application to launch, or to edit a message before the UAP sends it to another system.

user journal

Any information specified by a user to be stored in a system journal file. User journals are collected during UAP processing.

user server

A generic name for processes that execute OpenTP1 UAPs that function as user-created servers in OpenTP1 systems, or for those OpenTP1 UAPs themselves.

WebSphere MQ

A generic name of the products for MQA message-queuing-type communication developed by the IBM Corp. OpenTP1 allows message-queuing-type communication, using TP1/Message Queue.

X/Open Distributed Transaction Processing (DTP) model

A distributed processing system model defined by X/Open: an organization for the standardization of open systems. The DTP model consists of a transaction manager that manages and executes transactions; a resource manager, which manages system resources; and application programs.

Appendix E. Glossary