Design overview

Figure 92 shows the overall design of this component.

Figure 92. Transaction routing
 The modules involved in the transaction routing component are as follows. DFHAPRT, the relay program. DFHRTE, the transaction routing program. DFHZTSP, the terminal sharing program, which deals with remote attach, remote application requests, remote detach, remote flush and route. DFHXTP, the transaction routing transformation program, which involves Transformations 1 to 4.

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.

Overview of operation in the application-owning region for APPC transaction routing

Figure 93 shows the modules in the application-owning region for transaction routing for APPC devices.

Figure 93. Transaction routing for APPC devices: modules in the application-owning region
 This is a technical drawing showing the modules in the application-owning region for transaction routing for APPC devices, and the relationships between them.

APPC control blocks

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.

Figure 94. Transaction routing for APPC devices: TCT control-block structure in the application-owning region
 In the remote system entry, TCSESKA points to the TCT skeleton entry. The TCT skeleton entry includes TCTSKSYS, which points to the TCTSE for link (owning connection); TCTSKMDE and TCTSKSRE, which point to the remote system entry. The surrogate session entry includes TCTTEIST, which points to the remote system entry.
Remote system entry

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.

Surrogate session entry

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.

DFHZXRL

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.

Table 28. DFHZXRL’s processing of DFHLUC requests
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.

ATTACH processing in the application-owning region

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.

DFHZSUP module
  1. Issues DFHSEC TYPE=CHECK,RESTYPE=TRAN to validate transaction security against the security values associated with the intersystem link at bind time.
  2. Processes the incoming attach FMH5.

    For an LU6.2 ISC connection:

    For an MRO connection:

  3. Issues DFHZUSRM TYPE=SET,REQUEST=ATTACH_INBOUND and DFHLUC TYPE=INIT-CALL macros to move input data into a buffer bypassing the FMH5 ATTACH header.
  4. PIP processing is bypassed because PIP is never present on an attach from a terminal-owning region when transaction routing.
  5. Puts the remaining data into a TIOA with a DFHTC TYPE=(READ,WAIT),NOATNI=YES.
  6. Issues a DFHIS TYPE=RATT, to call DFHZTSP to build a surrogate session entry to represent the session TCTTE in the terminal-owning region.
  7. Assign the security values established for the link to the surrogate, as preset security values are shipped from the terminal-owning region, and cannot be defined on the application-owning region.

    ATTACH security processing in DFHZSUP has established two SNTTEs associated with the link session:

    1. The SNTTE pointed to by TCTELSNT in the LU6.2 extension or TCTEIRSN for MRO represents link-level security values established at bind time.
    2. The SNTTE pointed to by TCTTESNT represents user-level security values established during ATTACH security processing.

    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.

  8. Passes control to the requested application program.
DFHZTSP module
  1. Performs initialization housekeeping, checks the link TCTTE and TIOA.
  2. Locates remote system entry from the TMP REMOTE domain. If not found, attaches the CITS transaction (DFHZATS) to install it.
  3. Builds surrogate session TCTTE.
  4. Gets a TIOA and chains it to the surrogate.
  5. Issues DFHIS TYPE=XTP,XFNUM=2 to call DFHXTP.
  6. Chains surrogate to TCA and Link TCTTE.
  7. Copies link operator dispatching priority from the link and establishes dispatching priority for the surrogate.

DETACH processing in the application-owning region

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.

ALLOCATE processing 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.

DFHZXRL module

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:

  1. Checks that the parameter list contains the TCTSE address for the remote LU6.2 system.
  2. Obtains the address of the TCTSE of the system to which the LU6.2 commands are to be routed.
  3. Allocates a session to the terminal-owning region.

    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:

  4. Issues a DFHIS TYPE=XTP,XFNUM=3 macro call that invokes a stream that is passed to the terminal-owning region.
  5. Issues a DFHTC TYPE=(WRITE,WAIT,READ),FMH=YES macro call to send the request to the terminal-owning region and receive the response.
  6. Issues a DFHIS TYPE=RALL that invokes DFHZTSP to build a surrogate session TCTTE, then chains the link session TCTTE and the surrogate session TCTTE together.
  7. Issues a DFHIS TYPE=XTP,XFNUM=2 macro call that invokes DFHXTP to unwrap the response from the terminal-owning region and update the surrogate session TCTTE and the parameter list created by the DFHLUC macro.
  8. Examines the return codes in the response:

