Model 204 intersystem processing - Revision history

DCameron: /* Horizon */

2019-02-12T13:45:05Z

Horizon

← Older revision		Revision as of 13:45, 12 February 2019
Line 182:		Line 182:
	</li>		</li>
	</ul>		</ul>

	==SNA concepts and terminology==		==SNA concepts and terminology==
	<p>		<p>

JAL: add clarifier

2017-10-10T23:21:03Z

add clarifier

← Older revision		Revision as of 23:21, 10 October 2017
Line 260:		Line 260:
	A Model 204 system in which a client program runs is referred to as a <var class="term">client system</var>; one in which a server program runs is called a <var class="term">server system</var>.</p>		A Model 204 system in which a client program runs is referred to as a <var class="term">client system</var>; one in which a server program runs is called a <var class="term">server system</var>.</p>
	<p>		<p>
	A system is designated client or server only in the context of a particular transaction. In [[#Horizon Distributed Transaction\|Horizon Distributed Transaction]], 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.</p>		A system is designated client or server only in the context of a particular transaction. In the [[#Horizon Distributed Transaction\|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.</p>

	<p class="note"><b>Note:</b> 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. <br /> For more information about the Horizon IODEV, see [[Horizon network management#IODEV specification for Horizon inbound threads\|IODEV specification for Horizon inbound threads]] and also [[Defining the user environment (CCAIN)#Horizon (IODEV=27)\|Horizon (IODEV=27)]].</p>		<p class="note"><b>Note:</b> 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. <br /> For more information about the Horizon IODEV, see [[Horizon network management#IODEV specification for Horizon inbound threads\|IODEV specification for Horizon inbound threads]] and also [[Defining the user environment (CCAIN)#Horizon (IODEV=27)\|Horizon (IODEV=27)]].</p>

	===Horizon programs can have multiple roles and partners===		===Horizon programs can have multiple roles and partners===

JAL: /* Horizon terms have multiple synonyms */ misc formatting

2017-03-28T20:30:18Z

Horizon terms have multiple synonyms: misc formatting

← Older revision		Revision as of 20:30, 28 March 2017
Line 285:		Line 285:
	<th>Meaning</th>		<th>Meaning</th>
	</tr>		</tr>

	<tr>		<tr>
	<td>end user</td>		<td>end user</td>
Line 290:		Line 291:
	<td>User on a terminal thread connected to the client system</td>		<td>User on a terminal thread connected to the client system</td>
	</tr>		</tr>

	<tr>		<tr>
	<td>client program</td>		<td>client program</td>
	<td nowrap>[client \| outbound} {user \| program \| process \| application</td>		<td nowrap>{client \| outbound} <br />{user \| program \| process \| application}</td>
	<td>Model 204 application that initiates a conversation</td>		<td>Model 204 application that initiates a conversation</td>
	</tr>		</tr>

	<tr>		<tr>
	<td>client system</td>		<td>client system</td>
	<td>{client \| outbound} {system \| Online \| node \| LU}</td>		<td>{client \| outbound} <br />{system \| Online \| node \| LU}</td>
	<td>Host and provider of network services to a client program</td>		<td>Host and provider of network services to a client program</td>
	</tr>		</tr>

	<tr>		<tr>
	<td>server program</td>		<td nowrap>server program</td>
	<td>{server \| service \| inbound} {user \| program \| process \| application}</td>		<td>{server \| service \| inbound} <br />{user \| program \| process \| application}</td>
	<td>Model 204 application that is initiated by an incoming conversation request</td>		<td>Model 204 application that is initiated by an incoming conversation request</td>
	</tr>		</tr>

	<tr>		<tr>
	<td>server system</td>		<td>server system</td>
	<td>{server \| service \| inbound} {system \| Online \| node \| LU}</td>		<td>{server \| service \| inbound} <br />{system \| Online \| node \| LU}</td>
	<td>Host and provider of network services to a server program</td>		<td>Host and provider of network services to a server program</td>
	</tr>		</tr>

Admin: /* TCP/IP support */ link repair

2017-03-24T21:10:32Z

TCP/IP support: link repair

← Older revision		Revision as of 21:10, 24 March 2017
Line 134:		Line 134:
	On IBM z/VM and IBM z/VSE systems, Horizon supports IPv4 network addresses.</p>		On IBM z/VM and IBM z/VSE systems, Horizon supports IPv4 network addresses.</p>
	<p>		<p>
	On IBM z/OS systems, Horizon supports either IPv4 or IPv6 network addresses. For ~~full~~ details on IPv6 network address support for Horizon, see the ~~<var class="book">~~[~~http~~://~~docs.rocketsoftware.com/nxt/gateway.dll/RKBnew556%2Fmodel%20204%2Fprevious%20versions%2Fv7.4%2Fm204_releasenotes_v74.pdf Rocket Model 204 Release Notes: New Features Version 7 Release 4.0</var>~~].</p>		On IBM z/OS systems, Horizon supports either IPv4 or IPv6 network addresses. For details on IPv6 network address support for Horizon, see the [[DEFINE LINK command: Horizon for TCP/IP#IPv6 addresses\|Horizon for TCP/IP DEFINE LINK command]].</p>

	====Operation and restrictions====		====Operation and restrictions====

JAL: /* Network diagram */ typo

2017-03-24T20:07:13Z

Network diagram: typo

ELowell at 19:13, 15 June 2016

2016-06-15T19:13:03Z

← Older revision		Revision as of 19:13, 15 June 2016
Line 17:		Line 17:
	</ul>		</ul>
	<p>		<p>
	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 ~~manual~~, 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: </p>		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: </p>
	<ul>		<ul>
	<li>Model 204</li>		<li>Model 204</li>
Line 49:		Line 49:
	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:</p>		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:</p>
	<ul>		<ul>
	<li>[[Program ~~Communications Facilities~~]]</li>		<li>[[Program Communication facilities]]</li>
	<li>[[Using Program Communication facilities]]</li>		<li>[[Using Program Communication facilities]]</li>
	<li>[[DEFINE LINK command: TPROCESS]]</li>		<li>[[DEFINE LINK command: TPROCESS]]</li>
Line 105:		Line 105:
	<li>The User Language request transfers control to the partner.</li>		<li>The User Language request transfers control to the partner.</li>
	<li>Communication passes through the terminal connection or through SNA Communications Server.</li>		<li>Communication passes through the terminal connection or through SNA Communications Server.</li>
	<li>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 ~~in the Rocket Model 204 Command Reference Manual~~.</li>		<li>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 <var>[[IODEV parameter\|IODEV]]</var> parameter.</li>
	</ul>		</ul>

ELowell: /* Operation and restrictions */

2016-06-15T19:09:24Z

Operation and restrictions

← Older revision		Revision as of 19:09, 15 June 2016
Line 69:		Line 69:
	<li>The User Language request must initiate the partner process. Under CICS, the request may transfer control to the partner.</li>		<li>The User Language request must initiate the partner process. Under CICS, the request may transfer control to the partner.</li>
	<li>Communication passes through the terminal connection.</li>		<li>Communication passes through the terminal connection.</li>
	<li>The terminal thread IODEV number must be 11 or 41. For more information about these IODEVs, see the IODEV parameter ~~in the Rocket Model 204 Command Reference Manual~~. </li>		<li>The terminal thread IODEV number must be 11 or 41. For more information about these IODEVs, see the <var>[[IODEV parameter\|IODEV]]</var> parameter.</li>
	<li>Under CICS, the partner process may be written in any supported host language. Under CMS, the language must be REXX or EXEC2.</li>		<li>Under CICS, the partner process may be written in any supported host language. Under CMS, the language must be REXX or EXEC2.</li>
	<li>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.</li>		<li>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.</li>

JAL: link repair

2015-10-13T20:38:25Z

link repair

← Older revision		Revision as of 20:38, 13 October 2015
Line 141:		Line 141:
	Communication passes through the SNA network (as described in [[#SNA concepts and terminology\|SNA concepts and terminology]]).</li>		Communication passes through the SNA network (as described in [[#SNA concepts and terminology\|SNA concepts and terminology]]).</li>
	<li>		<li>
	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 [[~~Network~~ management]] and also [[Defining the user environment (CCAIN)#Horizon (IODEV=27)\|Horizon (IODEV=27)]]. </li>		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 [[Defining the user environment (CCAIN)#Horizon (IODEV=27)\|Horizon (IODEV=27)]]. </li>
	<li>		<li>
	The partner process can be written in any language that has access to an LU 6.2 communication interface. Currently supported partner languages include:		The partner process can be written in any language that has access to an LU 6.2 communication interface. Currently supported partner languages include:
Line 258:		Line 258:
	A system is designated client or server only in the context of a particular transaction. In [[#Horizon Distributed Transaction\|Horizon Distributed Transaction]], 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.</p>		A system is designated client or server only in the context of a particular transaction. In [[#Horizon Distributed Transaction\|Horizon Distributed Transaction]], 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.</p>

	<p class="note"><b>Note:</b> 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. <br /> For more information about the Horizon IODEV, see [[~~Network~~ management#IODEV specification for Horizon inbound threads\|IODEV specification for Horizon inbound threads]] and also [[Defining the user environment (CCAIN)#Horizon (IODEV=27)\|Horizon (IODEV=27)]].</p>		<p class="note"><b>Note:</b> 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. <br /> For more information about the Horizon IODEV, see [[Horizon network management#IODEV specification for Horizon inbound threads\|IODEV specification for Horizon inbound threads]] and also [[Defining the user environment (CCAIN)#Horizon (IODEV=27)\|Horizon (IODEV=27)]].</p>

	===Horizon programs can have multiple roles and partners===		===Horizon programs can have multiple roles and partners===

JAL: link repair

2015-10-13T20:26:10Z

link repair

← Older revision		Revision as of 20:26, 13 October 2015
Line 219:		Line 219:
	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.</p>		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.</p>
	<p>		<p>
	The architecture to which these and other LU 6.2 interfaces conform is documented in detail in IBM publication <var class="book">GC30-3084: the Transaction Programmer's Reference Manual for LU Type 6.2</var>. A mapping between Horizon's User Language statements and their LU 6.2 architectural specifications is provided in [[LU 6.2 ~~Verb set~~ 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.</p>		The architecture to which these and other LU 6.2 interfaces conform is documented in detail in IBM publication <var class="book">GC30-3084: the Transaction Programmer's Reference Manual for LU Type 6.2</var>. 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.</p>

	===Sessions connect LUs; conversations connect programs===		===Sessions connect LUs; conversations connect programs===

ELowell: Created page with "==Overview==
This topic introduces Model 204 intersystem processing options and provides a discussion of basic concepts and terminology. Information about the particular..."

2015-09-29T22:20:07Z

Created page with "==Overview== This topic introduces Model 204 intersystem processing options and provides a discussion of basic concepts and terminology. Information about the particular..."

New page

==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:
<ul>
<li>The Virtual Telecommunication Access Method (VTAM)</li>
<li>The Model 204 Cross Region Access Method (CRAM)</li>
<li>The VM Inter User Communication Vehicle (IUCV) </li>
</ul>

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 manual, 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: 
<ul>
<li>Model 204</li>
<li>CICS</li>
<li>CMS</li>
<li>PC DOS or OS/2</li>
</ul>

===Network diagram===

The following figure is a diagram of a hypothetical network.

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

Network Transactions
[[File:Horizon_fig2-1_Netwk_transactions.gif]] 

Essential elements of the previous figure are described below:
<ul>
<li>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.</li>
<li>M204C is an additional node that runs on the same machine and in the same domain as M204A.</li>
<li>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). </li>
<li>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.</li>
<li>
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. </li>
<li>
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|SNA concepts and terminology]] later in this chapter. The two programs that converse are referred to as conversation partners.</li>
</ul>
==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:
<ul>
<li>[[Program Communications Facilities]]</li>
<li>[[Using Program Communication facilities]]</li>
<li>[[DEFINE LINK command: TPROCESS]]</li>
<li>[[DEFINE LINK command: Transfer Control]]</li>
</ul>

===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====
<ul>
<li>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.</li>
<li>The User Language request must initiate the partner process. Under CICS, the request may transfer control to the partner.</li>
<li>Communication passes through the terminal connection.</li>
<li>The terminal thread IODEV number must be 11 or 41. For more information about these IODEVs, see the IODEV parameter in the Rocket Model 204 Command Reference Manual. </li>
<li>Under CICS, the partner process may be written in any supported host language. Under CMS, the language must be REXX or EXEC2.</li>
<li>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.</li>
</ul>

====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:
<ul>
<li>
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.
</li>
<li>
Passing DB2 or VSAM data from a CICS region into a Model 204 application.</li>
<li>
Editing a file using XEDIT under CMS, and then uploading the data into Model 204.</li>
<li>
Downloading data from Model 204 to CMS or CICS for manipulation by a statistical or graphics package. </li>
</ul>

===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====
<ul>
<li>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.</li>
<li>The User Language request transfers control to the partner.</li>
<li>Communication passes through the terminal connection or through SNA Communications Server.</li>
<li>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 in the Rocket Model 204 Command Reference Manual.</li>
</ul>

====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:
<ul>
<li>Under CICS, transferring a user back to an initiating transaction.</li>
<li>Transferring a SNA Communications Server user between Model 204 regions without the user's awareness of the change of environment.</li>
<li>Testing Horizon applications: a programmer can transfer between Model 204 partners checking the results of a Horizon testing phase.</li>
</ul>

===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 full details on IPv6 network address support for Horizon, see the <var class="book">[http://docs.rocketsoftware.com/nxt/gateway.dll/RKBnew556%2Fmodel%20204%2Fprevious%20versions%2Fv7.4%2Fm204_releasenotes_v74.pdf Rocket Model 204 Release Notes: New Features Version 7 Release 4.0</var>].

====Operation and restrictions====
<ul>
<li>
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.</li>
<li>
The User Language request may initiate the conversation, or the partner may initiate it.</li>
<li>
Communication passes through the SNA network (as described in [[#SNA concepts and terminology|SNA concepts and terminology]]).</li>
<li>
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 [[Network management]] and also [[Defining the user environment (CCAIN)#Horizon (IODEV=27)|Horizon (IODEV=27)]]. </li>
<li>
The partner process can be written in any language that has access to an LU 6.2 communication interface. Currently supported partner languages include:
<ul>
<li>User Language</li>
<li>assembler</li>
<li>C</li>
<li>COBOL</li>
<li>PL/1</li>
</ul>
</li>
<li>
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. </li>
</ul>
====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:
<ul>
<li>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.
</li>
<li>
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.
</li>
<li>
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.
</li>
</ul>
==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 <var class="term">Logical Unit</var> (<var class="term">LU</var>), 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
[[File:Horizon_fig2-2_app_prog_LU.gif]] 

The LU provides various services to the application program:
<ul>
<li>An application programming interface for communications.</li>
<li>Enforcement of rules governing application program behavior.</li>
<li>Packaging of application data in network format for transmission, and unpackaging and presentation to the application program of received application data.</li>
<li>Error detection, and, when possible, recovery. </li>
</ul>

===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 <var class="book">GC30-3084: the Transaction Programmer's Reference Manual for LU Type 6.2</var>. A mapping between Horizon's User Language statements and their LU 6.2 architectural specifications is provided in [[LU 6.2 Verb set 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 <var class="term">session</var>.

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 <var class="term">session limit</var> 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 <var class="term">conversation</var> is a communication between two application programs. The program that initiates the conversation is called the <var class="term">client</var> program. The client's partner in the conversation is called the <var class="term">server</var> 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 <var class="term">bound</var>, 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 <var class="term">single session</var> (one session active at a time, reused serially for conversations) or by <var class="term">parallel sessions</var> (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 <var class="book">SNA Format and Protocol Reference Manual: Architecture Logic for LU Type 6.2</var>).

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
[[File:Horizon_fig2-3_Horizon_dist_trans.gif]] 

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 <var class="term">outbound</var> 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 <var class="term">inbound</var> program.

A Model 204 system in which a client program runs is referred to as a <var class="term">client system</var>; one in which a server program runs is called a <var class="term">server system</var>.

A system is designated client or server only in the context of a particular transaction. In [[#Horizon Distributed Transaction|Horizon Distributed Transaction]], 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 [[Network management#IODEV specification for Horizon inbound threads|IODEV specification for Horizon inbound threads]] and also [[Defining the user environment (CCAIN)#Horizon (IODEV=27)|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
[[File:Horizon_fig2-4_multi_node_trans.gif]] 

===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|Synonyms for Horizon terms]] lists possible elements in a typical Horizon network transaction along with their synonyms and definitions.
<table>
<caption>Synonyms for Horizon terms</caption>
<tr class="head">
<th>Term</th>
<th>Also known as</th>
<th>Meaning</th>
</tr>
<tr>
<td>end user</td>
<td>terminal user</td>
<td>User on a terminal thread connected to the client system</td>
</tr>
<tr>
<td>client program</td>
<td nowrap>[client | outbound} {user | program | process | application</td>
<td>Model 204 application that initiates a conversation</td>
</tr>
<tr>
<td>client system</td>
<td>{client | outbound} {system | Online | node | LU}</td>
<td>Host and provider of network services to a client program</td>
</tr>
<tr>
<td>server program</td>
<td>{server | service | inbound} {user | program | process | application}</td>
<td>Model 204 application that is initiated by an incoming conversation request</td>
</tr>
<tr>
<td>server system</td>
<td>{server | service | inbound} {system | Online | node | LU}</td>
<td>Host and provider of network services to a server program</td>
</tr>
</table>

[[Category: Horizon]]

← Older revision		Revision as of 20:07, 24 March 2017
Line 29:		Line 29:
	The following figure is a diagram of a hypothetical network.</p>		The following figure is a diagram of a hypothetical network.</p>
	<p>		<p>
	It consists of three nodes and the software communication interface SNA Communications ~~Serverdoc~~. The network links system M204A with system M204B; the transactions originate from terminals X, Y, and Z. </p>		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. </p>

	<p class="caption" style="width:468px">Network Transactions</p>		<p class="caption" style="width:468px">Network Transactions</p>
Line 37:		Line 37:
	<ul>		<ul>
	<li>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.</li>		<li>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.</li>

	<li>M204C is an additional node that runs on the same machine and in the same domain as M204A.</li>		<li>M204C is an additional node that runs on the same machine and in the same domain as M204A.</li>
	<li>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). </li>
			<li>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). </li>

	<li>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.</li>		<li>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.</li>
	<li>
	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. </li>		<li>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. </li>
	<li>
	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\|SNA concepts and terminology]] later in this chapter. The two programs that converse are referred to as conversation partners.</li>		<li>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\|SNA concepts and terminology]] later in this chapter. The two programs that converse are referred to as conversation partners.</li>
	</ul>		</ul>

	==Model 204's intersystem facilities==		==Model 204's intersystem facilities==
	<p>		<p>

Model 204 intersystem processing - Revision history

DCameron: /* Horizon */

JAL: add clarifier

JAL: /* Horizon terms have multiple synonyms */ misc formatting

Admin: /* TCP/IP support */ link repair

JAL: /* Network diagram */ typo

ELowell at 19:13, 15 June 2016

ELowell: /* Operation and restrictions */

JAL: link repair

JAL: link repair

ELowell: Created page with "==Overview== This topic introduces Model 204 intersystem processing options and provides a discussion of basic concepts and terminology. Information about the particular..."

ELowell: Created page with "==Overview==
This topic introduces Model 204 intersystem processing options and provides a discussion of basic concepts and terminology. Information about the particular..."