Network Job Entry (NJE) Formats and Protocols
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Block control byte (BCB)

Network Job Entry (NJE) Formats and Protocols
SA32-0988-00

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.
Figure 1. Results of Not Transmitting Null Records.hasa6015
Figure 2. Correct Recovery with Null Recordshasa6016

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

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014