Model 204 intersystem processing

Overview

This topic introduces Model 204 intersystem processing options and provides a discussion of basic concepts and terminology. Information about the particular conventions of Model 204 is useful for both experienced and inexperienced intersystem programming personnel.

Terms and concepts

This section introduces some of the basic networking terminology used in this document and illustrates a simple intersystem connection involving Model 204.

Network: a collection of nodes

In this topic, a computer network is defined as a collection of nodes, connected, at the software level, by a communication interface. Some examples of communication interfaces are:

• The Virtual Telecommunication Access Method (VTAM)
• The Model 204 Cross Region Access Method (CRAM)
• The VM Inter User Communication Vehicle (IUCV)

Strictly speaking, there are different types of nodes on a network: application nodes, terminal nodes, printer nodes, and so on. When the term node is used in this topic, however, it refers to an application node, that is, the point of connection to the network for some system that supports application programs. Examples of such systems follow:

• Model 204
• CICS
• CMS
• PC DOS or OS/2

Network diagram

The following figure is a diagram of a hypothetical network.

It consists of three nodes and the software communication interface SNA Communications Server. The network links system M204A with system M204B; the transactions originate from terminals X, Y, and Z.

Network Transactions

Essential elements of the previous figure are described below:

• Each node on the network has a name by which it is known to other nodes. The node to the left is named M204A, and the one to the right is M204B.
• M204C is an additional node that runs on the same machine and in the same domain as M204A.
• Users X, Y, and Z are end users. An end user is defined as a user connected to a Model 204 terminal thread, such as IODEV 7 (SNA Communications Server 3270) or IODEV 41 (CMS Full Screen).
• User X is running a single node transaction, that is, a transaction whose programs execute completely within a single application node of the network. This type of transaction has always been supported by Model 204.
• User Z is also running a single node transaction, but using a cross-domain terminal connection. User Z's terminal is owned by the SNA Communications Server on the machine that runs M204A, but is not involved with the M204A application node in any way. Z's terminal is connected to the application node M204B, which runs on a different machine (in SNA terms, "in a different domain"). This is still a single node transaction, because all the application programs involved run at a single application node: M204B.
• User Y is running a distributed transaction. A distributed transaction is a transaction that requires application programs at more than one node. The exchange of data between two application programs at different nodes is referred to as a conversation. Conversations are defined in greater detail in SNA concepts and terminology later in this chapter. The two programs that converse are referred to as conversation partners.

Model 204's intersystem facilities

The Model 204 intersystem processing facilities, TPROCESS, Transfer Control, and Horizon, support distributed transactions. They are summarized below. See the following for more complete information about TPROCESS and Transfer Control:

• Program Communication facilities
• Using Program Communication facilities
• DEFINE LINK command: TPROCESS
• DEFINE LINK command: Transfer Control

Terminal Process Communication facility (TPROCESS)

This facility allows a User Language request to communicate with a partner process that runs in either CMS or CICS. The partner process is a CICS program or CMS EXEC. TPROCESS is a standard part of User Language.

A listing of basic requirements, operation, and applications of TPROCESS follows.

Configuration requirements

The terminal user must connect to Model 204 through either the CICS or CMS full screen interface. SNA Communications Server is not required.

Operation and restrictions

• The partner process must run in the same physical machine as the User Language request. The partner process runs in the environment (region or virtual machine) where the terminal is attached: CICS or CMS.
• The User Language request must initiate the partner process. Under CICS, the request may transfer control to the partner.
• Communication passes through the terminal connection.
• The terminal thread IODEV number must be 11 or 41. For more information about these IODEVs, see the IODEV parameter.
• Under CICS, the partner process may be written in any supported host language. Under CMS, the language must be REXX or EXEC2.
• The User Language request is always Master in the conversation, and the partner process is the Slave. This means that the User Language request controls the communication channel, and that the partner may not send data on it unless the User Language request is ready to receive it.

Applications

TPROCESS is appropriate for many applications that require interaction between a User Language request and a program running in the terminal-owning environment. Examples include:

• Switching between a COBOL application running under CICS and a User Language application running in Model 204.

  Control can be transferred between the two applications repeatedly without any awareness on the part of the end user that each application runs in a different environment.

