Basics of SNA and Protocol Converters.
Here's how. Data communications, from the invention of the telegraph onward, has had a strong element of the asynchronous; that is, start-stop, character-oriented transmission protocols. The low efficiency or low line use of these methods underlies the entire industry for statistical multiplexers.
When large computers were pushed from batch processing into on-line interactive applications, their manufacturers had to make them communicate with large numbers of remote terminals. Collectively, they came up with what was in many ways a better idea: synchronous protocols with inherent error correction. The largest maker of large computers set the de facto standard for this type of computer-driven communications.
So today we have a continuing effort to be compatible with IBM's Systems Network Architecture (SNA) for data communications. Simple Initial Efforts
The first efforts to put interactive terminals on line were necessarily simple--from the system programmer's point of view. The main CPU was the only engine available to drive the communications network, so the Basic Telecommunications Access Method (BTAM), was made part of each application program (Figure 1).
RTAM was developed about the same time as BTAM, but specifically for remote-job-entry or batch stations, and will not be elaborated on here.
The first front-end processors (FEPs) were hard-wired, and dumb, because the CPU did most of the work. The FEP (possibly more than one) was attached to the mainframe by the best available link, the local channel, which consisted of two parallel busses--data and control. Channels also connect tape drives, printers and other strictly local peripherals (in the same computer room).
The FEP talks to the world over normal communications lines, anything from dial-up analog lines to high-speed digital circuits. The interfaces are usually RS-232, so modems or modem eliminators are needed for distances greater than the standard 50 feet.
It is on these lines that we find the various protocols. BTAM was riginally written for async, but extensions handle bi-synchronous protocols that have become the most common with BTAM.
The terminals do not communicate directly with the FEP. Again, the intelligent engine is centralized, in the 3274 cluster controller that controls multiple dumb devices (the 3278 terminals or 3287 printers).
The link from the cluster controller to the terminal, however, demands great capacity. Because the controller maintains and refreshes the terminal screen, far more than simply sending characters, the rate needed is 2.5 million bits per second. This speed requires shielded conductor, now typically RG/11 coaxial cable. So each 3278 terminal has a coax to the 3274 controller.
While the simplest implementation of communications--and the most reliable after 15 years of debugging--BTAM lacks flexibility. Each application "owns" its connected terminals, lines and communications hardware.
For example, in the BTAM illustration in Figure 1, the 3274 terminal cluster controler and all of the 3278 terminals attached to it work with only one application. These terminals cannot log onto another application. The entire controller and all its terminals could be dedicated to another application, but that would require modifying and reloading the system software.
Note that this strictly hierarchical tree topology precludes direct communication between applications or between different hosts. Toward Greater Networking Flexibility
The TeleCommunications Access Method (Figure 2) represents a step toward greater networking flexibility. Now the common communications program allows applications to exchange data, but the lines and terminals are still dedicated to one application each.
Systems Network Architecture itself is not a protocol, but a scheme or overall plan for handling communications. SNA is embodied in both software and hardware (Figure 3), principally:
* VTAM (Virtual Telecommunications Access Method) is a "master" system program in the host that controls communications for all the applications in that host.
* The 3705 front-end processor or communications controller attaches to the mainframe via the local channel. The 3705 contains a processor dedicated to communications handling, and thus can remove much of the overhead burden from the main CPU. Current models support one or more data links to FEPs on other hosts, in addition to the channel.
* NCP (Network Control Program) is the software in the 3705 FEP. The latest editions support interactions among multiple hosts. NCP is responsible for handling the line protocols, which could be 3270 bisync in addition to Synchronous Data-Link Control (SDLC), to the cluster controlers and other FEPs.
* The 3274 cluster controler is an intelligent processor that controls up to 32 dumb (but expensive) terminals, the 3278s.
* The 3276 small cluster controller is built into the same cabinet as a 3278 terminal. It can support as many as seven additional 3278 terminals, as if it were a 3274. A Transparent Error-Free Path
Synchronous Data Link Control is (at last) a real protocol. It governs how a line transmits data in full duplex mode. SDLC concerns itself only with one line between two nodes (for example, between the 3705 and 3274). Its only job is to provide a transparent, error-free path over which the nodes can exchange data.
Toward that end, SDLC contains error-checking routines and provides for retransmission of data found in error.
Transparency is the ability to send any string of characters, or any bit sequence, without affecting the transmission. In async and bisync protocols, which are character-oriented, the line-handlers are always looking for recognizable control characters, usually seven or eight bits long. These sequences must be excluded from the data stream to prevent miscues. SDLC uses three techniques to provide transparency and still retain control of the line.
* Data Blocking: information is sent in blocks, or frames, at the data-link level. Each frame is marked, at beginning and end, by a unique falg (six 1 bits in a row). It is the frame that is checked for errors and retransmitted when necessary.
* Bit Stuffing prevents the unique flag (six 1 bits) from appearing within the frame by adding, at the sending end of the line, an extra zero after every five consecutive 1 bits in the data. At the receiving end, the flags are removed, then the 0's after five 1's are deleted automatically.
* Polarity reversal, rather than a fixed state, is used to indicate a 0 bit; no change in polarity from clock period to clock period indicates a 1 bit.
These last two techniques ensure good synchronization between sender and receiver. Bit stuffing prevents long strings of 1's from holding the line signal static--the extra 0 reverses the polarity at least once every six bits. Reversal on 0 bits makes long strings of 0's into continuous transitions that are easily detected.
Onto this very deterministic, highly centralized datacomm architecture, deus ex machina, drops the personal computer.
But it doesn't fit. Almost every business with an IBM mainframe computer also has, or is thinking of buying, personal computers. Most of them, out of the box, don't talk to each other or to the mainframe. The few that do communicate in 3270 do so clumsily.
The 3278 terminal has one BNC coax connector for data in and out; the PC has an RS-232 interface. Even if the PC could emulate the 3274 cluster controller, running the software would put a large overhead burden on the microprocessor, possibly more than it can handle.
And what about dialing into the SNA network? No provisionn for it. How can you direct your letters to a full-character daisy printer? You can't. Enter the Protocol Converter
For any of these problems, one possible solution would be to add a dedicated microprocessor to handle the overhead, convert EBCDIC character code to ASCII, handle a synchronous protocol on one side and an async interface on the other and multiplex terminals.
That dedicated processor is the protocol converter.
There are two points in the SNA network where a substitute processor can emulate an older product without the need to modify the central-site hardware or software--at the FEP and at the cluster controller.
At the cluster controller coax interface, a processor need deal with only one application, and one or two logical units (end devices like CRT screen or printer). Because of the differences in their needs, terminals and printers may have separate protocol converters.
At the FEP, a single communications line may address only one station (typical with older products like remote-job-entry stations running bisync). On the other hand, one SDLC line could multidrop many 3274 cluster controllers, addressing hundreds of logical units through multidrop modems. These are very different requirements and will require different protocol converters.
These points are found in networks bases on the 370 and 4300 models of IBM mainframes. Other IBM products will differ as they have distinct architectures.
|Printer friendly Cite/link Email Feedback|
|Date:||May 1, 1984|
|Previous Article:||Adding Communications Computer in SNA Net Can Offer More-timely Data.|
|Next Article:||ISDN: Interface Standards Usher in Ultimate Network.|