Figure 92 shows the overall design of this component.
CICS® executes the CICS relay program DFHAPRT (which invokes the user-replaceable dynamic transaction routing program) as follows:
If CICS has been generated with the appropriate options for intercommunication, the initialization of CICS with the ISC=YES system initialization parameter specified causes the following modules to be loaded:
The entry point addresses of these modules are contained in the optional features list that is addressed by CSAOPFLA in the CSA.
The rest of this topic is mainly concerned with APPC transaction routing, which occurs when an APPC device is linked through an LU6.2 session to a transaction that is defined as remote.
Figure 93 shows the modules in the application-owning region for transaction routing for APPC devices.
A remote APPC device is defined in the application-owning region with a remote terminal control table system entry (or remote system entry). There are no TCT mode entries or session TCTTE entries associated with the remote system entry when it is defined.
A session with the remote APPC device is represented by a surrogate session TCTTE (or surrogate session entry). The surrogate is built dynamically when the conversation between the systems is initiated, and is deleted when the conversation terminates.
Figure 94 shows the way in which the TCT entries are related.
The remote system entry is similar to a normal system entry and, together with the TCT skeleton entry, also includes the following information:
The remote system entry may be defined explicitly with CEDA DEFINE and INSTALL commands.
Alternatively, it is installed dynamically when the first transaction is routed from the remote APPC device. In this case, all data required to build the system entry is included in the initial ATTACH data stream from the application-owning region. No INQUIRE or INSTALL data is sent.
The remote system entry is recorded on the catalog and recovered after warm start and restart. It is located by TMP in the REMOTE domain and SYSTEM domain.
The session between the terminal-owning region and the APPC device is represented in the application-owning region by a surrogate session entry.
The surrogate session entry is used to support the routing of commands to the APPC device, and to record security and status information for the conversation.
A surrogate session entry cannot be defined by the user; instead it is created when the conversation is initiated (by an ATTACH request from the APPC device, or an ALLOCATE request from the application-owning region), and is deleted when the conversation ends.
The surrogate session entry is not recorded on the catalog, is not accessible via TC LOCATE, and does not have an entry in the TMP index. It is not recovered after warm start or restart.
CEMT and EXEC CICS INQUIRE or SET commands cannot be used to modify a remote system entry.
This module forms a principal part of the transaction routing component for APPC devices. It passes DFHLUC macro requests issued in an application-owning region to the terminal-owning region.
All DFHLUC macro requests cause DFHZARL to be invoked. DFHZARL passes a request to DFHZXRL if the TCTTE address passed is for a surrogate session, and the request is one that DFHZXRL is known to handle (apart from ALLOCATE). ALLOCATE requests are always routed from DFHZARL to DFHZISP. DFHZISP is then responsible for calling DFHZXRL if the system from which a session is to be allocated is found to be remote. Table 28 summarizes this and shows which of the three main routines in DFHZXRL is called. ZXRL_ALLOCATE, ZXRL_COMMANDS, and ZXRL_FREE are described in ALLOCATE processing in the application-owning region, Other LU6.2 command processing in the application-owning region, and FREE processing in the application-owning region respectively.
DFHLUC request | DFHZXRL’s caller | DFHZXRL routine called |
---|---|---|
ALLOCATE | DFHZISP | ZXRL_ALLOCATE |
ISSUE-ABEND ISSUE-ATTACH ISSUE-CONFIRMATION ISSUE-ERROR ISSUE-SIGNAL RECEIVE SEND WAIT EXTRACT-PROCESS |
DFHZARL | ZXRL_COMMANDS |
FREE | DFHZARL | ZXRL_FREE |
The input and output for DFHZXRL is provided by means of the LUC parameter list, that is, the parameter list which is built by the DFHLUC macro. DFHZARL passes the LUC parameter list to DFHZXRL unaltered. If the LUC parameter list previously contained only the SYSID name, DFHZISP adds the address of the remote system entry to the LUC parameter list before passing it to DFHZXRL.
DFHZXRL calls routine RAPPCRE of DFHZTSP to build the surrogate TCTTE representing the session with the APPC device, and DFHZISP calls routine RDETENT to free it.
The following describes how a transaction is attached in the application-owning region when the attach request has been routed from the terminal-owning region.
For an LU6.2 ISC connection:
For an MRO connection:
ATTACH security processing in DFHZSUP has established two SNTTEs associated with the link session:
TCTTESNT is copied to the surrogate TCTTE. No provision is made for preset user security values to override the TCTTESNT value.
Preset security values defined for the terminal session on the terminal-owning region are processed only on that system, during local attach processing. The SNTTE then associated with the local TCTTE is used to build the routed attach FMH5.
At transaction end, no SNTTEs addressed by the surrogate are deleted when the surrogate is deleted. This is done, if necessary, as part of the termination of the LINK SESSION.
Each system in a "daisy chain" imposes its own link security requirements. An intermediate system with a lower level of security would route the ATTACH with lower security (that is, no USERID or verified bit) which could cause it to be rejected by the next system in the chain.
At transaction end, routine RDETENT of DFHZTSP is called to delete the surrogate session entry. The remote system entry is not deleted, and can be used by a subsequent transaction routing request, by an ATI request, or by an ALLOCATE request issued in the application-owning region.
A session can be allocated as a result of either of the following macro calls:
The DFHLUC call invokes DFHZARL, which passes control to DFHZISP, the module that handles allocation and freeing of sessions. The DFHTC call invokes DFHZISP directly.
DFHZISP locates the TCTSE for the system identified on the ALLOCATE request.
The request is routed to DFHZXRL if the following conditions hold:
The address of the remote TCTSE is inserted in the parameter list passed to DFHZXRL.
If a Privileged Allocate request is made, the transaction abends, because the request is not permitted for a remote system.
For an ALLOCATE request, control passes to subroutine ZXRL_ALLOCATE which establishes a session between the application-owning region and the alternate facility, and builds a surrogate session TCTTE.
Subroutine ZXRL_ALLOCATE:
The connection between the terminal-owning region and application-owning region which supports remote alternate facilities may be an LU6.2 ISC connection or an MRO connection. Subroutine ZXRL_ALLOCATE allocates the session using a DFHTC TYPE=ALLOCATE macro call that can allocate a session on either type of connection.
The default profile DFHCICSR is used; this may specify the modename for an LU6.2 connection. The modename specified on the EXEC CICS ALLOCATE is not used here, but is shipped to the terminal-owning region where it is used to allocate an LU6.2 session between the terminal-owning region and the APPC device.
The queuing option (NOQUEUE|NOSUSPEND) specified on the ALLOCATE request by the caller is used when the DFHTC TYPE=ALLOCATE macro call is issued for the connection. If NOQUEUE is not specified, the request may also be queued when it is issued in the terminal-owning region. If a session failure occurs during this period, the transaction in the application-owning region and the relay transaction in the terminal-owning region abend.
If a session between the application-owning region and terminal-owning region cannot be allocated:
The return code is handled so as to minimize the differences between local and remote APPC devices as seen by the user of the DFHLUC interface. The actions available are:
One of the following macro calls is made in the application-owning region to request that a surrogate session TCTTE should be freed:
The DFHLUC TYPE=FREE call invokes DFHZARL, which passes control to DFHZXRL; and subroutine ZXRL_FREE in DFHZXRL is then called to issue a DFHTC TYPE=FREE request against the surrogate. The DFHTC TYPE=FREE call invokes DFHZISP.
DFHZISP:
Most SAA communications calls, EXEC CICS GDS commands, and EXEC CICS commands relating to LU6.2 sessions cause a call to DFHZARL using the DFHLUC macro.
The EXEC CICS SYNCPOINT, EXEC CICS SYNCPOINT ROLLBACK, and EXEC CICS (GDS) ISSUE PREPARE commands are handled under the control of the syncpoint program, which uses DFHLUC macro requests to send syncpoint flows on LU6.2 sessions, and DFHTC macro calls to end any dangling conversations.
DFHTC macro requests may be issued against surrogate session TCTTEs. Unlike requests for other surrogate TCTTEs, which are passed to DFHZTSP, DFHZARQ handles these requests in the same way as other requests against LU6.2 sessions: they are passed to DFHZARM which in turn calls DFHZARL. Within DFHZARL, requests are handled in a similar way to those initiated by the DFHLUC macro.
DFHLUC requests are passed to DFHZARL: when the session is a surrogate, the request is passed to DFHZXRL (routine ZXRL_COMMANDS).
Input to routine ZXRL_COMMANDS in DFHZXRL is the application command in the form of a DFHLUC macro call parameter list.
However, if the first syncpoint flow has been received, then:
If it finds that it is in ‘RECEIVE’ state, it issues a DFHTC TYPE=(READ,WAIT) in order to receive the change direction (CD) indicator from the terminal-owning region. Except during syncpoint processing, however, the session is normally in ‘SEND’ state when a command is issued.
In other cases and when the link between the terminal-owning region and application-owning region is MRO, ZXRL_COMMANDS issues a DFHTC TYPE=(WRITE,WAIT,READ).
However, when the link is LU6.2, the following additional rules are applied in order to exploit the buffering provided by LU6.2:
ZXRL_COMMANDS issues a DFHTC TYPE=(WRITE,WAIT,READ) to send the change direction indicator and get the abnormal response from the terminal-owning region.
When there is no wrapped reply, ZXRL_COMMANDS checks for SYNCPOINT ROLLBACK received (the only possibility under these circumstances).
There is no special-case code to distinguish between the terminal-owning region and an intermediate system. When DFHZXRT has interpreted a request received from the application-owning region, it issues the LU6.2 service request (DFHLUC) macro call with the parameter list that was created in the application-owning region. The macro generates a call to DFHZARL. If the TCTTE is a surrogate, which is the case in an intermediate system, control passes to DFHZXRL as described above.
Figure 95 shows the modules in the terminal-owning region for transaction routing for APPC devices.
In the terminal-owning region, operation is under the control of a relay program. When transaction routing is initiated from the APPC device, the relay program is DFHAPRT (which is also used for non-APPC devices). When transaction routing is initiated by an ALLOCATE request in the application-owning region, the relay program is DFHCRT. Both relay programs call DFHZTSP, which calls DFHZXRT.
When an APPC device initiates a conversation with an application in the application-owning region, relay program DFHAPRT is started in the terminal-owning region. It calls the ROUTENT routine of DFHZTSP, which allocates a session to the application-owning region and starts the requested transaction there (see ATTACH processing in the terminal-owning region).
When an application running in the application-owning region initiates a conversation with a remote APPC device by issuing an ALLOCATE request, the DFHCRT relay program is started in the terminal-owning region. It calls the ALLOCLUC routine of DFHZTSP which allocates a session to the APPC device (see Program error program).
After a conversation has been started by either method, the LU6.2 commands passed from the application-owning region are processed by DFHZXRT, which issues the LU6.2 service request (DFHLUC) macro with an appropriate parameter list against the APPC device.
The following flow describes the steps involved in routing a transaction from an APPC device across an LU6.2 intersystem link.
Transaction CXRT (program DFHCRT) is started in the terminal-owning region when the attach FMH5 is received from the application-owning region
Program DFHCRT:
If not, and if it is a terminal, a message is written to the facility, and the transaction terminates.
The ALLOCLUC routine of DFHZTSP is invoked when the DFHIS TYPE=ALLOC macro is issued. This routine is called with input from the application-owning region in a TIOA.
Routine ALLOCLUC:
When an end-bracket has flowed from the application-owning region to the terminal-owning region as a result of an application command (for example, EXEC CICS SEND LAST), and the corresponding command has been issued in the terminal-owning region against the terminal, DFHZXRT issues a DFHLUC TYPE=FREE macro against the terminal, and a DFHTC TYPE=FREE macro against the link to the application-owning region.
DFHZXRT is called by DFHZTSP following a DFHTC TYPE=(WRITE,WAIT,READ) macro. The reply received from the application-owning region is processed as follows:
Normally the wrapped terminal response is sent to the application-owning region with a DFHTC TYPE=(WRITE,WAIT,READ) macro. However, there are exceptions:
The response to the macro is processed in the same way as when a SYNCPOINT request is received from the application, and issued to the terminal, except that the roles of the terminal and link are reversed.
However, if the link between the terminal-owning and application-owning regions is LU6.2, and the response to the DFHLUC macro issued to the terminal indicates that the terminal has issued one of ISSUE_SIGNAL, ISSUE_ERROR, ISSUE_ABEND, or SYNCPOINT_ROLLBACK, DFHZXRT issues an ISSUE_SIGNAL against the link with the application-owning region to notify the application-owning region that the terminal-owning region wants to send. It then issues a series of DFHTC TYPE=READ macros until it receives the change of direction indicator.
The data is processed in the normal way when ‘SIGNAL’ is received from the terminal. In the other cases, that is, if a negative response is received from the terminal, the data from the application-owning region is purged.
After the change direction indicator is received, DFHZXRT sends the response to the application-owning region, ISSUE_SIGNAL and ISSUE_ERROR are sent using a DFHTC TYPE=(WRITE,WAIT,READ) macro, ISSUE_ABEND is sent using a DFHTC TYPE=(WRITE,LAST) macro, and SYNCPOINT_ROLLBACK is sent using a DFHTC TYPE=WRITE macro.
If the terminal response indicates that a SYNCPOINT or BACKOUT request was issued, DFHSPP is called.
If the terminal response indicates that the terminal issued a SEND_ERROR request, DFHZXRT issues a DFHTC CTYPE=ISSUE_ERROR macro followed by a DFHTC TYPE=(WRITE,WAIT,READ) macro against the link session.
If the terminal response indicates that the terminal issued DEALLOCATE(ABEND), DFHZXRT issues a DFHTC CTYPE=ISSUE_ABEND macro against the link session. It then frees the link with the application-owning region and returns.
When DFHZXRT detects that EB has flowed on both the session with the terminal and the session with the application-owning region, it issues DFHTC TYPE=FREE on both and returns.
The terminal-sharing data-transformation program, DFHXTP, constructs and interprets the data streams flowing between terminal-owning and application-owning regions, for both APPC and non-APPC transaction routing environments.
It does this by using four transformers. These either wrap this data from the surrogate TCTTE (in the AOR) or the real TCTTE (in the TOR) into the link TCTTE’s TIOA, or they unwrap this data from the link TCTTE’s TIOA into the surrogate or real TCTTE.
The transformers work in matching wrap and unwrap pairs. Transformer 1 wraps any data to be sent from a TOR to an AOR, which is then unwrapped in the AOR by transformer 2. Transformer 3 wraps any data to be sent from an AOR to a TOR, which is then unwrapped in the TOR by transformer 4. Figure 96 shows this process.
The transformer program is capable of shipping data from the TCTTE and the following control blocks that are chained off the TCTTE:
Note that because this field is not chained off the TCTTE but is in LIFO, its address is passed as a parameter to the transformer program.
The fields to be shipped are defined in tables in the transformer program.
There is special-case code to deal with fields that cannot be processed by the table-driven code.
For the transaction routing of LU6.2 commands, DFHXTP must ensure that the data stream built for transmission contains all the information relevant to support the issuing of a DFHLUC macro request on the remote system. This information consists primarily of:
Figure 97 shows the types of transaction-routing data streams.
The transformer builds four types of data stream for transaction routing:
An LU6.1 attach FMH5 is used when a transaction is to be started in the system to which the request is sent. CSRR is specified as the return process to indicate the use of transaction routing. In the case of routing to the application-owning region, the transaction is the user transaction; in the case of routing to the terminal-owning region, the transaction is the CXRT relay transaction.
Figure 98 shows the format of the data stream passed between a TOR and an AOR to provide transaction routing from any supported device.
The fields that are shipped depend principally on the type of terminal and on other parameters, as follows:
The length field in Figure 98 depends upon whether the field type is described in the table that follows as being V (Variable), F (Fixed), or U (Undefined). A V field is 2 bytes in length, an F field is 1 byte, and U indicates a variable that is no longer wrapped or unwrapped if it is encountered.
Table 51 shows the various data fields that may appear in a transaction routing data stream, together with their codes and field types.
Code | Hex | Type | DSECT | Field | Description |
---|---|---|---|---|---|
1 | 01 | V | XTPCDTC1 | TC request bytes or attach start code | |
2 | 02 | V | XTPCDOPC | Operator class | |
3 | 03 | V | XTPCDTUA | TCTTE user area | |
4 | 04 | V | XTPCDTIA | Terminal I/O area | |
5 | 05 | V | XTPCDCMA | COMMAREA | |
6 | 06 | V | XTPCDLPS | Terminal partition set | |
7 | 07 | V | XTPCDPLM | Page LDC mnemonic | |
8 | 08 | V | XTPCDPGD | Page data | |
9 | 09 | V | XTPCDRQI | Request ID | |
10 | 0A | V | XTPCDETI | Error terminal ID | |
11 | 0B | V | XTPCDETL | Error terminal LDC | |
12 | 0C | V | XTPCDMCF | Message control flags | |
13 | 0D | V | XTPCDTTL | Message title | |
14 | 0E | V | XTPCDRTT | Route target ID: netname.termid.ldc.opid | |
15 | 0F | V | XTPCDCPS | Application partition set | |
16 | 10 | F | DFHTCTTE | TCTTEAID | Automatic initiate descriptor |
17 | 11 | F | DFHTCTTE | TCTTECAD | Cursor address |
18 | 12 | F | DFHTCTTE | TCTESIDO | Outbound signal data |
19 | 13 | F | DFHTCTTE | TCTESIDI | Inbound signal data |
20 | 14 | F | DFHTCTTE | TCTE32SF | Screen size attributes |
21 | 15 | F | DFHTCTTE | TCTTEFX | Transparency attributes |
22 | 16 | F | DFHTCTTE | TCTTEBMN | Map set name |
23 | 17 | F | DFHTCTTE | TCTTECRE | Request completion extension |
24 | 18 | F | DFHTCTTE | TCTTECR | Request completion analysis |
25 | 19 | F | DFHTCTTE | TCTTEDES | TCAM destination name |
26 | 1A | F | DFHTCTTE | TCTTETM | Terminal model number |
27 | 1B | F | DFHTCTTE | TCTTETID | Teller identification for 2980 |
28 | 1C | F | DFHTCTTE | TCTTEOI | Operator identification |
29 | 1D | F | DFHTCTTE | TCTTEEDF | EDF mode |
30 | 1E | F | DFHTCTTE | TCTTETC | Nominated transaction |
31 | 1F | F | DFHTCTTE | TCTTETS | Terminal status |
32 | 20 | U | DFHSNTTE | SNTESSF | Userid |
33 | 21 | F | DFHTCTTE | TCTEASCZ TCTEASCL TCTEASCC | Alternate screen size attributes |
34 | 22 | F | DFHTCTTE | TCTE32EF TCTE32E2 | 3270 extended feature flags |
35 | 23 | F | DFHTCTTE | TCTETXTF | 3270 text feature flag |
36 | 24 | F | TCTTETTE | TCTEAPGL TCTEAPGC | Alternate page size |
37 | 25 | F | DFHTCTTE | TCTECSG1 TCTECSG2 | Coded graphic character set identifiers |
38 | 26 | F | DFHTCTTE | TCTEUSRS | LU6.2 conversation state machine |
39 | 27 | F | TCTTELUC | TCTECVT | LU6.2 conversation type (mapped or unmapped) |
40 | 28 | F | TCTTELUC | TCTESPL | LU6.2 syncpoint level |
41 | 29 | F | DFHTCTTE | TCTESPSA | Additional syncpoint flags |
42 | 2A | F | TCTTELUC | TCTEIAHB | Attach FMH indicator |
43 | 2B | F | DFHTCTSE | TCSESID | NETNAME of APPC device |
44 | 2C | U | DFHSNTTE | SNTENLS | User’s national language |
45 | 2D | F | DFHTCTTE | TCTENLS | National Language Support Code |
46 | 2E | F | DFHTCTTE | TCTESCFL | Security flag |
47 | 2F | F | DFHTCTTE | TCTEITRS | Trace flags |
48 | 30 | F | DFHTCTME | TCMEMODE | Mode group name |
49 | 31 | F | DFHTCTTE | TCTTENLI | National language in use |
50 | 32 | F | TCTTELUC | TCTELUC1 | LUC flag byte 1 |
51 | 33 | F | DFHTCTTE | TCTESSPL | Synclevel of link |
53 | 35 | F | DFHTCTTE | TCTEVTP | Send mode/receive mode |
54 | 36 | F | DFHTCTTE | TCTTEIO | Task to be initiated |
55 | 37 | F | DFHLFS | PRESETC | Preset userid |
56 | 38 | F | TCTTETTE | TCTTEFMB | Outbound formatting status |
57 | 39 | F | DFHTCTTE | TCTEUCTB | UCTRAN = YES |
58 | 3A | F | DFHTCTTE | TCTETSU3 | UCTRAN = TRANID |
63 | 3F | F | DFHTCTTE | TCTTETT | Terminal type code |
64 | 40 | F | DFHLUCDS | LUCOPN0 LUCOPN1 LUCOPN2 LUCOPN3 | LUC request codes |
65 | 41 | F | DFHLUCDS | LUCRCODE | LUC request error feedback |
66 | 42 | F | DFHLUCDS | LUCSDBLK | LUC conversation feedback |
67 | 43 | F | DFHLUCDS | LUCNSYS | System name for LUC Allocate |
68 | 44 | F | DFHLUCDS | LUCMODNM | Modename for LUC Allocate |
69 | 45 | F | DFHLUCDS | LUCMSGNO | Message number for LUC Abend and Error |
70 | 46 | F | DFHLUCDS | LUCSENSE | Sense code for LUC Abend and Error |
71 | 47 | F | DFHLUCDS | LUCRQCON | Conversation type for LUC Issue Attach |
72 | 48 | F | DFHLUCDS | LUCRQSYN | Syncpoint level for LUC Issue Attach |
73 | 49 | F | DFHLUCDS | LUCFTPNL LUCFTPN | TPN for LUC Issue Attach |
74 | 4A | F | DFHLUCDS | LUCPIP | PIP indicator for LUC Issue Attach |
75 | 4B | F | DFHLUCDS | LUCTAREL | Maximum receivable length for LUC Receive |
76 | 4C | F | DFHLUCDS | LUCMGAL | Mode group name of allocated session |
90 | 5A | F | DFHDIBDS | DIBSENSE | DIB system/user sense data |
128 | 80 | V | XTPCDZIR | ZC install response | |
129 | 81 | V | XTPCDZBP | ZC builder parameter set | |
130 | 82 | V | XTPCDZIM | ZC install message set | |
131 | 83 | V | XTPCOPCL | Opclass in routed message | |
132 | 84 | V | XTPCDPNM | Program name for ISSUE LOAD | |
133 | 85 | V | XTPLUCSD | Message text for LUC Send | |
134 | 86 | V | XTPLUCRD | Message text for LUC Receive | |
135 | 87 | V | XTPLUTCX | TCA extension for LU6.2 | |
136 | 88 | V | XTPLUMSG | Message text for LUC Issue Abend or Issue Error | |
137 | 89 | V | XTPIPASS | Issue Pass | |
138 | 8A | V | XTPLDATA | Logon Data | |
139 | 8B | V | XTPRETC | Issue Pass Return Code | |
140 | 8C | V | XTPLMOD | Issue Pass Logmode |