• Passing DB2 or VSAM data from a CICS region into a Model 204 application.
• Editing a file using XEDIT under CMS, and then uploading the data into Model 204.
• Downloading data from Model 204 to CMS or CICS for manipulation by a statistical or graphics package.

Transfer Control facility

This facility allows a User Language request to transfer control to a partner process that runs in CICS or to another Model 204 region or non-Model 204 SNA Communications Server application. The partner is a CICS program or SNA Communications Server application. Transfer Control is a standard part of User Language.

A listing of basic requirements, operation, and applications of Transfer Control follows.

Configuration requirements

The terminal user must connect to Model 204 through either the CICS or SNA Communications Server full screen interface.

Only z/OS and z/VSE SNA Communications Server users can execute a transfer of control.

Operation and restrictions

• The partner can run in the same physical machine as the User Language request or in a different physical machine: CICS partners must be in the same machine; SNA Communications Server partners can be in the same or in a different machine.
• The User Language request transfers control to the partner.
• Communication passes through the terminal connection or through SNA Communications Server.
• For CICS partners, the terminal thread IODEV number must be 11. If the partner is a SNA Communications Server application, the terminal thread IODEV number must be 7. For more information about these IODEVs, see the IODEV parameter.

Applications

Transfer Control is appropriate for applications that require a transfer of a user from one Model 204 online into another or from one Model 204 online into a non-Model 204 CICS or SNA Communications Server application. Examples include:

• Under CICS, transferring a user back to an initiating transaction.
• Transferring a SNA Communications Server user between Model 204 regions without the user's awareness of the change of environment.
• Testing Horizon applications: a programmer can transfer between Model 204 partners checking the results of a Horizon testing phase.

Horizon

This feature is more powerful and general than TPROCESS. It offers a communication interface in User Language that conforms to the SNA LU 6.2 protocol. Horizon is an optional feature which must be purchased separately and must be installed to be used.

A listing of basic requirements, operation, and applications of Horizon follows.

Configuration requirements

The ACF/SNA Communications Server product or a supported TCP/IP product must be available in the operating system under which Model 204 is running. This guide assumes that the network product is SNA Communications Server.

TCP/IP support

Although SNA Communications Server is assumed, appropriate changes to the LINK and PROCESSGROUP command definitions allow the same Horizon code to work with a TCP/IP network product, unless mentioned otherwise in this guide.

On IBM z/VM and IBM z/VSE systems, Horizon supports IPv4 network addresses.

On IBM z/OS systems, Horizon supports either IPv4 or IPv6 network addresses. For details on IPv6 network address support for Horizon, see the Horizon for TCP/IP DEFINE LINK command.

Operation and restrictions

• The User Language request's partner process may run in the same copy of Model 204, in an adjacent region or virtual machine, or in a different physical machine.
• The User Language request may initiate the conversation, or the partner may initiate it.
• Communication passes through the SNA network (as described in SNA concepts and terminology).
• The terminal thread that initiates the conversation may be any IODEV number. The thread that receives an incoming conversation request must be IODEV 27. For more information, see Horizon network management and also Horizon (IODEV=27).
• The partner process can be written in any language that has access to an LU 6.2 communication interface. Currently supported partner languages include:
  • User Language
  • assembler
  • C
  • COBOL
  • PL/1
• The two communicating partners interact as peers. Each one can control the communication channel at different times during a conversation. Change of direction can be negotiated.

Applications

Horizon permits applications that require "any-to-any" connectivity. A transaction that originates in User Language might request data from three partners, all of whom run on different hardware. This application can be designed so that the User Language request has the same conversation with each partner, yet is completely unaware of the different hardware environments in which its partners run.

Horizon is therefore more flexible than TPROCESS, for example, which requires partners to run on the same physical machine. The relationship between the two Horizon partners is peer-to-peer, rather than the master/slave relationship required by TPROCESS.

Some possible applications include:

• A central site polling a number of satellites and aggregating data for a report.

  For example, a concern with several geographically distributed warehouses, each with its own IBM 9370-based inventory database, might want an aggregate total of its supply of a particular stock item.

