Binary Synchronous Communications

Binary Synchronous Communication (BSC or Bisync) is an IBM link protocol, announced in 1967 after the introduction of System/360. It replaced the synchronous-transmit-receive (STR) protocol used with second generation computers. The intent was that common link management rules could be used with three different alphabets for encoding messages. Six-bit Transcode looked backwards to older systems; USASCII with 128 characters and EBCDIC with 256 characters looked forward. Transcode disappeared very quickly but the EBCDIC dialect of Bisync still has very limited use in the 2000s.

Framing

BiSync differs from all popular protocols which succeeded it, in the complexity of message framing. Later protocols used a single framing scheme for all messages sent by the protocol. HDLC, Digital Data Communications Message Protocol (DDCMP), Point-to-Point Protocol (PPP), etc all have different framing schemes but only one frame format exists within a specific protocol. Bisync had five different framing formats. Normal data framing restricted the number of different characters which could be included in a text block to: Transcode 59, USASCII 123, EBCDIC 251. Transparent data framing provided an unrestricted alphabet of 64, 128 or 256 characters. The framing protocol varied with the message content:
# Normal data: restricted character set
# Transparent data: unrestricted character set
# Single character link control phrase: EOT, NACK etc.
# DLE stick: ACK0, ACK1, WACK, RVI, DLE-EOT
# Forward abort: STX ... ENQ::a. Temporary Transmit Delay: (TTD) encoded STX ENQ

All of these frame formats begin with at least two SYNC bytes. The binary form of the SYNC byte has the property that no rotation of the byte is equal to the original.This allows the receiver to find the beginning of a frame by searching the received bit stream for the SYNC pattern. When this is found, tentative byte synchronization has been achieved. If the next character is also a SYNC, character synchronization has been achieved. The receiver then searches for a character which can start a frame. Characters outside of this set are described as "leading graphics". They are sometimes used to identify the sender of a frame.

The beginning of a data frame is signalled by the special character SYN (synchronization). The body of the frame is wrapped between two special sentinel characters: STX (start of text) and ETX (End of text).

Normal data frames do not allow certain characters to appear in the data. These are the block ending characters: ETB, ETX and ENQ and the ITB and SYNC characters. A long data frame should contain an inserted SYNC byte every two seconds to indicate that character synchronization is still present. The receiver deletes this character. A normal block ending character (ETB or ETX) is followed by some kind of checksum. For Transcode and EBCDIC this is a two character cyclic redundancy check; for USASCII is a one character longitudinal redundancy check. A data frame may contain an intermediate checksum preceded by an ITB character. This ability to include intermediate checksums in a long data frame allowed a considerable improvement of the error detection probability.

Transparent data frames allowed all 256 EBCDIC characters to be transmitted. Block framing characters such as ETB, ETX, and SYNC were preceded by a DLE character to indicate their control significance. This technique became known as character stuffing, by analogy with bit stuffing.

Error protection for ACK0 and ACK1 is weak. The Hamming distance between the two messages is only two bits.

Link Control

The link control protocol is similar to STR. The designers attempted to protect against simple transmission errors. The EBCDIC CRC-16 used to protect data frames is reasonably strong; the Transcode CRC-12 is somewhat weaker. The protocol requires that every message be acknowledged (ACK) or negatively acknowledged (NAK), so transmittal of small packets has high transmission overhead. The protocol can recover from a corrupted data frame, a lost data frame, and a lost acknowledgment.

Error recovery is by retransmission of the corrupted frame. Since bisync data packets aren't serial-numbered, it's considered possible for a data frame to go missing without the receiver realizing it. Therefore, alternating ACK0s and ACK1s are deployed; if the transmitter receives the wrong ACK, it can assume a data packet (or an ACK) went missing. A potential flaw is that corruption of ACK0 into ACK1 could result in duplication of a data frame.

The protocol is half-duplex (2-wire). In this environment, packets or frames of transmission are strictly unidirectional, necessitating 'turn-around' for even the simplest purposes, such as acknowledgments. Turn-around involves
* the reversal of transmission direction,
* quiescing of line echo,
* and resyncing.In a 2-wire environment, this causes a noticeable round-trip delay and reduces performance.

Some datasets support full-duplex operation, and full-duplex (4-wire) can be used in many circumstances to improve performance by eliminating the turn-around time, at the added expense of 4-wire installation and support. In typical full-duplex , data packets are transmitted along one wire pair while the acknowledgements are returned along the other.

Routing

Much bisync traffic was strictly point-to-point. In some cases connection of a terminal to multiple hosts was possible via the dial telephone network.

Multi-drop was part of the initial bisync protocol. A master station (control unit) would poll several terminals which are attached via analog bridges to the same communication line. The selected station could then transmit a message to the master. The master could address a message to a specific station. Leading graphics mentioned above were used for station selection.

BiSync Applications

The original purpose of bisync was for batch communications between a System/360 mainframe and another mainframe or an Remote Job Entry (RJE) terminal such as the IBM 2780 and IBM 3780. The RJE terminals supported a limited number of data formats: punched card images in and out and print line images to the terminal. Some non-IBM hardware vendors such as Mohawk Data Sciences used bisync for other purposes such as tape to tape transmission. RPG for System/36 and System/38 included support for bisync. A programmer could easily emulate an RJE terminal or other device.

IBM offered assembler language macros to provide programming support. During the S/360 era, these primitive methods were BTAM (basic teleprocessing access method) and QTAM (queued teleprocessing access method). IBM introduced VTAM (virtual teleprocessing access method) with the S/370 and, subsequently, CICS environment in support of the remote 3270. The 3270s were further supported by Remote DUCS (display unit control system) and WestiTAM (Westinghouse telecommunications access method) application platorms (both written by the same architect). CICS went on to fold in SDLC under the SNA umbrella.

Pseudo-Bisync Applications

Some important systems used Bisync data framing with a different link control protocol. HASP used Bisync half-duplex hardware in conjunction with their own link control protocol to provide full-duplex multi-datastream communication between a small computer and a mainframe running HASP. Some early X.25 networks tolerated a connection scheme where transparent Bisync data frames encapsulated HDLC LAPB data and control packets.

Disposition

Bisync was first displaced by Systems Network Architecture which allows construction of a network with multiple hosts and multiple programs using telecommunications. X.25 and Internet Protocol of system which like SNA provide more than mere link control.

ee also

* IBM HASP
* IBM 2780/3780
* IBM 3270

References

* [http://www.aton.com/Training/Report_Abstracts/Bisync_Paper/bisync_paper.htm Detailed discussion of Bisync link control] (dead link)
* cite web |title=Bisync, BSC
work=Connectivity Knowledge Platform
publisher=Made IT
url=http://ckp.made-it.com/bisync.html
accessdate=2006-07-06 A detailed description of the protocol.
* [http://www.ibm1130.net/functional/SCA.html Bisync & STR programming for IBM 1130]
* cite web
title = Data Communications Protocols
work = Telecom Corner Technical Reference Site
publisher = TBI/WebNet, Inc.
date = October, 2004
url = http://telecom.tbi.net/protocol.htm
accessdate = 2006-07-06
* cite web | title = What is Bisync? A Short History Lesson
publisher = Serengeti Systems
url = http://www.serengeti.com/what_is_bisync.php3
accessdate = 2006-07-06

"Includes material from FOLDOC, used with permission."