TUCoPS :: Truly Miscellaneous :: zmodemdo.txt

Description of Zmodem and how to implement it

     The ZMODEM Asynchronous Inter Application File Transfer Protocol

                              Chuck Forsberg

                           Omen Technology Inc

                              Chuck Forsberg

                           Omen Technology Inc

                   17505-V Northwest Sauvie Island Road

                          Portland Oregon 97231

                           Voice: 503-621-3406

            Modem (TeleGodzilla): 503-621-3746 Speed 1200,300

                          Compuserve: 70007,2304

                    UUCP: ...!tektronix!reed!omen!caf

Chapter 0               Rev091186 Typeset 9-11-86                        1

Chapter 0               Rev091186 Typeset 9-11-86                        2


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.


In the beginning of ZMODEM development, we thought a few modifications to

XMODEM might 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 signals

used by XMODEM and YMODEM.  The resultant protocol would allow the sender

to send more than one block before waiting for a response.

But how to add the block number to XMODEM's ACK and NAK?  Pure binary

won't do, some combinations won't pass through networks and operating

systems.  Other operating systems may not be able to recognize comething

coming back unless a break signal or particular code is present.[1] Hmmm,

this starts to sound like a PACKET, with variable preamble, encoded data,

and an ending sequence, a far cry from XMODEM's simple ACK and NAK.

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.  This extrapolates to the

better part of 20000 characters at 19.2 kbps.  Much of the SuperKermit's

complexity and debugging time centered around its ring buffering and

window management.  There had to be an easier way to get the job done.

A sore point in XMODEM and YMODEM 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?  Y/YMODEM 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 pass 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 that does not appear

anywhere else.  WXMODEM and ZMODEM use character sequences to delineate

the start of frames.

A further error recovery problem arises in streaming protocols.  How does


 1. Without waiting for a response

 2. The WINDOW is the data in transit between sender and receiver.

Chapter 2               Rev091186 Typeset 9-11-86                        2

Chapter 2               Rev091186 Typeset 9-11-86                        3

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 bacause the sender did not receive the

error signal?  How long should the receiver let this continue before

sending another error signal?  How can the protocol prevent this from

degenerating into an argument about mixed signals?

SuperKermit uses selective retransmission, so it can accept any good

packet it receives.  Each time the SuperKermit receiver gets a data

packet, it goes through a routine to decide which outstanding packet (if

any) it "wants most" to receive, and asks for that one.

In the ZMODEM development, we decided to forgo the complexity of

SuperKermit's selective retransmission scheme and its associated buffer

management logic and memory requirements.

Another sore point with XMODEM (and WXMODEM) is the garbage added at the

end of files.  This was accpetable with old CP/M files which had no exact

length, but not with modern systems such as DOS and Unix.  YMODEM and FAST

use file length information 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 two bytes to represent packet length.  The length of data

subpackets is denoted by ending each subpacket with an escape sequence

analagous to BISYNC and HDLC.

The end result was a ZMOEM header containing a "frame type", four bytes of

supervisory information, and its own CRC-16.  Data frames consist of a

header followed by 1 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 encoded 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 (network friendly) frames, the

sending program can send an "invitation to receive" sequence to activate

the receiver without undue concern of crashing the remote application with

unexpected  control characters.

Going "back to scratch" in the protocol design presents an oppurtunity 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

Chapter 2               Rev091186 Typeset 9-11-86                        3

Chapter 2               Rev091186 Typeset 9-11-86                        4

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 is incomplete if the user

must assign transfer options to both the sending and receiving programs.

As a result, transfer options may be specified to the sending program,

which passes them to the receiving program in the ZFILE header.


Encouragement and suggestions by Thomas Buck, Ward Christensen, Earl Hall,

Irv Hoff, Stuart Mathison, and John Wales, are gratefully acknowledged.


The following files may be useful while studying this document:


zzzzmmmmooooddddeeeemmmm....hhhh Provides definitions for the manifest consteferenced


rrrrzzzz....cccc,,,, sssszzzz....cccc,,,, rrrrbbbbssssbbbb.cccc Unix source code for operating ZMODEM programs.

rrrrzzzz....1111,,,, sssszzzz....1111 Manual pages for rz and sz (Troff s).

zzzzmmmm....cccc,,,, zzzzmmmmooooddddeeeemmmm....hhhh Operatitem independent ZMODEM subroutines, header



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 0 or more data subpackets.

Chapter 5               Rev091186 Typeset 9-11-86                        4

Chapter 5               Rev091186 Typeset 9-11-86                        5

XMODEM  refers to the original 1979 file transfer etiquette introduced by

        Ward Christensen's 1979 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


XMODEM/CRC replaces XMODEM's 1 byte checksum with a two byte Cyclical

        Redundancy Check (CRC-16), improving error detection.

YMODEM  refers to the XMODEM/CRC protocol with the throughput and/or batch

        transmission enhancements described in YMODEM.DOC.


Since its development half a decade ago, the Ward Christensen MMMMOOOODDDDEEEEMMMM

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 XXXXMMMMOOOODDDDEEEEMMMM.

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:

   o+ The user interface is suitable for computer hobbyists.  Multiple

     commands must be keyboarded to transfer each file.

   o+ Since commands must be given to both programs, simple menu selections

     are not possible.

   o+ The short block length causes throughput to suffer when used with

     timesharing systems, packet switched networks, satellite circuits,

     and buffered (error correcting) modems.

   o+ The 8 bit checksum and unprotected transactions allow undetected

     errors and disrupted file transfers.

   o+ 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


   o+ The transmitted file accumulates as many as 127 bytes of garbage.

   o+ The modification date and other file attributes are lost.

   o+ XMODEM requires _c_o_m_p_l_e_t_e 8 bit transparency, all 256 codes.  XMODEM

     will not operate over some networks that use ASCII flow control or

     escape codes.  Setting pure transparency often disables important

     network control functions for the duration of the call.

Chapter 6               Rev091186 Typeset 9-11-86                        5

Chapter 6               Rev091186 Typeset 9-11-86                        6

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

have displaced XMODEM to date.

   o+ Lack of public domain documentation and example programs have kept

     proprietary protocols such as MNP, Blast, and others tightly bound to

     the fortunes of their suppliers.

   o+ Link level protocols such as X.25, X.PC, and MNP do not manage

     application to application file transfers.

   o+ 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]

     Kermit Sliding Windows ("SuperKermit") improves throughput over

     networks at the cost of increased complexity.  SuperKermit state

     transitions are encoded in a special language "wart" which requires a

     C compiler.  The SuperKermit C code 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.

     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.

A number of extensions to the XMODEM protocol have been made under the

