A CONNECTION defines a remote system with which your CICS® system communicates,
using intersystem communication (ISC) or multiregion operation (MRO).
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,
refers to a CONNECTION definition through its CONNECTION name. These attributes
are used for transaction routing.
The REMOTESYSTEM name on a PROGRAM definition refers to a CONNECTION definition
through its CONNECTION 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 CICS Intercommunication
Guide 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 definition 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 below.
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-VTAM
terminals for transaction routing across intermediate systems. Optionally,
you can use them with VTAM 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 resource definitions required for transaction routing, see the CICS Intercommunication Guide.
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.