@make(text) @style @case[device, postscript="@style", x9700="@style @modify" ] @modify @modify @begin(center) @begin(majorheading) EVALUATING RS-232 COMMUNICATION PACKAGES @end(majorheading) @blankspace(0.5) Frank da Cruz,@ @ Christine Gianone @blankspace(0.5) Columbia University Center for Computing Activities New York, N.Y. 10027 @i@foot(This is the original manuscript of the article that was published in Data Communications Magazine as "Shopping for Software That Lets PCs Chat With Mainframes", December 1987, pp.155-170.) @end(center) @blankspace(0.5inch) In most places where there are computers, nobody questions the need for data communication. The question is more likely to be how best to do it. In theory networks can do the job, typically PC LANs, perhaps interconnected by gateways to mainframe networks. But this arrangement presumes that equipment was purchased according to some consistent plan, with networking in mind. In practice, most organizations have a patchwork history of computer acquisition, resulting in a hodgepodge of PCs, minis, and mainframes for which compatible networking options are not available or affordable. Often, the only device these systems share in common is the humble RS-232 asynchronous communication port. Even when comprehensive networking solutions exist, the cost of attaching hundreds or thousands of PCs, at $500-$1500 per PC, to a Token Ring or Ethernet can be daunting. And those who want to dial in from home, or dial out to external services, must still be accommodated. For these reasons, many organizations choose to connect PCs to their networks through use of RS-232 communication packages like Crosstalk, Blast, Relay Gold, Smartcomm, VTERM, Kermit, PC-Talk, ProComm, Red Ryder, HyperACCESS, or ASCII Pro. Hundreds of these products permeate the marketplace, and, if selected intelligently, they can fill the gaps in an organization's network effectively and inexpensively. The cost for PC-resident data communication programs typically ranges from $20 to $500 per PC, with some exceptions (some are free, others cost more). And that makes these programs more affordable than most PC network connections. Evaluating RS-232 communication packages can be a complicated process. The Cost must be weighed carefully against the needs of your organization. Reviews and surveys of communication packages appear frequently in the popular computer publications, and they can help. But surveys consisting mostly of charts in which, say, 100 popular software packages are compared on the basis of, say, 20 arbitrarily chosen features, are necessarily superficial. And many articles concentrate on frills and conveniences while giving short shrift to central issues like connection establishment and maintenance, terminal emulation, and file transfer. In this article we attempt to present the features of RS-232 communication packages in a way that will help you to assess their relative importance for yourself or your organization. @subheading RS-232 communication packages are software programs that run on personal computers like the IBM PC, IBM clone, Apple II, or Macintosh, and communicate asynchronously with remote computers through RS-232-C serial ports, either directly or through modems. This distinguishes them from specialized products that emulate synchronous terminals in IBM mainframe, Wang, or similar environments, for which special adapters (like an Irma board) and connections (like coax) are required, and which won't be discussed here. There are two fundamental aspects to any PC communication package. One is terminal emulation, which allows you to connect your PC to a mini or mainframe as a terminal in order to conduct a timesharing session or to access an application on a central, shared system. The other is data transfer, which lets you exchange information between your PC and a mini or mainframe (or another PC). For terminal emulation, PC-resident software is the only requirement. For error-free data transfer, however, a companion program is required on the other computer. The cost for commercial mini- or mainframe-based communication programs runs much higher than PC versions, typically ranging from $1000 to $100,000 (again, with exceptions). @subheading The most immediately striking aspect of any program is the "user interface": the prompts, commands, menus, function keys, etc, with which you make your wishes known to the program, and the displays with which it makes the results known to you. There are many styles of user interface: command line, interactive prompt and command, menus and arrow keys, mice and windows. The fundamental tradeoff is ease of learning versus ease of use. Ease of learning is important if many people will be using the package infrequently or if there is rapid personnel turnover, so that relatively little time need be "wasted" in learning and training. A user interface designed for ease of learning presents you with all the choices in menus. The penalty is that you are always presented with menus for everything, which slows you down needlessly once you have become expert. At the other extreme are programs that favor the expert, providing only terse and cryptic commands, sometimes with no way for a novice to get help at all, short of reading the manual. A compromise, "menu on demand", lets the expert issue rapid, terse commands, while still allowing the novice to see a menu at any point by entering a special help key. There is an oft-neglected aspect of the user interface that falls into the "ease of use" category: can the package be used by people with disabilities like motor impairment, blindess, or deafness? If you can depress only a single key at a time, how can you enter complicated Ctrl-Alt-Shift key combinations? If your PC is connected to an ASCII-oriented speaking device or a Braille terminal, how can you decipher multicolor animated graphics screens? If you can't hear, how do you know when the package is beeping or whistling at you to signal some important event? Often, the fancier the user interface, the less it lends itself to use by the disabled. Another item of minor importance, but whose absence can be a nuisance, is the ability to access system functions without actually leaving the program. If you want to change directories, list files, display a file, or delete a file, you should not have to exit the communication program, and then restart it afterwards. This can be time consuming, especially on floppy-disk-based systems, and even more so when settings -- or the connection itself -- must be reestablished. Commercial communication packages tend to place great emphasis on the appearance and style of the user interface, primarily for marketing reasons. But for most people, the user interface should not be a key factor in evaluating a product. It only lets you specify the real work to be done, and it should take up a relatively small proportion of the total time you spend with the package. Ultimately, it is much more important to know whether the product can perform the required tasks, and how well. CONNECTION ESTABLISHMENT AND MAINTENANCE Perhaps the most important aspect of any communication package its set of mechanisms for establishing a connection, matching communication parameters to the communication medium and the system on the other end, monitoring the connection once established, and breaking the connection. @subheading Any communication program should allow you control over communication parameters like bits per second, parity, duplex, flow control, and the number of data, start and stop bits per character. Each of these parameters is important, and the lack of any particular option may prevent you from communicating satisfactorily with another computer. Before you select a communication package, you should be sure it supports all the communication parameters and settings required by all the computers you need to communicate with. For example, most DEC minis and mainframes employ XON/XOFF full duplex flow control to prevent data overruns; if your PC communication package does not support XON/XOFF, then data transferred between it and the DEC system could be lost. IBM mainframe ASCII TTY linemode connections, on the other hand, are half duplex and exercise a line turnaround handshake discipline: if you transmit to the IBM mainframe before it has given you permission (by sending a special "handshake" character, such as Control-Q), it will not accept your data. Certain popular mainframes and minis, as well as public data networks like Telenet and Tymnet, use even, odd, or mark parity, and will not recognize your characters unless the right parity is applied. And if your package cannot distinguish parity bits from data bits, the wrong characters will be displayed on your screen. Table 1 shows typical RS-232 communication parameters for various systems. @begin(example) ______________________________________________________________________________ Computer Front End Duplex Flow Control Parity Terminal --------------- --------- ------ ------------ ------ -------- Data General MV None Full XON/XOFF None Dasher DEC PDP-11 None Full XON/XOFF None VT52,VT100 DEC VAX None Full XON/XOFF None VT52,VT100 DECSYSTEM-20 PDP-11 Full XON/XOFF Even VT52,VT100 Honeywell DPS8 DN335 Half XON Handshake None VIP7300,7800 HP-1000 None Full ENQ/ACK None HP262x HP-3000 None Half XON Handshake None HP262x IBM 370 Series 3705 TTY Half XON Handshake Mark TTY IBM 370 Series 7171 P.E. Full XON/XOFF Even Various* Prime minis None Full XON/XOFF Mark TTY, PS300 P.E. = 3270 Protocol Emulator, TTY = ASCII Linemode Connection. *Delivered with support for 13 popular terminals, configurable for more. Table 1: Typical Communication Parameters ______________________________________________________________________________ @end(example) Some communication packages support only a limited range of transmission speeds. For instance, they may be designed to work only for dialup connections at speeds up to 1200 or 2400 bits per second (bps). If you should ever need to connect two computers directly, you should not be artificially limited to such low speeds. Even if dialups are the only connections you will ever make, you should be aware that new modems are appearing on the market that operate at speeds in excess of 9600 bps on ordinary voice-grade phone connections. For these reasons, any communication package should be able to operate at 9600 bps or higher. 9600 bps is the highest speed supported by most minis, mainframes, and front ends today (some support 19,200 bps). Micros like the IBM PC/AT and the Macintosh, however, can drive their RS-232 ports to speeds of 38,400 bps or higher, and two such PCs connected back to back can actually transfer data at these speeds. But the higher the speed, the more important it is to have an effective flow control mechanism supported by the systems on each end of the connection. @subheading Unless your computers are hardwired together with dedicated lines, you probably use asynchronous dialup modems to establish connections with other systems. Modems communicate special control information with the PC via RS-232 modem signals like DTR, DSR, and CD (see Table 2). Most communication packages can control and monitor these signals to detect when the connection is broken, or to break the connection and hang up the phone. If you use your package interactively, modem control is largely superfluous because you will notice when the connection is broken, or you will hang up the phone yourself when you are done with it. For unattended operation, on the other hand, modem control is important in avoiding the excessive phone bills that could result when the communication package does not notice that connections break and leaves the phone off hook all night. @begin(example) ______________________________________________________________________________ FG Frame Ground TD Transmitted Data, from PC to modem RD Received Data, from modem to PC RTS Request To Send, from PC to modem, used with half duplex modems CTS Clear To Send, from modem to PC, ditto SG Signal Ground DSR Data Set Ready, indicates modem is in data transmission mode CD Carrier Detect, indicates that modem is connected to other modem DTR Data Terminal Ready, tells modem that PC is ready to communicate RI Ring Indicator, tells PC that the phone is ringing Table 2: RS-232-C Asynchronous Modem Signals ______________________________________________________________________________ @end(example) Modems may be either external or internal. External modems are controlled in a consistent way according to RS-232-C, and rarely pose a problem to communications software. Although generally more expensive, external modems are interchangeable between different computers. Internal modems, on the other hand, are built specifically for certain computers, and sometimes require special handling by the software. A particular software package will not necessarily operate correctly with a specific internal modem (check with the software vendor!). And, of course, two modems that are to communicate must support the same modulation techniques and speeds. Some packages are designed to be used only with modems, and don't work properly when two computers are connected directly by a cable, unless certain modem signals are "faked" by cross-connections or jumper wires within the cable connectors. Such a fakeout cable is called a "null modem" or "modem eliminator" (Figure 1), readily available from any computer supply house, and also available as an adapter that you can connect to your modem cable. But different systems may require different signals connected in different ways, so be prepared for some experimentation (a breakout box will help). Your communication software package can relieve you of the tinkering if it can be configured to ignore modem signals altogether when you connect two computers directly. @begin(example) ______________________________________________________________________________ True Null Modem Minimal Null Modem (8 wires) (4 wires) FG ----------- FG FG ----------- FG TD ----\ /---- TD TD ----\ /---- TD X X RD ----/ \---- RD RD ----/ \---- RD RTS ----\ /---- RTS RTS -+ +- RTS X | | CTS ----/ \---- CTS CTS -+ +- CTS DSR -+ +- DSR DSR -+ +- DSR | | | | CD -+--\ /--+- CD CD -+ +- CD X | | DTR -+--/ \--+- DTR DTR -+ +- DTR | | | | RI -+ +- RI RI -+ +- RI SG ----------- SG SG ----------- SG Figure 1: Null Modems ______________________________________________________________________________ @end(example) @subheading Many PCs are connected to the outside world only by telephone. "Smart modems", like those manufactured by Hayes, are able to dial the phone for you if they receive commands in the right format from the PC. This means that your communication package must understand the dialing language of the modem. Although the Hayes "AT" language has become a de-facto standard, not all autodial modems conform to it (prominent counterexamples include DEC DF-series modems, and selected models from Racal-Vadic, US Robotics, and Ventel). Be sure your modem's dialing language is supported by your communication package. Dialing software simplifies connection establishment, hiding the details of the dialing language from you. You tell the program what number to call, and let the software handle the details. Some packages go a step further and include a phone directory so that you don't even have to remember phone numbers, just the names of the places you want to call. Dialer control and phone directories fall into the frill category for most users. It's not much more trouble to type "ATDT7654321" than it is to type "dial fred". For unattended operation, however, automatic dialing is an essential feature. If a dial command is lacking, then the same function can be performed by a script, described below. @subheading Often, we can only guess what the right combination of speed, stop bits, parity bits, data bits, duplex, and flow control might be for a particular connection. What if we guess wrong? What tools does the communication package give us to pin down the offending parameters? Obviously, if the package lets us set these parameters independently, we can vary them until the connection works, but the combinations could be endless. Your communication package should include debugging tools to reduce the guesswork, like special display or logging of received characters, preferably including their 8-bit numeric values. If examination of the log reveals a byte with a numeric value of 193 (= 11000001 binary) where you would expect an ASCII "A" (= 01000001 binary), then you probably should be looking for 7 data bits with odd or mark parity rather than 8 data bits with no parity. A good communication package will also include a troubleshooting guide, like the one in Table 3, in which you can look up symptoms and find the corresponding diagnoses and prescriptions. @begin(example) ______________________________________________________________________________ SYMPTOM POSSIBLE CAUSE CURE Blank, dark screen. PC turned off. Turn on PC. Total garbage on screen. Wrong speed. Try another speed. Spurts of garbage on screen. Noise. Hang up and redial. Uniform mixture of good and Parity. Select a different bad characters on screen. parity. Typed characters appear twice. Duplex. Select full duplex. Typed characters don't appear. Duplex. Select half duplex. Random gaps in screen text. No flow control. Use flow control, or a slower speed. Table 3: Sample Entries from a Troubleshooting Guide ______________________________________________________________________________ @end(example) @subheading Once you have discovered the proper settings for communicating with a particular machine, you will want to have some way of saving them. To alleviate the tedium of setting five or ten communication parameters each time you connect to a given system, the package should allow settings to be collected together into "configurations" which may be saved under mnemonic names. Some packages are delivered with a set of configurations for popular dialup services like Dow-Jones, Compuserve, MCI Mail, The Source, etc. These built-in configurations shield you from having to know anything about data communication parameters. But when you must establish a connection to a system the package doesn't know about -- like from your PC at home to the mainframe at work -- you should be able to manipulate the communication settings yourself and save them for future use. Once you've determined the appropriate settings for, say, your company's DEC VAX, IBM 3090, Harris 800, plus your local Telenet PAD, you only need mention the associated configuration name to set all the corresponding parameters at once. @subheading