A link to an IMS™ system requires a definition of the connection (or system) and a separate definition of each of the sessions.
The form of definition for individual LUTYPE6.1 sessions is shown in Figure 46.
DEFINE
CONNECTION(sysidnt)
GROUP(groupname)
NETNAME(name)
ACCESSMETHOD(VTAM)
PROTOCOL(LU61)
DATASTREAM(USER|3270|SCS|STRFIELD|LMS)
RECORDFORMAT(U|VB)
QUEUELIMIT(NO|0-9999)
MAXQTIME(NO|0-9999)
INSERVICE(YES)
SECURITYNAME(name)
ATTACHSEC(LOCAL)
Each individual session is then defined as follows:
DEFINE
SESSIONS(csdname)
GROUP(groupname)
CONNECTION(sysidnt)
SESSNAME(name)
NETNAMEQ(name)
PROTOCOL(LU61)
RECEIVECOUNT(1|0)
SENDCOUNT(0|1)
SENDSIZE(size)
RECEIVESIZE(size)
SESSPRIORITY(number)
AUTOCONNECT(NO|YES|ALL)
BUILDCHAIN(YES)
IOAREALEN(value)
This section describes the writing of suitable CICS® definitions that are compatible with the corresponding IMS definitions.
An overview of IMS system definition is given in Installation considerations for intersystem communication. The relationships between CICS and IMS definitions are summarized in Figure 47.
The network name of the CICS system (its applid) is specified on the APPLID CICS system initialization parameter. This name must be specified on the NAME operand of the IMS TERMINAL macro that defines the CICS system. For CICS systems that use XRF, the name will be the CICS generic applid. For non-XRF CICS systems, the name will be the single applid specified on the APPLID SIT parameter (see Generic and specific applids for XRF).
The network name of the IMS system may be specified in various ways:
You must specify the network name of the IMS system on the NETNAME option of the CICS DEFINE CONNECTION command that defines the IMS system.
In IMS, the number of parallel sessions that are required between the CICS and IMS system must be specified in the SESSION operand of the IMS TERMINAL macro. Each session is then represented by a SUBPOOL entry in the IMS VTAMPOOL. In CICS, each of these sessions is represented by an individual session definition.
Each CICS-to-IMS session is uniquely identified by a session-qualifier pair, which is formed from the CICS name for the session and the IMS name for the session.
The CICS name for the session is specified in the SESSNAME option of the DEFINE SESSIONS command. For sessions that are to be initiated by IMS, this name must correspond to the ID parameter of the IMS OPNDST command for the session. For sessions initiated by CICS, the name is supplied on the CICS OPNDST command and is saved by IMS.
The IMS name for the session is specified in the NAME operand of the IMS SUBPOOL macro. You must make the relationship between the session names explicit by coding this name in the NETNAMEQ option of the corresponding DEFINE SESSIONS command.
The CICS and the IMS names for a session can be the same, and this approach is recommended for operational convenience.
This section lists the remaining options of the DEFINE CONNECTION and DEFINE SESSIONS commands that are of significance for CICS-to-IMS sessions.
BUILDCHAIN(YES) must be specified (or allowed to default) for LUTYPE6.1 sessions.
This option is used only when CICS is communicating with IMS by using the START command (asynchronous processing). CICS messages generated by the START command always cause IMS to interpret the data stream profile as input for component 1.
The data stream profile for distributed transaction processing can be specified by the application program by means of the DATASTR option of the BUILD ATTACH command.
Two types of data-handling algorithms are supported between CICS and IMS:
The data stream format for distributed transaction processing can be specified by the application program by means of the RECFM option of the BUILD ATTACH command.
Additional information on these data formats is given in CICS-to-IMS applications.
A SEND session is one in which the local CICS is the secondary and is the contention winner. Specify:
A RECEIVE session is one in which the local CICS is the primary and is the contention loser. Specify:
SEND sessions are recommended for all CICS-to-IMS sessions.
You need not specify a SENDPFX or a RECEIVEPFX; the name of the session is taken from the SESSNAME option.
CICS IMS
DFHSIT TYPE=CSECT COMM APPLID=SYSIMS
,SYSIDNT=CICL 7 RECANY=nnn+22
,APPLID=SYSCICS 1 EDTNAME=ISCEDT
4 TYPE UNITYPE=LUTYPE6
1 TERMINAL NAME=SYSCICS
DEFINE CONNECTION(IMSR) 2 SESSION=2
GROUP(groupname) COMPT1
NETNAME(SYSIMS) 3 COMPT2
ACCESSMETHOD(VTAM) 6 OUTBUF=mmm
PROTOCOL(LU61)
DATASTREAM(USER)
ATTACHSEC(LOCAL)
DEFINE SESSIONS(csdname)
GROUP(groupname) VTAMPOOL
CONNECTION(IMSR) 2
SESSNAME(IMS1) 5 SUBPOOL NAME=CIC1
NETNAMEQ(CIC1) 5 NAME CICLT1 COMPT=1
PROTOCOL(LU61) 4
SENDCOUNT(1)
SENDSIZE(nnn) 7 NAME CICLT1A
RECEIVESIZE(mmm) 6
IOAREALEN(nnn,16364)
DEFINE SESSIONS(csdname)
GROUP(groupname)
CONNECTION(IMSR) 2
SESSNAME(IMS2) 8 SUBPOOL NAME=CIC2
NETNAMEQ(CIC2) 8 NAME CICLT2 COMPT=2
PROTOCOL(LU61) 4
SENDCOUNT(1)
SENDSIZE(nnn) 7 3 DFSHSBxx USERVAR=SYSIMS
RECEIVESIZE(mmm) 6
IOAREALEN(nnn,16364)
Note: For SEND sessions, allow RECEIVECOUNT to default. For RECEIVE
sessions, allow SENDCOUNT to default.
Note: For SEND sessions, allow RECEIVECOUNT to default. For RECEIVE sessions, allow SENDCOUNT to default.
Figure 47 shows the relationship between the CICS and IMS definitions of an intersystem link. Related options and operands are shown by identical numbers.
You can define more than one intersystem link between a CICS and an IMS system. This is done by creating two or more CONNECTION definitions (with their associated SESSION definitions), with the same netname but with different sysidnts (Figure 48). Although all the system definitions resolve to the same netname, and therefore to the same IMS system, the use of a sysidnt name in CICS causes CICS to allocate a session from the link with the specified sysidnt.
It is recommended that you define up to three links (that is, groups of sessions) between a CICS and an IMS system, depending upon the application requirements of your installation:
CICS applications that use the SEND/RECEIVE interface can use the sysidnt of this group to allocate a session to the remote system. The session is held (‘busy’) until the conversation is terminated.
CICS applications that use the START command can name the sysidnt of this group. CICS uses the first ‘non-busy’ session to ship the start request.
IMS sends a positive response to CICS as soon as it has queued the start request, so that the session is in use for a relatively short period. Consequently, the first session in the group shows the heaviest usage, and the frequency of usage decreases towards the last session in the group.
This group is also useful as part of the solution to a performance problem that can arise with CICS-initiated asynchronous processing. An IMS transaction that is initiated as a result of a START command shipped on a particular session uses the same session to ship its "reply" START command to CICS. For the reasons given in (2) above, the CICS START command was probably shipped on the busiest session and, because the session is busy and CICS is the contention winner, the replies from IMS may be queuing for a chance to use the session.
However, facilities exist in IMS for a transaction to alter its default output session, and a switch to a session in this third group can reduce this sort of queuing problem.
DFHSIT TYPE=CSECT,
SYSIDNT=CICL,
APPLID=SYSCICS
CICS-initiated distributed transaction processing
DEFINE CONNECTION(IMSA)
NETNAME(SYSIMS)
ACCESSMETHOD(VTAM)
DEFINE SESSIONS(csdname)
CONNECTION(IMSA)
SESSNAME(IMS1)
NETNAMEQ(DTP1)
PROTOCOL(LU61)
DEFINE SESSIONS(csdname)
.
.
CICS-initiated asynchronous processing
DEFINE CONNECTION(IMSB)
NETNAME(SYSIMS)
ACCESSMETHOD(VTAM)
DEFINE SESSIONS(csdname)
CONNECTION(IMSB)
SESSNAME(IMS1)
NETNAMEQ(ASP1)
PROTOCOL(LU61)
DEFINE SESSIONS(csdname)
.
.
IMS-initiated asynchronous processing
DEFINE CONNECTION(IMSC)
NETNAME(SYSIMS)
ACCESSMETHOD(VTAM)
DEFINE SESSIONS(csdname)
CONNECTION(IMSC)
SESSNAME(IMS1)
NETNAMEQ(IST1)
PROTOCOL(LU61)
DEFINE SESSIONS(csdname)
. .
. .