collective name YMODEM.

 o+ YMODEM-k uses 1024 byte blocks to reduce the overhead from transmission

   delays by 87 per cent compared to XMODEM, but network delays can still

   degrade performance.  Some networks may not be transmit the 1024 byte

   packets unmodified.

 o+ The handling of files that are not a multiple of 1024 or 128 bytes is

   awkward, especially if the file length is not known, or changes during


 o+ YYYYMMMMOOOODDDDEEEEMMMM----gggg provides efficient batch file transferserving exact file

   length and file modification date.  YYYYMMMMOOOODDDDEEEEMMMM----gggg is eally insensitive

   to network delays.  Because it does not support error recovery,


 1. Some Kermit programs support run length encoding.

Chapter 6               Rev091186 Typeset 9-11-86                        6

Chapter 6               Rev091186 Typeset 9-11-86                        7

   YMODEM-g is usually used hardwired or with a reliable link level

   protocol.  IF YMODEM-g detects a CRC error, data transfers are aborted.

   YMODEM-g is easy to implement because it closely resembles XMODEM-CRC.

Another XMODEM "extension" is protocol cheating, referred to as "Turbo

Download" and OOOOvvvveeeerrrrTTTThhhhrrrruuuusssstttteeeerrrr[2ese sometimes improve XMODEM throughput

by disabling error recovery.

The ZMODEM Protocol corrects the weaknesses described above while

maintaining as much of XMODEM/CRC's simplicity and prior art as possible.

7.  ZZZZMMMMOOOODDDDEEEEMMMM PPPPrrrroooottttooooccccoooollDDDeeeessssiiiiggggnnnn CCCCrrrriiiitttteeeerrrriiiiaaaa

The design of a file transfer protocol is an engineering compromise

between conflicting requirements:

7.1  EEEEaaaasssseeee ooooffff UUUUsssseeee

 o+ ZMODEM allows either program to initiate file transfers, passing

   commands and/or modifiers to the other program.

 o+ File names need be entered only once.

 o+ Menu selections are supported.

 o+ Wild Card names may be used with batch transfers.

 o+ Minimum keystrokes required to initiate transfers.

 o+ ZRQINIT frame sent by sending program can trigger automatic downloads.

 o+ ZMODEM can step down to X/YMODEM if the other end does not support


7.2  TTTThhhhrrrroooouuuugggghhhhppppuuuutttt

ZMODEM is designed for optimum performance with almost no degradation

caused by delays introduced by packet switched networks and timesharing


ZMODEM is optimized for best throughput over networks where line hits


 2. Omen Technology Trademark

 1. Provided the transmission medium accommodates X/YMODEM.

Chapter 7               Rev091186 Typeset 9-11-86                        7

Chapter 7               Rev091186 Typeset 9-11-86                        8

occur infrequently.  This assumption markedly reduces code complexity and

memory requirements.  ZMODEM protocol features enhance rapid error

recovery compared to network compatible XMODEM implementations.

In the absence of network delays, error recovery is rapid, much faster

than YMODEM or network compatible versions of XMODEM.

Many transfers will originate from a timesharing system connected to a

packet switched network.  ZMODEM features allow simple, efficient

implementation on a wide variety of timesharing hosts.

File transfers begin immediately regardless of which program is started

first, without the 10 second delay associated with XMODEM.

7.3  IIIInnnntttteeeeggggrrrriiiittttyyyy aaaannnndddd RRRRobbbuuuussssttttnnnneeeessssssss

Once a ZMODEM session is begun, all transactions are protected with 16 bit

CRC.[2] Complex proprietary techniques such as CCCCyyyybbbbeeeerrrrnnnneeeettiicccc DDDDaaaattttaaaa

RRRReeeeccccoooovvvveeeerrrryyyy((((TTTTMMMM))))[3] are not need reliable transfers.

A security challenge mechanism guards against "Trojan Horse" messages.

7.4  EEEEaaaasssseeee ooooffff IIIImmmmpppplllleeeemmmmeeeentttaaaattttiiiioooonnnn

ZMODEM accommodates a wide variety of systems:

 o+ Microcomputers that cannot overlap disk and serial i/o

 o+ Microcomputers that cannot overlap serial send and receive

 o+ Computers and/or networks requiring XON/XOFF flow control

 o+ 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.[4]


 2. Except for the CAN-CAN-CAN-CAN-CAN abort sequence.

 3. Unique to Professional-YAM and PowerCom

Chapter 7               Rev091186 Typeset 9-11-86                        8

Chapter 7               Rev091186 Typeset 9-11-86                        9

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



ZMODEM requires an 8 bit transfer medium.  ZMODEM escapes network control

characters to allow operation with packet switched networks.  In general,

ZMODEM operates over any path that supports XMODEM, and over some that


To support full streaming, the path should either assert flow control[1]

or pass full speed transmission without loss of data.

8.1  FFFFiiiilllleeee CCCCoooonnnntttteeeennnnttttssss

ZMODEM places no constraints on the information content of binary files,

except that the number of bits in the file must be a multiple of 8.

Since ZMODEM is used to transfer files between different types of computer

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


Overstruck characters may be generated by backspacing or by overprinting

the line with CR (015) not followed by LF.

Overstruck characters generated with backspaces should be sent with the

most important character last to accomodate CRT displays that cannot

overstrike.  A text line is terminated by a CR/LF (015, 012) sequence, or

by a NL (012) character.  The sending program may use the ZZZZCCCCNNNNLLLL bit to

force the receiving program to convert the received end of line to its

local end of line convention.

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


 4. Streaming strateges are discussed in coming chapters.

 1. With XOFF and XON, or out of band flow control such as X.25 or CTS

Chapter 8               Rev091186 Typeset 9-11-86                        9

Chapter 8               Rev091186 Typeset 9-11-86                       10


NNNN....BBBB....:::: Files that have been translated in such a way as to modify theirth cannot be updated with the ZZZZCCCCRRRREEEECCCCOOOOVVVV Conversion Optiowihalows

interrupted transfers to be resumed without loss of data.


9.1  PPPPaaaacccckkkkeeeettttiiiizzzzaaaattttiiiioooonnnn

ZMODEM frames differ somewhat from X/YMODEM blocks.  X/YMODEM blocks are

not used for the following reasons:

 o+ Block numbers are limited to 256

 o+ No provision for variable length blocks

 o+ 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 X/YMODEM programs such as Professional-YAM and

   PowerCom overcome some of these weaknesses with clever proprietary

   code, but a stronger protocol is desired.

 o+ It is difficult to determine the beginning and ends of X/YMODEM blocks

   when line hits cause a loss of synchronization.  This precludes rapid

   error recovery.

9.2  LLLLiiiinnnnkkkk EEEEssssccccaaaappppeeee EEEEnnnnccccodddiiiinnnngggg

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


Link Escape coding does add some overhead.  The worst case, a file

consisting entirely of escaped characters, would incur a 50% overhead.


 1. This and other constants are defined in the _z_m_o_d_e_m._h include file.

    Please note that constants with a leading 0 are octal constants in C.

Chapter 9               Rev091186 Typeset 9-11-86                       10

