Block control byte (BCB)

Every BSC buffer begins with a block control byte (BCB) which contains inbound and outbound buffer sequence counters. These counters are used to synchronize inbound and outbound transmissions and to detect and correct sequence errors. Table 1 shows the BCB bit definitions.

Table 1. BCB bit definitions
Binary	Meaning
1... ....	Must be 1
1xxx ....	Control information as follows:
1000 cccc	Normal block
1001 ....	Bypass sequence count validation (sometimes called "BCB ignore bit")
1010 cccc	Reset expected block sequence count to cccc.
1011 ....	Reserved for IBM's use
11xx ....	Reserved for IBM's use

After a BSC line completes initialization, each directly-attached node initializes the inbound and outbound BCB counters to 0000 and maintains it in modulo sixteen. The outbound BCB count is incremented by one each time an acknowledgement (ACK) is received. The inbound BCB count is also updated to reflect the number of transmission buffers that the node has received. When a node receives a BCB the outbound count should be one more than the last BCB it received (the inbound count). If so, data transmission is normal and no data has been lost.

If the count in the BCB is not what is expected, the receiving node must indicate an error by sending an RCB indicating a BCB sequence error. When the sequence error is received, the node receiving it terminates the connection because error recovery is not possible.

If a duplicate BCB is received, the system receiving it assumes the last transmission buffer it sent has been lost and its last transmission buffer that did not receive an acknowledgement must be re-sent. The duplicate buffer is discarded. This allows the NJE network to recover from errors rather than terminating the connection by indicating a sequence error.

Because the BCB is also used to detect lost blocks, a null block containing a BCB should always be sent as an acknowledgement rather than using a DLE ACK0 as the acknowledgement. Figure 1 and Figure 2 clarify the importance of using the DLE as an acknowledgement.

hasa6015 — Figure 1. Results of Not Transmitting Null Records.

hasa6016 — Figure 2. Correct Recovery with Null Records

Use Table 2 to determine the state a node is placed in and the action it takes after receiving a transmission block.

Table 2. Transmission Block Handling State Table
Current state of node	Event	Action node takes	New state of node after action is taken
State 1:Waiting for a response	Receives a data block		Checks the BCB
	Receives DLE ACK0	Transmits last non-NAK block of data	Waits for a response
	Receives a NAK	Retransmits last non-NAK	Waits for a response
	Receives an error (not CE-DE status)	Increments error count	Checks error count
State 2:Checking a BCB	Corrects the BCB	Transmits last non-NAK block of data	Waits for a response
	Detects a duplicate BCB	Retransmits the last non-NAK	Waits for a response
	Detects an incorrect BCB	Transmits a sequence error	Waits for a response
State 3:Recovering from an error and waiting for a response	Receives a data block		Checks the BCB
	Receives DLE ACK0	Transmits last non-NAK block of data	Waits for a response
	Receives a NAK	Retransmits last non-NAK	Waits for a response
	Receives an error (not CE-DE status)	Increments error count	Checks error count
State 4:Checking error count	Error count is not exceeded	Transmit a NAK	Recovers from the error and waits for a response