

















           The ZMODEM Inter Application File Transfer Protocol

                              Chuck Forsberg

                           Omen Technology Inc


          A overview of this document is available as ZMODEM.OV
                             (in ZMDMOV.ARC)



                       Omen Technology Incorporated
                      The High Reliability Software

                   17505-V Northwest Sauvie Island Road
                          Portland Oregon 97231
                        VOICE: 503-621-3406 :VOICE
          Modem: 503-621-3746 Speed 1200,2400,19200(Telebit PEP)
                     Compuserve:70007,2304  GEnie:CAF
                    UUCP: ...!tektronix!reed!omen!caf







       ABSTRACT


       The ZMODEM file transfer protocol provides reliable file and command
       transfers with complete end-to-end data integrity between application
       programs. ZMODEM's 32-bit CRC catches errors that continue to sneak
       into even the most advanced networks.

       ZMODEM rapidly transfers files, particularly with buffered (error
       correcting) modems, timesharing systems, satellite relays, and wide
       area packet switched networks.

       ZMODEM greatly simplifies file transfers compared to XMODEM. In
       addition to a friendly user interface, ZMODEM provides Personal
       Computer and other users an efficient, accurate, and robust file
       transfer method.

       ZMODEM provides advanced file management features including
       AutoDownload (Automatic file Download initiated without user
       intervention), Crash Recovery, selective file transfers, and security
       verified command downloading.

       ZMODEM protocol features allow implementation on a wide variety of
       systems operating in a wide variety of environments. A choice of
       buffering and windowing modes allows ZMODEM to operate on systems that
       cannot support other streaming protocols. Finely tuned control character
       escaping allows operation with real world networks without Kermit's high
       overhead.

       Although ZMODEM software is more complex than unreliable XMODEM
       routines, actual C source code to production programs allows developers
       to upgrade their applications with efficient, reliable ZMODEM file
       transfers with a minimum of effort.

       ZMODEM is carefully designed to provide these benefits using a minimum
       of new software technology. ZMODEM can be implemented on all but the
       most brain-damaged computers. 

       ZMODEM was developed for the public domain under a Telenet contract.
       The ZMODEM protocol descriptions and the Unix RZ/SZ program source code
       are public domain. No licensing, trademark, or copyright restrictions
       apply to the use of the protocol, the Unix RZ/SZ source code and the
       ZMODEM name.







                              C O N T E N T S 


       1. INTENDED AUDIENCE....................................... 1

       2. WHY DEVELOP ZMODEM?..................................... 1

       3. ZMODEM Protocol Design Criteria......................... 4
           3.1    Ease of Use..................................... 4
           3.2    Throughput...................................... 4
           3.3    Integrity and Robustness........................ 5
           3.4    Ease of Implementation.......................... 5

       4. EVOLUTION OF ZMODEM..................................... 6

       5. ROSETTA STONE........................................... 9

       6. ZMODEM REQUIREMENTS..................................... 10
           6.1    File Contents................................... 10

       7. ZMODEM BASICS........................................... 11
           7.1    Packetization................................... 11
           7.2    Link Escape Encoding............................ 12
           7.3    Header.......................................... 13
           7.4    Binary Data Subpackets.......................... 16
           7.5    ASCII Encoded Data Subpacket.................... 16

       8. PROTOCOL TRANSACTION OVERVIEW........................... 16
           8.1    Session Startup................................. 16
           8.2    File Transmission............................... 18
           8.3    Session Cleanup................................. 20
           8.4    Session Abort Sequence.......................... 20

       9. STREAMING TECHNIQUES / ERROR RECOVERY................... 20
           9.1    Full Streaming with Sampling.................... 21
           9.2    Full Streaming with Reverse Interrupt........... 23
           9.3    Full Streaming with Sliding Window.............. 23
           9.4    Full Streaming over Error Free Channels......... 23
           9.5    Segmented Streaming............................. 24

      10. ATTENTION SEQUENCE...................................... 24







      11. FRAME TYPES............................................. 25
           11.1   ZRQINIT......................................... 25
           11.2   ZRINIT.......................................... 25
           11.3   ZSINIT.......................................... 25
           11.4   ZACK............................................ 26
           11.5   ZFILE........................................... 26
           11.6   ZSKIP........................................... 28
           11.7   ZNAK............................................ 28
           11.8   ZABORT.......................................... 28
           11.9   ZFIN............................................ 28
           11.10  ZRPOS........................................... 28
           11.11  ZDATA........................................... 29
           11.12  ZEOF............................................ 29
           11.13  ZFERR........................................... 29
           11.14  ZCRC............................................ 29
           11.15  ZCHALLENGE...................................... 29
           11.16  ZCOMPL.......................................... 29
           11.17  ZCAN............................................ 29
           11.18  ZFREECNT........................................ 29
           11.19  ZCOMMAND........................................ 29

      12. SESSION TRANSACTION EXAMPLES............................ 30
           12.1   A simple file transfer.......................... 30
           12.2   Challenge and Command Download.................. 31

      13. ZFILE FRAME FILE INFORMATION............................ 31

      14. PERFORMANCE RESULTS..................................... 33
           14.1   Compatibility................................... 33
           14.2   Throughput...................................... 33
           14.3   Error Recovery.................................. 34

      15. PACKET SWITCHED NETWORK CONSIDERATIONS.................. 35
      16. PERFORMANCE COMPARISON TABLES........................... 36
      17. FUTURE EXTENSIONS....................................... 41
      18. REVISIONS............................................... 42
      19. MORE INFORMATION........................................ 43
           19.1   TeleGodzilla Bulletin Board..................... 43
           19.2   Unix UUCP Access................................ 43

      20. ZMODEM PROGRAMS......................................... 44
           20.1   Adding ZMODEM to DOS Programs................... 45

      21. YMODEM PROGRAMS......................................... 46
      22. ACKNOWLEDGMENTS......................................... 46
      23. RELATED FILES........................................... 47



      LIST OF FIGURES

      Figure 1. Order of Bytes in Header.......................... 13
      Figure 2. 16 Bit CRC Binary Header.......................... 14
      Figure 3. 32 Bit CRC Binary Header.......................... 14
      Figure 4. HEX Header........................................ 15
      Figure 5. Transmission Time Comparison...................... 37


      LIST OF TABLES

      TABLE 1. Network and Flow Control Compatibility............. 36
      TABLE 2. Protocol Overhead Information...................... 37
      TABLE 3. Local Timesharing Computer Download Performance.... 37
      TABLE 4. File Transfer Speeds............................... 38
      TABLE 5. Protocol Checklist................................. 40

      ZMODEM Protocol
      Documentation
      Page 1


      1. INTENDED AUDIENCE

      This document is intended for telecommunications managers, systems
      programmers, and others who choose and implement asynchronous file
      transfer protocols over dial-up networks and related environments.


      2. WHY DEVELOP ZMODEM?

      Since its development half a decade ago, the Ward Christensen modem
      protocol has enabled a wide variety of computer systems to interchange
      data. There is hardly a communications program that doesn't at least
      claim to support this protocol, now called XMODEM.

      Advances in computing, modems and networking have spread the XMODEM
      protocol far beyond the micro to micro environment for which it
      was designed. These application have exposed some weaknesses:

      ==> The awkward user interface is suitable for computer hobbyists.
          Multiple commands must be keyboarded to transfer each file.
 
      ==> Since commands must be given to both programs, simple menu
          selections are not possible.

      ==> The short block length causes throughput to suffer when used with
          timesharing systems, packet switched networks, satellite circuits,
          and buffered (error correcting) modems.

      ==> The 8-bit checksum and unprotected supervison allow undetected
          errors and disrupted file transfers.

      ==> Only one file can be sent per command. The file name has to be
          given twice, first to the sending program and then again to the
          receiving program.

      ==> The transmitted file accumulates as many as 127 bytes of garbage.

      ==> The modification date and other file attributes are lost.

      ==> XMODEM requires complete 8-bit transparency, all 256 codes. XMODEM
          will not operate over some networks that use ASCII flow control or
          escape codes. Setting network transparency disables important
          control functions for the duration of the call.

      ZMODEM Protocol
      Documentation
      Page 2


      A number of other protocols have been developed over the years, but none
      have proven satisfactory.

      ==> Lack of public-domain documentation and example programs have kept
          proprietary protocols such as RELAY, BLAST, and others tightly bound
          to the fortunes of their suppliers. These protocols have not
          benefited from public scrutiny of their design features.

      ==> Link-level protocols such as X.25, X.PC, and MNP do not manage
          application-to-application file transfers.

      ==> Link-level protocols do not eliminate end-to-end errors. Interfaces
          between error-free networks are not necessarily error-free.
          Sometimes, error-free networks aren't.

      ==> The KERMIT protocol was developed to allow file transfers in
          environments hostile to XMODEM. The performance compromises
          necessary to accommodate traditional mainframe environments limit
          Kermit's efficiency. Even with completely transparent channels,
          Kermit control character quoting limits the efficiency of binary
          file transfers to about 75 per cent. [1]

      A number of submodes are used in various Kermit programs, including
      different methods of transferring binary files. Two Kermit programs will
      mysteriously fail to operate with each other if the user has not
      correctly specified these submodes.

      Kermit Sliding Windows ("SuperKermit") improves throughput over networks
      at the cost of increased complexity. SuperKermit requires full duplex
      communications and the ability to check for the presence of characters
      in the input queue, precluding its implementation on some operating
      systems.

      SuperKermit state transitions are encoded in a special language "wart"
      which requires a C compiler.

      SuperKermit sends an ACK packet for each data packet of 96 bytes (fewer
      if control characters are present). This reduces throughput on 
      high-speed modems, from 1350 to 177 characters per second in one test.



      [1]. Some Kermit programs support run-length encoding.

      ZMODEM Protocol
      Documentation
      Page 3


      A number of extensions to the XMODEM protocol have been made to improve
      performance and (in some cases) the user interface. They provide useful
      improvements in some applications but not in others. XMODEM's
      unprotected control messages compromise their reliability. Complex
      proprietary techniques such as Cybernetic Data Recovery (TM) [1] improve
      reliability, but are not universally available. Some of the XMODEM
      mutant protocols have significant design flaws of their own.

      ==> XMODEM-K uses 1024 byte blocks to reduce the overhead from
          transmission delays by 87 per cent compared to XMODEM, but network
          delays still degrade performance. Some networks cannot transmit 1024
          byte packets without flow control, which is difficult to apply
          without impairing the perfect transparency required by XMODEM.
          XMODEM-K adds garbage to received files.

      ==> YMODEM sends the file name, file length, and creation date at the
          beginning of each file, and allows optional 1024 byte blocks for
          improved throughput. The handling of files that are not a multiple
          of 1024 or 128 bytes is awkward, especially if the file length is
          not known in advance, or changes during transmission. The large
          number of non-conforming and substandard programs claiming to
          support YMODEM further complicates its use.

      ==> YMODEM-G provides efficient batch file transfers, preserving exact
          file length and file modification date. YMODEM-G is a modification
          to YMODEM wherein ACKs for data blocks are not used. YMODEM-G is
          essentially insensitive to network delays. Because it does not
          support error recovery, YMODEM-G must be used hard wired or with a
          reliable link level protocol. Successful application at high speed
          requires careful attention to transparent flow control. When
          YMODEM-G detects a CRC error, data transfers are aborted. YMODEM-G
          is easy to implement because it closely resembles standard YMODEM.

      ==> WXMODEM, SEALINK, and MEGALINK have applied a subset of ZMODEM's
          techniques to "Classic XMODEM" to improve upon their suppliers'
          previous offerings. They provide good performance under ideal
          conditions.

      Another XMODEM "extension" is protocol cheating, such as Omen
      Technology's OVERTHRUSTER(TM) and OVERTHRUSTER II(TM). These improve
      XMODEM throughput under some conditions by compromising error recovery.

      The ZMODEM Protocol corrects the weaknesses described above while
      maintaining as much of XMODEM/CRC's simplicity and prior art as
      possible.

      [1]. Unique to DSZ, ZCOMM, Professional-YAM and PowerCom.

      ZMODEM Protocol
      Documentation
      Page 4


      3. ZMODEM PROTOCOL DESIGN CRITERIA

      The design of a file transfer protocol is an engineering compromise
      between conflicting requirements:


      3.1 EASE OF USE

      ==> ZMODEM allows either program to initiate file transfers, passing
          commands and/or modifiers to the other program.

      ==> File names need be entered only once.

      ==> Menu selections are supported.

      ==> Wild Card names may be used with batch transfers.

      ==> Minimum keystrokes required to initiate transfers.

      ==> ZRQINIT frame sent by sending program can trigger automatic
          downloads.

      ==> ZMODEM can step down to YMODEM if the other end does not support
          ZMODEM. [1]


      3.2 THROUGHPUT

      All file transfer protocols make tradeoffs between throughput,
      reliability, universality, and complexity according to the technology
      and knowledge base available to their designers.

      In the design of ZMODEM, three applications deserve special attention.

      ==> Network applications with significant delays (relative to character
          transmission time) and low error rate.

      ==> Timesharing and buffered modem applications with significant delays
          and throughput that is quickly degraded by reverse channel traffic.
          ZMODEM's economy of reverse channel bandwidth allows modems that
          dynamically partition bandwidth between the two directions to
          operate at optimal speeds. Special ZMODEM features allow simple,
          efficient implementation on a wide variety of timesharing hosts.


      [1]. Provided the transmission medium accommodates X/YMODEM.

      ZMODEM Protocol
      Documentation
      Page 5


      ==> Direct modem to modem communications with high error rate.

      Unlike Sliding Windows Kermit, ZMODEM is not optimized for optimum
      throughput when error rate and delays are both high. This tradeoff
      markedly reduces code complexity and memory requirements. ZMODEM
      generally provides faster error recovery than network compatible XMODEM
      implementations.

      In the absence of network delays, rapid error recovery is possible, much
      faster than MEGAlink and network compatible versions of YMODEM and
      XMODEM.
 
      File transfers begin immediately regardless of which program is started
      first, without the 10-second delay associated with XMODEM.


      3.3 INTEGRITY AND ROBUSTNESS

      Once a ZMODEM session is begun, all transactions are protected with 16-
      or 32-bit CRC. [1] Complex proprietary techniques such as Cybernetic
      Data Recovery (TM) [2] are not needed for reliable transfers.

      An optional 32-bit CRC used as the frame check sequence in ADCCP (ANSI
      X3.66, also known as FIPS PUB 71 and FED-STD-1003, the U.S. versions of
      CCITT's X.25) is used when available. The 32-bit CRC reduces undetected
      errors by at least five orders of magnitude when properly applied (-1
      preset, inversion).

      A security challenge mechanism guards against "Trojan Horse" messages
      written to mimic legitimate command or file downloads.

      3.4 EASE OF IMPLEMENTATION

      ZMODEM accommodates a wide variety of systems:

      ==> Microcomputers that cannot overlap disk and serial i/o.

      ==> Microcomputers that cannot overlap serial send and receive.

      ==> Computers and/or networks requiring XON/XOFF flow control.


      [1]. Except for the CAN-CAN-CAN-CAN-CAN abort sequence which requires
           five successive CAN characters.

      [2]. Unique to Professional-YAM and PowerCom.


      ZMODEM Protocol
      Documentation
      Page 6


      ==> Computers that cannot check the serial input queue for the presence
          of data without having to wait for the data to arrive.


      Although ZMODEM provides "hooks" for multiple "threads", ZMODEM is not
      intended to replace link-level protocols such as X.25.

      ZMODEM accommodates network and timesharing system delays by
      continuously transmitting data unless the receiver interrupts the sender
      to request retransmission of garbled data. ZMODEM in effect uses the
      entire file as a window. [1] Using the entire file as a window simplifies
      buffer management, avoiding the window-overrun failure modes that
      affect MEGAlink, SuperKermit, and others.

      ZMODEM provides a general purpose application to application file
      transfer protocol which may be used directly or with with reliable link
      level protocols such as X.25, MNP, Fastlink, etc. When used with X.25,
      MNP, Fastlink, etc., ZMODEM detects and corrects errors in the
      interfaces between error-controlled media and the remainder of the
      communications link.

      ZMODEM was developed for the public domain under a Telenet contract. The
      ZMODEM protocol descriptions and the Unix RZ/SZ program source code are
      public domain. No licensing, trademark, or copyright restrictions apply
      to the use of the protocol, the Unix RZ/SZ source code or the ZMODEM
      name.


      4. EVOLUTION OF ZMODEM

      In early 1986, Telenet funded a project to develop an improved public-
      domain application-to-application file transfer protocol. This protocol
      would alleviate the throughput problems network customers were
      experiencing with XMODEM and Kermit file transfers.

      In the beginning, we thought a few modifications to XMODEM would allow
      high performance over packet-switched networks while preserving XMODEM's
      simplicity.

      The initial concept would add a block number to the ACK and NAK
      characters used by XMODEM. The resultant protocol would allow the sender
      to send more than one block before waiting for a response.



      [1]. Streaming strategies are discussed in coming chapters.

      ZMODEM Protocol
      Documentation
      Page 7


      But how to add the block number to XMODEM's ACK and NAK? WXMODEM,
      SEAlink, MEGAlink and some other protocols add binary byte(s) to
      indicate the block number.

      Pure binary was unsuitable for ZMODEM because binary code combinations
      won't pass bidirectionally through some modems, networks and operating
      systems. Other operating systems may not be able to recognize something
      coming back [1] unless a break signal or a system dependent code or
      sequence is present. By the time all this and other problems with the
      simple ACK/NAK sequences mentioned above were corrected, XMODEM's simple
      ACK and NACK characters had evolved into a real packet. The Frog was
      riveting.

      Managing the window [2] was another problem. Experience gained in
      debugging The Source's SuperKermit protocol indicated a window size of
      about 1000 characters was needed at 1200 bps. High speed modems require
      a window of 20000 or more characters for full throughput. Much of the
      SuperKermit's inefficiency, complexity and debugging time centered
      around its ring buffering and window management. There had to be a
      better way to get the job done.

      A sore point with XMODEM and its progeny is error recovery. More to the
      point, how can the receiver determine whether the sender has responded,
      or is ready to respond, to a retransmission request? XMODEM attacks
      the problem by throwing away characters until a certain period of
      silence. Too short a time allows a spurious pause in output (network or
      timesharing congestion) to masquerade as error recovery. Too long a
      timeout devastates throughput, and allows a noisy line to lock up the
      protocol. SuperKermit solves the problem with a distinct start-of-packet
      character (SOH). WXMODEM and ZMODEM use unique character sequences to
      delineate the start of frames. SEAlink and MEGAlink do not address this
      problem.

      A further error-recovery problem arises in streaming protocols. How does
      the receiver know when (or if) the sender has recognized its error
      signal? Is the next packet the correct response to the error signal? Is
      it something left over "in the queue"? Or is this new subpacket one of
      many that will have to be discarded because the sender did not receive
      the error signal? How long should this continue before sending another
      error signal? How can the protocol prevent this from degenerating into
      an argument about mixed signals?


      [1]. Without stopping for a response.

      [2]. The WINDOW is the data in transit between sender and receiver.

      ZMODEM Protocol
      Documentation
      Page 8


      SuperKermit uses selective retransmission, so it can accept any good
      packet it receives. Each time the SuperKermit receiver gets a data
      packet, it must decide which outstanding packet (if any) it "wants most"
      to receive, and asks for that one. In practice, complex software "hacks"
      are needed to attain acceptable robustness. [1]

      For ZMODEM, we decided to forgo the complexity of SuperKermit's packet
      assembly scheme and its associated buffer management logic and memory
      requirements.

      Another sore point with XMODEM and WXMODEM is the garbage added to
      files. This was acceptable with old CP/M files which had no exact
      length, but not with modern systems such as DOS and Unix. YMODEM uses
      file length information transmitted in the header block to trim the
      output file, but this causes data loss when transferring files that grow
      during a transfer. In some cases, the file length may be unknown, as
      when data is obtained from a process. Variable-length data subpackets
      solve both of these problems.

      Since some characters had to be escaped anyway, there wasn't any point
      wasting bytes to fill out a fixed packet length or to specify a variable
      packet length. In ZMODEM, the length of data subpackets is denoted by
      ending each subpacket with an escape sequence similar to BISYNC and
      HDLC.

      The end result is a ZMODEM header containing a "frame type", four bytes
      of supervisory information, and its own CRC. Data frames consist of a
      header followed by one or more data subpackets. In the absence of
      transmission errors, an entire file can be sent in one data frame.

      Since the sending system may be sensitive to numerous control characters
      or strip parity in the reverse data path, all of the headers sent by the
      receiver are sent in hex. A common lower-level routine receives all
      headers, allowing the main program logic to deal with headers and data
      subpackets as objects.

      With equivalent binary (efficient) and hex (application friendly)
      frames, the sending program can send an "invitation to receive" sequence
      to activate the receiver without crashing the remote application with
      unexpected control characters.


      [1]. For example, when SuperKermit encounters certain errors, the WNDESR
           function is called to determine the next block to request. A burst
           of errors generates several wasteful requests to retransmit the
           same block.

      ZMODEM Protocol
      Documentation
      Page 9


      Going "back to scratch" in the protocol design presents an opportunity
      to steal good ideas from many sources and to add a few new ones.

      From Kermit and UUCP comes the concept of an initial dialog to exchange
      system parameters.

      ZMODEM generalizes Compuserve B Protocol's host-controlled transfers to
      single-command AutoDownload and command downloading. A Security
      Challenge discourages password hackers and Trojan Horse authors from
      abusing ZMODEM's power.

      We were also keen to the pain and $uffering of legions of
      telecommunicators whose file transfers have been ruined by
      communications and timesharing faults. ZMODEM's file transfer recovery
      and advanced file management are dedicated to these kindred comrades.

      After ZMODEM had been operational a short time, Earl Hall pointed out
      the obvious: ZMODEM's user-friendly AutoDownload was almost useless if
      the user must assign transfer options to each of the sending and
      receiving programs. Now, transfer options may be specified to/by the
      sending program, which passes them to the receiving program in the ZFILE
      header.


      5. ROSETTA STONE

      Here are some definitions which reflect current vernacular in the
      computer media. The attempt here is identify the file transfer protocol
      rather than specific programs.

      FRAME
        A ZMODEM frame consists of a header and zero or more data subpackets.

      XMODEM
        Refers to the original 1977 file transfer etiquette introduced by Ward
        Christensen's MODEM2 program. It's also called the MODEM or MODEM2
        protocol. Some who are unaware of MODEM7's unusual batch file mode
        call it MODEM7. Other aliases include "CP/M Users's Group" and
        "TERM II FTP 3". This protocol is supported by most communications
        programs because it is easy to implement.

      XMODEM/CRC 
        Replaces XMODEM's one-byte checksum with a two-byte Cyclical Redundancy
        Check (CRC-16), improving error detection.

      XMODEM-1K 
        Refers to XMODEM-CRC with optional 1024-byte blocks.

      ZMODEM Protocol
      Documentation
      Page 10


      YMODEM
        Refers to the XMODEM/CRC protocol with batch transmission and
        optional 1024 byte blocks as described in YMODEM.DOC. [1]


      6. ZMODEM REQUIREMENTS

      ZMODEM requires an 8-bit transfer medium. [2] ZMODEM escapes network
      control characters to allow operation with packet switched networks. In
      general, ZMODEM operates over any path that supports XMODEM, and over
      many that don't.

      To support full streaming, [3] the transmission path should either
      assert flow control or pass full speed transmission without loss of
      data. Otherwise the ZMODEM sender must manage the window size.


      6.1 FILE CONTENTS

      6.1.1 BINARY FILES

      ZMODEM per systems, text files must meet minimum requirements if they are
      to be readable on a wide variety of systems and environments.

      Text lines consist of printing ASCII characters, spaces, tabs, and
      backspaces.


      6.1.2.1 ASCII END-OF-LINE

      The ASCII code definition allows text lines terminated by a CR/LF
      (013,012) sequence, or by a NL (012) character. Lines logically
      terminated by a lone CR (013) are not ASCII text.

      [1]. Available on TeleGodzilla as part of YZMODEM.ZOO.

      [2]. The ZMODEM design allows encoded packets for less transparent media.

      [3]. With XOFF and XON, or out-of-band flow control such as X.25 or CTS.

      ZMODEM Protocol
      Documentation
      Page 11


      A CR (013) without a linefeed implies overprinting, and is not
      acceptable as a logical line separator. Overprinted lines should print
      all important characters in the last pass to allow CRT displays to
      display meaningful text. Overstruck characters may be generated by
      backspacing or by overprinting the line with CR (013) not followed by
      LF.

      Overstruck characters generated with backspaces should be sent with the
      most important character last to accommodate CRT displays that
   : :cannot overstrike. The sending program may use the ZCNL bit to force the
      receiving program to convert the received end-of-line to its local
      end-of-line convention. [1]


      7. ZMODEM BASICS

      7.1 PACKETIZATION

      ZMODEM frames differ somewhat from XMODEM blocks. XMODEM blocks are not
      used for the following reasons:

      ==> Block numbers are limited to 256

      ==> No provision for variable length blocks

      ==> Line hits corrupt protocol signals, causing failed file transfers.
          In particular, modem errors sometimes generate false block numbers,
          false EOTs and false ACKs. False ACKs are the most troublesome as
          they cause the sender to lose synchronization with the receiver.

      State-of-the-art programs such as Professional-YAM and ZCOMM overcome
      some of these weaknesses with clever proprietary code, but a stronger
      protocol is desired.

      ==> It is difficult to determine the beginning and ends of XMODEM blocks
          when line hits cause a loss of synchronization. This precludes rapid
          error recovery.


      [1]. Files that have been translated in such a way as to modify their
           length cannot be updated with the ZCRECOV Conversion Option.

      ZMODEM Protocol
      Documentation
      Page 12


      7.2 LINK ESCAPE ENCODING

      ZMODEM achieves data transparency by extending the 8-bit character set
      (256 codes) with escape sequences based on the ZMODEM data link escape
      character ZDLE. [1]

      Link escape coding permits variable-length data subpackets without the
      overhead of a separate byte count. It allows the beginning of frames to
      be detected without special timing techniques, facilitating rapid error
      recovery.

      Link escape coding does add some overhead. The worst case, a file
      consisting entirely of escaped characters, would incur a 50% overhead.

      The ZDLE character is special. ZDLE represents a control sequence of
      some sort. If a ZDLE character appears in binary data, it is prefixed
      with ZDLE, then sent as ZDLEE.

      The value for ZDLE is octal 030 (ASCII CAN). This particular value was
      chosen to allow a string of 5 consecutive CAN characters to abort a
      ZMODEM session, compatible with YMODEM session abort.

      Since CAN is not used in normal terminal operations, interactive
      applications and communications programs can monitor the data flow for
      ZDLE. The following characters can be scanned to detect the ZRQINIT
      header, the invitation to automatically download commands or files.

      Receipt of five successive CAN characters will abort a ZMODEM session.
      Eight CAN characters are sent.

      The receiving program decodes any sequence of ZDLE followed by a byte
      with bit 6 set and bit 5 reset (upper case letter, either parity) to the
      equivalent control character by inverting bit 6. This allows the
      transmitter to escape any control character that cannot be sent by the
      communications medium. In addition, the receiver recognizes escapes for
      0177 and 0377 should these characters need to be escaped.

      ZMODEM software escapes ZDLE, 020, 021, 023, 0220, 0221, and 0223. If
      preceded by 0100 or 0300 (@), 015 and 0215 are also escaped to protect
      the Telenet command escape CR-@-CR. The receiver ignores 021, 023, 0221,
      and 0223 characters in the data stream.


      [1]. This and other constants are defined in the ZMODEM.H include file.
           Please note that constants with a leading '0' are octal constants
           in C.

      ZMODEM Protocol
      Documentation
      Page 13


      The ZMODEM routines in ZM.C accept an option to escape all control
      characters, to allow operation with less transparent networks. This
      option can be given to either the sending or receiving program.


      7.3 HEADER

      All ZMODEM frames begin with a header which may be sent in binary or HEX
      form. ZMODEM uses a single routine to recognize binary and hex
      headers. Either form of the header contains the same raw information:

      ==> A type byte [1] [2]

      ==> Four bytes of data indicating flags and/or numeric quantities
          depending on the frame type


      Figure 1.
      Order of Bytes in Header

      TYPE:frame type
      F0: Flags least significant byte
      P0: file Position least significant
      P3: file Position most significant

      TYPE  F3 F2 F1 F0
      -------------------
      TYPE  P0 P1 P2 P3


      7.3.1 16-BIT CRC BINARY HEADER

      A binary header is sent by the sending program to the receiving program.
      ZDLE encoding accommodates XON/XOFF flow control.

      A binary header begins with the sequence ZPAD, ZDLE, ZBIN.

      The frame type byte is ZDLE-encoded.

      The four position/flags bytes are ZDLE-encoded.


      [1]. The frame types are cardinal numbers beginning with zero to
           minimize state transition table memory requirements.

      [2]. Future extensions to ZMODEM may use the high-order bits of the type
           byte to indicate thread selection.

      ZMODEM Protocol
      Documentation
      Page 14


      A two-byte CRC of the frame type and position/flag bytes is
      ZDLE-encoded.

      Zero or more binary data subpackets with 16-bit CRC will follow
      depending on the frame type.

      The function ZSBHDR transmits a binary header. The function ZGETHDR
      receives a binary or hex header.


      Figure 2.
      16-BIT CRC BINARY HEADER

      * ZDLE A TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2


      7.3.2 32-BIT CRC BINARY HEADER

      A "32-bit CRC" Binary header is similar to a Binary Header, except the
      ZBIN (A) character is replaced by a ZBIN32 (C) char[cter, [nd four
      characters of CRC are sent. Zero or more binary data subpackets with
      32-bit CRC will follow depending on the frame type.

      The common variable TXFCS32 may be set TRUE for 32-bit CRC if the
      receiver indicates the capability with the CANFC32 bit. The ZGETHDR,
      ZSDATA AND ZRDATA functions automatically adjust to the type of Frame
      Check Sequence being used.


      Figure 3.
      32-BIT CRC BINARY HEADER

      * ZDLE C TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2 CRC-3 CRC-4


      7.3.3 HEX HEADER

      The receiver sends responses in hex headers. The sender also uses hex
      headers when they are not followed by binary data subpackets.

      Hex encoding protects the reverse channel from random control
      characters. The hex header receiving routine ignores parity.

      ZMODEM Protocol
      Documentation
      Page 15


      Use of Kermit-style encoding for control and paritied characters was
      considered and rejected because of increased possibility of interacting
      with some timesharing systems' line-edit functions. Use of HEX headers
      from the receiving program allows control characters to be used to
      interrupt the sender when errors are detected. A HEX header may be used
      in place of a binary header wherever convenient. If a data packet
      follows a HEX header, it is protected with CRC-16.

      A hex header begins with the sequence ZPAD, ZPAD, ZDLE, ZHEX. The
      ZGETHDR routine synchronizes with the ZPAD-ZDLE squnce. The extra ZPAD
      character allows the sending program to detect an asynchronous header
      (indicating an error condition) and then call ZGETHDR to receive the
      header.

      The type byte, the four position/flag bytes, and the 16-bit CRC thereof
      are sent in hex using the character set 01234567890ABCDEF. Upper-case
      hex digits are not allowed; they falsely trigger XMODEM and YMODEM
      programs. Since this form of hex encoding detects many patterns of
      errors, especially missing characters, a hex header with 32-bit CRC has
      not been defined.

      A carriage return and line feed are sent with HEX headers. The receive
      routine expects to see at least one of these characters, two if the
      first is CR. The CR/LF aids debugging from printouts, and helps overcome
      certain operating-system-related problems.

      An XON character is appended to all HEX packets except ZACK and ZFIN.
      The XON releases the sender from spurious XOFF flow control characters
      generated by line noise, a common occurrence. XON is not sent after ZACK
      headers to protect flow control in streaming situations. XON is not sent
      after a ZFIN header to allow clean session cleanup.

      Zero or more data subpackets will follow depending on the frame type.

      The function ZSHHDR sends a hex header.


      Figure 4.
      HEX Header

      * * ZDLE B TYPE F3/P0 F2/P1 F1/P2 F0/P3 CRC-1 CRC-2 CR LF XON

      (TYPE, F3...F0, CRC-1, and CRC-2 are each sent as two hex digits.)



      ZMODEM Protocol
      Documentation
      Page 16


      7.4 BINARY DATA SUBPACKETS

      Binary data subpackets immediately follow the associated binary header
      packet. A binary data packet contains 0 to 1024 bytes of data.
      Recommended length values are 256 bytes below 2400 bps, 512 at 2400 bps,
      and 1024 above 4800 bps or when the data link is known to be relatively
      error-free. [1]

      No padding is used with binary data subpackets. The data bytes are 
      ZDLE-encoded and transmitted. A ZDLE and frame-end are then sent,
      followed by two or four ZDLE encoded CRC bytes. The CRC accumulates the
      data bytes and frame-end.

      The function ZSDATA sends a data subpacket. The function ZRDATA receives
      a data subpacket.


      7.5 ASCII-ENCODED DATA SUBPACKET

      The format of ASCII-Encoded data subpackets is not currently specified.
      These could be used for server commands, or main transfers in 7-bit
      environments.


      8. PROTOCOL TRANSACTION OVERVIEW

      As with the XMODEM recommendation, ZMODEM timing is receiver-driven. The
      transmitter should not time out at all, except to abort the program if
      no headers are received for an extended period of time, say one minute.
      [2]


      8.1 SESSION STARTUP

      To start a ZMODEM file transfer session, the sending program is called
      with the names of the desired file(s) and option(s).



      [1]. Strategies for adjusting the subpacket length for optimal results
           based on real-time error rates are still evolving. Shorter
           subpackets speed error detection but increase protocol overhead
           slightly.

      [2]. Special considerations apply when sending commands.

    ZMODEM Protocol
      Documentation
      Page 17


      The sending program may send the string "RZ/R" to invoke the receiving
      program from a possible command mode. The "RZ" followed by carriage
      return activates a ZMODEM receive program or command if it were not
      already active.

      The sender may then display a message intended for human consumption,
      such as a list of the files requested, etc.

      Then the sender may send a ZRQINIT header. The ZRQINIT header causes a
      previously started receive program to send its ZRINIT header without
      delay.

      In an interactive or conversational mode, the receiving application may
      monitor the data stream for ZDLE. The following characters may be
      scanned for B00 indicating a ZRQINIT header, a command to download a
      command or data.

      The sending program awaits a command from the receiving program to start
      file transfers. If a "C", "G", or NAK is received, an XMODEM or YMODEM
      file transfer is indicated, and file transfer(s) use the YMODEM
      protocol. Note: With ZMODEM and YMODEM, the sending program provides the
      file name, but not with XMODEM.

      In case of garbled data, the sending program can repeat the
      invitation-to-receive a number of times until a session starts.

      When the ZMODEM receive program starts, it immediately sends a ZRINIT
      header to initiate ZMODEM file transfers, or a ZCHALLENGE header to
      verify the sending program. The receive program resends its header at
      response time (default 10 second) intervals for a suitable period of
      time (40 seconds total) before falling back to YMODEM protocol.

      If the receiving program receives a ZRQINIT header, it resends the
      ZRINIT header. If the sending program receives the ZCHALLENGE header, it
      places the data in ZP0...ZP3 in an answering ZACK header.

      If the receiving program receives a ZRINIT header, it is an echo
      indicating that the sending program is not operational.

      Eventually the sending program correctly receives the ZRINIT header.

      The sender may then send an optional ZSINIT frame to define the
      receiving program's ATTN sequence, or to specify complete control
      character escaping. [1]

      [1]. If the receiver specifies the same or higher level of escaping, the
           ZSINIT frame need not be sent unless an ATTN sequence is needed.

      ZMODEM Protocol
      Documentation
      Page 18


      If the ZSINIT header specifies ESCCTL or ESC8, a HEX header is used, and
      the receiver activates the specified ESC modes before reading the
      following data subpacket.

      The receiver sends a ZACK header in response, optionally containing the
      serial number of the receiving program, or zero.


      8.2 FILE TRANSMISSION

      The sender then sends a ZFILE header with ZMODEM Conversion, Management,
      and Transport options [1] followed by a ZCRCW data subpacket containing
      the file name, file length, modification date, and other information
      identical to that used by YMODEM Batch.

      The receiver examines the file name, length, and date information
      provided by the sender in the context of the specified transfer options,
      the current state of its file system(s), and local security
      requirements. The receiving program should insure the pathname and
      options are compatible with its operating environment and local security
      requirements.

      The receiver may respond with a ZSKIP header, which makes the sender
      proceed to the next file (if any) in the batch.

      If the receiver has a file with the same name and length, it may respond
      with a ZCRC header, which requires the sender to perform a 32-bit CRC on
      the file and transmit the complement of the CRC in a ZCRC header. [2]
      The receiver uses this information to determine whether to accept the
      file or skip it. This sequence is triggered by the ZMCRC Management
      Option.

      A ZRPOS header from the receiver initiates transmission of the file data
      starting at the offset in the file specified in the ZRPOS header.
      Normally the receiver specifies the data transfer to begin at offset
      zero in the file.

:  :  [1]. See below, under ZFILE header type.

      [2]. The CRC is initialized to 0xff.

      ZMODEM Protocol
      Documentation
      Page 19


      The receiver may start the transfer further down in the file. This
      allows a file transfer interrupted by a loss of carrier or system crash
      to be completed on the next connection without requiring the entire file
      to be retransmitted. [1] If downloading a file from a timesharing system
      that becomes sluggish, the transfer can be interrupted and resumed later
      with no loss of data.

      The sender sends a ZDATA binary header (with file position) followed by
      one or more data subpackets.

      The receiver compares the file position in the ZDATA header with the
      number of characters successfully received to the file. If they do not
      agree, a ZRPOS error response is generated to force the sender to the
      right position within the file. [2]

      A data subpacket terminated by ZCRCG and CRC does not elicit a response
      unless an error is detected; more data subpacket(s) follow immediately.

      ZCRCQ data subpackets expect a ZACK response with the receiver's file
      offset if no error, otherwise a ZRPOS response with the last good file
      offset. Another data subpacket continues immediately. ZCRCQ subpackets
      are not used if the receiver does not indicate FDX ability with the
      CANFDX bit.

      ZCRCW data subpackets expect a response before the next frame is sent.
      If the receiver does not indicate overlapped I/O capability with the
      CANOVIO bit, or sets a buffer size, the sender uses the ZCRCW to allow
      the receiver to write its buffer before sending more data.

      A zero-length data frame may be used as an idle subpacket to prevent the
      receiver from timing out in case data is not immediately available to
      the sender.

      In the absence of fatal error, the sender eventually encounters 
      end-of-file. If the end-of-file is encountered within a frame, the frame
      is closed with a ZCRCE data subpacket which does not elicit a response
      except in case of error.


      [1]. This does not apply to files that have been translated.
                                                                                
      [2]. If the ZMSPARS option is used, the receiver instead seeks to the
           position given in the ZDATA header.

      ZMODEM Protocol
      Documentation
      Page 20


      The sender sends a ZEOF header with the file ending offset equal to the
      number of characters in the file. The receiver compares this number with
      the number of characters received. If the receiver has received all of
      the file, it closes the file. If the file close was satisfactory, the
      receiver responds with ZRINIT. If the receiver has not received all the
      bytes of the file, the receiver ignores the ZEOF because a new ZDATA is
      coming. If the receiver cannot properly close the file, a ZFERR header
      is sent.

      After all files are processed, any further protocol errors should not
      prevent the sending program from returning with a success status.


      8.3 SESSION CLEANUP

      The sender closes the session with a ZFIN header. The receiver
      acknowledges this with its own ZFIN header.

      When the sender receives the acknowledging header, it sends two
      characters, "OO" (Over and Out) and exits to the operating system or
      application that invoked it. The receiver waits briefly for the "O"
      characters, then exits whether they were received or not.


      8.4 SESSION ABORT SEQUENCE

      If the receiver is receiving data in streaming mode, the ATTN sequence
      is executed to interrupt data transmission before the CANCEL sequence is
      sent. The CANCEL sequence consists of eight CAN characters and ten
      backspace characters. ZMODEM only requires five CANCEL characters, the
      other three are "insurance".

      The trailing backspace characters attempt to erase the effects of the
      CAN characters if they are received by a command interpreter.

      static char canistr[] = 24,24,24,24,24,24,24,24,8,8,8,8,8,8,8,8,8,8,0;


      9. STREAMING TECHNIQUES / ERROR RECOVERY

      It is a fact of life that no single method of streaming is applicable to
      a majority of today's computing and telecommunications environments.
      ZMODEM provides several data streaming methods selected according to the
      limitations of the sending environment, receiving environment, and
      transmission channel(s).

      ZMODEM Protocol
      Documentation
      Page 21


      9.1 FULL STREAMING WITH SAMPLING

      If the receiver can overlap serial I/O with disk I/O, and if the sender
      can sample the reverse channel for the presence of data without having
      to wait, full streaming can be used with no ATTN sequence required. The
      sender begins data transmission with a ZDATA header and continuous ZCRCG
      data subpackets. When the receiver detects an error, it executes the
      ATTN sequence and then sends a ZRPOS header with the correct position
      within the file.

      At the end of each transmitted data subpacket, the sender checks for the
      presence of an error header from the receiver. To do this, the sender
      samples the reverse data stream for the presence of either a ZPAD or CAN
      character. [1] Flow control characters (if present) are acted upon.

      Other characters (indicating line noise) increment a counter which is
      reset whenever the sender waits for a header from the receiver. If the
      counter overflows, the sender sends the next data subpacket as ZCRCW,
      and waits for a response.

      ZPAD indicates some sort of error header from the receiver. A CAN
      suggests the user is attempting to "stop the bubble machine" by
      keyboarding CAN characters. If one of these characters is seen, an empty
      ZCRCE data subpacket is sent. Normally, the receiver will have sent an
      ZRPOS or other error header, which will force the sender to resume
      transmission at a different address, or take other action. In the
      unlikely event the ZPAD or CAN character was spurious, the receiver will
      time out and send a ZRPOS header. [2]

      Then the receiver's response header is read and acted upon. [3]

      A ZRPOS header resets the sender's file offset to the correct position.
      If possible, the sender should purge its output buffers and/or networks
      of all unprocessed output data, to minimize the amount of unwanted data
      the receiver must discard before receiving data starting at the correct
      file offset. The next transmitted data frame should be a ZCRCW frame
      followed by a wait to guarantee complete flushing of the network's
      memory.

      [1]. The call to RDCHK() in SZ.C performs this function.

      [2]. The obvious choice of ZCRCW packet, which would trigger an ZACK
           from the receiver, is not used because multiple in-transit frames
           could result if the channel has a long propagation delay.

      [3]. The call to GETINSYNC() in SZ.C performs this function.

      ZMODEM Protocol
      Documentation
      Page 22


      If the receiver gets a ZACK header with an address that disagrees with
      the sender address, it is ignored, and the sender waits for another
      header. A ZFIN, ZABORT, or timeout terminates the session; a ZSKIP
      terminates the processing of this file.

      The reverse channel is then sampled for the presence of another header
      from the receiver. [1] If one is detected, the GETINSYNC() function is
      again called to read another error header. Otherwise, transmission
      resumes at the (possibly reset) file offset with a ZDATA header followed
      by data subpackets.


      9.1.1 WINDOW MANAGEMENT

      When sending data through a network, some nodes of the network store
      data while it is transferred to the receiver. Seven thousand bytes and
      more of transient storage have been observed. Such a large amount of
      storage causes the transmitter to "get ahead" of the receiver. This can
      be fatal with MEGAlink and other protocols that depend on timely
      notification of errors from the receiver. This condition is not fatal
      with ZMODEM, but it does slow error recovery.

      To manage the window size, the sending program uses ZCRCQ data
      subpackets to trigger ZACK headers from the receiver. The returning ZACK
      headers inform the sender of the receiver's progress. When the window
      size (current transmitter file offset - last reported receiver file
      offset) exceeds a specified value, the sender waits for a ZACK [2]
      packet with a receiver file offset that reduces the window size.

      Unix SZ versions beginning with May 9 1987 control the window size with
      the "-Zw N" option, where N is the maximum window size. Pro-YAM, ZCOMM
      and DSZ versions beginning with May 9 1987 control the window size with
      "ZMODEM PWN". This is compatible with previous versions of these
      programs. [3]



      [1]. If sampling is possible.

      [2]. ZRPOS and other error packets are handled normally.

      [3]. When used with modems or networks that simultaneously assert flow
           control with XON and XOFF characters and pass XON characters that
           violate flow control, the receiving program should have a revision
           date of May 9 or later.

      ZMODEM Protocol
      Documentation
      Page 23


      9.2 FULL STREAMING WITH REVERSE INTERRUPT

      The above method cannot be used if the reverse data stream cannot be
      sampled without entering an I/O wait. An alternate method is to instruct
      the receiver to interrupt the sending program when an error is detected.

      The receiver can interrupt the sender with a control character, break
      signal, or combination thereof, as specified in the ATTN sequence. After
      executing the ATTN sequence, the receiver sends a hex ZRPOS header to
      force the sender to resend the lost data.

      When the sending program responds to this interrupt, it reads a HEX
      header (normally ZRPOS) from the receiver and takes the action described
      in the previous section. The Unix SZ.C program uses a SETJMP/LONGJMP
      call to catch the interrupt generated by the ATTN sequence. Catching the
      interrupt activates the GETINSYNC() function to read the receiver's
      error header and take appropriate action.

      When compiled for standard SYSTEM III/V Unix, SZ.C uses an ATTN sequence
      of Ctrl-C followed by a 1 second pause to interrupt the sender, then
      give the sender (Unix) time to prepare for the receiver's error header.


      9.3 FULL STREAMING WITH SLIDING WINDOW

      If none of the above methods is applicable, hope is not yet lost. If the
      sender can buffer responses from the receiver, the sender can use ZCRCQ
      data subpackets to get ACKs from the receiver without interrupting the
      transmission of data. After a sufficient number of ZCRCQ data subpackets
      have been sent, the sender can read one of the headers that should have
      arrived in its receive-interrupt buffer.

      A problem with this method is the possibility of wasting an excessive
      amount of time responding to the receiver's error header. It may be
      possible to program the receiver's ATTN sequence to flush the sender's
      interrupt buffer before sending the ZRPOS header.


      9.4 FULL STREAMING OVER ERROR-FREE CHANNELS

      File transfer protocols predicated on the existence of an error-free 
      end-to-end communications channel have been proposed from time to time.
      Such channels have proven to be more readily available in theory than in
      actuality. The frequency of undetected errors increases when modem
      scramblers have more bits than the error-detecting CRC.

      ZMODEM Protocol
      Documentation
      Page 24


      A ZMODEM sender assuming an error-free channel with end-to-end flow
      control can send the entire file in one frame without any checking of
      the reverse stream. If this channel is completely transparent, only ZDLE
      need be escaped. The resulting protocol overhead for average long files
      is less than one percent. [1]


      9.5 SEGMENTED STREAMING

      If the receiver cannot overlap serial and disk I/O, it uses the ZRINIT
      frame to specify a buffer length which the sender will not overflow.
      The sending program sends a ZCRCW data subpacketandwaits for a ZACK
      header before sending the next segment of the file.

      If the sending program supports reverse data stream sampling or
      interrupt, error recovery will be faster (on average) than a protocol
      (such as YMODEM) that sends large blocks.

      A sufficiently large receiving buffer allows throughput to closely
      approach that of full streaming. For example, 16KB segmented streaming
      adds about 3 percent to full streaming ZMODEM file transfer times when
      the round trip delay is five seconds.


      10. ATTENTION SEQUENCE

      The receiving program sends the ATTN sequence whenever it detects an
      error and needs to interrupt the sending program.

      The default ATTN string value is empty (no ATTN sequence). The receiving
      program resets ATTN to the empty default before each transfer session.

      The sender specifies the ATTN sequence in its optional ZSINIT frame. The
      ATTN string is terminated with a null.


      Two meta-characters perform special functions:

      ==> /335 (octal) Send a break signal
      ==> /336 (octal) Pause one second


      [1]. One in 256 for escaping ZDLE, about two (four if 32-bit CRC is
           used) in 1024 for data subpacket CRC's.

      ZMODEM Protocol
      Documentation
      Page 25


      11. FRAME TYPES

      The numeric values for the values shown in boldface are given in
      ZMODEM.H. Unused bits and unused bytes in the header (ZP0...ZP3) are set
      to zero. 


      11.1 ZRQINIT

      Sent by the sending program, to trigger the receiving program to send
      its ZRINIT header. This avoids the aggravating startup delay associated
      with XMODEM and Kermit transfers. The sending program may repeat the
      receive invitation (including ZRQINIT) if a response is not obtained at
      first.

      ZF0 contains ZCOMMAND if the program is attempting to send a command,
      zero otherwise.


      11.2 ZRINIT

      Sent by the receiving program. ZF0 and ZF1 contain the bitwise-OR of the
      receiver capability flags:
                                                                              
      #define CANCRY      8   /* Receiver can decrypt */
      #define CANFDX     01   /* Receiver can send and receive true FDX */
      #define CANOVIO    02   /* Receiver can receive data during disk I/O */
      #define CANBRK     04   /* Receiver can send a break signal */
      #define CANCRY    010   /* Receiver can decrypt */
      #define CANLZW    020   /* Receiver can uncompress */
      #define CANFC32   040   /* Receiver can use 32-bit Frame Check */
      #define ESCCTL   0100   /* Receiver expects CTL chars to be escaped */
      #define ESC8     0200   /* Receiver expects 8th bit to be escaped */

      ZP0 and ZP1 contain the size of the receiver's buffer in bytes, or zero
      if nonstop I/O is allowed.


      11.3 ZSINIT

      The Sender sends flags followed by a binary data subpacket terminated
      with ZCRCW.

      /* Bit Masks for ZSINIT flags byte ZF0 */
       #define TESCCTL 0100 /* Transmitter expects CTL chars to be escaped*/
       #define TESC8 0200 /* Transmitter expects 8th bit to be escaped

      ZMODEM Protocol
      Documentation
      Page 26


      The data subpacket contains the nu]l-termited ATTN sequence, maximum
      length 32 bytes including the terminating null.


      11.4 ZACK

      Acknowledgment to a ZSINIT frame, ZCHALLENGE header, ZCRCQ or ZCRCW data
      subpacket. ZP0 to ZP3 contain file offset. The response to ZCHALLENGE
      contains the same 32-bit number received in the ZCHALLENGE header.


      11.5 ZFILE

      This frame denotes the beginning of a file transmission attempt. ZF0,
      ZF1, and ZF2 may contain options. A value of zero in each of these bytes
      implies no special treatment. Options specified to the receiver override
      options specified to the sender with the exception of ZCBIN which
      overrides any other Conversion Option given to the sender or receiver.


      11.5.1 ZF00 CONVERSION OPTION

      If the receiver does not recognize the Conversion Option, an
      application-dependent default conversion may apply.

      ZCBIN 
       "Binary" transfer - inhibit conversion unconditionally.

      ZCNL
       Convert received end-of-line to local end-of-line convention. The
       supported end-of-line conventions are CR/LF (most ASCII based operating
       systems except Unix and Macintosh), and NL (Unix). Either of these two
       end-of-line conventions meet the permissible ASCII definitions for
       Carriage Return and Line Feed/New Line. Neither the ASCII code nor
       ZMODEM ZCNL encompass lines separated only by carriage returns. Other
       processing appropriate to ASCII text files and the local operating
 :   : system may also be applied by the receiver. [1]

      ZCRECOV 
       Recover/Resume interrupted file transfer. ZCREVOV is also useful for
       updating a remote copy of a file that grows without resending of old
       data. If the destination file exists and is no longer than the source,
       append to the destination file and start transfer at the offset
       corresponding to the receiver's end-of-file. This option does not apply
       if the source file is shorter. Files that have been converted (e.g.,
       ZCNL) or subject to a single ended Transport Option cannot have their
       transfers recovered.
      [1]. Filtering RUBOUT, NULL, Ctrl-Z, etc.

      ZMODEM Protocol
      Documentation
      Page 27


      11.5.2 ZF1 MANAGEMENT OPTION

      If the receiver does not recognize the Management Option, the file
      should be transferred normally.

      The ZMSKNOLOC bit instructs the receiver to bypass the current file if
      the receiver does not have a file with the same name.

      Five bits (defined by ZMMASK) define the following set of mutually
      exclusive management options.

      ZMNEWL
        Transfer file if destination file absent. Otherwise, transfer file
        overwriting destination if the source file is newer or longer.

      ZMCRC
        Compare the source and destination files. Transfer if file lengths or
        file polynomials differ.

      ZMAPND
        Append source file contents to the end of the existing destination
        file (if any).

      ZMCLOB
        Replace existing destination file (if any).

      ZMDIFF
        Transfer file if destination file absent. Otherwise, transfer file
        overwriting destination if files have different lengths or dates.

      ZMPROT
        Protect destination file by transferring file only if the destination
        file is absent.

      ZMNEW
        Transfer file if destination file absent. Otherwise, transfer file
        overwriting destination if the source file is newer.


      11.5.3 ZF2 TRANSPORT OPTION

      If the receiver does not implement the particular transport option, the
      file is copied without conversion for later processing.

      ZTLZW
        Lempel-Zev-Welch Compression. Transmitted data will be identical to
        that produced by COMPRESS 4.0 operating on a computer with VAX byte
        ordering, using 12-bit encoding.

      ZMODEM Protocol
      Documentation
      Page 28


      ZTCRYPT
        Encryption. An initial null-terminated string identifies the key.
        Details to be determined.

      ZTRLE
        Run-Length encoding. Details to be determined. A ZCRCW data subpacket
        follows with file name, file length, modification date, and other
        information described in a later chapter.


      11.5.4 ZF3 EXTENDED OPTIONS

      The Extended Options are bit-encoded.

      ZTSPARS
        Special processing for sparse files, or sender-managed selective
        retransmission. Each file segment is transmitted as a separate frame,
        where the frames are not necessarily contiguous. The sender should end
        each segment with a ZCRCW data subpacket and process the expected ZACK
        to insure no data is lost. ZTSPARS cannot be used with ZCNL.

      11.6 ZSKIP
        Sent by the receiver in response to ZFILE, makes the sender skip to
        the next file.

      11.7 ZNAK
        Indicates last header was garbled. (See also ZRPOS).

      11.8 ZABORT
        Sent by receiver to terminate batch file transfers when requested by
        the user. Sender responds with a ZFIN sequence. [1]

      11.9 ZFIN
        Sent by sending program to terminate a ZMODEM session. Receiver
        responds with its own ZFIN.

      11.10 ZRPOS
        Sent by receiver to force file transfer to resume at file offset given
        in ZP0...ZP3.


       [1]. Or ZCOMPL in case of server mode.

      ZMODEM Protocol
      Documentation
      Page 29


      11.11 ZDATA
        ZP0...ZP3 contain file offset. One or more data subpackets follow.

      11.12 ZEOF
        Sender reports end-of-file. ZP0...ZP3 contain the ending file offset.

      11.13 ZFERR
        Error in reading or writing file, protocol equivalent to ZABORT.

      11.14 ZCRC
        Request (receiver) and response (sender) for file polynomial.
        ZP0...ZP3 contain file polynomial.

      11.15 ZCHALLENGE
        Request sender to echo a random number in ZP0...ZP3 in a ZACK frame.
        Sent by the receiving program to the sending program to verify that
        it is connected to an operating program, and was not activated by
        spurious data or a Trojan Horse message.

      11.16 ZCOMPL
        Request now completed.

      11.17 ZCAN
        This is a pseudo frame type returned by GETHDR() in response to a
        Session Abort sequence.

      11.18 ZFREECNT
        Sending program requests a ZACK frame with ZP0...ZP3 containing the
        number of free bytes on the current file system. A value of zero
        represents an indefinite amount of free space.

      11.19 ZCOMMAND
        ZCOMMAND is sent in a binary frame. ZF00 contains 00 or ZCACK1 (see
        below).

        A ZCRCW data subpacket follows, with the ASCII text command string
        terminated with a NULL character. If the command is intended to be
        executed by the operating system hosting the receiving program (e.g.,
        "shell escape"), it must have "!" as the first character. Otherwise
        the command is meant to be executed by the application program which
        receives the command.

        If the receiver detects an illegal or badly formed command, the
        receiver immediately responds with a ZCOMPL header with an error code
        in ZP0...ZP3.


      ZMODEM Protocol
      Documentation
      Page 30


        If ZF0 contained ZCACK1, the receiver immediately responds with a
        ZCOMPL header with zero status.

        Otherwise, the receiver responds with a ZCOMPL header when the
        operation is completed. The exit status of the completed command is
        stored in ZP0...ZP3. A zero exit status implies nominal completion of
        the command.

        If the command causes a file to be transmitted, the command sender
        will see a ZRQINIT frame from the other computer attempting to send
        data.

        The sender examines ZF0 of the received ZRQINIT header to verify it is
        not an echo of its own ZRQINIT header. It is illegal for the sending
        program to command the receiving program to send a command.

        If the receiver program does not implement command downloading, it may
        display the command to the standard error output, then return a ZCOMPL
        header.


      12. SESSION TRANSACTION EXAMPLES

      12.1  A SIMPLE FILE TRANSFER

      A simple transaction, one file, no errors, no CHALLENGE, overlapped I/O:

      Sender         Receiver

      "rz/r"
      ZRQINIT(0)
                     ZRINIT
      ZFILE
                     ZRPOS
      ZDATA data ...
      ZEOF
                     ZRINIT
      ZFIN
                     ZFIN
      OO



      ZMODEM Protocol
      Documentation
      Page 31


      12.2  CHALLENGE AND COMMAND DOWNLOAD


      Sender              Receiver

      "rz/r"
      ZRQINIT(ZCOMMAND)
                          ZCHALLENGE(random-number)
      ZACK(same-number)
                          ZRINIT
      ZCOMMAND, ZDATA
                          (Performs Command)
                          ZCOMPL
      ZFIN
                          ZFIN
      OO


      13. ZFILE FRAME FILE INFORMATION

      ZMODEM sends the same file information with the ZFILE frame data that
      YMODEM Batch sends in its block zero. The pathname (file name) field
      is mandatory.

      PATHNAME
        The pathname (conventionally, the file name) is sent as a
        null-terminated ASCII string. This is the filename format used by the
        handle-oriented MS-DOS(TM) functions and C library FOPEN functions.
        An assembly language example follows:

        DB 'foo.bar',0

        No spaces are included in the pathname. Normally only the file name
        stem (no directory prefix) is transmitted unless the sender has
        selected YAM's 'F' option to send the full absolute or relative
        pathname. The source drive designator (A:, B:, etc.) usually is not
        sent.

      FILENAME CONSIDERATIONS

      ==> File names should be translated to lower case unless the sending
          system supports upper/lower case file names. This is a convenience
          for users of systems (such as Unix) which store filenames in upper
          and lower case.


      ZMODEM Protocol
      Documentation
      Page 32


      ==> The receiver should accommodate file names in lower and upper case.

      ==> When transmitting files between different operating systems, file
          names must be acceptable to both the sender and receiving operating
          systems. If not, transformations should be applied to make the file
          names acceptable. If the transformations are unsuccessful, a new
          file name may be invented by the receiving program.

      If directories are included, they are delimited by '/' ; i.e.,
      "subdir/foo" is acceptable, "subdir foo" is not.

      LENGTH
        The file length and each of the succeeding fields are optional. [1]
        The length field is stored as a decimal string counting the number of
        data bytes in the file.

        The ZMODEM receiver uses the file length as an estimate only. It may
        be used to display an estimate of the transmission time, and may be
        compared with the amount of free disk space. The actual length of the
        received file is determined by the data transfer. A file may grow
        after transmission commences, and all the data will be sent.

      MODIFICATION DATE
        A single space separates the modification date from the file length.
        The modification date is optional, and the filename and length may be
        sent without requiring the modification date to be sent.

        The modification date is sent as an octal number giving the time the
        contents of the file were last changed measured in seconds from Jan 1
        1970 Coordinated Universal Time (UTC). A date of zero implies the
        modification date is unknown and should be left as the date the file
        is received.

        This standard format was chosen to eliminate ambiguities arising from
        transfers between different time zones.


      FILE MODE
        A single space separates the file mode from the modification date. The
        file mode is stored as an octal string. Unless the file originated
        from a Unix system, the file mode is set to zero. RZ(1) checks the file
        mode for the 0x8000 bit which indicates a Unix type regular file.
        Files with the 0x8000 bit set are assumed to have been sent from
        another Unix (or similar) system which uses the same file conventions.
        Such files are not translated in any way.

      [1]. Fields may not be skipped.

      ZMODEM Protocol
      Documentation
      Page 33


      SERIAL NUMBER
        A single space separates the serial number from the file mode. The
        serial number of the transmitting program is stored as an octal
        string. Programs which do not have a serial number should omit this
        field, or set it to zero. The receiver's use of this field is optional.

      NUMBER OF FILES REMAINING
        If the number of files remaining is sent, a single space separates
        this field from the previous field. This field is coded as a decimal
        number, and includes the current file. This field is an estimate, and
        incorrect values must not be allowed to cause loss of data. The
        receiver's use of this field is optional.

      NUMBER OF BYTES REMAINING
        If the number of bytes remaining is sent, a single space separates
        this field from the previous field. This field is coded as a decimal
        number, and includes the current file. This field is an estimate, and
        incorrect values must not be allowed to cause loss of data. The
        receiver's use of this field is optional.

      The file information is terminated by a null. If only the pathname is
      sent, the pathname is terminated with two nulls. The length of the file
      information subpacket, including the trailing null, must not exceed 1024
      bytes; a typical length is less than 64 bytes.


      14. PERFORMANCE RESULTS

      14.1 COMPATIBILITY

      Extensive testing has demonstrated ZMODEM to be compatible with
      satellite links, packet switched networks, microcomputers,
      minicomputers, regular and error-correcting buffered modems at 75 to
      19200 bps. ZMODEM's economy of reverse channel bandwidth allows modems
      that dynamically partition bandwidth between the two directions to
      operate at optimal speeds.


      14.2 THROUGHPUT

      Between two single-task PC-XT computers sending a program image on an
      in-house Telenet link, SuperKermit provided 72 ch/sec throughput at
      1200 baud. YMODEM-K yielded 85 chars/sec, and ZMODEM provided 113
      chars/sec. XMODEM was not measured, but would have been much slower
      based on observed network propagation delays.

      ZMODEM Protocol
      Documentation
      Page 34


      Recent tests downloading large binary files to an IBM PC (4.7 mHz V20)
      running YAMK 16.30 with table-driven 32-bit CRC calculation yielded a
      throughput of 1870 cps on a 19200 bps direct connection.

      Tests with TELEBIT TrailBlazer modems have shown transfer rates
      approaching 1400 characters per second for long files. When files are
      compressed, effective transfer rates of 2000 characters per second are
      possible.


      14.3 ERROR RECOVERY

      Some tests of ZMODEM protocol error-recovery performance have been made.
      A PC-AT with SCO SYS V Xenix or DOS 3.1 was connected to a PC with
      DOS 2.1 either directly at 9600 bps or with unbuffered dial-up 1200 bps
      modems. The ZMODEM software was configured to use 1024-byte data
      subpacket lengths above 2400 bps, 256 otherwise.

      Because no time delays are necessary in normal file transfers, per-file
      negotiations are much faster than with YMODEM, the only observed delay
      being the time required by the program(s) to update logging files.

      During a file transfer, a short line hit seen by the receiver usually
      induces a CRC error. The interrupt sequence is usually seen by the
      sender before the next data subpacket is completely sent, and the
      resultant loss of data throughput averages about half a data subpacket
      per line hit. At 1200 bps this is would be about .75 second lost per
      hit. At 10-5 error rate, this would degrade throughput by about 9 per
      cent.

      The throughput degradation increases with increasing channel delay, as
      more data subpackets in transit through the channel are discarded when
      an error is detected.

      A longer noise burst that affects both the receiver and the sender's
      reception of the interrupt sequence usually causes the sender to remain
      silent until the receiver times out in 10 seconds. If the round trip
      channel delay exceeds the receiver's 10 second timeout, recovery from
      this type of error may become difficult.

      Noise affecting only the sender is usually ignored, with one common
      exception. Spurious XOFF characters generated by noise stop the sender
      until the receiver times out and sends an interrupt sequence which
      concludes with an XON.

      ZMODEM Protocol
      Documentation
      Page 35


      In summation, ZMODEM performance in the presence of errors resembles
      that of X.PC and SuperKermit. Short bursts cause minimal data
      retransmission. Long bursts (such as pulse dialing noises) often require
      a timeout error to restore the flow of data.


      15. PACKET SWITCHED NETWORK CONSIDERATIONS

      Flow control is necessary for printing messages and directories, and for
      streaming file transfer protocols. A non-transparent flow control is
      incompatible with XMODEM and YMODEM transfers. XMODEM and YMODEM
      protocols require complete transparency of all 256 8-bit codes to
      operate properly.

      The "best" flow control (when X.25 or hardware CTS is unavailable) would
      not "eat" any characters at all. When the PAD's buffer almost fills up,
      an XOFF should be emitted. When the buffer is no longer nearly full,
      send an XON. Otherwise, the network should neither generate nor eat XON
      or XOFF control characters.

      On Telenet, this can be met by setting CCIT X3 5:1 and 12:0 at both ends
      of the network. For best throughput, parameter 64 (advance ACK) should
      be set to something like 4. Packets should be forwarded when the packet
      is a full 128 bytes, or after a moderate delay (3:0, 4:10, 6:0).

      With PC-Pursuit, it is sufficient to set parameter 5 to 1 at both ends
      after one is connected to the remote modem.

        <ENTER> @ <ENTER>
        set 5:1 <ENTER>
        rst? 5:1 <ENTER>
        cont <ENTER>

        Unfortunately, many PADs do not accept the "rst?" command.

        For YMODEM, PAD buffering should guarantee that a minimum of 1040
        characters can be sent in a burst without loss of data or generation
        of flow control characters. Failure to provide this buffering will
        generate excessive retries with YMODEM.


      ZMODEM Protocol
      Documentation
      Page 36


      TABLE 1.
      Network and Flow Control Compatibility

                               INTER-             WX       SUPER
          CONNECTIVITY         ACTIVE    XMODEM   MODEM    KERMIT   ZMODEM

          Direct Connect       YES       YES      YES      YES      YES
          Network, no FC       NO        YES      [4]      [6]      YES [1]
          Net, transparent FC  YES       YES      YES      YES      YES
          Net, non-trans. FC   YES       NO       NO [5]   YES      YES
          Network, 7 bit       YES       NO       NO       YES [2]  YES [3]


      [1] ZMODEM can optimize window size or burst length for fastest
          transfers.
      [2] Parity bits must be encoded, slowing binary transfers.
      [3] Natural protocol extension possible for encoding data to 7 bits.
      [4] Small WXMODEM window size may may allow operation.
      [5] Some flow control codes are not escaped in WXMODEM.
      [6] Kermit window size must be reduced to avoid buffer overrun.


      16. PERFORMANCE COMPARISON TABLES

      "Round Trip Delay Time" includes the time for the last byte in a packet
      to propagate through the operating systems and network to the receiver,
      plus the time for the receiver's response to that packet to propagate
      back to the sender.

      The figures shown below are calculated for round trip delay times of 40
      milliseconds and 5 seconds. Shift registers in the two computers and a
      pair of 212 modems generate a round trip delay time on the order of 40
      milliseconds. Operation with busy timesharing computers and networks can
      easily generate round trip delays of five seconds. Because the round
      trip delays cause visible interruptions of data transfer when using
      XMODEM protocol, the subjective effect of these delays is greatly
      exaggerated, especially when the user is paying for connect time.

      A 102400-byte binary file with randomly distributed codes is sent at
      1200 bps 8 data bits, 1 stop bit. The calculations assume no
      transmission errors. For each of the protocols, only the per-file
      functions are considered. Processor and I/O overhead are not included.
      YM-K refers to YMODEM with 1024-byte data packets. YM-G refers to the
      YMODEM "G" option. ZMODEM uses 256-byte data subpackets for this
      example. SuperKermit uses maximum standard packet size, 8-bit
      transparent transmission, no run-length compression. The 4-block WXMODEM
      window is too small to span the 5-second delay in this example; the
      resulting thoughput degradation is ignored.

      ZMODEM Protocol
      Documentation
      Page 37


      For comparison, a straight "dump" of the file contents with no file
      management or error checking takes 853 seconds.

      TABLE 2.
      Protocol Overhead Information
      (102400-byte binary file, 5 Second Round Trip)


      Protocol               XMODEM  YM-K   YM-G  ZMODEM  SKermit  WXMODEM

      Protocol Round Trips   804     104    5     5       5        4
      Trip Time at 40ms      32s     4s     0     0       0        0
      Trip Time at 5s        4020s   520s   25s   25s     25       20
      Overhead Characters    4803    603    503   3600    38280    8000
      Line Turnarounds       1602    204    5     5       2560     1602
      Transfer Time at 0s    893s    858s   857s  883s    1172s    916s
      Transfer Time at 40ms  925s    862s   857s  883s    1172s    916s
      Transfer Time at 5s    5766s   1378s  882s  918s    1197s    936s


      FIGURE 5.
      Transmission Time Comparison
      (102400-byte binary file, 5 Second Round Trip)

      XMODEM       **************************************************

      YMODEM-K     ************

      SuperKermit  **********
       (Sliding Windows)

      ZMODEM 16kb  *******
       Segmented Streaming

      ZMODEM       *******
       Full Streaming 

      YMODEM-G     *******

      TABLE 3.
      Local Timesharing Computer Download Performance

      Command          Protocol  Time/HD   Time/FD  Throughput   Efficiency 

      kermit -x         Kermit     1:49      2:03      327          34%
      sz -Xa phones.t   XMODEM     1:20      1:44      343          36%
      sz -a phones.t    ZMODEM      :39       :48      915          95%

      ZMODEM Protocol
      Documentation
      Page 38


      Times were measured downloading a 35721-character text file at 9600 bps,
      from Santa Cruz SysV 2.1.2 Xenix on a 9 mHz IBM PC-AT to DOS 2.1 on an
      IBM PC. Xenix was in multi-user mode but otherwise idle. Transfer times
      to PC hard disk and floppy disk destinations are shown.

      C-Kermit 4.2 (030) used server mode and file compression, sending to
      Pro-YAM 15.52 using zero delay and a "get phones.t" command.

      Crosstalk XVI 3.6 used XMODEM 8-bit checksum (CRC not available) and an
      "ESC rx phones.t" command. The Crosstalk time does not include the time
      needed to enter the extra commands not needed by Kermit and ZMODEM.

      Professional-YAM used ZMODEM AutoDownload. ZMODEM times included a
      security challenge to the sending program.


      TABLE 4.
      File Transfer Speeds

      PROT     FILE            BYTES    BPS    CH/SEC     NOTES

      X        jancol.c        18237    2400     53       Tymnet PTL 
                                                            5/3/87
      X        source.xxx      6143     2400     56       Source/Telenet
                                                            PTL
      X        jancol.c        18237    2400     64       Tymnet PTL
      B        jancol.c        18237    1200     87       DataPac
                                                            (604-687-7144)
      XN       tsrmaker.arc    25088    1200     94       GEnie PTL
      B/ovth   emaibm.arc      51200    1200     101      CIS PTL MNP
      UUCP     74 files, each  >7000    1200     102      Average for
                                                            Various callers
      ZM       jancol.c        18237    1200     112      DataPac
                                                            (604-687-7144)
      X/ovth   emaibm.arc      51200    1200     114      CIS PTL MNP
      ZM       emaibm.arc      51200    1200     114      CIS PTL MNP
      B        jancol.c        18237    2400     124      Tymnet PTL
      B        YI0515.87       9081     2400     157      CIS PTL node
                                                            5/29/87
      SK       source.xxx      6143     2400     170      Source/Telenet
                                                            PTL 5/29/87
      ZM       jancol.c        18237    2400     221      Tymnet PTL
                                                            upl/dl
      B/ovth   destro.gif      33613    2400     223      CIS/PTL LEVEL 5
                                                            9-12-87
      ZM       jancol.c        18237    2400     224      Tymnet PTL
      ZM       jancol.c        18237    2400   226/218    TeleGodzilla upl
      ZM       jancol.c        18237    2400     226      Tymnet PTL 5/3/87

      ZMODEM Protocol
      Documentation
      Page 39


      PROT     FILE            BYTES    BPS    CH/SEC     NOTES

      ZM       zmodem.ov       35855    2400     227      CIS PTL node
      C        jancol.c        18237    2400     229      Tymnet PTL
                                                            5/3/87
      ZM       jancol.c        18237    2400   229/221    TeleGodzilla
      ZM       zmodem.ov       35855    2400     229      CIS PTL node upl
      ZM       jancol.c        18237    2400     232      CIS PTL node
      ZM       mbox            473104   9600    948/942   TeleGodzilla upl
      ZM       zmodem.arc      318826   14k    1357/1345  TeleGodzilla
      ZM       mbox            473104   14k    1367/1356  TeleGodzilla upl
      ZM       c2.doc          218823   38k      3473     Xenix 386
                                                            Toolkit upload
      ZM       mbox            511893   38k      3860     386 Xenix 2.2
                                                            Beta #
      ZM       c.doc           218823   57k      5611     **


         ABBREVIATIONS:

           B = Compuserve B Protocol
      B/ovth = CIS B with Omen Technology OverThruster(TM)
           C = Capture DC2/DC4 (no protocol)
           K = Kermit
         MNP = Microcom MNP error correcting SX/1200 modem
         PTL = Portland Oregon network node
          SK = Sliding Window Kermit (SuperKermit) w=15
           X = XMODEM
          XN = XMODEM protocol implemented in network modes
      X/ovth = XMODEM, Omen Technology OverThruster(TM)
          ZM = ZMODEM
          Tk = Xenix 386 Toolkit, rz compiled -M3, dumb serial port
          ** = AT Clone ramdisk to 386 ramdisk, or either ramdisk to nul
           # = On the fly format translation NL to CR/LF

      Times are for downloads unless noted. Where two speeds are noted, the
      faster speed is reported by the receiver because its transfer time
      calculation excludes the security check and transaction log file
      processing. The TeleGodzilla computer is a 4.77 MHZ IBM PC with a 10 MB
      hard disk. The 386 computer uses an Intel motherboard at 18 MHZ 1ws.
      The AT Clone (QIC) runs at 8 MHZ 0ws.

      ZMODEM Protocol
      Documentation
      Page 40


      TABLE 5. 
      Protocol Checklist

      ITEM                XMODEM  WXMODEM  YMDM-K   YMDM-K  ZMODEM  SKermit

      IN SERVICE          1977    1986     1982     1985    1986    1985

      User features
      User Friendly I/F   -       -        -        -       YES     -
      Commands/batch      2*N     2*N      2        2       1       1 [1]
      Commands/file       2       2        0        0       0       0
      Command Download    -       -        -        -       YES     YES [6]
      Menu Compatible     -       -        -        -       YES     -
      Transfer Recovery   -       -        -        -       YES     -
      File Management     -       -        -        -       YES     -
      Security Check      -       -        -        -       YES     -
      YMODEM Fallback     YES     YES      YES      YES     YES     -
     **********************************************************************
      COMPATIBILITY       XMODEM  WXMODEM  YMDM-K   YMDM-K  ZMODEM  SKermit

      Dynamic Files       YES     YES      fail     fail    YES     YES
      Packet SW NETS      -       YES      -        -       YES     YES
      7-bit PS NETS       -       -        -        -       [8]     YES
      Old Mainframes      -       -        -        -       [8]     YES
      CP/M-80             YES     YES      YES      -       YES[9]  -
     **********************************************************************
      ATTRIBUTES          XMODEM  WXMODEM  YMDM-K   YMDM-K  ZMODEM  SKermit

      Reliability [5]     fair    poor     fair[5]  none    BEST    HIGH
      Streaming           -       YES      -        YES     YES     YES
      Overhead [2]         7%      7%       1%       1%      1%      30%
      Faithful Xfers      -       -        YES      YES     YES     YES
      Preserve Date       -       -        YES      YES     YES     -
     **********************************************************************
      COMPLEXITY          XMODEM  WXMODEM  YMDM-K   YMDM-K  ZMODEM  SKermit

      No-Wait Sample      -       REQD     -        -       opt     REQD
      Ring Buffers        -       REQD     -        -       opt     REQD
      XMODEM Similar      YES     LOW      HIGH     HIGH    LOW     NONE
      Complexity          LOW[5]  MED      LOW[5]   LOW     MED     HIGH
     **********************************************************************
      EXTENSIONS          XMODEM  WXMODEM  YMDM-K   YMDM-K  ZMODEM  SKermit

      Server Operation    -       -        -        -       YES[4]  YES
      Multiple Threads    -       -        -        -       future  -

      ZMODEM Protocol
      Documentation
      Page 41


     NOTES:

      [1] Server mode or Omen Technology Kermit AutoDownload
      [2] Character count, binary file, transparent channel
      [3] 32-bit math needed for accurate transfer (no garbage added)
      [4] AutoDownload operation
      [5] Cybernetic Data Recovery(TM) improves XMODEM and YMODEM
          reliability with complex proprietary logic.
      [6] Server commands only
      [7] No provision for transfers across time zones
      [8] Future enhancement provided for
      [9] With Segmented Streaming

      WXMODEM: XMODEM derivative protocol with data encoding and windowing


      17. FUTURE EXTENSIONS

      Future extensions include:

      ==> Compatibility with 7-bit networks

      ==> Server/Link Level operation: An END-TO-END error-corrected
          program-to-program session is required for financial and other
          sensitive applications.

      ==> Multiple independent threads

      ==> Encryption

      ==> Compression

      ==> File Comparison

      ==> Selective transfer within a file (e.g., modified segments of a
          database file)

      ==> Selective Retransmission for error correction

      ZMODEM Protocol
      Documentation
      Page 42


      18. REVISIONS

      10-27-87 Optional fields added for number of files remaining to be sent
               and total number of bytes remaining to be sent.

      07-31-87 The receiver should ignore a ZEOF with an offset that does not
               match the current file length. The previous action of
               responding with ZRPOS caused transfers to fail if a CRC error
               occurred immediately before end-of-file, because two
               retransmission requests were being sent for each error. This
               has been observed under exceptional conditions, such as data
               transmission at speeds greater than the receiving computer's
               interrupt response capability or gross misapplication of flow
               control. Discussion of the Tx backchannel garbage count and
               ZCRCW after error ZRPOS was added. Many revisions for clarity.

      07-09-87 Corrected XMODEM's development date, incorrectly stated as 1979
               instead of the actual August 1977. More performance data was
               added.

      05-30-87 Added ZMNEW and ZMSKNOLOC

      05-14-87 Window management, ZACK ZSHHDR XON removed, control-character
           on.

      03-15-87 32-bit CRC added.

      12-19-86 Zero-Length ZCRCW data subpacket sent in response to ZPAD or
               ZDELE detected on reverse channel has been changed to ZCRCE.
               The reverse channel is now checked for activity before sending
               each ZDATA header.

      11-08-86 Minor changes for clarity.

      10-02-86 ZCNL definition expanded.

      09-11-86 ZMPROT file management option added.

      08-20-86 More performance data included.

      08-04-86 ASCII DLE (Ctrl-P, 020) now escaped; compatible with previous
               versions. More document revisions for clarity.

      ZMODEM Protocol
      Documentation
      Page 43


      07-15-86 This document was extensively edited to improve clarity and
               correct small errors. The definition of the ZMNEW management
               option was modified, and the ZMDIFF management option was
               added. The cancel sequence was changed from two to five CAN
               characters after spurious two-character cancel sequences were
               detected.


      19. MORE INFORMATION

      Please contact Omen Technology for troff source files and typeset copies
      of this document.


      19.1 TELEGODZILLA BULLETIN BOARD

      More information may be obtained by calling the TeleGodzilla bulletin
      board at 503-621-3746. TeleGodzilla supports 19200 (Telebit PEP), 2400
      and 1200 bps callers with automatic speed recognition.

      Relevant files include YZMODEM.ZOO, YAMDEMO.ZOO, YAMHELP.ZOO,
      ZCOMMEXE.ARC, ZCOMMDOC.ARC, ZCOMMHLP.ARC, and YMODEM.DQC.

      Useful commands for TeleGodzilla include "menu", "dir",
      "sx file (XMODEM)", "kermit sb file ...", and "sz file ...".


      19.2 UNIX UUCP ACCESS

      UUCP sites can obtain the current version of this file with

        UUCP omen!/u/caf/public/zmodem.doc /tmpA

      continually updated list of available files is stored in 

       /usr/spool/UUCPpublic/FILES.

       UUCPomen!UUCP/FILES /usr/spool/UUCPpublic

      The following L.sys line allows UUCP to call site "omen" via Omen's
      bulletin board system "TeleGodzilla". TeleGodzilla is an instance of
      Omen Technology's Professional-YAM in host operation, acting as a
      bulletin board and front-ending a Xenix system.

      ZMODEM Protocol
      Documentation
      Page 44


      In response to TeleGodzilla's "Name Please:" (e:--e:),

         "uucico"

      gives the Pro-YAM "link" command as a user name. Telegodzilla then asks
      for a link password (d:). The password (Giznoid) controls access to the
      Xenix system connected to the IBM PC's other serial port.
      Communications between Pro-YAM and Xenix use 9600 bps; YAM converts
      this to the caller's speed.

      Finally, the calling "uucico" sees the Xenix "Login:" message (n:--n:),
      and logs in as "UUCP". No password is used for the UUCP account.

         omen Any ACU 2400 1-503-621-3746 e:--e: link d: Giznoid n:--n: UUCP


      20. ZMODEM PROGRAMS

      A copy of this document, a demonstration version of Professional-YAM, a
      flash-up tree-structured help file and processor, are available in
      YZMODEM.ZOO on TeleGodzilla and other bulletin boards. This file must be
      unpacked with LOOZ.EXE, also available on TeleGodzilla. YZMODEM.ZOO may
      be distributed provided none of the files are deleted or modified
      without the written consent of Omen Technology.

      TeleGodzilla and other bulletin boards also feature ZCOMM, a shareware
      communications program. ZCOMM includes Omen Technology's TurboLearn(TM)
      Script Writer, ZMODEM, Omen's highly acclaimed XMODEM and YMODEM
      protocol support, Sliding Windows Kermit, several traditional protocols,
      a powerful script language, and the most accurate VT100/102 emulation
      available in a user-supported program. The ZCOMM files include:

      ==> ZCOMMEXE.ARC Executable files and beginner's telephone directory

      ==> ZCOMMDOC.ARC "Universal Line Printer Edition" Manual

      ==> ZCOMMHLP.ARC Tree-structured Flash-up help processor and database

      Source code and manual pages for the Unix/Xenix RZ and SZ programs are
      available on TeleGodzilla in RZSZ.ZOO. This ZOO archive may be unpacked
      with LOOZ.EXE, also available on TeleGodzilla. Most Unix-like systems
      are supported, including V7, Sys III, 4.x BSD, SYS V, Idris, Coherent,
      and Regulus.

      ZMODEM Protocol
      Documentation
      Page 45


      RZSZ.ZOO includes a ZCOMM/Pro-YAM/PowerCom script ZUPL.T to upload the
      small (178 lines) YMODEM bootstrap program MINIRB.C without a file
      transfer protocol. MINIRB uses the Unix STTY(1) program to set the
      required raw TTY modes, and compiles without special flags on virtually
      all Unix and Xenix systems. ZUPL.T directs the Unix system to compile
      MINIRB, then uses it as a bootstrap to upload the RZ/SZ source and
      manual files.

      The PC-DOS OPUS and NOCHANGE bulletin boards support ZMODEM. Integrated
      ZMODEM support for the COLLIE bulletin board program is planned.

      A number of other bulletin board programs support ZMODEM with external
      modules (DSZ, etc.).

      The PC-DOS Teleconferencing system IN-SYNCH uses ZMODEM.

      The LAN modem-sharing program LINE PLUS has announced ZMODEM support.

      Other PC-DOS communications programs with ZMODEM support modules include
      QMODEM and BOYAN. Many programs are adding direct ZMODEM support,
      including Crosstalk Mark IV, Telix 3.0, and (expected) Procomm and
      Qmodem.

      The ZMDM communications program by Jwahar Bammi runs on Atari ST
      machines.

      The online!!!! program for the Amiga supports ZMODEM.

      The Compuserve Information Service has ported the Unix RZ/SZ ZMODEM
      programs to DEC SYSTEM 20 assembler.


      20.1 ADDING ZMODEM TO DOS PROGRAMS

      DSZ is a small program that supports XMODEM, YMODEM, and ZMODEM file
      transfers. DSZ is designed to be called from a bulletin board program or
      another communications program. It may be called ASDSZ PORT 2 SZ FILE1
      FILE2 to send files, or as DSZ PORT 2 RZTO receive zero or more file(s),
      or as DSZ PORT 2 RZ FILEA FILEB to receive two files, the first to FILEA
      and the second (if sent) to FILEB. This form of DSZ may be used to
      control the pathname of incoming file(s). In this example, if the
      sending program attempted to send a third file, the transfer would be
      terminated.

      DSZ uses DOS stdout for messages (no direct CRT access), acquires the
      COMM port vectors with standard DOS calls, and restores the COMM port's
      interrupt vector and registers upon exit.

      ZMODEM Protocol
      Documentation
      Page 46


      Further information on DSZ may be found in DSZ.DOC and the ZCOMM or
      Pro-YAM user manuals.


      21. YMODEM PROGRAMS

      The Unix RZ/SZ programs support YMODEM as well as ZMODEM. Most Unix-like
      systems are supported, including V7, Sys III, 4.2 BSD, SYS V, Idris,
      Coherent, and Regulus.

      A version for VAX-VMS is available in VRBSB.SHQ, in the same directory.

      Irv Hoff has added 1k packets and YMODEM transfers to the KMD and IMP
      series programs, which replace the XMODEM and MODEM7/MDM7xx series
      respectively. Overlays are available for a wide variety of CP/M systems.

      Many other programs, including MEX-PLUS and Crosstalk Mark IV also
      support some of YMODEM's features.

      Questions about YMODEM, the Professional-YAM communications program, and
      requests for evaluation copies may be directed to:

          Chuck Forsberg
          Omen Technology Inc
          17505-V Sauvie Island Road
          Portland Oregon 97231
          VOICE: 503-621-3406
          Modem (TeleGodzilla): 503-621-3746
          Usenet: ...!tektronix!reed!omen!caf
          Compuserve: 70007,2304
          Source: TCE022


      22. ACKNOWLEDGMENTS

      ZMODEM was developed for the public domain under a Telenet contract. The
      ZMODEM protocol descriptions and the Unix RZ/SZ program source code are
      public-domain. No licensing, trademark, or copyright restrictions apply
      to the use of the protocol, the Unix RZ/SZ source code and the ZMODEM
      name.

      Encouragement and suggestions by Thomas Buck, Ward Christensen, Earl
      Hall, Irv Hoff, Stuart Mathison, and John Wales, are gratefully
      acknowledged. 32-bit CRC code courtesy Gary S. Brown.

      ZMODEM Protocol
      Documentation
      Page 47


      23. RELATED FILES

      The following files may be useful while studying this document:

      YMODEM.DOC.........Describes the XMODEM, XMODEM-1k, and YMODEM batch
                         file transfer protocols. This file is available on
                         TeleGodzilla's YMODEM.DQC.

      ZMODEM.H...........Definitions for ZMODEM manifest constants.

      RZ.C, SZ.C, RBSB.C Unix source code for operating ZMODEM programs.

      RZ.1, SZ.1.........Manual pages for RZ and SZ (Troff sources).

      ZM.C...............Operating-system-independent low-level ZMODEM
                         subroutines.

      MINIRB.C...........A YMODEM bootstrap program, 178 lines.

      RZSZ.ZOO,RZSZ.ARC..Contain the C source code and manual pages listed
                         above, plus a ZCOMM script to upload MINIRB.C to a
                         Unix or Xenix system, compile it, and use the program
                         to upload the ZMODEM source files with error
                         checking.

      DSZ.ZOO,DSZ.ARC....Contains DSZ.COM, a shareware X/Y/ZMODEM subprogram,
                         DESQ view "pif" files for background operation in
                         minimum memory, and DSZ.DOC.

      ZCOMM*.ARC.........Archive files for ZCOMM, a powerful shareware
                         communications program.


                       - = [ E n d   O f   T e x t ] = -

