This section discusses things that you need to consider when using the 3270 bridge from BTS.
To avoid indefinite waits for a 3270 transaction to reply, the client could set a timer. If the timer expires, the client is reactivated and assumes that an error has occurred. The client can cancel the 3270 transaction-- by issuing a CANCEL ACTIVITY command if the activity hasn’t started, or a SET TASK PURGE command if it has.
If the 3270 transaction ends abnormally, an abend call is made to the bridge exit. Note that this call occurs at the end of the transaction--it cannot be used to implement an abend handler.
If it is necessary for the exit program to reply to the client, it cannot do so simply by issuing a PUT CONTAINER command. Because BTS activities are always recoverable, the command would be backed out. One solution is for the exit program to write a message to a non-recoverable transient data or temporary storage queue. It could, for example, delegate this task to a child activity.
Figure 33 contains example pseudocode for dealing with an abend of the 3270 transaction. The Requestor activity is a child of the bridge exit; it handles the abend.
Bridge exit program | Requestor activity |
---|---|
|
|
Note that the exit program issues a LINK ACTIVITY, rather than a RUN ACTIVITY SYNCHRONOUS, command to activate the Requestor activity. This is necessary because the child must execute in the same unit of work as the exit program.
The 3270 bridge does not support transaction restart. If a client activity is restarted and tries to reuse a bridge facility token, an ABRH abend occurs.