The local node supports bracket termination rule one (conditional) and bracket termination rule two (unconditional), as specified in the BIND request. Some sessions only allow bracket termination by one session partner; this is a BIND option (supplied in the BICB on Open(PLU) OK Confirm), and it is the application's responsibility to determine if (and when) it should request bracket termination.
If an application is allowed by its BIND to terminate brackets, it does so by setting the EBI application flag in an inbound Data or Status-Control(LUSTAT/CHASE/QC/CANCEL) message. The bracket is only terminated when the application receives a Status-Session (BETB) from the local node.
If the host terminates a bracket successfully, the local node sends a Status-Session(BETB) to the application. Note that the EBI application flag on outbound messages does not indicate bracket termination, but indicates that the corresponding RU carried EB. The bracket is only terminated when the application receives Status-Session(BETB).
Note that if the application queues data, then it should also queue Status-Session(BETB) messages; they must not be processed as expedited.
The following two figures illustrate bracket termination protocols between the local node and the application and how those protocols relate to the underlying SNA protocols.
In the following illustration, the application successfully terminates a bracket by sending an EBI data chain when the application's state is in-bracket, which the host accepts. The local node sends a Status-Session(BETB) to indicate that the application's state is now between-bracket.
In the following illustration, the host successfully terminates a bracket by sending an EBI data chain when the application's state is in-bracket, which the application accepts. The local node sends a Status-Session(BETB) to indicate that the application's state is now between-bracket.
