CONNECTION resources

A CONNECTION defines a remote system with which your CICS® system communicates, using intersystem communication (ISC) or multiregion operation (MRO).

ISC uses the APPC or LUTYPE6.1 communication protocol. MRO uses the IRC, XM, or XCF/MRO access method.

See also IPCONN resources. Like a CONNECTION, an IPCONN defines a communication link to a remote system, but in this case the connection uses the TCP/IP protocol.

When you define a CONNECTION, you give enough information to identify the system and specify its basic attributes. You put details in the SESSIONS definition about the sessions you use to communicate with the system. CICS uses the CONNECTION name to identify the other system when the definition has been installed. For other CICS systems connected via MRO, this name is typically the same as that specified in the other CICS system as the SYSIDNT system initialization parameter. For other systems connected via ISC, this name is typically based on an acronym that describes the location of or the organization that owns the system (for example, USA1 or IBMC).

The REMOTESYSTEM name on a TRANSACTION definition, or on a TERMINAL definition, can refer to a CONNECTION definition through its CONNECTION name (or to an IPCONN definition through its IPCONN name). These attributes are used for transaction routing.

The REMOTESYSTEM name on a PROGRAM definition can refer to a CONNECTION definition through its CONNECTION name (or to an IPCONN definition through its IPCONN name). This attribute is used for distributed program link.

The CONNECTION definition does not name associated SESSIONS.

Before you start creating definitions for intercommunication resources, see Defining intercommunication resources for further guidance. There you can find many useful examples of the attributes you must specify for different types of links and sessions.

Special considerations for different connection types are:

MRO links and sessions

You define an MRO link using one CONNECTION definition, and its associated parallel sessions using one SESSIONS definition.

ACCESSMETHOD: On the CONNECTION definition, specify this as IRC (for interregion communication), or XM (for cross-memory services). IRC is used to open and close the links.
PROTOCOL: On the SESSIONS definition, specify LU61 as the PROTOCOL. On the CONNECTION definition, leave the PROTOCOL value blank.
SENDPFX, SENDCOUNT, RECEIVEPFX, RECEIVECOUNT: In one SESSIONS definition, you specify a number of send sessions and a number of receive sessions. The values that you specify in these attributes are used to determine the names of the TCT entries created when the definition is installed. (See Installing connection definitions.)

APPC links and parallel sessions

For APPC, the sessions are grouped into modesets. You define each modeset with a SESSIONS definition, so you have as many SESSIONS definitions as you require modesets. You define the link as a CONNECTION definition. The following attributes are significant:

ACCESSMETHOD: On the CONNECTION definition, specify this as VTAM®.
MAXIMUM: Use this to control the number of sessions in the modeset.
MODENAME: On the SESSIONS definition for each modeset, name the modeset with the MODENAME. This is the name by which the modeset is known to CICS when the definition is installed in the active system.
PROTOCOL: On both the CONNECTION and SESSIONS definitions, specify APPC as the protocol.

APPC (LUTYPE6.2) single session terminal

You can define an APPC terminal as a CONNECTION-SESSIONS pair or as a TERMINAL-TYPETERM pair. The TERMINAL-TYPETERM method is described in APPC (LUTYPE6.2) single session terminal. If you want to use the CONNECTION-SESSIONS method, the following attributes are significant:

ACCESSMETHOD: On the CONNECTION definition, specify this as VTAM.
MAXIMUM: For a single session terminal, specifying 1,0 or 1,1 has the same effect. (For further information, see CONNECTION attributes.)
MODENAME: On the SESSIONS definition, specify the MODENAME. This is the name that CICS uses to identify the session when the definition is installed in the active system.
PROTOCOL: On both the CONNECTION and SESSIONS definitions, specify APPC as the protocol.
SINGLESESS: YES indicates that the CONNECTION definition is for a single session terminal.

LUTYPE6.1 links and sessions

LUTYPE6.1 links and sessions can be defined in one of two ways:

In one CONNECTION and one SESSIONS definition
In one CONNECTION and a number of SESSIONS definitions: one for each session needed

If your sessions are all to have identical attributes, define each link in one CONNECTION definition and all its associated sessions in one SESSIONS definition.

ACCESSMETHOD: On the CONNECTION definition, specify this as VTAM.
PROTOCOL: On the SESSIONS definition and on the CONNECTION definition, specify this as LU61.
RECEIVECOUNT, RECEIVEPFX, SENDCOUNT, SENDPFX: These attributes are used as for MRO links and sessions.

If your sessions are to have different attributes from each other, you must create a separate SESSIONS definition for each one. With the exception of NETNAMEQ, this method is the same as that for CICS-IMS sessions, described here.

Note: For CICS-CICS ISC links and sessions, you are recommended to use APPC rather than LUTYPE6.1.

LUTYPE6.1 CICS-IMS links and sessions

IMS needs each session to be defined in a separate SESSIONS definition, because each session must have a different NETNAMEQ.

You define the link as a CONNECTION definition, and create a number of SESSIONS definitions: one for each SEND session and one for each RECEIVE session.

ACCESSMETHOD

On the CONNECTION definition, specify this as VTAM.

NETNAMEQ

This is the name that the remote IMS system uses to identify the session.

PROTOCOL

On both the CONNECTION and SESSIONS definitions, specify LU61 as the protocol.

SESSNAME

This is the name that CICS uses to identify the session when the definition is installed in the active system.

RECEIVECOUNT

SENDCOUNT

Use these attributes to specify whether a session is a SEND session or a RECEIVE session.

A RECEIVE session is one in which the local CICS is the primary and is the contention loser. It is specified by defining RECEIVECOUNT(1) and leaving SENDCOUNT to default to blank. (You do not need to specify a SENDPFX or a RECEIVEPFX.)

A SEND session is one in which the local CICS is the secondary and is the contention winner. Specify it by defining SENDCOUNT(1) and leaving RECEIVECOUNT to default to blank.

INDIRECT connections

An INDIRECT connection is a remote system for which you have not defined a direct link with the local system. Instead, the two systems communicate with each other by way of one or more intermediate systems. You can use this method for transaction routing. The remote system, indirectly connected, is always the terminal-owning region; the local system is always the application-owning region or an intermediate region on the transaction routing path.

Indirect connections are required only if you use non-z/OS® Communications Server terminals for transaction routing across intermediate systems. Optionally, you can use them with z/OS Communications Server terminals, where several transaction routing paths are possible, to identify the preferred path to the terminal-owning region. For information about why you might want to define indirect connections, and about the resources required for transaction routing, see Defining indirect links for transaction routing.

In the local system, you must have ordinary CONNECTION and SESSIONS definitions for the intermediate systems to which you are directly connected. The ACCESSMETHOD should be IRC or XM with PROTOCOL(LU61), or VTAM with PROTOCOL(APPC).

For the INDIRECT connection (also known as an indirect link or an indirect system) you need, in the local system, a CONNECTION definition only. You do not need a SESSIONS definition: the sessions that are used are those of the intermediate system. The following attributes of the CONNECTION definition are significant:

ACCESSMETHOD: Specify this as INDIRECT.
INDSYS: Specify the CONNECTION definition for the MRO or APPC link that is the start of a path to the terminal-owning system.
NETNAME: Specify the APPLID of the terminal-owning system.