Chapter 9               Rev091186 Typeset 9-11-86                       11

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 CAN characters to abort a ZMODEM session,

compatible with X/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.

By default, ZMODEM software currently escapes ZDLE, 020, 0220, 021, 0221,

023, and 0223.  If preceded by 0100 or 0300 (@), 015 and 0215 are also

escaped to protect the Telenet command escape CR-@-CR.

The ZMODEM routines in zm.c accept an option to escape all control

characters, to allow operation with less transparent networks.  The

routines also accept an option to escape only the ZDLE character, for

highest possible throughput.

9.3  HHHHeeeeaaaaddddeeeerrrr

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:

 o+ A type byte[2] [3]


 2. The frame types are cardinal numbers beginning with 0 to minimize

    state transition table memory requirements.

 3. Future extensions to ZMODEM may use the high order bits of the type

    byte to indicate thread selection.

Chapter 9               Rev091186 Typeset 9-11-86                       11

Chapter 9               Rev091186 Typeset 9-11-86                       12

 o+ Four bytes of data indicating flags and/or numeric quantities depending

   on the frame type

                   FFFFiiiigggguuuurrrreeee 1111....  Order of Bytes in Head                   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

9.3.1  BBBBiiiinnnnaaaarrrryyyy HHHHeeeeaaaaddddeeeerrrr

A binary header is only sent by the sending program to the receiving


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.

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

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

The function _z_s_b_h_d_r transmits a binary header.  The function _z_g_e_t_h_d_r

receives a binary or hex header.

                         FFFFiiiigggguuuurrrreeee 2222....  Binary Header

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

9.3.2  HHHHEEEEXXXX HHHHeeeeaaaaddddeeeerrrr

The receiver sends responses in hex headers.  The sender also uses hex

headers when they are not followed by binary data subpackets.

Hex encoding accomodates XON/XOFF flow control.  The hex header receiving

routine ignores flow control characters.

Use of Kermit style encoding for control and paritied characters was

considered and rejected because of increased possibility of interacting

with some timesharing systems's 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.  Except for header types

that imply data subpackets to follow, a HEX header may be used in place of

a binary header wherever convenient.

A hex header begins with the sequence ZPAD, ZPAD, ZDLE, ZHEX.  The _z_g_e_t_h_d_r

Chapter 9               Rev091186 Typeset 9-11-86                       12

Chapter 9               Rev091186 Typeset 9-11-86                       13

routine synchronizes with the ZPAD-ZDLE sequence.  The extra ZPAD allows

other parts of the program to detect a ZMODEM header and then call _z_g_e_t_h_d_r

to receive the header.

The type byte, the four position/flag bytes, and the CRC thereof are sent

in hex using the character set 01234567890abcdef.  Upper case hex digits

are not allowed; they false trigger X/YMODEM programs.

A carriage return, line feed, and XON[4] are appended to the HEX header

but are not strictly a part of it.  The CR/LF aids debugging from

printouts.  The XON releases the sender from spurious XOFF flow control

characters generated by line noise, a common occurrence.

0 or more ASCII Encoded data subpackets will follow depending on the frame


The function _z_s_h_h_d_r sends a hex header.

                          FFFFiiiigggguuuurrrreeee 3333....  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.)

9.4  BBBBiiiinnnnaaaarrrryyyy DDDDaaaattttaaaa SSSSuuuubbbbpaaacccckkkkeeeettttssss

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 4800 bps, 1024 above 4800

bps or when the data link is known to be relatively error free.  Except

for the last subpacket in a file,[5] lengths should be a power of two.

No padding is used with binary data subpackets.  The data bytes are ZDLE

encoded and transmitted.  A ZDLE and frameend are then sent, followed by

two ZDLE encoded CRC bytes.  The CRC accumulates the data bytes and


The function _z_s_d_a_t_a sends a data subpacket.  The function _z_r_d_a_t_a receives

a data subpacket.


 4. XON is not sent after a ZFIN header, to allow clean session cleanup.

 5. Or file segment if a sparse file is being processed

Chapter 9               Rev091186 Typeset 9-11-86                       13

Chapter 9               Rev091186 Typeset 9-11-86                       14

9.5  AAAASSSSCCCCIIIIIIII EEEEnnnnccccooooddddeeeedddd DDDDatttaaaa SSSSuuuubbbbppppaaaacccckkkkeeeetttt

The format of ASCII Encoded data subpackets is not currently specified.

These would be used for server commands, or main transfers in 7 bit



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.[1]

10.1  SSSSeeeessssssssiiiioooonnnn SSSSttttaaaarrrrttttuuuup

To start a ZMODEM file transfer session, the sending program is called

with the names of the desired file(s) and option(s).

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 ZZZZRRRRQQQQIIIINNNNIIIITTTT header.  The ZZZZRRQQQIIIINNNNIIIITTTT header causes a

previously started receive program to send its ZZZZRRRRIIIINNNNIIIITTTT header witdelay.

In an interactive or conversational mode, the receiving application may

monitor the data stream for ZDLE.  The following characters may be scanned

for BBBB00000000 indicating a ZRQINIT header, a command to download a command or


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 X/YMODEM

protocol.  Note: With ZMODEM and YMODEM Batch, 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.


 1. Special considerations apply when sending commands.

Chapter 10              Rev091186 Typeset 9-11-86                       14

Chapter 10              Rev091186 Typeset 9-11-86                       15

When the ZMODEM receive program starts, it immediately sends a ZZZZRRRRIIIINNNNIIIIT
header to initiate ZMODEM file transfers, or a ZZZZCCCCHHHHAAAALLLLLLLLEEEENNGGEEEE header to verify

the sending program.  The receive program resends its header at _r_e_s_p_o_n_s_e

_t_i_m_e (default 10 second) intervals for a suitable period of time (40

seconds total) before falling back to X/YMODEM protocol.

If the receiving program receives a ZZZZRRRRQQQQIIIINNNNIIIITTTT header, it reshe ZZZZRRRRIIIINNNNIIIITTTT

header.  If the sending program receives the ZZZZCCCCHHHHAAAALLLLLLLLEEEENNNGEEEE header, it places

the data in ZP0...ZP3 in an answering ZZZZAAAACCCCKKKK header.

If the receiving program receives a ZZZZRRRRIIIINNNNIIIITTTT header, it is an echocating that the sending program is not operational.

Eventually the sending program correctly receives the ZZZZRRRRIIIINNNNIIIITTTT hea

The sender may then send an optional ZZZZSSSSIIIINNNNIIIITTTT frame to define the ing

program's AAAAttttttttnnnn sequence.  The receiver sends a ZZZZAAAACCCCKKKK  in response,

optionally containing the serial number of the receiving program, or 0.

10.2  FFFFiiiilllleeee TTTTrrrraaaannnnssssmmmmiiiissssssssiooonnnn