• A central server used by several remote requestors.

  For example, an insurance company keeps premium calculation rules in a central database. Proposal generation is a distributed transaction: a branch office collects input data, ships it to the server for calculation, and then accepts the result and formats a report. One branch office keeps its local customer information in a Model 204 database on an IBM 9370, while a smaller office uses a Personal Computer.

• Aggregation of data from several different sources.

  A transaction interacts with an end user via a User Language request, which invokes requests to CICS for DB2 data, to CMS for SQL/DS data, and even to a DEC computer for data residing there.

SNA concepts and terminology

This section provides a brief review of SNA concepts and how Horizon applies those concepts.

SNA networks provide resource sharing

Before the advent of Systems Network Architecture (SNA), data communication for IBM was mostly a matter of dedicated, hard-wired connections between communicating objects (usually a terminal communicating with a program). SNA moves toward an environment where network resources are managed by an operating system layer.

A major benefit of this approach is that network resources can be shared among different applications. An early example of this benefit is its removal of the need to dedicate a terminal to an application like CICS or Model 204. Instead, the terminal is "owned" by an operating system component called SNA Communications Server, which can connect it to CICS, Model 204, TSO, and so forth, at the terminal user's request.

SNA protocols neutralize physical differences

A second objective of SNA is to standardize the rules, or protocols, by which two partners communicate. An important result of this is that partners have a logical, rather than a physical, view of each other. An application is not concerned about whether a terminal is attached locally or remotely, or about the idiosyncrasies of different terminal devices. At the application programming level, each communicating node in an SNA network is, therefore, referred to as a Logical Unit (LU), and each node on an SNA network is the point of connection for an LU.

Multiple LU types are defined; each is associated with the a set of rules (protocol) that the partners must obey to communicate. For inter-program communication, these rules specify an application program interface.

When this interface is offered by a particular product or language, it allows a program written in that language to converse with another program using a similar interface. Neither program needs any knowledge of what language its partner is written in, what hardware it runs on, what communication media are used, or what the physical network looks like.

This application program interface and the associated rules that specify how the communicating partners are to behave define LU type 6.2.

LUs service application programs

An LU is the system software under which an application program runs at a network node. With the installation of Horizon, Model 204 can become such an LU. The following figure illustrates the relationship between an application program and an LU.

Application Program and LU

The LU provides various services to the application program:

• An application programming interface for communications.
• Enforcement of rules governing application program behavior.
• Packaging of application data in network format for transmission, and unpackaging and presentation to the application program of received application data.
• Error detection, and, when possible, recovery.

Horizon partner programs can be written in different languages

Horizon is Model 204's implementation of LU 6.2. Using Horizon, a User Language request can participate in a conversation with another program. That partner program can be another User Language request or a program written in another language which satisfies the LU 6.2 conversation interface protocols.

To design an application that involves conversations between programs in different languages, the designer must understand the common SNA standard to which the different interfaces conform. For example, the syntax of Horizon is somewhat different from that of the CICS interface and quite different from the subroutine-calling interface offered by APPC/PC. But all three LU 6.2 interfaces make a common set of operations available to an application program.

The architecture to which these and other LU 6.2 interfaces conform is documented in detail in IBM publication GC30-3084: the Transaction Programmer's Reference Manual for LU Type 6.2. A mapping between Horizon's User Language statements and their LU 6.2 architectural specifications is provided in LU 6.2 and Horizon equivalences. This information is useful for programmers who intend to develop conversation partner programs in different languages; for conversations where both partners are written in User Language, this manual should be sufficient.

Sessions connect LUs; conversations connect programs

The connection between two logical units over which conversation data flows is called a session.

Each session can be thought of as an individual telephone line between two LUs, in that it can be used by only one pair of conversing programs at any given time. A session is thus a resource "owned" by an LU and assigned to an application program for the duration of a conversation. A session between two LUs usually survives after a conversation ends and is then free to be reassigned to a subsequent conversation.

A session limit can be set between any two LUs. This limit determines how many concurrent conversations can be active between them; it puts a cap on the number of parallel sessions that may exist between the two LUs.

