PreviousConfiguring CICS Regions Configuring CICS for FileshareNext"

Chapter 5: Configuring CICS for Communications

This chapter describes the facilities provided by CICS Option for distributed processing and how to set up CICS Option to use these facilities.

5.1 Overview

The distributed processing facilities provided by CICS Option allow communication between two CICS Option systems, or between CICS Option and an IBM-compatible CICS system. These facilities are:

5.2 Function Shipping

Function shipping enables a transaction executing on a local CICS Option to access remote resources (files, temporary storage queues and transient data queues).

A special form of function shipping, called asynchronous processing, enables a local transaction program to initiate a transaction program on a remote system by means of the EXEC CICS START command.

The operation of function shipping is illustrated in Figure 5-1.


Figure 5-1: Function Shipping

Functions can be shipped both to and from CICS Option by another CICS Option or by an IBM-compatible CICS system.

5.2.1 Restrictions on Function Shipping

The following restrictions apply to function shipping as implemented in CICS Option:

5.2.2 Configuration for Function Shipping

You can configure your CICS Option for outbound and inbound function shipping.

In the following descriptions, only the Resource Definition Table (RDT) entries required specifically for configuring communications are described. The ones described here are in addition to the Terminal Control Table entries described in the section Network Links.

5.2.2.1 Configuring for Outbound Function Shipping

Outbound function shipping is when your local transaction programs ship functions to remote systems. To configure your CICS Option to support this:

  1. Set up the local and remote ends of the network link to each of the remote systems to which functions are shipped. See the section Network Links for instructions on how to do this.

  2. Set up the local resource definitions shown in the following tables as required, in addition to the Terminal table entries described in the section Network Links.

Table
Required Entry
FCT Each remote file to be accessed, specifying:
  • Remote system ID
    The ID of the Terminal table entry for the remote system.
  • Remote filename
    The name by which the file is known on the remote system. If you do not specify this field, the file is assumed to have the same name on both systems.
DCT Each remote TD queue that can be accessed by local transactions, specifying:
  • Remote system ID
    The ID of the Terminal table entry for the remote system.
  • Remote queue ID
    The name by which the TD queue is known on the remote system. If you do not specify this field, the TD queue is assumed to have the same name on both systems.
TST Each remote TS queue that can be accessed by local transactions, specifying:
  • Remote system ID
    The ID of the Terminal table entry for the remote system.
  • Remote data ID
    The name by which the TS queue is known on the remote system. If you do not specify this field, the TS queue is assumed to have the same name on both systems.
PCT Each remote transaction that can be initiated (using ATI) by a local transaction, specifying:
  • Remote system ID
    The ID of the Terminal table entry for the remote system.
  • Remote transaction ID
    The name by which the transaction is known on the remote system. If you do not specify this field, the transaction is assumed to have the same name on both systems.

Note: If local transactions using ANSI ship functions to an IBM-compatible EBCDIC CICS system, you must set up data conversion facilities on the remote system.


5.2.2.2 Configuring for Inbound Function Shipping

Inbound function shipping is when remote CICS Options (or IBM-compatible systems) can ship functions to your CICS Option. Only multi-tasking systems can accept inbound function shipping.

To configure CICS Option to support this:

  1. Set up the local and remote ends of the network link to each of the remote systems from which functions are shipped. See the section Network Links for instructions on how to do this.

  2. Add the resource group DFHISC to the startup list for the SIT.

  3. Set the System Initialization Table to activate the required CCI gateway if you are using one.

5.3 Transaction Routing

Transaction routing enables a CICS Option user to invoke transactions on a remote system. The remote system treats the local system as a remote terminal.

The operation of transaction routing is illustrated in Figure 5-2.


Figure 5-2: Transaction Routing

Transactions can be routed to and from CICS Option by another CICS Option, or by an IBM-compatible CICS system.

5.3.1 Implementing Transaction Routing

You can implement transaction routing on CICS Option in one of two ways:

5.3.1.1 Using the Routing Transaction CRTE

You can use the supplied transaction CRTE to start a routing session on a remote system. When the routing session has been established, your local system appears as a remote terminal to the remote system. All transactions invoked during this session are executed on the remote system.

The use of CRTE to implement transaction routing is illustrated in Figure 5-3.


Figure 5-3: Transaction Routing via CRTE

No configuration of the local or remote system (other than the link itself) is required when using CRTE. You should use CRTE, instead of making PCT definitions, in the following cases:

Note that, because the routing session has to be explicitly established and canceled, you might have to perform additional signon operations.

CRTE supports both conversational and pseudo-conversational transactions. Transactions invoked by PA or PF keys cannot be invoked through CRTE.

5.3.1.2 Defining Remote Terminals

Each time a terminal invokes a transaction on the remote system, the remote system first looks to see if a remote definition is present before asking for a definition to be shipped.

You can define a remote terminal by:

3270 terminals and printers default to the shipping method, but you can duplicate the definitions if you choose.

With either method, each terminal name must be unique across the entire network.

