Figure 5-1: Function Shipping
This chapter describes the facilities provided by CICS Option for distributed processing and how to set up CICS Option to use these facilities.
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:
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.
The following restrictions apply to function shipping as implemented in CICS Option:
This is advisable because function shipping only incorporates sync level 1 logic. Whether you have single or multiple connected systems, a sync request can be propagated through all the connected systems.
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.
Outbound function shipping is when your local transaction programs ship functions to remote systems. To configure your CICS Option to support this:
| Table |
Required Entry |
|---|---|
| FCT | Each remote file to be accessed, specifying:
|
| DCT | Each remote TD queue that can be accessed by local
transactions, specifying:
|
| TST | Each remote TS queue that can be accessed by local
transactions, specifying:
|
| PCT | Each remote transaction that can be initiated (using
ATI) by a local transaction, specifying:
|
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.
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:
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.
You can implement transaction routing on CICS Option in one of two ways:
See the section Configuration for Transaction Routing later in this chapter for more information on how to set up this implementation of transaction routing.
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.
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:
There are several restrictions that apply to the transaction routing as implemented in CICS Option:
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.
Outbound transaction routing consists of routing transactions to remote systems. To configure your CICS Option to support this:
| Table |
Required Entry |
|---|---|
| PCT | Each remote transaction that can be initiated (using
ATI) by a local transaction, specifying:
|
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:
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.
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.
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.
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.
Outbound linking consists of local transaction programs linking to programs on remote systems. To configure your CICS Option to support this:
| Table |
Required Entry |
|---|---|
| PPT | Each remote program to which a local program can link,
specifying:
|
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.
Inbound linking consists of transaction programs on remote CICS Option linking to local programs. To configure your CICS Option to support this:
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.
The following restrictions apply to Distributed Transaction Processing:
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.
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.
This section describes the setting up of network links for the following types of communications network:
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, you can use the following network links:
Between CICS Option running on two PCs, you can use the following network links:
You use Microsoft SNA Server to set up APPC network links, for both PC-to-mainframe and peer-to-peer communications. For detailed information see the chapter CICS Communications using Microsoft SNA Serverin your Administrator's Guide.
CICS Option uses Micro Focus CCI to handle other types of links: TCP/IP, NetBIOS and IPX. When you use TCP/IP to connect to the mainframe, you also need Micro Focus Mainframe Manager Version 1.17. Configuring CICS Option to use CCI-type links is described below.
This section describes the definitions you need to make to enable communications using CCI. To make these definitions, you need to use the character interface to resource definition: click CICS on the Tools menu, and then click Resource Definition. An ISPF-type screen is displayed. Navigate to the connection entry form: press F7, F2, select a group and press Enter, F9, F3 and F3 again.
You must set the following fields:
| Connect.id | The name of the target system: this is also the value you enter in SYSID when you define a remote transaction |
| Net name | The name of the target region |
| Connection type | This must be CCI |
| Session maximum | The maximum number of send sessions |
| Protocol | The CCI protocol name: CCCITCP, CCINETB or CCIIPX |
You need a connection defitnition for the region that is initiating the conversation, and a gateway in the target region. To enable a gateway:
If you create a connection definition in both regions and both regions try to initiate the connection, CICS Option resolves the contention.
If you create a connection definition for connection to a region, and that region does not have a gateway defined, a gateway is started anyway. If you specify the home region as the target region (that is, Connect.id and Net name are the same), CICS Option ignores the entry. This is useful because it enables a number of regions to share a single group that specifies the connections for all the regions.
Note: You can also use DDE for communications between two regions, as long as both regions run on the same PC. All you need to do is to enable a gateway in one of the regions: check DDE on the Communications page of the SIT dialog.
In this example a region on a PC is to be connected to a region on a mainframe using TCP/IP and Mainframe Manager. The connection definition is shown in Figure 5-4.
Figure 5-4: Example Connection Definition for RSYS
In this example, two regions, PEERRGN1 and PEERRGN2, are to be connected using CCITCP. Two connection definitions are shown, although only one is required.
The connection definition for the first region is shown in Figure 5-5.
Figure 5-5: Example Connection Definition for RGN1
The connection definition for the second region is shown in Figure 5-6.
Figure 5-6: Example Connection Definition for RGN2
Copyright © 2001 Micro Focus International Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.