A conversation is a communication between two application programs. The program that initiates the conversation is called the client program. The client's partner in the conversation is called the server program. When the LU at which the server program is to run receives the initiation request, it starts the server program.

A session can be thought of as a long-term connection between two LUs, whereas a conversation is seen as a short-term connection between two application programs. Since a conversation flows on a session, a session must be established, or bound, between the LUs involved before two application programs can have a conversation.

Horizon supports parallel sessions

A pair of LUs can connect to each other by a single session (one session active at a time, reused serially for conversations) or by parallel sessions (multiple sessions active at a time). Two LUs cannot be connected by both single and parallel sessions at the same time.

Parallel session support allows the partitioning of sessions into session groups that have common properties such as the remote partner and session limit and common session characteristics like message size and security.

Parallel sessions are supported in Model 204-to-Model 204 communications. Model 204 also provides CNOS (change number of sessions) parallel session support, and can connect with parallel sessions to any client that provides the CNOS minimum support set of functions and components (as defined in the SNA Format and Protocol Reference Manual: Architecture Logic for LU Type 6.2).

For parallel sessions connections from Model 204 to systems other than those running on SNA Communications Server, Model 204 must run with the so-called "peer-to-peer" release levels of SNA Communications Server and NCP.

Conversation partners are known as client and server

The following figure illustrates a distributed transaction and facilitates discussion of the relationship between the two conversation partners.

Horizon Distributed Transaction

The end user sits at a terminal. The thread that the end user is connected to runs the client program. The client program, also referred to as the outbound program, makes the initial request to establish a conversation, using the OPEN PROCESS statement.

The client program's OPEN PROCESS statement causes a conversation initiation request to pass over the communication path. The LU at which the server program is to run receives the initiation request and starts the server program. The server program, which services the request for a conversation, begins by issuing the OPEN PROCESS ACCEPT statement. The server program is also referred to as the inbound program.

A Model 204 system in which a client program runs is referred to as a client system; one in which a server program runs is called a server system.

A system is designated client or server only in the context of a particular transaction. In the Horizon Distributed Transaction figure, ONLINE M204A is the client system for transaction A, which initiates at M204A. For transaction B, which initiates at M204B, M204A is the server system.

Note: A client program never connects to an active server program. The OPEN PROCESS request actually initiates, or attaches, the server program. For Model 204, this implies that there must be a free (that is, not currently used) thread on the server system to run the server program. This free thread must be a Horizon IODEV (IODEV=27), defined by the system manager in the user zero input stream.
For more information about the Horizon IODEV, see IODEV specification for Horizon inbound threads and also Horizon (IODEV=27).

Horizon programs can have multiple roles and partners

As shown in "Multi-node transaction", it is possible to build distributed transactions that span more than two nodes.

In multi-node transaction, the application program at M204A has two open conversations: one with a program at the M204B node, and one at M204C. The application program at M204B is both a server to the client program at M204A, and a client program to the server at M204D.

The designation of a program as client or server carries no implications about how it behaves with respect to its partner once the conversation is established. These terms only describe who initiated the conversation (the client), and who was initiated by it (the server). Since the Horizon protocol is peer-to-peer, which partner has control of the conversation (that is, the one allowed to send data at any given point in processing) is completely up to the application designer.

Multi-node transaction

Horizon terms have multiple synonyms

Unmodified, "client" can refer to a Model 204 ONLINE system or to an application program that runs in that Model 204 ONLINE. "Server" similarly can refer to a system or a program. To clarify the terms used in this document, Synonyms for Horizon terms lists possible elements in a typical Horizon network transaction along with their synonyms and definitions.

Synonyms for Horizon terms

Term	Also known as	Meaning
end user	terminal user	User on a terminal thread connected to the client system
client program	{client | outbound} {user | program | process | application}	Model 204 application that initiates a conversation
client system	{client | outbound} {system | Online | node | LU}	Host and provider of network services to a client program
server program	{server | service | inbound} {user | program | process | application}	Model 204 application that is initiated by an incoming conversation request
server system	{server | service | inbound} {system | Online | node | LU}	Host and provider of network services to a server program