FREE processing in the application-owning region

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:

  1. Bypasses security processing (sign-off) for a surrogate session entry, because the sign-off is performed for the link.
  2. Issues the DFHIS TYPE=RDET macro that calls DFHZTSP to free the surrogate and link TCTTEs.

Other LU6.2 command processing in the application-owning region

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

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

DFHLUC requests are passed to DFHZARL: when the session is a surrogate, the request is passed to DFHZXRL (routine ZXRL_COMMANDS).

DFHZXRL module

Input to routine ZXRL_COMMANDS in DFHZXRL is the application command in the form of a DFHLUC macro call parameter list.

  1. ZXRL_COMMANDS normally wraps up the command to be shipped and relevant TCTTE fields by calling a transformer routine in DFHXTP.

    However, if the first syncpoint flow has been received, then:

  2. ZXRL_COMMANDS tests the state of its link with the terminal-owning region (this may not be the same as the state of the application):

    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.

  3. ZXRL_COMMANDS then sends the wrapped-up request to the remote system using the DFHTC macro. To reduce the number of flows when the command may result in the termination of the conversation, the following rules are applied for both MRO and ISC links:

    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:

  4. ZXRL_COMMANDS receives the response to its DFHTC macro call. This may be:
  5. When the DFHTC macro included a READ, and the request was succesfully processed, ZXRL_COMMANDS checks for a wrapped reply from the terminal-owning region, and calls DFHXTP to unwrap the reply. When the resulting DFHLUC parameter list indicates SYNCPOINT or SYNCPOINT ROLLBACK, and the link is an MRO connection, ZXRL_COMMANDS issues a DFHTC TYPE=READ, because there is a SYNCPOINT or ROLLBACK flow pending.

    When there is no wrapped reply, ZXRL_COMMANDS checks for SYNCPOINT ROLLBACK received (the only possibility under these circumstances).

LU6.2 daisy-chaining considerations

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.

Overview of operation in the terminal-owning region for APPC transaction routing

Figure 95 shows the modules in the terminal-owning region for transaction routing for APPC devices.

Figure 95. Transaction routing for APPC devices: Modules in the terminal-owning region
 This figure shows the modules in the terminal-owning region, as described in the text following the figure.

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.

ATTACH processing in the terminal-owning region

The following flow describes the steps involved in routing a transaction from an APPC device across an LU6.2 intersystem link.

DFHZSUP module
  1. Processes the incoming FMH5 from the terminal. This:
  2. Checks transaction security code against new security levels developed during ATTACH security processing above.
  3. Issues DFHSEC TYPE=CHECK,RESTYPE=TRAN to validate transaction security against the security values associated with the terminal (and with the user, if signed on).
  4. Issues DFHZUSRM TYPE=SET,REQUEST=ATTACH_INBOUND and DFHLUC TYPE=INIT-CALL macros to move input data into a buffer bypassing the FMH5 ATTACH header.
  5. If PIP is present, builds a new TCA extension and moves the PIP data into it by issuing a DFHLUC TYPE=RECEIVE (which also causes the PIP data to be deleted from the buffer).
  6. Puts remaining mapped data into a TIOA with a DFHTC TYPE=(READ,WAIT),NOATNI=YES.
  7. Issues DFHPC TYPE=XCTL to the relay program DFHAPRT.
DFHAPRT module
  1. Drives the dynamic routing exit if the transaction has been defined as dynamic.
  2. Sets up the DFHISCRQ parameter list with remote sysid and tranid.
  3. Recognizes that the principal facility is an APPC device.
  4. Issues DFHIS macro to invoke DFHZTSP.
