Bracket protocols

A bracket is any "uninterruptible" unit of work that an application program and an LU have been programmed to accomplish. A bracket can consist of any combination of data requests and data replies, ranging from a single request in one direction to an elaborate exchange of requests and replies. (Reply is used here to mean a data request sent in answer to a previously received data request.) But, no matter how simple or complex the series of requests and replies can be, the characteristic that makes them all part of the same bracket is that they all pertain to the same unit of work.

A database inquiry transaction is a typical example of a bracket. In such a transaction, the LU sends an inquiry to the host processor asking for some piece or body of information stored in the database. For example, an insurance agent at a terminal asks the processor to provide information on all insurance policies issued to a particular client. In answer to the inquiry, the application program in the host processor sends a single request or a series of requests containing the requested information. At this point, the bracket might end. Or, as the result of one of the replies, the LU might ask for further details. In that case, the bracket does not end until the application program has acquired the details from the database and sent them to the LU.

Bracket protocols are used when one, or both, of the ends of the session cannot begin processing a new unit of work on the session until the current one has been completed. For example, it can be used if the LU or application program cannot start handling a new inquiry on the session until the replies to the current inquiry have been completed. Bracket protocols provide a way of ensuring that a new unit of work is not started until the preceding one has been finished.

The application program and LU that are using bracket protocols indicate for each chain whether that chain is the beginning, middle, or end of the bracket. This allows the receiving LU to determine whether a new bracket can be started. A begin bracket (BB) indicator is turned on in the first request of the first chain in a bracket. The end bracket (EB) indicator is turned on in the first request of the last chain in the bracket; alternatively, the conditional end bracket (CEB) indicator is turned on in the last request in the last chain in a bracket. (CEB can be specified only if FM profile 19 is used in the session.) A VTAM® application program turns on these indicators by issuing SEND BRACKET=BB, SEND BRACKET=EB, and SEND BRACKET=CEB, respectively.

When a session is established, bits in the session parameters determine who wins bracket contention when both sides want to begin a bracket simultaneously, who can end a bracket, and whether bracket termination is conditional (the session partner sending EB does not consider the bracket ended until it receives a positive response to the chain that includes EB) or unconditional (termination occurs when the chain containing EB is sent). Figure 1 shows an example of bracket protocol.

Figure 1. Bracket protocol

The diagram shows an example of bracket protocol. In this example, the logical unit determines the beginning and the end of the bracket. In other applications, the application program can determine the beginning and the end of the bracket, or one node can determine the beginning and the other node can determine the end.

One bracket-related bit in the session parameters determines the winner of bracket contention by assigning the role of first speaker to one LU and the role of bidder to the other participant. The first speaker is the LU that is given the ability to begin a bracket without asking permission from the other LU in the session. The bidder is the LU that must ask for and receive permission from the first speaker to begin a bracket. The bit in the session parameters designates whether the PLU or the SLU is to be the first speaker; the other LU is automatically the bidder.

When a bracket is ended, the first speaker can start a new bracket if needed. The bidder, however, must ask permission to begin a bracket. The bidder can do this in either of two ways:

The bidder can ask permission by sending a Bid data-flow-control request to the first speaker. A positive response to the Bid request indicates that the first speaker has granted permission. A negative response indicates that permission is denied. The negative response, however, can be accompanied by sense data that indicates whether the first speaker will or will not later grant the permission by sending a Ready to Receive data-flow-control request. On receipt of that request, the bidder can begin a bracket.
The bidder can ask permission by starting to send a chain in which the first request contains BB. The response indicates whether the bidder can continue with the bracket, with a positive response indicating that it can continue and a negative response indicating that the attempt was rejected. The negative response, however, can be accompanied by sense data that indicates whether the first speaker does or does not later send the Ready to Receive request. There are restrictions on attempting to begin a bracket by starting to send a chain with BB:
- If the bidder is sending only a single chain, the first request in the chain must specify BB and EB.
- If the bidder is sending multiple chains, the first request in the first chain must specify BB and the bidder must ask for a definite response to the first chain. If the bidder gets a negative response, it knows that its bracket-initiation request was rejected and that it must terminate the chain (either by sending the Cancel request or by sending a request marked last in chain).

Like quiesce and change-direction protocol, bracket protocol is not enforced by VTAM. It must be adhered to by the participants.