Shipping definitions has some advantages over duplicating definitions:

5.3.2 Restrictions on Transaction Routing

There are several restrictions that apply to the transaction routing as implemented in CICS Option:

5.3.3 Configuration for Transaction Routing

You can configure your CICS Option for outbound and inbound transaction routing. In the following descriptions, only the Resource Definition Table (RDT) entries required specifically for configuring communications are described. The ones described here are in addition to the Terminal Control Table entries described in the section Network Links.

5.3.3.1 Configuring for Outbound Transaction Routing

Outbound transaction routing consists of routing transactions to remote systems. To configure your CICS Option to support this:

  1. Set up the local and remote ends of the network link to each of the remote systems to which transactions are routed. See the section Network Links for instructions on how to do this.
  2. Set up the following local resource definitions, in addition to the Terminal table entries described in the section Network Links.
Table
Required Entry
PCT Each remote transaction that can be initiated (using ATI) by a local transaction, specifying:
  • Remote system ID
    The ID of the Terminal table entry for the remote system.
  • Remote transaction ID
    The name by which the transaction is known on the remote system. If you do not specify this field, the transaction is assumed to have the same name on both systems.

5.3.3.2 Configuring for Inbound Transaction Routing

Inbound transaction routing consists of remote CICS Options or IBM-compatible CICS systems routing transactions to your CICS Option. To configure your CICS Option to support this:

  1. Set up the local and remote ends of the network link to each of the remote systems from which transactions are routed. See the section Network Links for instructions on how to do this.
  2. Add the resource group DFHISC to the startup list for the SIT.
  3. If this is an LU 6.2 link, you may need to define the inbound transactions to your communications software. See the section Network Links.

5.4 Distributed Program Linking

Distributed program linking (DPL) enables a transaction program running on CICS Option to link to a transaction program running on a remote system. This provides an easy way to access DL/I (IMS) and SQL databases and BDAM files on a remote CICS system.

A transaction program running on CICS Option can link to, and receive link requests from, programs on another CICS Option, or on an IBM-compatible CICS system.

5.4.1 Restrictions on Distributed Program Linking

There are certain restrictions on the types of program to which you can link using the distributed program linking feature of CICS Option.

You cannot link to programs that:

In addition to these restrictions, you should also be aware that when you are accessing DB2 from a transaction running on CICS Option, security access to the DB2 plan is based on the transaction ID that CICS Option passes to the CPMI transaction of DB2. The mainframe CICS EIB transaction ID is set to the transaction ID passed by CICS Option, and this is used for the duration of the link. This mechanism enables greater selectivity for DB2 plans.

In all other respects (such as security attributes and task priority), the mainframe CICS CPMI transaction operates normally.

5.4.2 Abends When Using Distributed Program Linking

If the remote program terminates abnormally, the remote system's mirror program returns the last abend code to CICS Option, using the ASSIGN ABCODE command.

If the remote program terminates, the returned abend code is the last abend to occur in the remote program, which might have handled other abends before terminating.

5.4.3 Configuration for Distributed Program Linking

You can configure your CICS Option for outbound and inbound linking. In the following descriptions, only the Resource Definition Table (RDT) entries required specifically for configuring communications are described. The ones described here are in addition to the Terminal Control Table entries described in the section Network Links.

5.4.3.1 Configuring for Outbound Linking

Outbound linking consists of local transaction programs linking to programs on remote systems. To configure your CICS Option to support this:

  1. Set up the local and remote ends of the network link to each of the remote systems to which programs might link. See the section Network Links for instructions on how to do this.
  2. Set up the following local resource definitions:
Table
Required Entry
PPT Each remote program to which a local program can link, specifying:
  • Remote system ID
    The ID of the Terminal table entry for the remote system.
  • Remote transaction ID
    The name by which the program is known on the remote system. If you do not specify this field, the program is assumed to have the same name on both systems.

Note: If local programs that use a different character set (ANSI or EBCDIC) are linked, you may need to set up data conversion facilities on the remote system.


5.4.3.2 Configuring for Inbound Linking

Inbound linking consists of transaction programs on remote CICS Option linking to local programs. To configure your CICS Option to support this:

  1. Set up the local and remote ends of the network link to each of the remote systems from which programs can link. See the section Network Links for instructions on how to do this.
  2. Add the resource group DFHISC to the SIT's startup list.

5.5 Distributed Transaction Processing

Distributed Transaction Processing (DTP) allows a CICS transaction running in one system to communicate with a transaction running in another system. The transactions are written and designed to communicate with each other over the intersystem communication link. DTP provides facilities so that two programs can communicate with each other, signal each other with regard to their status, and jointly commit modifications to protected resources.

DTP takes place between programs that are designed to be a matched pair. Their activities, command utilization, error protocols, and message formats must all be coordinated. CICS Option enables transactions running in the CICS Option to initiate and communicate synchronously with transactions in remote systems that support the APPC protocols. The CICS Option also supports DTP requests raised by remote systems.