The sender then sends a ZZZZFFFFIIIILLLLEEEE header with ZMODEM Conversion, Managemend Transport options[2] 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 ZZZZSSSSKKKKIIIIPPPP 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 ZZZZCCCCRRRRCCCC header, which requires the

       sender to perform a CRC on the file and transmit the CRC in

       a ZZZZCCCCRRRRCCCC header.  The receiver uses this information to

       determine whether to accept the file or skip it.  This

       sequence is triggered by the ZMCRC Management Option.[3]


 2. See below, under ZFILE header type.

 3. The type of CRC has not been determined yet.  The obvious choice of

    the CRC-16 used to protect packets may not be optimum for detecting

    differences between long files.  The fact that the file lengths are

    identical may give some guidance to the selection of CRC.

Chapter 10              Rev091186 Typeset 9-11-86                       15

Chapter 10              Rev091186 Typeset 9-11-86                       16

A ZZZZRRRRPPPPOOOOSSSS header from the receiver initiates transmission of the file daarting at the offset in the file specified in the ZZZZRRRRPPPPOOOOSSSS header.

Normally the receiver specifies the data transfer begin begin at offset 0

in the file.

       The receiver may start the transfer further down in the

       file.  This allows a file transfer interrupted by a loss

       or carrier or system crash to be completed on the next

       connection without requiring the entire file to be

       retransmitted.[4] 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 ZZZZDDDDAAAATTTTAAAA binary header (with file position) followed b or more data subpackets.

The receiver compares the file position in the ZZZZDDDDAAAATTTTAAAA header with the

number of characters successfully received to the file.  If they do not

agree, a ZZZZRRRRPPPPOOOOSSSS error response is generated to force the sender to the

right position within the file.[5]

A data subpacket terminated by ZZZZCCCCRRRRCCCCGGGGOOOO and CRC does not elicit a se

unless an error is detected; more data subpacket(s) follow immediately.

       ZZZZCCCCRRRRCCCCQQQQ data subpackets expect a ZZZZAAAACCCCKKKK reswith the

       receiver's file offset if no error, otherwise a ZZZZRRRRPPPPOOOOSSSS

       response with the last good file offset.  Another data

       subpacket continues immediately.  ZZZZCCCCRRRRCCCCQQQQ subpackets are

       not used if the receiver does not indicate FDX ability


ZZZZCCCCRRRRCCCCWWWW data subpackets expect a response before the next frame is sent.he receiver does not indicate overlapped I/O capability with the

CCCCAAAANNNNOOOOVVVVIIIIOOOO bit, or sets a buffer size, the sender uses the ZCCCRRRRCCCCWWWW 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 ZZZZCCCCRRRRCCCCEEEE data subpacket which does not elicit a response


 4. This does not apply to files that have been translated.

 5. If the ZMSPARS option is used, the receiver instead seeks to the

    position given in the ZDATA header.

Chapter 10              Rev091186 Typeset 9-11-86                       16

Chapter 10              Rev091186 Typeset 9-11-86                       17

except in case of error.

The sender sends a ZZZZEEEEOOOOFFFF 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 ZZZZRRRRIIIINNNNIIIITTTT.  If the receive
not received all the bytes of the file, the receiver sends ZZZZRRRRPPPPOOOOSSSS with

the current file offset, forcing the sender to resend the missing

data.  (If the receiver cannot properly close the file, a ZZZZFFFFEEEERRRRRRRR headerent.)

       After all files are processed, any further protocol

       errors should not prevent the sending program from

       returning with a success status.

10.3  SSSSeeeessssssssiiiioooonnnn CCCClllleeeeaaaannnnuuuup

The sender closes the session with a ZZZZFFFFIIIINNNN header.  The receiver

acknowledges this with its own ZZZZFFFFIIIINNNN 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.

10.4  SSSSeeeessssssssiiiioooonnnn CCCCaaaannnncccceeeellll Seeeeqqqquuuueeeennnncccceeee

If the receiving program has been receiving data in streaming mode,

the AAAAttttttttnnnn sequence is executed to interrupt data transmission.  The

Cancel sequence of eight CAN characters[6] and ten backspace

characters is sent.

       static char canistr[] = {




 6. The trailing backspace characters attempt to erase the effects of the

    CAN characters if they are received by a command interpreter.

Chapter 10              Rev091186 Typeset 9-11-86                       17

Chapter 10              Rev091186 Typeset 9-11-86                       18


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).

11.1  FFFFuuuullllllll SSSSttttrrrreeeeaaaammmmiiiinnnngggg wiiiitttthhhh SSSSaaaammmmpppplllliiiinnnngggg

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 AAAAttttttttnnnn

sequence required.  The sender begins data transmission with a ZZZZDDDDAAAATTTTAAAA

header and continuous ZZZZCCCCRRRRCCCCGGGG data subpackets.  When the receiver

detects an error, it executes the AAAAttttttttnnnn sequence and then sends a

ZZZZRRRRPPPPOOOOSSSS 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.  Any other character is ignored.[1]

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 ZCRCW data subpacket is sent to force the receiver to send a

ZZZZAAAACCCCKKKK header in case the ZPAD or CAN was spurious and the receiver was

still reading data subpackets.

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

ZZZZRRRRPPPPOOOOSSSS header resets the sender's file offset to the correct position.

If a ZZZZAAAACCCCKKKK header is recieved, the reverse channel is sampled for the

possible presence of another header from the receiver.  If a ZZZZRRRRPPPPOOOOSSSS

header is received, it is processed as above.  A ZZZZFFFFIIIINNNN, ZZZZAAAABBBBORRRRTTTT, or

TTTTIIIIMMMMEEEEOOOOUUUUTTTT terminates the session; a ZZZZSSSSKKKKIIPPP terminates the processing of

this file.  Otherwise, transmission resumes at the (possibly reset)

file offset with a ZZZZDDDDAAAATTTTAAAA header followed by data subpackets.


 1. The call to rdchk() in sssszzzz....cccc performs this function.

 2. The call to getinsync() in sssszzzz....cccc performs this function.

Chapter 11              Rev091186 Typeset 9-11-86                       18

Chapter 11              Rev091186 Typeset 9-11-86                       19

11.2  FFFFuuuullllllll SSSSttttrrrreeeeaaaammmmiiiinnnngggg wiiiitttthhhh RRRReeeevvvveeeerrrrsssseeee IIIInnnntttterrrrrrrruuuupppptttt

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 AAAAttttttttnnnn sequence.

After executing the AAAAttttttttnnnn sequence, the receiver sends a hex ZZZZRRRRPOOOSSSS

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 sssszzzz....cccc program uses a

setjmp/longjmp call to catch the interrupt generated by the AAAAttttttttnnnn

sequence.  Catching the interrupt activates the getinsync() function

to read the receiver's error header and take appropriate action.

Unix sssszzzz....cccc uses an AAAAttttttttnnnn sequence of Ctrl-C followed bsecond

pause to interrupt the sender, then give the sender (Unix) time to

prepare for the receiver's error header.

