home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / e / dc.mss < prev    next >
Text File  |  2020-01-01  |  60KB  |  1,223 lines

  1. @make(text)
  2. @style<Justification On, Hyphenation On, WidestBlank 1.4,Indent 2>
  3. @case[device,
  4. postscript="@style<spacing 1.2,spread 0.8,fontfamily NewCenturySchoolbook>",
  5. x9700="@style<fontfamily univers10,spacing 1,spread 1>
  6.     @modify<example,facecode U>"
  7. ]
  8. @modify<example,above 1,below 1,group,leftmargin 0,rightmargin 0>
  9. @modify<subheading,above 2,below 1,need 6>
  10. @begin(center)
  11. @begin(majorheading)
  12. EVALUATING RS-232 COMMUNICATION PACKAGES
  13. @end(majorheading)
  14. @blankspace(0.5)
  15. Frank da Cruz,@ @ Christine Gianone
  16. @blankspace(0.5)
  17. Columbia University Center for Computing Activities
  18. New York, N.Y.  10027
  19.  
  20. @i<December 1987>@foot(This is the original manuscript
  21. of the article that was published in Data Communications Magazine as "Shopping
  22. for Software That Lets PCs Chat With Mainframes", December 1987, pp.155-170.)
  23. @end(center)
  24. @blankspace(0.5inch)
  25. In most places where there are computers, nobody questions the need for data
  26. communication.  The question is more likely to be how best to do it.  In
  27. theory networks can do the job, typically PC LANs, perhaps interconnected by
  28. gateways to mainframe networks.  But this arrangement presumes that
  29. equipment was purchased according to some consistent plan, with networking
  30. in mind.  In practice, most organizations have a patchwork history of
  31. computer acquisition, resulting in a hodgepodge of PCs, minis, and
  32. mainframes for which compatible networking options are not available or
  33. affordable.  Often, the only device these systems share in common is the
  34. humble RS-232 asynchronous communication port.  Even when comprehensive
  35. networking solutions exist, the cost of attaching hundreds or thousands of
  36. PCs, at $500-$1500 per PC, to a Token Ring or Ethernet can be daunting.  And
  37. those who want to dial in from home, or dial out to external services, must
  38. still be accommodated.
  39.  
  40. For these reasons, many organizations choose to connect PCs to their
  41. networks through use of RS-232 communication packages like Crosstalk, Blast,
  42. Relay Gold, Smartcomm, VTERM, Kermit, PC-Talk, ProComm, Red Ryder,
  43. HyperACCESS, or ASCII Pro.  Hundreds of these products permeate the
  44. marketplace, and, if selected intelligently, they can fill the gaps in an
  45. organization's network effectively and inexpensively.  The cost for
  46. PC-resident data communication programs typically ranges from $20 to $500
  47. per PC, with some exceptions (some are free, others cost more).  And that
  48. makes these programs more affordable than most PC network connections.
  49.  
  50. Evaluating RS-232 communication packages can be a complicated process.  The
  51. Cost must be weighed carefully against the needs of your organization.
  52. Reviews and surveys of communication packages appear frequently in the
  53. popular computer publications, and they can help.  But surveys consisting
  54. mostly of charts in which, say, 100 popular software packages are compared
  55. on the basis of, say, 20 arbitrarily chosen features, are necessarily
  56. superficial.  And many articles concentrate on frills and conveniences while
  57. giving short shrift to central issues like connection establishment and
  58. maintenance, terminal emulation, and file transfer.  In this article we
  59. attempt to present the features of RS-232 communication packages in a way
  60. that will help you to assess their relative importance for yourself or your
  61. organization.
  62.  
  63. @subheading<WHAT IS AN RS-232 COMMUNICATION PACKAGE?>
  64.  
  65. RS-232 communication packages are software programs that run on personal
  66. computers like the IBM PC, IBM clone, Apple II, or Macintosh, and
  67. communicate asynchronously with remote computers through RS-232-C serial
  68. ports, either directly or through modems.  This distinguishes them from
  69. specialized products that emulate synchronous terminals in IBM mainframe,
  70. Wang, or similar environments, for which special adapters (like an Irma
  71. board) and connections (like coax) are required, and which won't be
  72. discussed here.
  73.  
  74. There are two fundamental aspects to any PC communication package.  One is
  75. terminal emulation, which allows you to connect your PC to a mini or
  76. mainframe as a terminal in order to conduct a timesharing session or to
  77. access an application on a central, shared system.  The other is data
  78. transfer, which lets you exchange information between your PC and a mini or
  79. mainframe (or another PC).  For terminal emulation, PC-resident software is
  80. the only requirement.  For error-free data transfer, however, a companion
  81. program is required on the other computer.  The cost for commercial mini- or
  82. mainframe-based communication programs runs much higher than PC versions,
  83. typically ranging from $1000 to $100,000 (again, with exceptions).
  84.  
  85. @subheading<USER INTERFACE>
  86.  
  87. The most immediately striking aspect of any program is the "user interface":
  88. the prompts, commands, menus, function keys, etc, with which you make your
  89. wishes known to the program, and the displays with which it makes the
  90. results known to you.
  91.  
  92. There are many styles of user interface: command line, interactive prompt
  93. and command, menus and arrow keys, mice and windows.  The fundamental
  94. tradeoff is ease of learning versus ease of use.  Ease of learning is
  95. important if many people will be using the package infrequently or if there
  96. is rapid personnel turnover, so that relatively little time need be "wasted"
  97. in learning and training.  A user interface designed for ease of learning
  98. presents you with all the choices in menus.  The penalty is that you are
  99. always presented with menus for everything, which slows you down needlessly
  100. once you have become expert.  At the other extreme are programs that favor
  101. the expert, providing only terse and cryptic commands, sometimes with no way
  102. for a novice to get help at all, short of reading the manual.  A compromise,
  103. "menu on demand", lets the expert issue rapid, terse commands, while still
  104. allowing the novice to see a menu at any point by entering a special help
  105. key.
  106.  
  107. There is an oft-neglected aspect of the user interface that falls into the
  108. "ease of use" category: can the package be used by people with disabilities
  109. like motor impairment, blindess, or deafness?  If you can depress only a
  110. single key at a time, how can you enter complicated Ctrl-Alt-Shift key
  111. combinations?  If your PC is connected to an ASCII-oriented speaking device
  112. or a Braille terminal, how can you decipher multicolor animated graphics
  113. screens?  If you can't hear, how do you know when the package is beeping or
  114. whistling at you to signal some important event?  Often, the fancier the
  115. user interface, the less it lends itself to use by the disabled.
  116.  
  117. Another item of minor importance, but whose absence can be a nuisance, is
  118. the ability to access system functions without actually leaving the program.
  119. If you want to change directories, list files, display a file, or delete a
  120. file, you should not have to exit the communication program, and then
  121. restart it afterwards.  This can be time consuming, especially on
  122. floppy-disk-based systems, and even more so when settings -- or the
  123. connection itself -- must be reestablished.
  124.  
  125. Commercial communication packages tend to place great emphasis on the
  126. appearance and style of the user interface, primarily for marketing reasons.
  127. But for most people, the user interface should not be a key factor in
  128. evaluating a product.  It only lets you specify the real work to be done,
  129. and it should take up a relatively small proportion of the total time you
  130. spend with the package.  Ultimately, it is much more important to know
  131. whether the product can perform the required tasks, and how well.
  132.  
  133.  CONNECTION ESTABLISHMENT AND MAINTENANCE
  134.  
  135. Perhaps the most important aspect of any communication package its set of
  136. mechanisms for establishing a connection, matching communication parameters
  137. to the communication medium and the system on the other end, monitoring the
  138. connection once established, and breaking the connection.
  139.  
  140. @subheading<COMMUNICATION PARAMETER SETTINGS>
  141.  
  142. Any communication program should allow you control over communication
  143. parameters like bits per second, parity, duplex, flow control, and the
  144. number of data, start and stop bits per character.  Each of these parameters
  145. is important, and the lack of any particular option may prevent you from
  146. communicating satisfactorily with another computer.  Before you select a
  147. communication package, you should be sure it supports all the communication
  148. parameters and settings required by all the computers you need to
  149. communicate with.
  150.  
  151. For example, most DEC minis and mainframes employ XON/XOFF full duplex flow
  152. control to prevent data overruns; if your PC communication package does not
  153. support XON/XOFF, then data transferred between it and the DEC system could
  154. be lost.  IBM mainframe ASCII TTY linemode connections, on the other hand,
  155. are half duplex and exercise a line turnaround handshake discipline: if you
  156. transmit to the IBM mainframe before it has given you permission (by sending
  157. a special "handshake" character, such as Control-Q), it will not accept your
  158. data.  Certain popular mainframes and minis, as well as public data networks
  159. like Telenet and Tymnet, use even, odd, or mark parity, and will not
  160. recognize your characters unless the right parity is applied.  And if your
  161. package cannot distinguish parity bits from data bits, the wrong characters
  162. will be displayed on your screen.  Table 1 shows typical RS-232
  163. communication parameters for various systems.
  164.  
  165. @begin(example)
  166. ______________________________________________________________________________
  167.  
  168. Computer         Front End   Duplex   Flow Control     Parity    Terminal
  169. ---------------  ---------   ------   ------------     ------    --------
  170. Data General MV   None        Full      XON/XOFF        None      Dasher
  171. DEC PDP-11        None        Full      XON/XOFF        None      VT52,VT100
  172. DEC VAX           None        Full      XON/XOFF        None      VT52,VT100
  173. DECSYSTEM-20     PDP-11       Full      XON/XOFF        Even      VT52,VT100
  174. Honeywell DPS8   DN335        Half    XON Handshake     None      VIP7300,7800
  175. HP-1000           None        Full      ENQ/ACK         None      HP262x
  176. HP-3000           None        Half    XON Handshake     None      HP262x
  177. IBM 370 Series   3705 TTY     Half    XON Handshake     Mark      TTY
  178. IBM 370 Series   7171 P.E.    Full      XON/XOFF        Even      Various*
  179. Prime minis       None        Full      XON/XOFF        Mark      TTY, PS300 
  180.  
  181.        P.E. = 3270 Protocol Emulator, TTY = ASCII Linemode Connection.
  182.    *Delivered with support for 13 popular terminals, configurable for more.
  183.  
  184.                   Table 1: Typical Communication Parameters
  185. ______________________________________________________________________________
  186. @end(example)
  187.  
  188. Some communication packages support only a limited range of transmission
  189. speeds.  For instance, they may be designed to work only for dialup
  190. connections at speeds up to 1200 or 2400 bits per second (bps).  If you
  191. should ever need to connect two computers directly, you should not be
  192. artificially limited to such low speeds.  Even if dialups are the only
  193. connections you will ever make, you should be aware that new modems are
  194. appearing on the market that operate at speeds in excess of 9600 bps on
  195. ordinary voice-grade phone connections.  For these reasons, any
  196. communication package should be able to operate at 9600 bps or higher.  9600
  197. bps is the highest speed supported by most minis, mainframes, and front ends
  198. today (some support 19,200 bps).  Micros like the IBM PC/AT and the
  199. Macintosh, however, can drive their RS-232 ports to speeds of 38,400 bps or
  200. higher, and two such PCs connected back to back can actually transfer data
  201. at these speeds.  But the higher the speed, the more important it is to have
  202. an effective flow control mechanism supported by the systems on each end of the
  203. connection.
  204.  
  205. @subheading<MODEM CONTROL>
  206.  
  207. Unless your computers are hardwired together with dedicated lines, you
  208. probably use asynchronous dialup modems to establish connections with other
  209. systems.  Modems communicate special control information with the PC via
  210. RS-232 modem signals like DTR, DSR, and CD (see Table 2).  Most
  211. communication packages can control and monitor these signals to detect when
  212. the connection is broken, or to break the connection and hang up the phone.
  213. If you use your package interactively, modem control is largely superfluous
  214. because you will notice when the connection is broken, or you will hang up
  215. the phone yourself when you are done with it.  For unattended operation, on
  216. the other hand, modem control is important in avoiding the excessive phone
  217. bills that could result when the communication package does not notice that
  218. connections break and leaves the phone off hook all night.
  219.  
  220. @begin(example)
  221. ______________________________________________________________________________
  222.  
  223.   FG   Frame Ground
  224.   TD   Transmitted Data, from PC to modem
  225.   RD   Received Data, from modem to PC
  226.   RTS  Request To Send, from PC to modem, used with half duplex modems
  227.   CTS  Clear To Send, from modem to PC, ditto
  228.   SG   Signal Ground
  229.   DSR  Data Set Ready, indicates modem is in data transmission mode
  230.   CD   Carrier Detect, indicates that modem is connected to other modem
  231.   DTR  Data Terminal Ready, tells modem that PC is ready to communicate
  232.   RI   Ring Indicator, tells PC that the phone is ringing
  233.  
  234.                  Table 2: RS-232-C Asynchronous Modem Signals
  235. ______________________________________________________________________________
  236. @end(example)
  237.  
  238. Modems may be either external or internal.  External modems are controlled
  239. in a consistent way according to RS-232-C, and rarely pose a problem to
  240. communications software.  Although generally more expensive, external modems
  241. are interchangeable between different computers.  Internal modems, on the
  242. other hand, are built specifically for certain computers, and sometimes
  243. require special handling by the software.  A particular software package
  244. will not necessarily operate correctly with a specific internal modem (check
  245. with the software vendor!).  And, of course, two modems that are to
  246. communicate must support the same modulation techniques and speeds.
  247.  
  248. Some packages are designed to be used only with modems, and don't work
  249. properly when two computers are connected directly by a cable, unless
  250. certain modem signals are "faked" by cross-connections or jumper wires
  251. within the cable connectors.  Such a fakeout cable is called a "null modem"
  252. or "modem eliminator" (Figure 1), readily available from any computer supply
  253. house, and also available as an adapter that you can connect to your modem
  254. cable.  But different systems may require different signals connected in
  255. different ways, so be prepared for some experimentation (a breakout box will
  256. help).  Your communication software package can relieve you of the tinkering
  257. if it can be configured to ignore modem signals altogether when you connect
  258. two computers directly.
  259.  
  260. @begin(example)
  261. ______________________________________________________________________________
  262.  
  263.            True Null Modem                  Minimal Null Modem
  264.             (8 wires)                         (4 wires)
  265.  
  266.          FG ----------- FG                 FG ----------- FG
  267.  
  268.          TD ----\ /---- TD                 TD ----\ /---- TD
  269.              X                                 X
  270.          RD ----/ \---- RD                 RD ----/ \---- RD
  271.  
  272.         RTS ----\ /---- RTS               RTS -+       +- RTS
  273.              X                             |       |
  274.         CTS ----/ \---- CTS               CTS -+       +- CTS
  275.  
  276.         DSR -+       +- DSR               DSR -+       +- DSR
  277.          |       |                         |       |
  278.          CD -+--\ /--+- CD                CD  -+       +- CD
  279.              X                             |       |
  280.         DTR -+--/ \--+- DTR               DTR -+       +- DTR
  281.          |       |                         |       |
  282.          RI -+       +- RI                 RI -+       +- RI
  283.  
  284.          SG ----------- SG                 SG ----------- SG
  285.  
  286.                             Figure 1: Null Modems
  287. ______________________________________________________________________________
  288. @end(example)
  289.  
  290. @subheading<DIALER CONTROL>
  291.  
  292. Many PCs are connected to the outside world only by telephone.  "Smart
  293. modems", like those manufactured by Hayes, are able to dial the phone for
  294. you if they receive commands in the right format from the PC.  This means
  295. that your communication package must understand the dialing language of the
  296. modem.  Although the Hayes "AT" language has become a de-facto standard, not
  297. all autodial modems conform to it (prominent counterexamples include DEC
  298. DF-series modems, and selected models from Racal-Vadic, US Robotics, and
  299. Ventel).  Be sure your modem's dialing language is supported by your
  300. communication package.
  301.  
  302. Dialing software simplifies connection establishment, hiding the details of
  303. the dialing language from you.  You tell the program what number to call,
  304. and let the software handle the details.  Some packages go a step further
  305. and include a phone directory so that you don't even have to remember phone
  306. numbers, just the names of the places you want to call.
  307.  
  308. Dialer control and phone directories fall into the frill category for most
  309. users.  It's not much more trouble to type "ATDT7654321" than it is to type
  310. "dial fred".  For unattended operation, however, automatic dialing is an
  311. essential feature.  If a dial command is lacking, then the same function can
  312. be performed by a script, described below.
  313.  
  314. @subheading<DEBUGGING COMMUNICATION PARAMETERS>
  315.  
  316. Often, we can only guess what the right combination of speed, stop bits,
  317. parity bits, data bits, duplex, and flow control might be for a particular
  318. connection.  What if we guess wrong?  What tools does the communication
  319. package give us to pin down the offending parameters?
  320.  
  321. Obviously, if the package lets us set these parameters independently, we can
  322. vary them until the connection works, but the combinations could be endless.
  323. Your communication package should include debugging tools to reduce the
  324. guesswork, like special display or logging of received characters,
  325. preferably including their 8-bit numeric values.  If examination of the log
  326. reveals a byte with a numeric value of 193 (= 11000001 binary) where you
  327. would expect an ASCII "A" (= 01000001 binary), then you probably should be
  328. looking for 7 data bits with odd or mark parity rather than 8 data bits with
  329. no parity.
  330.  
  331. A good communication package will also include a troubleshooting guide, like
  332. the one in Table 3, in which you can look up symptoms and find the
  333. corresponding diagnoses and prescriptions.
  334.  
  335. @begin(example)
  336. ______________________________________________________________________________
  337.  
  338.     SYMPTOM                           POSSIBLE CAUSE      CURE
  339.  
  340.     Blank, dark screen.               PC turned off.      Turn on PC.
  341.  
  342.     Total garbage on screen.          Wrong speed.        Try another speed.
  343.  
  344.     Spurts of garbage on screen.      Noise.              Hang up and redial.
  345.  
  346.     Uniform mixture of good and       Parity.             Select a different
  347.     bad characters on screen.                             parity.
  348.  
  349.     Typed characters appear twice.    Duplex.             Select full duplex.
  350.  
  351.     Typed characters don't appear.    Duplex.             Select half duplex.
  352.  
  353.     Random gaps in screen text.       No flow control.    Use flow control,
  354.                                                           or a slower speed.
  355.  
  356.              Table 3: Sample Entries from a Troubleshooting Guide
  357. ______________________________________________________________________________
  358. @end(example)
  359.  
  360. @subheading<SAVING COMMUNICATION PARAMETERS>
  361.  
  362. Once you have discovered the proper settings for communicating with a
  363. particular machine, you will want to have some way of saving them.  To
  364. alleviate the tedium of setting five or ten communication parameters each
  365. time you connect to a given system, the package should allow settings to be
  366. collected together into "configurations" which may be saved under mnemonic
  367. names.
  368.  
  369. Some packages are delivered with a set of configurations for popular dialup
  370. services like Dow-Jones, Compuserve, MCI Mail, The Source, etc.  These
  371. built-in configurations shield you from having to know anything about data
  372. communication parameters.  But when you must establish a connection to a
  373. system the package doesn't know about -- like from your PC at home to the
  374. mainframe at work -- you should be able to manipulate the communication
  375. settings yourself and save them for future use.  Once you've determined the
  376. appropriate settings for, say, your company's DEC VAX, IBM 3090, Harris 800,
  377. plus your local Telenet PAD, you only need mention the associated
  378. configuration name to set all the corresponding parameters at once.
  379.  
  380. @subheading<SCRIPT LANGUAGE, UNATTENDED OPERATION>
  381.  
  382. Just as a communication package may remember your communication settings or
  383. phone numbers for you, it can also allow repetitive interactive tasks, like
  384. login sequences, to be automated by means of "scripts".  Scripts are little
  385. "programs" that look for specific outputs from the remote computer and
  386. provide appropriate responses.  When the package, or the underlying system,
  387. allows a script to be executed at a predesignated time, then it is possible
  388. to carry on a canned dialog with no human operator present.  For instance,
  389. you might program your PC to "wake up" at midnight, set the proper
  390. communication parameters and dial up your office mini, log in, deposit the
  391. day's transactions, fetch and print the day's mail, log out, and hang up.
  392. Script languages vary from the primitive and cryptic to full-blown
  393. programming languages complete with variables and conditional branching.
  394. Figure 2 shows a simple script for dialing a Hayes modem to establish a
  395. connection to a Unix system and then logging in.  It illustrates how a
  396. script can be used in place of built-in dialer control.
  397.  
  398. @begin(example)
  399. ______________________________________________________________________________
  400.  
  401.     set speed 1200                   Bits per second
  402.     set parity none                  Parity
  403.     output AT\13                     Wake up the modem
  404.     input OK                         Look for its "OK"
  405.     output ATD7654321\13             Give modem's dialing command
  406.     input CONNECT                    Look for desired response
  407.     pause 1                          Wait a second
  408.     output \13                       Send a carriage return
  409.     input login:                     Look for login prompt
  410.     output chris\13                  Send user ID, followed by carriage return
  411.     input Password:                  Look for password prompt
  412.     echo Connecting to Unix System...
  413.     echo Please type your password:
  414.     connect                          Let the user take over
  415.  
  416.                       Figure 2: Script Language Example
  417.  
  418. ______________________________________________________________________________
  419. @end(example)
  420.  
  421. The "output" commands send the indicated text strings to the Unix system
  422. ("\13" is a code for carriage return), and the "input" commands search the
  423. incoming data for the indicated strings.  If any of the input commands fail,
  424. the script is automatically terminated.  This is an important feature of a
  425. script language.  Suppose, for instance, you have a nightly script which
  426. sends your day's work to a mainframe and then deletes it from the PC's hard
  427. disk.  If the data could not be successfully transmitted, then you certainly
  428. don't want the script to forge ahead stubbornly and destroy all your work.
  429.  
  430. Scripts are essential for unattended operation, and they are also useful in
  431. setting up procedures for relatively unskilled operators such as data entry
  432. clerks.  For the typical interactive user, however, scripts are a minor
  433. convenience rather than a necessity.
  434.  
  435. @subheading<TERMINAL EMULATION>
  436.  
  437. The PC has increasingly replaced the terminal in many organizations.  In
  438. addition to its other capabilities, a properly programmed PC can also act
  439. like ("emulate") a terminal, so that you can use it to conduct a dialog with
  440. a remote computer.  Your keystrokes are sent out the communication port, and
  441. characters that arrive at the port are displayed on the screen.  On half
  442. duplex, local echo connections, your keystrokes are also displayed on the
  443. screen.  On full duplex connections, terminal emulation can be a tricky
  444. business because characters may arrive at the port at the same time that you
  445. are typing; communication programs vary in their ability to handle both
  446. events at once, especially at higher speeds.
  447.  
  448. It should be stressed that terminal emulation does NOT provide any sort of
  449. automatic error control, any more than a real terminal would.  Bare
  450. characters are sent back and forth with absolutely no error recovery
  451. mechanism.  If a package claims to supply error-checking data transfer, you
  452. should understand that this claim applies to its file transfer functions and
  453. not to its terminal emulator.  A noisy telephone line would probably leave
  454. garbage on your screen during terminal emulation even though files could be
  455. transferred successfully.
  456.  
  457. In addition to sending and displaying characters, a terminal emulator also
  458. attempts to imitate the repertoire of special effects of some particular
  459. real ASCII video display terminal, such as the DEC VT100 series, the IBM
  460. 3101, the Televideo 920, the ADM3A, etc.  This means that the program
  461. responds to screen control sequences sent by the host just as the real
  462. terminal would.  For example, the ASCII sequence "ESC [ 5 ; 7 H" sent to a
  463. DEC VT100 positions the cursor at row 5, column 7; "ESC [ 0 J" clears the
  464. screen, and so a PC programmed to emulate a VT100 would understand the same
  465. sequences and perform the same actions.  When emulating a terminal, the
  466. package should also provide some mapping between the terminal's function
  467. keys and the PC's, so that they transmit the same sequences.  If the VT100
  468. PF1 key sends "ESC O P", then the IBM PC's F1 key might be programmed to
  469. send the same sequence.
  470.  
  471. Today's video display terminals possess a formidable array of features for
  472. tabbing, highlighting, partitioning the screen, erasing and inserting text,
  473. positioning the cursor, drawing figures, changing colors, switching
  474. character sets, activating printers, etc, all controlled by host-transmitted
  475. escape sequences.  A package may emulate such a terminal completely, or it
  476. may emulate a "subset" of its functions.  Some terminals have features that
  477. cannot be emulated by certain PCs.  For example, the DEC VT100 allows
  478. switching between 80- and 132-column modes, but an IBM PC can only display
  479. 80 columns.  To get 132 columns on a PC, a special board may be needed.
  480. Another example is the VT100's "smooth scrolling" feature, which allows a
  481. file to glide slowly along the screen -- the DEC Rainbow can do this, while
  482. the IBM PC cannot.
  483.  
  484. Emulation should be complete enough to allow you to access any desired
  485. software on the host which expects to control the appearance of the
  486. terminal's screen; full-screen text editors like EDT on VAX/VMS or GNU EMACS
  487. on a UNIX system are good tests.  Another is IBM 3270 protocol emulation as
  488. performed by the IBM 7171 or other protocol converter.  If emulation is not
  489. complete, you will see fragmented and jumbled screens, characters or lines
  490. overwriting each other, mysterious gaps and transpositions.
  491.  
  492. Terminal emulation is a very important function for people who engage in a
  493. lot of interactive dialog with a remote system, especially when screen
  494. control is involved.  In this case, it is essential that the communication
  495. package be capable of emulating a terminal that the remote system supports,
  496. such as a DEC VT100 or -200 series with a DEC VAX/VMS system, a Data General
  497. Dasher with DG minis, etc. (see Table 1).  Terminal emulation is less
  498. important for brief or non-interactive encounters, such as occasional
  499. sessions primarily for file transfer.
  500.  
  501. @subheading<KEY REDEFINITION AND CHARACTER TRANSLATION>
  502.  
  503. Since your PC keyboard may have a different layout than the emulated
  504. terminal, you may want to "move" the misplaced keys to their familiar
  505. locations (no, you can't use pliers for this).  For instance, the Escape
  506. (ESC) key (important to much host-resident software) is notoriously mobile,
  507. appearing in many different locations even on PCs from the same maker (IBM
  508. and DEC spring to mind).  If you're used to finding ESC immediately left of
  509. the "1", but your PC has "`" (accent grave) in that position, you could
  510. redefine "`" to transmit ESC (and vice versa).  Similarly for function keys:
  511. the VT100 PF keys are on the right, whereas the IBM PC's F keys are on the
  512. left; some VT100 users may find it more convenient to assign the PF keys to
  513. the PC's numeric pad.
  514.  
  515. A package might also allow you to assign any arbitrary character string to a
  516. key, so that you could transmit commonly typed items like your name or login
  517. sequence with a single keystroke.  Such many-to-one assignments are called
  518. "keyboard macros", and there are limits to the number of characters which
  519. may be represented by a single key.
  520.  
  521. Key redefinition is important if you switch frequently among terminals and
  522. PCs with different keyboard layouts; it means you don't have to retrain your
  523. fingers each time -- a blessing for touch typists.  It is also helpful when
  524. switching the same PC between different hosts.  If you are used to typing
  525. the Backspace key to erase a character, but one host uses ASCII Rubout for
  526. this function while another uses Control-H, you can assign the suitable
  527. character to the Backspace key.
  528.  
  529. Like communication settings, key definitions might take you some time and
  530. experimentation to perfect.  Once you have configured your keyboard 
  531. satisfactorily, you should be able to save your definitions for future use.
  532.  
  533. @subheading<CHARACTER SETS>
  534.  
  535. The ability to handle European and non-Roman character sets (keyboard input
  536. as well as screen output) is important for those who deal in languages other
  537. than English.  It is common practice in Germany and Scandanavia, for
  538. instance, to assign umlaut, slashed, or circled vowels to the ASCII bracket
  539. positions.  PCs and host computers must agree upon these conventions in
  540. order for characters to be displayed as intended, rather than in
  541. Anglo-American ASCII.  Translation of outbound and arriving characters is
  542. therefore an important function of the communication package.  To be totally
  543. general, the package should not be restricted to 7-bit ASCII, but should
  544. allow for 8-bit international character sets, in line with ISO
  545. Recommendations 2022, 6937, et al.
  546.  
  547. @subheading<TEXT SCREEN MEMORY>
  548.  
  549. A special advantage of emulating a terminal on a PC is that the PC may
  550. surpass the capabilities of the terminal.  The PC's memory may be used to
  551. hold hundreds of lines that have scrolled off the top for later recall.
  552. Current or previous screens may be dumped to a disk file or printer at the
  553. touch of a button.
  554.  
  555. Screen print, dump, and rollback fall into the convenience category, and yet
  556. once you've become used to them, you wonder how you ever lived (or at least,
  557. worked) without them.  How many times has some important message scrolled
  558. off your screen before you could read it?  How many times have you typed
  559. hundreds of lines of text into a computer that crashes before you could save
  560. your work?
  561.  
  562. @subheading<GRAPHICS>
  563.  
  564. If your PC has a color monitor, your communication program should be able to
  565. set the fore- and background text screen colors.  A well-chosen color scheme
  566. can reduce "operator fatigue" or, conversely, can jolt you awake during the
  567. less exciting hours of your day.
  568.  
  569. In order to access graphics-oriented applications on your mainframe or mini
  570. such as SAS Graph, SPSS Graphics, Plot 10, TELL-A-GRAF, or various CAD
  571. packages (not to mention certain dialup shopping services), the
  572. communication package must emulate a graphics terminal or standard known to
  573. the application, such as Tektronix 4010, 4014 or other model, DEC ReGIS,
  574. HPGL, GKS, GDDM, NAPLPS, etc.  Graphics terminal emulation is only found in
  575. a few communication packages, usually as an extra-cost item, and for certain
  576. PCs (like IBM) a special monitor and graphics board are also required.
  577.  
  578. In recent years, graphics tend to be done directly on the PC by such
  579. packages as Lotus, Macpaint, etc.  It is normally not possible to connect
  580. one PC to another in order to access the remote PC's graphics applications,
  581. though certain highly specialized packages do allow this.  You cannot expect
  582. to run Crosstalk from PC A to PC B, and expect Lotus on PC B to put a color
  583. pie chart on PC A's screen.  More commonly, the graphics package exists on
  584. both PCs and their data files are moved from one computer to another using a
  585. file transfer protocol built into the communication package.
  586.  
  587. @subheading<FILE TRANSFER>
  588.  
  589. "...transfers your data over phone lines at the speed of light!"  was a
  590. claim that once appeared in an advertisement for a communication package.
  591. While it's true that electricity travels through wires at near light speed,
  592. it is not (yet) true that one electron is equivalent to one bit of data.  In
  593. fact, at the most common speed used for dialup data communication, 1200 bits
  594. per second, a single bit is pretty big -- about 150 miles long!  A character
  595. (generally represented in transmission by 10 bits) is 1500 miles long; two
  596. characters, like "OK", would span the American continent.
  597.  
  598. Spurious advertising claims notwithstanding, transmission speed is a
  599. technological issue, but data transfer is a software issue:  How to make
  600. effective use of the transmission medium?  How to smooth over the
  601. differences between computers?
  602.  
  603. There are also several specific areas to watch out for.  Can binary files be
  604. transferred?  Can text file formats be converted to useful form between
  605. unlike systems?  Can a group of files be sent in a single operation?  Can
  606. filename collisions be avoided?  Can a file transfer be cleanly interrupted?
  607.  
  608. @subheading<ASCII VS ERROR-CHECKED PROTOCOLS>
  609.  
  610. Communication packages offer two basic types of data transfer: "raw" and
  611. error-checked.  The most common "raw" method is usually billed as "ASCII
  612. protocol".  This means that the data is sent as-is, as ASCII characters,
  613. from one computer's communication port to the other.  The advantage is
  614. simplicity.  No special software need be resident on the remote computer,
  615. beyond its text editor, or a "type" or "copy" command.  The disadvantages,
  616. however, explain why error-checked protocols have evolved, and are worth
  617. noting.  The data sent using the ASCII protocol will be corrupted if there
  618. is noise on the communication line.  Data will be lost if the receiving
  619. computer can't keep up with the sender.  Binary (non-textual) files
  620. generally cannot be transferred this way since many computers will ignore
  621. the "parity bit", or act upon control characters rather than accept them as
  622. data: Control-C, Control-S, and Control-Z are frequent culprits.  And
  623. finally, this method works for only one file at a time.
  624.  
  625. A refinement of ASCII protocol incorporates XON/XOFF or some other flow
  626. control method, to reduce the chances of data loss.  In this case, both
  627. computers must support the same flow control method, but corruption of the
  628. data (including the flow control signals themselves) remains a problem, as
  629. does file delimitation and the restriction on binary files.
  630.  
  631. If you want reliable, correct, and complete transmission of files between
  632. computers, then you can't trust the job to ASCII or XON/XOFF "protocol".
  633. You'll need a communications package that includes a true error-correcting
  634. file transfer protocol.  Error-checked data transfer requires cooperating
  635. programs on each end of the connection to exchange messages, called packets,
  636. according to agreed upon formats and rules, similar to how we behave on the
  637. telephone: I dial, your phone rings, you pick up and say hello, I identify
  638. myself, we take turns talking and if I didn't understand what you said then
  639. I ask you to repeat (and vice versa), then we say goodbye, and then we hang
  640. up.  And (an important point) we conduct the conversation in the same
  641. language.  A file transfer protocol operates similarly: the two processes
  642. "connect" with each other, identify the files that are being transferred,
  643. request retransmission of lost or damaged packets, identify the end of the
  644. file, and then disengage from each other.
  645.  
  646. By the way, the fact that many newer modems provide error correction does
  647. not eliminate the need for file transfer software.  An error-free data
  648. stream from modem to modem does not guarantee correct data from computer to
  649. computer.  Issues of end-to-end flow control and error correction, file
  650. delimitation, and format conversion must still be addressed within the
  651. computers themselves.
  652.  
  653. @subheading<XMODEM AND KERMIT>
  654.  
  655. Two well known error-checking file transfer protocols are Xmodem and Kermit.
  656. Many commercial packages include one or both of these protocols (sometimes
  657. alongside their own private, proprietary protocols), but there are also
  658. hundreds of public domain or freely sharable Kermit or Xmodem programs.  In
  659. fact, the major advantage of Xmodem and Kermit is that they are ubiquitous.
  660. The protocol specifications are open and public, and large bodies of Kermit
  661. and Xmodem software are available.  The cost to a large organization for
  662. these programs is minimal, compared with the per-CPU licensing fees required
  663. for commercial packages.  Furthermore, chances are greater that a Kermit or
  664. Xmodem program will exist for any given computer.
  665.  
  666. In the case of Kermit programs, source code is included, which encourages
  667. their adaptation to a wide range of systems.  Non-commercial Kermits can be
  668. had for more than 250 different machines and operating systems, ranging in
  669. size from the smallest micro to the largest supercomputer, and Kermit is
  670. included (at no extra charge) in about 100 different commercial software
  671. packages.  And, according to recent announcements from Telebit and AST,
  672. Kermit protocol is even beginning to find its way into silicon.  Xmodem is
  673. also available for a wide variety of computers, but it was designed
  674. primarily for micro-to-micro links.  It is most widely known by its
  675. commercial implementations, as a fixture in programs like Crosstalk.
  676.  
  677. Kermit, Xmodem, and other error-checking protocols are not equivalent.
  678. Kermit won't talk to Xmodem, and vice-versa.  Each must be evaluated
  679. according to several criteria: Is there a version of the protocol available
  680. for all the systems that must communicate?  Can the protocol accommodate all
  681. the communications parameters required for the systems, and for the
  682. communication medium?  Is the performance acceptable?  Is the software
  683. affordable?
  684.  
  685. Xmodem is more properly called the Christensen protocol after its designer,
  686. Ward Christensen, who originally intended it only for communication between
  687. CP/M micros.  Ward put his original 1977 MODEM program into the public
  688. domain, and it was modified by others over the years, and some protocol
  689. features were added, resulting in protocol variants with names like MODEM2,
  690. MODEM7, XMODEM, YMODEM, ZMODEM, etc.
  691.  
  692. The Kermit file transfer protocol was originally developed in 1981 at the
  693. Columbia University Center for Computing Activities for CP/M, MS-DOS, the
  694. DECSYSTEM-20, and IBM mainframes with VM/CMS; that is, for use in the
  695. micro-to-mainframe environment.  It was shared freely with other
  696. institutions, with sources and documentation included.  Everyone was, and
  697. is, permitted and encouraged to copy and share, to make improvements, and to
  698. contribute new versions.
  699.  
  700. Kermit and Xmodem both transfer files between computers in blocks of data,
  701. or packets.  Both protocols require a program running on each computer to
  702. compose, send, read, decipher, and act upon the packets.  Each packet is
  703. error-checked through the use of calculated checksums, and retransmission is
  704. requested when packets have incorrect checksums.  Deadlocks are broken by
  705. timeouts and retransmission.  Missing or duplicate packets are caught using
  706. packet sequence numbers.  Both protocols are half-duplex stop-and-wait: the
  707. next packet is not sent until the current packet is acknowledged.  Kermit
  708. and Xmodem packets are illustrated in Figure 3.
  709.  
  710. @begin(example)
  711. ______________________________________________________________________________
  712.  
  713. Xmodem:
  714. +-------+-------+-------+------------------+-------+
  715. | SOH   | BLOCK |-BLOCK | DATA (128 bytes) | CHECK |
  716. +-------+-------+-------+------------------+-------+
  717.  
  718. All fields are 8-bit binary:
  719.  
  720. SOH     is ASCII Control-A (SOH, Start of Header).
  721. BLOCK   is the 8-bit binary "block" (packet) number, 1-127 (recycles).
  722. -BLOCK  is 255 minus the block number (1's complement of block number).
  723. DATA    is exactly 128 bytes of unencoded 8-bit data (a CP/M disk block).
  724. CHECK   is an 8-bit binary checksum.
  725.  
  726. Kermit:
  727. +-------+-------+-------+-------+----------+-------+
  728. | START | LEN   | SEQ   | TYPE  | DATA.... | CHECK | <cr>
  729. +-------+-------+-------+-------+----------+-------+
  730.  
  731. Each Kermit packet field except DATA is a single character.  Each field
  732. except START is composed only of printable ASCII characters.  The packet is
  733. normally terminated by a carriage return.
  734.  
  735. START is usually Control-A (SOH), but can be redefined.
  736. LEN   is the packet length, 0-94, encoded as a printable ASCII character.
  737. SEQ   is the packet sequence number, 0-63 (recycles), printable.
  738. TYPE  is the packet type, S F D Z B Y N, etc.
  739. DATA  is a file name, file data, etc, depending on TYPE, printable ASCII.
  740. CHECK is an 8-bit checksum, folded into 6 bits as a printable character.
  741.  
  742.                      Figure 3: Xmodem and Kermit Packets
  743.  
  744. ______________________________________________________________________________
  745. @end(example)
  746.  
  747. The differences between Xmodem and Kermit are worth noting.  First, Xmodem
  748. uses 8-bit binary bytes in its packet fields, and therefore requires an
  749. 8-bit transparent communication link.  It cannot function, even for text
  750. files, when parity is in use.  Similarly, when any device in the
  751. communication path is sensitive to control characters such as Control-Z or
  752. Control-S (which occur in the Xmodem packet control fields), Xmodem packets
  753. are subject to interference.  For this reason, Xmodem cannot operate in
  754. conjunction with XON/XOFF or other in-band flow control.  Kermit, on the
  755. other hand, encodes its packets as lines of text, and therefore does not
  756. have these restrictions.
  757.  
  758. Second, Xmodem packets are sent only in one direction.  The responses are
  759. bare unchecked control characters such as Control-F for acknowledgement,
  760. Control-U for negative acknowledgement, or Control-X for cancel.  Corruption
  761. of Xmodem responses into other valid responses is possible, and can cause a
  762. file transfer to terminate prematurely.  Kermit uses fully error-checked
  763. packets in both directions, and is therefore more robust in the face of
  764. transmission errors.
  765.  
  766. Third, Xmodem uses fixed-length packets.  There is no length field.  If a
  767. file's length is not an exact multiple of 128 bytes, then extra bytes will
  768. be transmitted.  Furthermore, if a computer, multiplexer, or other device
  769. cannot handle bursts of 132 characters, Xmodem packets will not get through.
  770. Kermit packets include a length field.  Packets can be adjusted to
  771. accommodate small buffers, and a short packet can be sent at the end, so
  772. there is no confusion about the exact end of file.
  773.  
  774. Fourth, Xmodem includes no mechanism for transmitting the file's name, and
  775. therefore has no way of sending multiple files in a single session.  Kermit
  776. does this routinely.
  777.  
  778. Fifth, Xmodem makes no distinction between text and binary files.  But since
  779. the conventions for representing text files on different systems can vary,
  780. the results of an Xmodem text-file transfer between unlike systems can be
  781. surprising.  Kermit specifies a common intermediate representation for text
  782. files during transmission, so that incoming text files can always be stored
  783. in a useful form.  However, this places the burden on the user to select
  784. text or binary transfer mode.
  785.  
  786. Finally, both the Xmodem and Kermit protocols have seen a number of
  787. extensions over the years.  Xmodem has no formal or consistent way to
  788. negotiate the presence or absence of given features, whereas feature
  789. negotiation is built into the basic Kermit protocol.  A pair of variant
  790. Xmodem programs will not necessarily be able to communicate, whereas any
  791. pair of Kermit programs will automatically fall back to the greatest common
  792. set of options.  Xmodem and Kermit protocol extensions include:
  793.  
  794. @begin(itemize)
  795.  
  796. Multiple files.  MODEM7 and YMODEM can transfer multiple files in a single
  797. batch, Xmodem can't.  Multiple file transmission is built into the basic
  798. Kermit protocol.
  799.  
  800. The ability to pass 8-bit data through a 7-bit channel.  Xmodem can't.
  801. Kermit supplies this as a negotiated feature (commonly available).
  802.  
  803. Alternate checksums.  Xmodem-CRC uses a 16-bit cyclic redundancy check for
  804. greater reliability, and tries to adapt itself to 8-bit-checksum-only Xmodem
  805. programs automatically.  Kermit supplies an optional 12-bit checksum, and
  806. a 16-bit CRC, negotiated with automatic fallback to the single character
  807. checksum.
  808.  
  809. File transfer interruption.  Both Xmodem and Kermit allow file transfer
  810. to be interrupted cleanly.  Kermit also includes the ability to cancel the
  811. current file in a group and proceed to the next one.
  812.  
  813. Compression.  Kermit programs may negotiate compression of repeated bytes.
  814. Xmodem lacks a compression option.
  815.  
  816. Long packets.  YMODEM allows 1K-byte fixed-length packets for greater
  817. efficiency.  Kermit extensions permit variable-length packets up to about
  818. 9K, negotiated with automatic fallback to regular-length packets.
  819.  
  820. Sliding windows.  Kermit programs may negotiate simultaneous and
  821. continuous transmission of packets and their acknowledgments on
  822. full-duplex links, with a window of up to 31 unacknowledged packets, and
  823. selective retransmission of lost or damaged packets.  (This option is not
  824. yet widespread among Kermit implementations). Sliding windows are not
  825. possible in Xmodem because its responses carry no sequence number (an
  826. Xmodem variant called WMODEM simulates sliding windows, but only works if
  827. there are no errors).
  828.  
  829. File attributes.  YMODEM transmits a file's name, size, and creation date.
  830. Xmodem does not.  Kermit always transmits the name, and the ability to
  831. communicate a wide range of other file attributes may be negotiated (but,
  832. like sliding windows, this is not yet a widely implemented Kermit feature).
  833.  
  834. Checkpoint/restart.  ZMODEM includes the ability to restart a file transfer
  835. after the connection was broken.  Neither Xmodem nor Kermit have this
  836. ability.
  837. @end(itemize)
  838.  
  839. Kermit also differs from Xmodem by including a "file server" mode of
  840. operation, in which the remote Kermit program receives all its instructions
  841. from the PC Kermit in packet form.  This simplifies operation considerably.
  842. Kermit servers can transfer files, as well as perform a variety of file
  843. management functions -- deletion, directory listing, changing directories,
  844. etc.
  845.  
  846. Implementations of Kermit can be had for most PCs, minis and mainframes.
  847. Xmodem implementations are found mostly on PCs, rarely on minis and
  848. mainframes.  Basic Xmodem is somewhat more efficient than basic Kermit,
  849. because the packets are slightly longer and there is less encoding overhead.
  850. The situation is reversed when Kermit can do compression, long packets, or
  851. sliding windows.
  852.  
  853. Most commercial RS-232 communication packages claim to include Xmodem,
  854. Kermit, or both.  In general, the commercial Xmodem implementations include
  855. none of the MODEM7, YMODEM, or ZMODEM options, but often do include support
  856. for CRCs.  Thus, they can transfer only a single file at a time, and only
  857. through transparent 8-bit communication channels.  The commercial Kermit
  858. implementations vary from the bare-bones to the very advanced, but all can
  859. transfer text files through 7-bit links, and can handle multiple files in a
  860. single operation.  It is not always apparent from vendor literature exactly
  861. which options are supported, so if any of these issues are important to you,
  862. you should call the vendor and ask about them.  After all, one of the
  863. advantages of commercial offerings over public domain software is telephone
  864. support.
  865.  
  866. @subheading<OTHER ASYNCHRONOUS PROTOCOLS>
  867.  
  868. Xmodem and Kermit are not the only two asynchronous communication protocols
  869. in the marketplace.  Others include UUCP, Blast, MNP, X.PC, Poly-Xfr, DX,
  870. Compuserve, FAST, and DART.  Most of these protocols are proprietary, which
  871. means that the protocol specification itself is secret, or licensed, and
  872. they are found primarily in commercial packages.  They often include
  873. advanced capabilities like checkpoint/restart, bidirectional file transfer,
  874. and sliding windows.
  875.  
  876. But all proprietary protocols have the same drawbacks: you must buy
  877. commercial packages in order to use them, and if there is not a package
  878. available for a certain computer that you need it for, you're out of luck.
  879. Of the commercial packages, Blast probably comes closest to Kermit in
  880. covering a wide variety of systems, and exceeds Kermit in many design and
  881. performance areas.  The drawback is the cost: $250 for the PC version, $450
  882. for a PDP-11 version, and more for larger minis or mainframes.  And since
  883. the Blast protocol is inherently full duplex, a special "Blast box" front
  884. end must be purchased for half duplex systems.  Kermit, on the other hand,
  885. may be used with either full or half duplex systems, and the cost is
  886. minimal.
  887.  
  888. @subheading<SUMMARY>
  889.  
  890. Here is a checkoff list that you can use to evaluate and compare
  891. communication packages.  Before purchase, you should decide which features
  892. are important to you, and then determine which packages have these features.
  893. Check the vendor literature, or call the vendor directly.
  894. @newpage()
  895. @begin(example)
  896. ______________________________________________________________________________
  897.  
  898. CONFIGURATION
  899.  
  900. Make and model of your computer:______________________________________________
  901.  
  902. Operating system and version:_________________________________________________
  903.  
  904. Memory:___________(K)  Floppy drives:_________  Hard Disk Capacity: _______(M)
  905.  
  906. Communications interfaces:____________________________________________________
  907.  
  908. Modem make and model:____________________________ [  ] Internal  [  ] External
  909.  
  910. Name of communications package:_______________________________________________
  911.  
  912. Communications package vendor:_________________________ Phone:________________
  913.  
  914. Package memory size:___________(K)  Package disk occupancy:________________(K)
  915.  
  916. Before proceeding, be sure that the communication package is compatible with
  917. your computer's configuration!
  918. @hinge()
  919. ______________________________________________________________________________
  920.  
  921. COST
  922.  
  923. (a) What is the unit cost of the package?                       $_____________
  924.  
  925. (b) Is source code included, so that you can make changes
  926.     and fix bugs?  Is there is an additional charge for
  927.     source code?  Cost of source code, if you want it:          $_____________
  928.  
  929. (c) Is copying allowed?  If so, go directly to (f).
  930.  
  931. (d) How many PCs will you need it for?  _____________
  932.     Is there a volume discount?  If so, enter discounted cost:  $_____________
  933.  
  934. (e) If a site license is available, what does it cost?          $_____________
  935.  
  936. (f) Enter best total price for PC versions . . . . . . . . . .  $_____________
  937.  
  938. (g) Do you also need minicomputer or mainframe versions?
  939.     If so, enter total cost for mini or mainframe versions . .  $_____________
  940.     (Figured as above)
  941.  
  942. (h) Total cost to your organization  . . . . . . . . . . . . .  $_____________
  943. @hinge()
  944. ______________________________________________________________________________
  945.  
  946.  
  947. DOCUMENTATION, TRAINING, AND SUPPORT
  948.  
  949. Is the manual...
  950. [  ] thick and unmanagable?
  951. [  ] thin and cryptic?
  952. [  ] just right?
  953.  
  954. How important is the manual?
  955. [  ] Must be consulted frequently
  956. [  ] Occasional lookups required
  957.  
  958. [  ] Does the manual have a good index and table of contents?
  959.  
  960. [  ] Is training available?
  961.  
  962. [  ] Is training necessary?
  963.  
  964. [  ] Is telephone support available and included in the package price?
  965. @hinge()
  966.  
  967. ______________________________________________________________________________
  968.  
  969.  
  970. WHAT IS YOUR PRIMARY USE FOR THE PACKAGE?
  971.  
  972. [  ] Long interactive remote sessions.  Communication parameter settings,
  973.      terminal emulation, and key definition are the most important features. 
  974.  
  975. [  ] Infrequent remote sessions mainly for the purpose of data transfer.
  976.      Concentrate on the user interface, script language, and file transfer
  977.      protocol.
  978. @hinge()
  979.  
  980. ______________________________________________________________________________
  981.  
  982.  
  983. COMMUNICATIONS PACKAGE FEATURES
  984.  
  985. Each of the features listed below should be evaluated according to your needs.
  986. The lack of a certain feature is not critical if you know you will never need
  987. that feature.  Items may be rated as follows:
  988.  
  989.       X - I don't care about this feature.
  990.       Y - I need this feature, and the package has it.
  991.       N - I need this feature, but the package doesn't have it.
  992.  
  993. A single "N" may be sufficient to disqualify the package, depending on how
  994. important the feature is to you.  If you don't know whether the package
  995. provides a feature you need, call the vendor and ask.
  996. @hinge()
  997.  
  998. ______________________________________________________________________________
  999.  
  1000.  
  1001. USER INTERFACE
  1002.  
  1003. [  ] Is help available at all times?
  1004.  
  1005. [  ] Does the user interface favor the novice user?  (Menus at all times)
  1006.  
  1007. [  ] Does it favor the expert user?  (No menus)
  1008.  
  1009. [  ] Is the package equally convenient for both novice and expert?  (Menu on
  1010.      demand) 
  1011.  
  1012. [  ] Can canned procedures be set up for unskilled users?  (Scripts, command
  1013.      files) 
  1014.  
  1015. [  ] Can local operating system functions be accessed without leaving the
  1016.      package? 
  1017.  
  1018. [  ] Can the package be used by the disabled?
  1019. @hinge()
  1020.  
  1021. ______________________________________________________________________________
  1022.  
  1023.  
  1024. COMMUNICATION PARAMETER SETTINGS (always important)
  1025.  
  1026. Bits/Second:  0,110,300,1200,2400,4800,9600,19200,etc.  Maximum:__________
  1027.  
  1028. Duplex
  1029. [  ] Full (e.g. for DEC minis)
  1030. [  ] Half (e.g. for IBM mainframes)
  1031.  
  1032. Echo
  1033. [  ] Remote (e.g. for DEC minis)
  1034. [  ] Local  (e.g. for IBM mainframe linemode connections)
  1035.  
  1036. Data Bits
  1037. [  ] 5 (Baudot)
  1038. [  ] 7 (ASCII)
  1039. [  ] 8 (national characters)
  1040.  
  1041. Stop Bits
  1042. [  ] 1   (for most connections)
  1043. [  ] 1.5 (rarely used)
  1044. [  ] 2   (used only for 110 bits per second or less)
  1045.  
  1046. Parity Selection
  1047. [  ] None (all bits used for data)
  1048. [  ] Even (required by some mainframes, front ends, public networks, etc)
  1049. [  ] Odd  (ditto)
  1050. [  ] Mark (ditto)
  1051. [  ] Space (rarely used, but sometimes handy)
  1052.  
  1053. Character Set Selection 
  1054. [  ] 5-bit Baudot (used in Telecommunication Devices for the Deaf)
  1055. [  ] 7-bit US ASCII (most common in English-speaking countries)
  1056. [  ] 7-bit "national ASCII" (Norwegian, German, etc)
  1057. [  ] 8-bit "extended ASCII" (e.g. use of IBM PC 8-bit character set)
  1058. [  ] Support for international standard non-Roman character sets
  1059. [  ] User-definable or downloadable character sets
  1060.  
  1061. Flow Control Selection
  1062. [  ] X-on/X-off (e.g. with DEC computers)
  1063. [  ] ENQ/ACK (e.g. with Hewlett-Packard computers)
  1064. [  ] RTS/CTS (for half duplex modems)
  1065. [  ] Half duplex line turnaround handshake (e.g. with IBM mainframes)
  1066. [  ] Other:________________________________
  1067. [  ] None (can flow control be turned off?)
  1068.  
  1069. Debugging
  1070. [  ] Special display of all received and transmitted characters
  1071. [  ] Logging of all received and transmitted characters
  1072.  
  1073. [  ] Can you collect communication settings into recallable configurations?
  1074. @hinge()
  1075.  
  1076. ______________________________________________________________________________
  1077.  
  1078.  
  1079. CONNECTION ESTABLISHMENT
  1080.  
  1081. Support for RS-232-C asynchronous modem signals (RTS, CTS, DSR, CD, DTR, RI):
  1082.  
  1083. [  ] Does the package monitor Carrier Detect (CD) and Data Set Ready (DSR)
  1084.        from the modem?
  1085. [  ] Does the package assert Data Terminal Ready (DTR)?
  1086. [  ] Can the package drop DTR to hang up the phone?
  1087. [  ] Does the package respond to Ring Indicator (RI) so that it can be called
  1088.        from outside?
  1089. [  ] If you have a half duplex modem, does the package support RTS/CTS?
  1090.  
  1091. [  ] Does your PC have an internal modem?
  1092. [  ] Does the package support this internal modem?
  1093.  
  1094. Dialer Control:
  1095. [  ] Does your modem provide automatic dialing?
  1096. [  ] What dialing language is used by your modem? ________________________
  1097. [  ] Does the package support automatic dialing?
  1098. [  ] Does the package support your modem's dialing language?
  1099. [  ] Does the package provide a phone directory?
  1100.  
  1101. [  ] Can the package operate over direct connections, without modems?  That 
  1102.      is, can it be told to ignore CD and DSR?  (If not, you will need the
  1103.      "fakeout" (minimal) null-modem cable from Figure 1).
  1104.  
  1105. Script language for automatic login, unattended operation:
  1106. [  ] Access to all necessary package commands from script language.
  1107. [  ] Conditional execution/termination of script commands.
  1108. [  ] Fancy script programming features (variables, labels, goto's, etc.)
  1109. [  ] Unattended operation (e.g. late at night, when phone rates are low).
  1110.  
  1111. [  ] Can the program be suspended and resumed without dropping the connection?
  1112. @hinge()
  1113.  
  1114. ______________________________________________________________________________
  1115.  
  1116.  
  1117. TERMINAL EMULATION:
  1118.  
  1119. What terminal(s) does the package emulate? ___________________________________
  1120.  
  1121. [  ] Is the maximum speed for full duplex terminal emulation sufficient for
  1122.      your needs?
  1123.  
  1124. [  ] Does the package emulate a terminal that is supported by the computers
  1125.      you wish to communicate with?
  1126.  
  1127. [  ] Is the terminal emulated fully enough for use with all desired software
  1128.      applications on these computers?
  1129.  
  1130. [  ] Is any special hardware (like a 132-column board) required in the PC?
  1131.  
  1132. [  ] Does the package support fore- and background colors?  
  1133.      (Do you need them?)
  1134.  
  1135. [  ] If a graphics terminal is emulated, does your application support it? 
  1136.  
  1137. [  ] Screen rollback (view screens that have scrolled away)
  1138.  
  1139. [  ] Screen dump (save current or previous screens in PC files)
  1140.  
  1141. [  ] Printer control (copy displayed characters to printer;print whole screen)
  1142.  
  1143. [  ] Print or save text screens in alternate character sets
  1144.  
  1145. [  ] Print or save graphics screens
  1146.  
  1147. [  ] Function keys
  1148.  
  1149. [  ] Key redefinition
  1150.  
  1151. [  ] Keystroke macros
  1152.  
  1153. [  ] Translation of displayed characters, alternate character sets
  1154. @hinge()
  1155.  
  1156. ______________________________________________________________________________
  1157.  
  1158.  
  1159. FILE TRANSFER PROTOCOLS
  1160.  
  1161. [  ] ASCII (this is not an error-correcting protocol)
  1162.  
  1163. [  ] XON/XOFF (this is not an error-correcting protocol)
  1164.  
  1165. [  ] Xmodem
  1166.  
  1167. [  ] Kermit
  1168.  
  1169. [  ] Proprietary (Blast, MNP, etc):____________________________________
  1170.  
  1171. [  ] Other: ___________________________________________________________
  1172.  
  1173. [  ] Do the systems you're communicating with support the same protocol(s)?
  1174.  
  1175. [  ] Does the package transfer both text and binary files?
  1176.  
  1177. [  ] Do text files arrive on the target computer in useful form?
  1178. @hinge()
  1179.  
  1180.  
  1181. XMODEM OPTIONAL FEATURES
  1182.  
  1183. [  ] Modem7-style transfer of multiple files
  1184.  
  1185. [  ] Xmodem-CRC for more reliable error checking
  1186.  
  1187. [  ] Ymodem 1K packets for increased efficiency (half duplex)
  1188.  
  1189. [  ] Ymodem filename transmission
  1190.  
  1191. [  ] Checkpoint/restart (Zmodem)
  1192.  
  1193. [  ] Wmodem continous transmission (full duplex)
  1194.  
  1195. [  ] Do the computers you wish to communicate with support the same
  1196.      Xmodem options?
  1197. @hinge()
  1198.  
  1199.  
  1200. KERMIT OPTIONAL FEATURES
  1201.  
  1202. [  ] 8-bit data through 7-bit links (e.g. links with parity)
  1203.  
  1204. [  ] Repeated character compression for improved efficiency
  1205.  
  1206. [  ] 12-bit checksum, 16-bit CRC, for more reliable error checking
  1207.  
  1208. [  ] File transfer interruption
  1209.  
  1210. [  ] Long packets (up to 9K) for improved efficiency (half duplex)
  1211.  
  1212. [  ] Sliding windows for improved efficiency (full duplex)
  1213.  
  1214. [  ] Transmission of file attributes
  1215.  
  1216. [  ] Server operation
  1217.  
  1218. [  ] Remote host commands and file management
  1219.  
  1220. ______________________________________________________________________________
  1221.  
  1222. @end(example)
  1223.