DFHZTSP module
  1. If the transaction has been defined with an associated TRPROF, the profile named is located with a DFHKC CTYPE=PROFLOC; otherwise the default DFHCICSS profile is used.
  2. Issues DFHTC TYPE=ALLOCATE,REQUID=CSRR to allocate a session to the remote system using the profile identified in step 1.
  3. Flags the returned TCTTE as a relay link and puts the remote sysid into TCTESYID in the terminal TCTTE. If the LINK TCTTE status is ‘COLD’, issues DFHTC CTYPE=CATALOG.
  4. Sets up the transformer parameter list (DFHXTSTG) to indicate ATTACH FMH5 required, COLD or not COLD, and transaction routing for an APPC device, passing the tranid, user TCTTE, and link TCTTE.
  5. Issues DFHIS TYPE=XTP,XFNUM=1 to call the transformer program, DFHXTP, to build the data. (See Transformer program (DFHXTP).)
  6. Issues DFHTC TYPE=(WRITE,WAIT,READ) against the link to route the ATTACH request to the application-owning region. This causes DFHZARM (when the link is ISC) or DFHZIS2 (when the link is MRO) to add an LU6.2 FMH5 preceding the LU6.1 FHM5 built by XTP. This contains security data required to validate the request at the application-owning region.

ALLOCATE processing in the terminal-owning region

DFHCRT module

Transaction CXRT (program DFHCRT) is started in the terminal-owning region when the attach FMH5 is received from the application-owning region

Program DFHCRT:

  1. Checks that the principal facility of the task is an ISC or MRO session.

    If not, and if it is a terminal, a message is written to the facility, and the transaction terminates.

  2. Issues DFHIS TYPE=ALLOC macro which calls DFHZTSP.
DFHZTSP module

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:

  1. Issues DFHIS TYPE=XTP,XFNUM=4 which updates the TCTTE and builds a parameter list of the type created by the DFHLUC macro.
  2. Verifies that the parameter list contains an ALLOCATE request (the only valid request at this stage). If it does not, the transaction abends.
  3. Issues a DFHLUC MF=E macro with the supplied parameter list.
  4. If the request is successful, DFHZTSP:
    1. Issues DFHIS TYPE=XTP,XFNUM=1 which wraps the updated TCTTE and DFHLUC parameter list ready for transmission to the application-owning region.
    2. Issues a DFHTC TYPE=(WRITE,WAIT,READ) against the session with the application-owning region.
    3. Passes control to DFHZXRT. The TIOA received with the preceding DFHTC request should contain data for one of the requests that DFHZXRT handles.
  5. If the request is unsuccessful, DFHZTSP:

FREE processing in the terminal-owning region

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.

Other LU6.2 command processing in the terminal-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:

  1. If an application request has been received, DFHZXRT:
  2. If a syncpoint request has been received, DFHZXRT:
  3. If a syncpoint rollback request has been received, DFHZXRT issues a SYNCPOINT ROLLBACK request.

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.

Transformer program (DFHXTP)

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.

Figure 96. DFHXTP transformer operations
 This figure shows the DFHXTP transformer operations, as described in the text above.

The transformer program is capable of shipping data from the TCTTE and the following control blocks that are chained off the TCTTE:

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:

Data streams for transaction routing

Figure 97 shows the types of transaction-routing data streams.

Figure 97. Transaction-routing data streams
 An attach data stream for principal or alternate facility contains: LU6.1 attach FMH; CICS relay FMH43; routed data. A request or response data stream contains: CICS relay FMH43; routed data. The format of FMH43 is: L; CT (43); XCMD; XMOD; FXCT. For XCMD, G=X'80' Relay FMH. FN is one of the following: X'01' INQUIRE terminal; X'02' INSTALL terminal; X'03' DELETE terminal; X'04' INSTALL response; X'05' LU6.2 remote terminal attach; X'06' LU6.2 DFHLUC request/response.

The transformer builds four types of data stream for transaction routing:

  1. Attach data stream for principal facility
  2. Attach data stream for alternate facility
  3. DFHLUC request data stream
  4. DFHLUC response data stream
Note:
The first transformer request for remote alternate facilities is to transformer 3, and not to transformer 1. This is because the same transformers are used whether transaction routing is initiated in the terminal-owning region or in the application-owning region.

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.

Transaction-routed data format

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:

Figure 98. Routed data format
 The data stream consists of a code field, a length field, a data field, followed by another code field, length field and data field, and so on in that sequence.

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.

Table 29. Transaction routing data stream Built by the terminal sharing transformer (DFHXTP).
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
[[ Contents Previous Page | Next Page Index ]]