11.3  FFFFuuuullllllll SSSSttttrrrreeeeaaaammmmiiiinnnngggg wiiiitttthhhh aaaa SSSSlllliiiiddddiiiinnnngggg WWWWiiiinnnndoooowwww

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 reciever's AAAAttttttttnnnn sequence to flush the

sender's interrupt buffer before sending the ZRPOS header.

11.4  FFFFuuuullllllll SSSSttttrrrreeeeaaaammmmiiiinnnngggg ovvvveeeerrrr EEEErrrrrrrroooorrrr FFFFrrrreeeeeeee CCCChhhhannnnnnnneeeellllssss

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.

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 per cent.[3]

Chapter 11              Rev091186 Typeset 9-11-86                       19

Chapter 11              Rev091186 Typeset 9-11-86                       20

11.5  SSSSeeeeggggmmmmeeeennnntttteeeedddd SSSSttttrrrreeeeammmiiiinnnngggg

If the receiver cannot overlap serial and disk I/O, it uses the

ZZZZRRRRIIIINNNNIIIITTTT frame to specify a buffer length which the sender will norflow.  The sending program sends a ZZZZCCCCRRRRCCCCWWWW data subpacket and waits

for a ZZZZAAAACCCCKKKK 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 per cent to full streaming ZMODEM file

transfer times when the round trip delay is five seconds.


The receiving program sends the AAAAttttttttnnnn sequence whenever it detects an

error and needs to interrupt the sending program.

The default AAAAttttttttnnnn 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 AAAAttttttttnnnn string is terminated with a null.

Two meta-characters perform special functions:

   o+ \335 (octal) Send a break signal

   o+ \336 (octal) Pause one second


The numeric values for the values shown in boldface are given in

_z_m_o_d_e_m._h.  Unused bits and unused bytes in the header (ZP0...ZP3) are

set to 0.


 3. One in 256 for escaping ZDLE, about two in 1024 for data subpacket


Chapter 13              Rev091186 Typeset 9-11-86                       20

Chapter 13              Rev091186 Typeset 9-11-86                       21


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,

0 otherwise.


Sent by the receiving program.  ZF0 and ZF1 contain the  bitwise or

of the receiver capability flags:

#define CANFDX  1 /* Receiver can send and receive simultaneously */

#define CANOVIO 2 /* Receiver can receive during disk I/O */

#define CANBRK  4 /* Rx can send a break signal */

#define CANCRY  8 /* Receiver can decrypt */

ZP0 and ZP1 contain the size of the receiver's buffer in bytes, or 0

if nonstop I/O is allowed.


Sender sends capability flags (currently all 0) (none currently

defined) followed by a binary data subpacket terminated with ZZZZCCCCRRRRCCCCWWWW.

The data subpacket contains the null terminated AAAAttttttttnnnn sequence,

maximum length 32 bytes including the terminating null.



subpacket.  ZP0 to ZP3 contain file offset.  The response to

ZCHALLENGE contains the same 32 bit number received in the ZCHALLENGE



This frame denotes the beginning of a file transmission attempt.

ZF0, ZF1, and ZF2 may contain options.  A value of 0 in each of these

bytes implies no special treatment.  Options specified to the

receiver override options specified to the sender with the exception

of ZZZZCCCCBBBBIIIINNNN which overrides any other Conversion Option given to the

sender or receiver.

13.5.1  ZZZZFFFF0000:::: CCCCoooonnnnvvvveeeerrrrssssiiiioooon OOOOppppttttiiiioooonnnn

If the receiver does not recognize the Conversion Option, an

application dependent default conversion may apply.

Chapter 13              Rev091186 Typeset 9-11-86                       21

Chapter 13              Rev091186 Typeset 9-11-86                       22

ZZZZCCCCBBBBIIIINNNN "Binary" transfer - inhibit conversion unconditionally

ZZZZCCCCNNNNLLLL 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.

ZZZZCCCCRRRREEEECCCCOOOOVVVV Recover/Resume interrupted file transfer.  ZCREVOV    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.

13.5.2  ZZZZFFFF1111:::: MMMMaaaannnnaaaaggggeeeemmmmeeeennnnt OOOOppppttttiiiioooonnnn

If the receiver does not recognize the Management Option, the

file should be transferred normally.

ZZZZMMMMNNNNEEEEWWWW Transfer file if destination file absent.  Otherwise,

     transfer file overwriting destination if source file

     newer or longer.

ZZZZMMMMCCCCRRRRCCCC Compare the source and destination files.  Transfer if

     file lengths or file polynomials differ.

ZZZZMMMMAAAAPPPPNNNNDDDD Append source file contents to the end of the existing

     destination file (if any).

ZZZZMMMMCCCCLLLLOOOOBBBB Replace existing destination file (if any).

ZZZZTTTTSSSSPPPPAAAARRRRSSSS Special processing for sparse file; each file segm    is transmitted as a separate frame, where the frames are

     not necessarily contiguous.  The sender should end each

     segment with a ZCRCW (or possibly ZCRCQ) data subpacket

     and process the expected ZACK to insure no data is lost.

ZZZZMMMMDDDDIIIIFFFFFFFF Transfer file if destination file absent.  Otherwise,

     transfer file overwriting destination if files have

     different lengths or dates.

ZZZZMMMMPPPPRRRROOOOTTTT Protect destination file by transferring file only if

     the destination file is absent.

Chapter 13              Rev091186 Typeset 9-11-86                       22

Chapter 13              Rev091186 Typeset 9-11-86                       23

13.5.3  ZZZZFFFF2222:::: TTTTrrrraaaannnnssssppppoooorrrrttttOppppttttiiiioooonnnn

If the receiver does not implement the particular transport

option, the file is copied without conversion for later


ZZZZTTTTLLLLZZZZWWWW Lempel-Ziv compression.  Transmitted data will be

     identical to that produced by ccccoooommmmpppprrrreeeessssssss 4444.0000 operating on

     a computer with VAX byte ordering, using 12 bit


ZZZZTTTTCCCCRRRRYYYYPPPPTTTT Encryption.  An initial null terminated string

     identifies the key.  Details to be determined.

ZZZZTTTTRRRRLLLLEEEE Run Length encoding, Details to be determined.

A ZZZZCCCCRRRRCCCCWWWW data subpacket follows with file name, file length,

modification date, and other information described in a later



Sent by the receiver in response to ZZZZFFFFIIIILLLLEEEE, makes the sender skip to

the next file.


Indicates last header was garbled.  (See also ZZZZRRRRPPPPOOOOSSSS).


Sent by receiver to terminate batch file transfers when requested by

the user.  Sender responds with a ZZZZFFFFIIIINNNN sequence.[1]


Sent by sending program to terminate a ZMODEM session.  Receiver

responds with its own ZZZZFFFFIIIINNNN.


Sent by receiver to force file transfer to resume at file offset