5.5.1 Restrictions on DTP

The following restrictions apply to Distributed Transaction Processing:

5.5.2 Configuring for DTP

Aside from the general system requirements for supporting LUTYPE 6.2 connections, DTP requires almost no special resource definitions. The LU 6.2 links to any interconnected system must be defined according to the examples provided in the section Network Links. When you have a functional LUTYPE 6.2 session established with another system, then you only need to define any programs and transactions that are to participate in a DTP conversation through resource definition table entries on both the local and remote system.

5.6 Network Links

The distributed processing facilities described above require that a network link is set up between the client and server systems. This section describes how to set up these links.

5.6.1 Types of Network

This section describes the setting up of network links for the following types of communications network:

There is an additional section at the end discussing aspects of security that you need to bear in mind.

5.6.2 Supported Link Types

The table below describes the types of network link that you can set up between two CICS Options. These are the network links that you can use for function shipping, transaction routing, distributed program linking and distributed transaction processing.

Between CICS Option and IBM-compatible CICS systems, the only network link you can use is APPC(LU6.2).

5.6.3 PC to Mainframe Communications

This section describes the generic Terminal Control Table (TCT) definitions you need to make for mainframe communications.


Figure 5-4: Sample TCT entries for host communications

The fields used in this example are described below.

Connect. id: The unique logical name of this terminal. In this example, WMCA is used.
Description: Up to 60 characters of optional text.
Connection type: The type of connection used by this terminal; in this example LU 6.2 is chosen for a remote connection over an APPC (LU6.2) link.
LU alias: The LU name by which the terminal is known in the APPC configuration. In this example, U05SM051 is the applid that the connection presents to the remote system. This must match the 370/3090 host CICS netname value for the connection as seen from the host. The field is the name of the local LU alias, as seen from the remote partner.
Partner alias: The name used by local transactions to refer to the partner LU. In this example, WMCCICSA.
Alias applid: The applid used by APPC links. In this example, U05SM051.
Mode table: Names the APPC transmission service profile (mode table) that describes the APPC link between the local and partner LUs. In this example, this is S36DUMMY.
Session maximum: There can be a maximum number of five sessions supported for the modeset.
Net name: Identifies this terminal to the network. In this example, the netname is U05SM051.
Priority: The terminal priority of transactions run from this terminal.
Inservice: This terminal can initiate transactions and receive messages.
Nat language: Messages are displayed on the terminal in English.
Session attach: The level of attach-time user security required on this terminal; "L" means that the authority of the user is taken to be that of the link.
Operator priority: The operator priority for transactions run from this terminal. You should specify this for terminals that cannot sign on, such as a printer.

5.6.4 Peer-to-Peer Communications

This section describes the generic definitions you need to make to enable peer-to-peer communications.

5.6.4.1 Terminal Control Table Entries

CICS Option supports peer-to-peer communication. You can use this by specifying certain fields in the Terminal Control Table connection entry. The fields to set are:

netname The region name of the target region
connection type This must be CCI or LU6.2
session maximum The maximum number of send sessions
mode table The CCI protocol name (for example, CCINETB, CCITCP) or LU62MODE

If a connection is loaded, the associated gateway is forced. If a connection is specified to self, it is bypassed. This enables a number of regions to share a single group that specifies the connections for all the regions; it also enables regions to talk to each other.

Peer-to-peer communication supports autoinstall. The connection does not need to be specified in both regions. If the connection is specified in both regions, and both regions try to initiate the connection, the contention is resolved.

5.6.4.2 Sample CCI TCT Entries

In this example, two regions, PEERRGN1 and PEERRGN2, are to be connected using CCITCP. Two TCT definitions are shown, although only one is required. If only one TCT is defined, then the other region must start a CCI gateway by selecting the required protocol in the SIT.


Figure 5-5: Sample TCT entry for RGN1

In this example, the following fields must be specified:

Netname: The name of the region to connect to, in this case PEERRGN1.
Connection type: CCI. This example is using the CCI connection type.
Protocol: Communication protocol. In this case, it is CCITCP.

An example of a TCT definition for a second region is shown in Figure 5-6.


Figure 5-6: Sample TCT definition - RGN2

In this example, the following fields must be specified:

Netname: The name of the region to connect to, in this case PEERRGN2.
Connection type: CCI. This example is using the CCI connection type.
Protocol: Communication protocol. In this case, it is CCITCP.

5.6.4.3 Sample LU 6.2 Entries

In this example, two regions, REGN1 and REGN2, are to be connected using an LU 6.2 protocol. Both TCT definitions are required, as well as a supported LU 6.2 manager.

Figure 5-7 shows a sample TCT entry for the first partner, using terminal REG1. Figure 5-8 shows a sample TCT entry for the second partner, using terminal REG2.


Figure 5-7: Sample TCT entry - First Partner


Figure 5-8: Sample TCT entry - Second Partner


Copyright © 1999 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.

PreviousConfiguring CICS Regions Configuring CICS for FileshareNext"