Defining CICS-to-IMS LUTYPE6.1 links

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.

Figure 46. Defining an LUTYPE6.1 link with individual sessions
 
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)

Defining compatible CICS and IMS nodes

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.

System names

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.

Number of sessions

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.

Session names

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.

Other session parameters

This section lists the remaining options of the DEFINE CONNECTION and DEFINE SESSIONS commands that are of significance for CICS-to-IMS sessions.

ATTACHSEC
Must be specified as LOCAL.
BUILDCHAIN(YES)
Specifies that multiple RU chains are to be assembled before being passed to the application program. A complete chain is passed to the application program in response to each RECEIVE command, and the application performs any required deblocking.

BUILDCHAIN(YES) must be specified (or allowed to default) for LUTYPE6.1 sessions.

DATASTREAM(USER)
Must be specified with the value USER or allowed to default.

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.

QUEUELIMIT(NO|0-9999)
Specifies the maximum number of requests permitted to queue for free sessions to the remote system. Further information is given in Intersystem session queue management.
MAXQTIME(NO|0-9999)
Specifies the maximum time, in seconds, between the queue for sessions to the remote system becoming full (that is, reaching the limit specified on QUEUELIMIT) and the queue being purged because the remote system is unresponsive. Further information is given in Intersystem session queue management.
RECORDFORMAT(U|VB)
Specifies the type of chaining that CICS is to use for transmissions on this session that are initiated by START commands (asynchronous processing).

Two types of data-handling algorithms are supported between CICS and IMS:

Chained
Messages are sent as SNA chains. The user can use private blocking and deblocking algorithms. This format corresponds to RECORDFORMAT(U).
Variable-length variable-blocked records (VLVB)
Messages are sent in variable-length variable-blocked format with a halfword length field before each record. This format corresponds to RECORDFORMAT(VB).

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.

SENDCOUNT and RECEIVECOUNT
Used to specify whether the session is a SEND session or a RECEIVE session.

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.

Start of changeSENDSIZE and RECEIVESIZEEnd of change
Start of changeSpecify the maximum VTAM request unit (RU) sizes for these sessions. End of change
Figure 47. Defining compatible CICS and IMS nodes
          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.

Note:
For an example of a VTAM® logmode table entry for IMS, see Figure 31.

Defining multiple links to an IMS system

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:

  1. For CICS-initiated distributed transaction processing (synchronous processing).

    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.

  2. For CICS-initiated asynchronous processing.

    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.

  3. For IMS-initiated asynchronous processing.

    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.

Figure 48. Defining multiple links to an IMS node
  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)
         .                              .
         .                              .

Related concepts
Introduction to link definition
Related tasks
Defining logical unit type 6.1 links
Identifying remote systems
Defining links for multiregion operation
Defining APPC links
Defining indirect links for transaction routing
[[ Contents Previous Page | Next Page Index ]]