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 OptionIf the receiver	does not implement the particular transportoption,	the file is copied without conversion for laterprocessing.ZTLZW Lempel-Ziv 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.ZTCRYPT	Encryption.  An	initial	null terminated	string     identifies	the key.  Details to be	determined.Chapter	11		Rev 8-3-87  Typeset 8-4-87			27Chapter	11		     ZMODEM Protocol				28ZTRLE 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	laterchapter.11.5.4	ZF3: Extended OptionsThe 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  ZSKIPSent by	the receiver in	response to ZFILE, makes the sender skip tothe next file.11.7  ZNAKIndicates last header was garbled.  (See also ZRPOS).11.8  ZABORTSent by	receiver to terminate batch file transfers when	requested bythe user.  Sender responds with	a ZFIN sequence.[2]11.9  ZFINSent by	sending	program	to terminate a ZMODEM session.	Receiverresponds with its own ZFIN.11.10  ZRPOSSent by	receiver to force file transfer	to resume at file offsetgiven in ZP0...ZP3.__________ 2. Or ZCOMPL in case of server	mode.Chapter	11		Rev 8-3-87  Typeset 8-4-87			28Chapter	11		     ZMODEM Protocol				2911.11  ZDATAZP0...ZP3 contain file offset.	One or more data subpackets follow.11.12  ZEOFSender reports End of File.  ZP0...ZP3 contain the ending fileoffset.11.13  ZFERRError in reading or writing file, protocol equivalent to ZABORT.11.14  ZCRCRequest	(receiver) and response	(sender) for file polynomial.ZP0...ZP3 contain file polynomial.11.15  ZCHALLENGERequest	sender to echo a random	number in ZP0...ZP3 in a ZACK frame.Sent by	the receiving program to the sending program to	verify thatit is connected	to an operating	program, and was not activated byspurious data or a Trojan Horse	message.11.16  ZCOMPLRequest	now completed.11.17  ZCANThis is	a pseudo frame type returned by	gethdr() in response to	aSession	Abort sequence.11.18  ZFREECNTSending	program	requests a ZACK	frame with ZP0...ZP3 containing	thenumber of free bytes on	the current file system.  A value of 0represents an indefinite amount	of free	space.11.19  ZCOMMANDZCOMMAND is sent in a binary frame.  ZF0 contains 0 or ZCACK1 (seebelow).A ZCRCW	data subpacket follows,	with the ASCII text command stringterminated with	a NULL character.  If the command is intended to beexecuted 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 applicationprogram	which receives the command.Chapter	11		Rev 8-3-87  Typeset 8-4-87			29Chapter	11		     ZMODEM Protocol				30If the receiver	detects	an illegal or badly formed command, thereceiver immediately responds with a ZCOMPL header with	an errorcode in	ZP0...ZP3.If ZF0 contained ZCACK1, the receiver immediately responds with	aZCOMPL header with 0 status.Otherwise, the receiver	responds with a	ZCOMPL header when theoperation is completed.	 The exit status of the	completed command isstored in ZP0...ZP3.  A	0 exit status implies nominal completion ofthe command.If the command causes a	file to	be transmitted,	the command senderwill see a ZRQINIT frame from the other	computer attempting to senddata.The sender examines ZF0	of the received	ZRQINIT	header to verify itis not an echo of its own ZRQINIT header.  It is illegal for thesending	program	to command the receiving program to send a command.If the receiver	program	does not implement command downloading,	itmay display the	command	to the standard	error output, then return aZCOMPL header.12.  SESSION TRANSACTION EXAMPLES12.1  A	simple file transferA simple transaction, one file,	no errors, no CHALLENGE, overlappedI/O:Sender	       Receiver"rz\r"ZRQINIT(0)	       ZRINITZFILE	       ZRPOSZDATA data ...ZEOF	       ZRINITZFIN	       ZFINOOChapter	12		Rev 8-3-87  Typeset 8-4-87			30Chapter	12		     ZMODEM Protocol				3112.2  Challenge	and Command DownloadSender		    Receiver"rz\r"ZRQINIT(ZCOMMAND)		    ZCHALLENGE(random-number)ZACK(same-number)		    ZRINITZCOMMAND, ZDATA		    (Performs Command)		    ZCOMPLZFIN		    ZFINOO13.  ZFILE FRAME FILE INFORMATIONZMODEM sends the same file information with the	ZFILE frame datathat YMODEM Batch sends	in its block 0.N.B.: 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 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 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.	+ 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	mayChapter	13		Rev 8-3-87  Typeset 8-4-87			31Chapter	13		     ZMODEM Protocol				32	  be invented be 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 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     contents of the file were last changed measured in	seconds	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.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 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.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__________ 1. Fields may not be skipped.Chapter	13		Rev 8-3-87  Typeset 8-4-87			32Chapter	13		     ZMODEM Protocol				33     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 pathnameis sent, the pathname is terminated with two nulls.  The length	ofthe file information subpacket,	including the trailing null, mustnot exceed 1024	bytes; a typical length	is less	than 64	bytes.14.  PERFORMANCE RESULTS14.1  CompatibilityExtensive testing has demonstrated ZMODEM to be	compatible withsatellite links, packet	switched networks, microcomputers,minicomputers, regular and error correcting buffered modems at 75 to19200 bps.  ZMODEM's economy of	reverse	channel	bandwidth allowsmodems that dynamically	partition bandwidth between the	twodirections to operate at optimal speeds.14.2  ThroughputBetween	two single task	PC-XT computers	sending	a program image	onan in house Telenet link, SuperKermit provided 72 ch/sec throughputat 1200	baud.  YMODEM-k	yielded	85 chars/sec, and ZMODEM provided113 chars/sec.	XMODEM was not measured, but would have	been muchslower based on	observed network propagation delays.Recent tests downloading large binary files to an IBM PC (4.7 mHzV20) running YAMK 16.30	with table driven 32 bit CRC calculationyielded	a throughput of	1870 cps on a 19200 bps	direct connection.Tests with TELEBIT TrailBlazer modems have shown transfer ratesapproaching 1400 characters per	second for long	files.	When filesare compressed,	effective transfer rates of 2000 characters persecond are possible.14.3  Error RecoverySome tests of ZMODEM protocol error recovery performance have beenmade.  A PC-AT with SCO	SYS V Xenix or DOS 3.1 was connected to	a PCwith DOS 2.1 either directly at	9600 bps or with unbuffered dial-up1200 bps modems.  The ZMODEM software was configured to	use 1024byte data subpacket lengths above 2400 bps, 256	otherwise.Because	no time	delays are necessary in	normal file transfers, perfile negotiations are much faster than with YMODEM, the	onlyobserved delay being the time required by the program(s) to updatelogging	files.Chapter	14		Rev 8-3-87  Typeset 8-4-87			33Chapter	14		     ZMODEM Protocol				34During a file transfer,	a short	line hit seen by the receiverusually	induces	a CRC error.  The interrupt sequence is	usually	seenby the sender before the next data subpacket is	completely sent, andthe resultant loss of data throughput averages about half a datasubpacket per line hit.	 At 1200 bps this is would be about .75second lost per	hit.  At 10-5 error rate, this would degradethroughput by about 9 per cent.The throughput degradation increases with increasing channel delay,as more	data subpackets	in transit through