gtps2m4i | ACF/SNA Data Communications Reference |
The CTCP receives both commands and data from NPSI for virtual circuits
defined for LLC4 (GATE) support. For this dialog, it is assumed that
the NPSI/GATE support is further defined to have Fast Connect (FC) capability,
resulting in both data messages and NPSI command messages flowing on the same
virtual circuit to the host. The first text character in each message
indicates whether it is a NPSI command or a data message.
In the following sections, the CTCP is assumed to be defined via a MSGRTA
statement as a TPF application named CTCP. TPF creates an associated
RVT definition of a TPF Primary LU resource named CTCP. The CTCP
functions are handled by a PSV routine (one or more ECB controlled programs)
named GATE1. GATE1 is specified as the PSV on the OSTG RSC statement
for each NPSI LU (both MCH_LU and VC_LU) defined to TPF which are in session
with the CTCP PLU. It is further assumed that the sessions between the
CTCP and the NPSI LU resources (both MCH_LU and necessary VC_LU resources)
have been established prior to any NPSI command flows, and that although the
PIU received is directed to the CTCP PLU, all data messages are ultimately
destined for a TPF application named 'APPL'.
This section describes the input-related flow and control blocks for
inbound data messages flowing through your CTCP Process. This material
is divided into two parts: data flow for soft copy and hard copy
devices.
See Figure 113 for this discussion of soft copy device data flow.
Figure 113. Soft Copy Input Data Flow
- An input PIU is read by the TPF system from the NCP.
- The PIU is passed to SNA Opzero, where an ECB is created and the PIU is
placed into the appropriate message block.
- The Communications Source package (COMMSRCE) is then started. This
is where the RCPL is created, including the RID of the origin VC_LU and the
name of the destination CTCP. COMMSRCE passes control to the GATE1 PSV
routine.
- The GATE1 PSV routine may perform various actions before returning to
COMMSRCE, including the following:
- Convert the RID of the input VC_LU, specified in the RCPL, to an
LEID. The LEID is determined from contact information <ci> found in
the VCCB<ci> and the address information, if any, contained in the message
text.
- Obtain the associated EPCB for the LEID.
- Modify the RCPL to reflect the LEID, rather than the VC_LU RID, as the
message origin.
- Modify the RCPL to reflect APPL, rather than the CTCP, as the message
destination. The application name is obtained from information stored
in the EPCB during logon processing.
- Translate the message into character coding required by the
application.
- Convert the input data from AMSG format to the message format required by
the application.
- Store the RID into the EPCB to facilitate finding the return address for
the resulting output.
The GATE1 routine returns control to COMMSRCE in order to:
- Interface to TPF data collection.
- Interface to TPF Program Test Vehicle, if appropriate.
- COMMSRCE then passes control to the Message Router package with the RCPL,
passed from the GATE1 routine, and the modified message block.
- The Message Router enters the TPF application (APPL) specified in the
RCPL.
See Figure 114 for this discussion of hard copy device data flow.
Figure 114. Hard Copy Input Data Flow
- An input PIU is read by the TPF system from the NCP.
- The PIU is passed to SNA Opzero, where an ECB is created and the PIU is
placed into the appropriate message block.
- The Communications Source package (COMMSRCE) is then started. The
RCPL is created, including the RID of the origin VC_LU and the name of the
destination CTCP. The Communications Source package passes control to
the GATE1 PSV routine.
- The GATE1 routine may perform various including the following:
- Convert the RID of the input VC_LU, specified in the RCPL, to an
LEID. The LEID is determined from contact information <ci> found in
the VCCB<ci> and the address information, if any, contained in the message
text.
- Obtain the associated EPCB for the LEID.
- Modify the RCPL to reflect the LEID, rather than the VC_LU RID, as the
message origin.
- Modify the RCPL to reflect APPL, rather than the CTCP, as the message
destination. The application name is obtained from information stored
in the EPCB during logon processing.
- Store the RID into the EPCB to facilitate finding the return address for
the resulting output.
- Determine whether the message is a positive or negative acknowledgment
(answer-back) and indicate the type of acknowledgement in the GDA area of the
RCPL.
- Swap the Origin and Destination addresses within the
RCPL.
At this point, output processing, where the queueing package is started
with the printer acknowledgement message, must be activated to perform the
necessary queue and transmit manipulations as dictated by the acknowledgement
type. The GATE1 PSV may activate the output processing in either of two
ways:
- Using the Input Message ECB - You can directly activate the GATE1 PSV
output processing.
- Using a new ECB - Issues ROUTC with the modified RCPL (swapped origin and
destination fields) and same message block. Your ROUTC EXIT processing
code determines that the LEID specified in the RCPL requires GATE1 PSV
processing. See the TPF System Installation Support
Reference for additional information about user exits. Your ROUTC
EXIT code returns to the TPF ROUTC processing indicating that the message must
be given to GATE1 for processing. TPF ROUTC removes the outbound
message from the ECB associated with the input message and attaches it to a
newly created ECB to be presented to the GATE1 PSV for output
processing.
The continuation of the flow is shown in Figure 118 and Figure 119. This is covered later in "Hard Copy Device Data Flow".
This section describes the output related flow and control blocks for
outbound data messages flowing through your CTCP process. This material
is divided into two parts: data flow for soft copy and hard copy
devices.
See Figure 115 for this discussion of soft copy device data flow.
Figure 115. Soft Copy Output Data Flow
- The TPF application (APPL) issues a ROUTC macro with an RCPL and a message
block. The origin in the RCPL is the TPF application and the
destination is an LEID representing the destination terminal.
- Your ROUTC EXIT processing code determines that the LEID specified in the
RCPL requires CTCP processing by the GATE1 PSV routine. See the TPF System Installation Support Reference for additional
information about user exits. Your code returns to the TPF ROUTC
processing indicating that the message must be given to GATE1 for
processing. TPF ROUTC removes the outbound message from the
application's ECB and attaches it to a newly created ECB to be presented
to the GATE1 PSV.
- On invocation, the GATE1 routine uses the LEID in the output RCPL to find
the associated terminal entry in the EPCB. From this entry, the RID of
the X.25 Virtual Circuit LU for this terminal is obtained. The
RID of the VC_LU replaces the LEID in the destination field of the
RCPL.
The End Point Control Block for this terminal is found by using the LEID as
an index. This control block provides the information necessary to
reformat the message (that is, physical terminal address, and character code
translation indicator). Thus, the GATE1 routine prepares the output
message for transport to the X.25 packet switching network.
- Finally, the GATE1 routine sets the BYPASS SEND INTERCEPT (CE1CPA
X'40') indicator to bypass ROUTC EXIT activation for the ensuing
ROUTC. GATE1 issues the ROUTC macro with the modified RCPL and message
block.
The following section describes different cases of data flow for hard copy
type devices.
See Figure 116 for this discussion of hard copy device data flow.
Figure 116. Hard Copy Enqueue, Dequeue, and Transmit
- The TPF application issues a ROUTC macro with an RCPL and a message
block. The origin in the RCPL is the TPF application and the
destination is an LEID representing the destination printer.
- Your ROUTC EXIT processing code determines that the LEID specified in the
RCPL requires GATE1 PSV processing.
See the TPF System Installation Support Reference
for additional information about user exits. Your code returns to the
TPF ROUTC processing indicating that the message must be given to GATE1 for
processing. TPF ROUTC removes the outbound message from the
application's ECB and attaches it to a newly created ECB to be presented
to the GATE1 PSV.
- On invocation, the GATE1 PSV activates the TPF Queue Manager package, to
queue the message. For more information on the Queue Manager interface,
see "Queue Manager".
- If the GATE1 PSV determines transmission to that device is possible, the
Queue Manager is activated to dequeue a message block from the top of the
QCB.
- The GATE1 routine may first reformat the message and then replace the LEID
of the destination in the RCPL with the RID of the VC_LU.
- Finally, the GATE1 routine sets the BYPASS SEND INTERCEPT (CE1CPA
X'40') indicator to bypass ROUTC EXIT activation for the ensuing
ROUTC. GATE1 issues the ROUTC macro with the modified RCPL and message
block.
See Figure 117 for this discussion of hard copy device data flow.
Figure 117. Hard Copy Enqueue and Exit
- The TPF application issues a ROUTC macro with an RCPL and a message
block. The origin in the RCPL is the TPF application and the
destination is an LEID representing the destination printer.
- Your ROUTC EXIT processing code determines that the LEID specified in the
RCPL requires GATE1 PSV processing. See the TPF
System Installation Support Reference for additional information about
user exits. Your code returns to the TPF ROUTC processing indicating
that the message must be given to GATE1 for processing. TPF ROUTC
removes the outbound message from the application's ECB and attaches it to
a newly created ECB to be presented to the GATE1 PSV.
- On invocation, the GATE1 PSV activates the TPF Queue Manager package, to
queue the message. For more information on the Queue Manager interface,
see "Queue Manager".
- If the GATE1 PSV determines that transmission to the device is not
possible or does not wish to transmit, the ECB is terminated. You can
write time initiated routines that directly interface with the Queue Manager
in order to dequeue and transmit the queued messages according to your
specifications.
See Figure 118 for this discussion of hard copy device data flow.
Figure 118. Hard Copy Queue Wake Up
In this case, the ROUTC macro was issued by the GATE1 PSV code activated
from COMMSRCE when a positive acknowledgment (answer-back) to a previously
sent message was received (see Figure 114). The intent is to wake up the existing queue.
- Using the modified RCPL and message, the GATE1 PSV code activated by
COMMSRCE forwards the message via ROUTC.
- Your ROUTC EXIT processing code determines that the LEID specified in the
RCPL requires GATE1 PSV processing. Your code returns to the TPF ROUTC
processing indicating that the message must be given to GATE1 for output
(WAKEUP) processing. TPF ROUTC removes the outbound message from the
ECB associated with the input message and attaches it to a newly created ECB
to be presented to the GATE1 PSV for output processing.
- On invocation, the GATE1 output processing determines that the existing
message is a positive acknowledgment. A possible implementation to
achieve this might be to have the GATE1 PSV code associated with the input
message ECB indicate in the GDA area of the RCPL that this is a positive
acknowledgement.
- If the GATE1 PSV determines transmission to that device is possible, the
Queue Manager is activated to dequeue a message block from the top of the QCB
(see Queue Manager).
- The GATE1 routine may first reformat the message and then replace the LEID
of the destination in the RCPL with the RID of the VC_LU and the origin field
of the RCPL with the CTCP application name.
- Finally, the GATE1 routine sets the BYPASS SEND INTERCEPT (CE1CPA
X'40') indicator to bypass ROUTC EXIT activation for the ensuing
ROUTC. GATE1 issues the ROUTC macro with the modified RCPL and message
block.
See Figure 119 for this discussion of hard copy device data flow.
Figure 119. Hard Copy Repeat Last Message/Negative Acknowledgment
In this case, the ROUTC macro was issued by the GATE1 PSV code activated
from COMMSRCE when a negative acknowledgment (answer-back) to a previously
sent message was received (see Figure 114). The intent is to wash the previously sent message
and retransmit it.
- Using the modified RCPL and message, the GATE1 PSV code activated by
COMMSRCE forwards the message via ROUTC.
- Your ROUTC EXIT processing code determines that the LEID specified in the
RCPL requires GATE1 PSV processing. Your code returns to the TPF ROUTC
processing indicating that the message must be given to GATE1 for output
(WAKEUP) processing. TPF ROUTC removes the outbound message from the
ECB associated with the input message and attaches it to a newly created ECB
to be presented to the GATE1 PSV for output processing.
- On invocation, the GATE1 output processing determines that the existing
message is a negative acknowledgment. A possible implementation to
achieve this might be to have the GATE1 PSV code associated with the input
message ECB indicate in the GDA area of the RCPL that this is a negative
acknowledgement. the GATE1 PSV output processing then requests from the
Queue Manager to WASH the previously sent message (see Queue Manager).
- If the GATE1 PSV determines transmission to that device is possible, the
Queue Manager is activated to dequeue a message block from the top of the
QCB.
- The GATE1 routine may first reformat the message and then replace the LEID
of the destination in the RCPL with the RID of the VC_LU and the origin field
of the RCPL with the CTCP application name.
- Finally, the GATE1 routine sets the BYPASS SEND INTERCEPT (CE1CPA
X'40') indicator to bypass ROUTC EXIT activation for the ensuing
ROUTC. GATE1 issues the ROUTC macro with the modified RCPL and message
block.