given in ZP0...ZP3.


 1. Or ZZZZCCCCOOOOMMMMPPPPLLLL in case of server mode.

Chapter 13              Rev091186 Typeset 9-11-86                       23

Chapter 13              Rev091186 Typeset 9-11-86                       24


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


Sender reports End of File.  ZP0...ZP3 contain the ending file



Error in reading or writing file, protocol equivalent to ZZZZAAAABBBBOOOORRRRTTTT..14  ZZZZCCCCRRRRCCCC

Request (receiver) and response (sender) for file polynomial.

ZP0...ZP3 contain file polynomial.


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.


Request now completed.


This is a pseudo frame type returned by gethdr() in response to a

Session Abort sequence.


Sending program requests a ZACK frame with ZP0...ZP3 containing the

number of free bytes on the current file system.  A value of 0

represents an indefinite amount of free space.


ZCOMMAND is sent in a binary frame.  ZZZZFFFF0000 contains 0000 or ZZZZCCCCAAAACKKKK1111 (see


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 received the command.

Chapter 13              Rev091186 Typeset 9-11-86                       24

Chapter 13              Rev091186 Typeset 9-11-86                       25

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.

If ZF0 contained ZZZZCCCCAAAACCCCKKKK1111,,,, the receiver immediately respondsa

ZCOMPL header with 0 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 0 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


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

should display the command to the standard error output, then return

a ZCOMPL header.


14.1  AAAA ssssiiiimmmmpppplllleeee ffffiiiilllleeee ttttrrrrannnnssssffffeeeerrrr

A simple transaction, one file, no errors, no CHALLENGE, overlapped


Sender         Receiver






ZDATA data ...






Chapter 14              Rev091186 Typeset 9-11-86                       25

Chapter 14              Rev091186 Typeset 9-11-86                       26

14.2  CCCChhhhaaaalllllllleeeennnnggggeeee aaaannnndddd CCCCommmmmmmmaaaannnndddd DDDDoooowwwwnnnnllllooooaaaadddd

Sender         Receiver







               (Performs Command)






ZMODEM sends the same file information with the ZZZZFFFFIIIILLLLEEEE frame data

that YMODEM Batch sends in its block 0.

NNNN....BBBB....:::: OOOOnnnnllllyyyy tttthhhheeee ppppaaathhhhnnnnaaaammmmeeee ((((ffffiiiilllleeee nnnnaaaammmm)))) ppppaaaarrrrtttt iiiissss mmmmaaaannnnddddaaaattttoorrryyyy....

PPPPaaaatttthhhhnnnnaaaammmmeeee The pathname (conventionally, the file nameent as a

     null terminated ASCII string.  This is the filename format used

     by the handle oriented MSDOS(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 ffff option to send the ffffuuuullllllll relative

     pathname.  The source drive designator (A:, B:, etc.) is not


     Filename Considerations:

        o+ 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.

        o+ The receiver should accommodate file names in lower and

          upper case.

        o+ 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

Chapter 15              Rev091186 Typeset 9-11-86                       26

Chapter 15              Rev091186 Typeset 9-11-86                       27

          the transformations are unsuccessful, an file name should

          be invented be the receiving program.

     If directories are included, they are delimited by /; i.e.,

     "subdir/foo" is acceptable, "subdir\foo" is not.

LLLLeeeennnnggggtttthhhh 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.

     With ZMODEM, the 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.

MMMMooooddddiiiiffffiiiiccccaaaattttiiiioooonnnn DDDDaaaateeee A single space separates the modification date

     from the file length.

     The mod date is optional, and the filename and length may be

     sent without requiring the mod date to be sent.

     The mod date is sent as an octal number giving the time the

     ccccoooonnnntttteeeennnnttttssss of the file were last changed measuredconds from

     Jan 1 1970 Universal Coordinated Time (GMT).  A date of 0

     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.

     Two Microsoft blunders complicate the use of modification dates

     in file transfers with MSDOS(TM) systems.  The first is the

     lack of timezone standardization in MS-DOS.  A file's creation

     time can not be known unless the timezone of the system that

     wrote the file[2] is known.  Unix solved this problem (for

     planet Earth, anyway) by stamping files with Universal Time

     (GMT).  Microsoft would have to include the timezone of origin

     in the directory entries, but does not.  Professional-YAM gets

     around this problem by using the zzzz parameter which is set to

     the number of minutes local time lags GMT.  For files known to

     originate from a different timezone, the ----zzzzTTTT option may be used


 1. Fields may not be skipped.

 2. Not necessarily that of the transmitting system!

Chapter 15              Rev091186 Typeset 9-11-86                       27

Chapter 15              Rev091186 Typeset 9-11-86                       28

     to specify TTTT as the timezone for an individual file transfer.

     The second problem is the lack of a separate file creation date

     in DOS.  Since some backup schemes used with DOS rely on the

     file creation date to select files to be copied to the archive,

     back-dating the file modification date could interfere with the

     safety of the transferred files.  For this reason,

     Professional-YAM does not modify the date of received files

     with the header information unless the dddd parameter is non zero.

FFFFiiiilllleeee MMMMooooddddeeee A single space separates the file mode fro
     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 0.  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.

SSSSeeeerrrriiiiaaaallll NNNNuuuummmmbbbbeeeerrrr A single spaceates 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 0.  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 ttttwwwwoooo 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.


16.1  CCCCoooommmmppppaaaattttiiiibbbbiiiilllliiiittttyyyy

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 marked economy of reverse channel bandwith

allows modems that dynamically partition bandwidth between the two

directions to operate at optimal speeds.

16.2  TTTThhhhrrrroooouuuugggghhhhppppuuuutttt

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.

Chapter 16              Rev091186 Typeset 9-11-86                       28

Chapter 16              Rev091186 Typeset 9-11-86                       29

Recent tests downloading program images to an IBM PC (4.7 mHz V20)

running YAMK 15.68 with table driven CRC calculation yielded a

throughput of about 17kb on a 19.2 kb direct connection.

16.3  EEEErrrrrrrroooorrrr RRRReeeeccccoooovvvveeeerrrryyyy

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 channel delay, as 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.

In summation, ZMODEM performance in the presence of errors resembles

that of X.PC and SuperKermit.  Short bursts cause minimal data loss.

Long bursts (such as pulse dialing noises) often require a timeout

error to restore the flow of data.

Chapter 17              Rev091186 Typeset 9-11-86                       29

Chapter 17              Rev091186 Typeset 9-11-86                       30


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)

does 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 bbbbooootttthhhh

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


With PC-Pursuit, it is sufficient to set parameter 5 to 1 at both


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.

                   TTTTAAAABBBBLLLLEEEE 1111....  Flow Control Compatibility

         Connectivity            Interactive   XMODEM   KERMIT   ZMODEM

Direct Connection                YES           YES      YES      YES

Network, no flow control         NNNNOOOO            YES      (1)      (1)

Network, transparent f.c.        YES           YES      YES      YES

Network, semi-transparent f.c.   YES           NNNNOOOO       YES      YES

Network, 7 bit                   YES           NNNNOOOO       YES(2)   NO(3)

(1) Cannot operate in streaming mode.  Kermit is very slow because

of 96 byte max packet size.  ZMODEM can optimize burst length for

fastest transfers.

(2) Parity bits must be encoded, slowing binary transfers.

(3) Protocol extension possible for encoding data to 7 bits.

Chapter 18              Rev091186 Typeset 9-11-86                       30

Chapter 18              Rev091186 Typeset 9-11-86                       31


"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 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.

For comparison, a straight "dump" of the file contents with no file

management or error checking takes 853 seconds.

                 TTTTAAAABBBBLLLLEEEE 2222....  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

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

Chapter 18              Rev091186 Typeset 9-11-86                       31

Chapter 18              Rev091186 Typeset 9-11-86                       32

                 FFFFiiiigggguuuurrrreeee 4444....  Transmission Time Compar           (102400 byte binary file, 5 Second Round Trip)

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

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

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

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

******* ZMODEM Full Streaming

******* YMODEM-G

        TTTTAAAABBBBLLLLEEEE 3333....  Local Timesharing Computer Download Perfe

    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%

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 multiuser mode but otherwise idle.

Transfer times to PC hard disk and floppy disk destinations are


C-Kermit 4.2(030) used server mode and file compression, sending to

Pro-YAM 15.52 using 0 delay and a "get phones.t" command.

Crosstalk 3.6 used XMODEM 8 bit checksum (CRC not available) and an

"ESC rx phones.t" command.  The Crosstalk time does nnnnooootttt include the

time needed to enter the extra commands not needed by Kermit and


Professional-YAM used ZMODEM AutoDownload.  ZMODEM times included a

security challenge of the sending program.

Chapter 18              Rev091186 Typeset 9-11-86                       32

Chapter 18              Rev091186 Typeset 9-11-86                       33

                       TTTTAAAABBBBLLLLEEEE 4444....  Protocol Checklist

Item                  FAST   XMODEM  WXM   YMDM-k  YMDM-g  ZMODEM  SKermit

IIIINNNN SSSSEEEERRRRVVVVIIIICCCCEEEE            NNNNOOOO     1979 NNOOOO    1982    1985    1986    1985


User Friendly I/F     -      -       -     -       -       YES     -

Commands/batch        2      2*N     2*N   2       2       1       1(1)

Commands/file         0      2       2     0       0       0       0

Command Download      -      -       -     -       -       YES     YES(6)

Menu Compatible       -      -       -     -       -       YES     -

Transfer Recovery     -      -       -     -       -       YES     -

File Management       -      -       -     -       -       YES     -

Security Check        -      -       -     -       -       YES     -

X/YMODEM Fallback     -      YES     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)  -


Reliability(5)        FAIL   fair    ???   fair    FAIL    HIGH    HIGH

Streaming             YES    -       YES   -       YES     YES     YES

Overhead(2)           0%     7%      7%    1%      1%      1%      30%

Faithful Xfers        YES    -       -     YES(3)  YES(3)  YES     YES

Preserve Date         NO(7)  -       -     YES     YES     YES     -


CRC-16                REQD   -       REQD  REQD    REQD    REQD    opt

32 bit math           REQD   -       -     (3)     (3)     REQD    -

No-Wait Sample        -      -       REQD  -       -       opt     REQD

Ring Buffers          -      -       REQD  -       -       opt     REQD

XMODEM Similar        NONE   YES     LOW   HIGH    HIGH    LOW     NONE

Complexity            MED    LOW(5)  MED   LOW(5)  LOW     MED     HIGH


Server Operation      -      -       -     -       -       YES(4)  YES

Multiple Threads      -      -       -     -       -       future  -


(1) Server mode only

(2) Character count, binary file, transparent channel

(3) 32 bit math needed for accurate transfer (no garbage added)

(4) AutoDownload operation

(5) X/YMODEM Reliability enhancemnets greatly add to complexity

(6) Server commands only

(7) No provision for transfers across time zones

Chapter 18              Rev091186 Typeset 9-11-86                       33

Chapter 18              Rev091186 Typeset 9-11-86                       34

(8) Future enhancement provided for

(9) With Segmented Streaming

WXM: XMODEM derivative with data encoding and Windowing

FAST: File transfer protocol requiring end-to-end 8-bit transparent,

error free communications.


Future extensions include:

   o+ Compatibility with 7 bit networks

   o+ Server/Link Level operation: An END-TO-END error corrected

     program to program session is required for financial and other

     sensitive applications.

   o+ 32 bit CRC: for sensitive applications

   o+ Multiple independent threads

   o+ Encryption

   o+ Compression

   o+ File Comparision

   o+ Selective transfer within a file (e.g., modified segments of a

     database file).


9-11-86:  ZMPROT file management option added.  8-20-86:  More

performance data included.  8-4-86:  ASCII DLE (Ctrl-P, 020) now

escaped; compatible with previous versions.  More document revisions

for clarity.

7-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.

Chapter 21              Rev091186 Typeset 9-11-86                       34

Chapter 21              Rev091186 Typeset 9-11-86                       35


More information may be obtained by calling TeleGodzilla at


UUCP sites can obtain the nroff/troff source to this file with

          uucp omen!/usr/caf/public/zmodem/zmodem.mm /tmp

A continually updated list of available files is stored in


The following L.sys line allows UUCP to call site "omen" via Omen's

bulletin board system "TeleGodzilla".  TeleGodzilla uses Pro-YAM in

host operation.

In response to TeleGodzilla's "Name Please:" uucico gives the

Pro-YAM "link" command as a user name.  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 logs in as uucp.

omen Any ACU 1200 1-503-621-3746 e:--e: link d: Giznoid n:--n: uucp


A copy of this document, a demonstration version of

Professional-YAM, a flash-up tree structured help file and

processor, are available in _Z_M_O_D_E_M._A_R_C on TeleGodzilla.  This file

must be unpacked with _A_R_C-_E._C_O_M compatible with ARC5x files.  _A_R_C-

_E._C_O_M is also available on TeleGodzilla.

Source code and manual pages for UNIX programs are available on

TeleGodzilla in _R_Z_S_Z_1._S_H_Q and _R_Z_S_Z_2._S_H_Q, squeezed "shell archives".

To use these files, unsqueeze them with YAMDEMO's "usq" command,

upload them to Unix, and then execute them as shell scripts to break

them into the program and documentation source files.  More detailed

instructions may be found in Chapter 8 of the Professional-YAM

User's manual.  Most Unix like systems are supported, including V7,

Sys III, 4.x BSD, SYS V, Idris, Coherent, and Regulus.

22.1  AAAAddddddddiiiinnnngggg ZZZZMMMMOOOODDDDEEEEMMMM tttto DDDDOOOOSSSS PPPPrrrrooooggggrrrraaaammmmssss

DOS programs such as bulletin boards may call YAMDEMO.EXE with the

DOS EXEC function to support fast, reliable ZMODEM file transfers.

This method allows program developers to add ZMODEM support with a

minimum of software development at the expense of higher memory

Chapter 22              Rev091186 Typeset 9-11-86                       35

Chapter 22              Rev091186 Typeset 9-11-86                       36

utilization than built-in routines.

YAMDEMO.EXE beginning with Version 15.61 include an _x_m_o_d_e_m command

which performs the following functions:

 o+ Sets _r_e_s_t_r_i_c_t_e_d opertaion, restricting pathnames and disallowing

   modification of existing files

 o+ Causes error messages to be sent to the modem

 o+ Forces an exit after the command is finished

When YAMDEMO.EXE is used in this way, the default setup file

DEMOPHON.T should be overriden with the DOS environment variable


                      set PHONES=C:/newphone.t

where newphone.t contains

setup              return

(other commands may be added as necessary).

If a comm port other than COM1 is used, the DPORT environment

variable should be set:

                            set DPORT=2

The Online help processor included in ZMODEM.ARC and the

Professional-YAM User's Manual contain other useful information that

applies to YAMDEMO.EXE.

YAMDEMO.EXE unmodified may be copied and used without licensing or

other liability.  Omen Technology requests that YAMDEMO.EXE be

distributed only in conjunction with all the files included in

ZMODEM.ARC, as distributed by Omen, with no files deleted.


Unix programs supporting the YMODEM protocol are available on

TeleGodzilla in the "upgrade" subdirectory as RBSB.SHQ (a SQueezed

shell archive).  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


Irv Hoff has added YMODEM 1k packets and YMODEM batch 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 and MEX-PC also support some of

Chapter 23              Rev091186 Typeset 9-11-86                       36

Chapter 23              Rev091186 Typeset 9-11-86                       37

the YMODEM extensions.

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

                                  Yours very truly,

Chapter 23              Rev091186 Typeset 9-11-86                       37


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

 2.  EVOLUTION OF ZMODEM..............................................   2

 3.  ACKNOWLEDGMENTS..................................................   4

 4.  RELATED DOCUMENTS................................................   4

 5.  ROSETTA STONE....................................................   4

 6.  WHY DEVELOP ZMODEM?..............................................   5

 7.  ZMODEM Protocol Design Criteria..................................   7

     7.1    Ease of Use...............................................   7

     7.2    Throughput................................................   7

     7.3    Integrity and Robustness..................................   8

     7.4    Ease of Implementation....................................   8

 8.  ZMODEM REQUIREMENTS..............................................   9

     8.1    File Contents.............................................   9

 9.  ZMODEM BASICS....................................................  10

     9.1    Packetization.............................................  10

     9.2    Link Escape Encoding......................................  10

     9.3    Header....................................................  11

     9.4    Binary Data Subpackets....................................  13

     9.5    ASCII Encoded Data Subpacket..............................  14

10.  PROTOCOL TRANSACTION OVERVIEW....................................  14

     10.1   Session Startup...........................................  14

     10.2   File Transmission.........................................  15

     10.3   Session Cleanup...........................................  17

     10.4   Session Cancel Sequence...................................  17

11.  STREAMING TECHNIQUES / ERROR RECOVERY............................  18

     11.1   Full Streaming with Sampling..............................  18

     11.2   Full Streaming with Reverse Interrupt.....................  19

     11.3   Full Streaming with a Sliding Window......................  19

     11.4   Full Streaming over Error Free Channels...................  19

     11.5   Segmented Streaming.......................................  20

12.  ATTENTION SEQUENCE...............................................  20

13.  FRAME TYPES......................................................  20

     13.1   ZRQINIT...................................................  21

     13.2   ZRINIT....................................................  21

     13.3   ZSINIT....................................................  21

     13.4   ZACK......................................................  21

                                  - i -

     13.5   ZFILE.....................................................  21

     13.6   ZSKIP.....................................................  23

     13.7   ZNAK......................................................  23

     13.8   ZABORT....................................................  23

     13.9   ZFIN......................................................  23

     13.10  ZRPOS.....................................................  23

     13.11  ZDATA.....................................................  24

     13.12  ZEOF......................................................  24

     13.13  ZFERR.....................................................  24

     13.14  ZCRC......................................................  24

     13.15  ZCHALLENGE................................................  24

     13.16  ZCOMPL....................................................  24

     13.17  ZCAN......................................................  24

     13.18  ZFREECNT..................................................  24

     13.19  ZCOMMAND..................................................  24

14.  SESSION TRANSACTION EXAMPLES.....................................  25

     14.1   A simple file transfer....................................  25

     14.2   Challenge and Command Download............................  26

15.  ZFILE FRAME FILE INFORMATION.....................................  26

16.  PERFORMANCE RESULTS..............................................  28

     16.1   Compatibility.............................................  28

     16.2   Throughput................................................  28

     16.3   Error Recovery............................................  29

17.  PACKET SWITCHED NETWORK CONSIDERATIONS...........................  30

18.  PERFORMANCE COMPARISON TABLES....................................  31

19.  FUTURE EXTENSIONS................................................  34

20.  REVISIONS........................................................  34

21.  MORE INFORMATION.................................................  35

22.  ZMODEM PROGRAMS..................................................  35

     22.1   Adding ZMODEM to DOS Programs.............................  35

23.  YMODEM PROGRAMS..................................................  36

                                  - ii -

                             LIST OF FIGURES

Figure 1.  Order of Bytes in Header...................................  12

Figure 2.  Binary Header..............................................  12

Figure 3.  HEX Header.................................................  13

Figure 4.  Transmission Time Comparison...............................  32

                                 - iii -

                              LIST OF TABLES

TABLE 1.  Flow Control Compatibility..................................  30

TABLE 2.  Protocol Overhead Information...............................  31

TABLE 3.  Local Timesharing Computer Download Performance.............  32

TABLE 4.  Protocol Checklist..........................................  33

                                  - iv -

     The ZMODEM Asynchronous Inter Application File Transfer Protocol

                              Chuck Forsberg

                           Omen Technology Inc


The ZMODEM file transfer protocol greatly simplifies file transfers

compared to XMODEM.  In addition to allowing a friendly user interface,

ZMODEM provides Personal Computer and other users an efficient, accurate,

robust file transfer method.

ZMODEM provides efficient file transfers with timesharing systems,

satellite relays, and wide area packet switched networks.

ZMODEM provides advanced file management features including AutoDownload

(Automatic file Download initiated without user intervention), aborted

transfer recovery, selective file transfers, and security verified command


ZMODEM is carefully designed to provide these benefits using a minimum of

new technology beyond XMODEM/CRC.

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 primitive XMODEM routines,

actual C source code for working ZMODEM programs allows developers to

provide solid, reliable ZMODEM implementations with minimum effort.

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH