CHAPTER 9 FILE TRANSFER The transfer mode lets you send text from your buffer or the contents of a disk file to another system. Several types of file transfers are supported by MODEM MGR. 1) The non-protocol transfer method will send text from one system to another without error detection or correction. There are several pacing (throttle) options provided for this type of transfer. 2) The universal XMODEM protocol transfer will send or receive disk files with error detection and correction. 3) A special MMGR protocol transfer will send or receive any type of DOS 3.3 or ProDOS disk file with error detection and correction. The MMGR protocol transfer also handles random-access files efficiently. 4) In the ProDOS version, an additional protocol transfer module may be installed. This is discussed later in this chapter. To perform l), 2), or 3), you must switch from the terminal command mode to the transfer mode. A summary of the commands to enter or exit the transfer mode is shown below. TERMINAL ---Y---> TRANSFER MODE <--- Q--- MODE <---*--- *Automatic quit after non-protocol send Use the Y command to enter the transfer mode from the terminal command mode. After a few seconds of disk activity, you will be in the transfer mode and the following prompt will be displayed: Xfer command? --> You may return to the terminal mode by entering Q (for Quit). The program will also return automatically to the terminal mode after a file has been sent with a non-protocol method. If this occurs, any text on the screen will not be cleared. In the DOS 3.3 version, your work disk must be in the same drive that the program was started in. If it is not in the same drive, the transfer module will not be found and the program will attempt to return to the terminal mode. If your work disk is not in the same drive, the terminal program will not be found either and the program will halt. An error message will prompt you to insert your work disk in the drive and press any key to re-start the program. After you return to the terminal mode with your work disk in the proper disk drive, you can try to enter the transfer mode again with the Y command. If you will be using a protocol transfer, the format of the data being sent or received must have 8 data bits. Set the proper data word length and baud rate while you are in the terminal mode before you enter the transfer mode. If you are transferring to or from an unattended remote system, you will have to issue the proper commands to initiate the transmitting and receiving at both ends. For example, if you are transmitting a file to a remote system, you must issue the appropriate receive commands to the remote system followed by the appropriate transmit commands for your system. If you are online with another individual user, he will enter the commands for his system while you are only responsible for issuing the commands for your system. While you are in the transfer mode, you will not be able to send characters from your keyboard. You can only transmit the contents of one of your disk files or text from your buffer. Anything received while you are in the transfer mode will not be displayed unless you have initiated a non-protocol transmission. Therefore, you should complete all commands (if online with an unattended system) or message exchanges in the terminal mode before you enter the transfer mode. The contents of the capture buffer will remain unchanged when you enter the transfer mode. However, any protocol file transfer will use the buffer for block storage. If you send or receive a disk file using the XMODEM or MMGR protocol, the buffer will be cleared. A warning will be displayed if there is text in the buffer and you enter a protocol transfer command. Enter [ESC] to cancel the command. This paragraph applies if you have enabled the capture buffer and are in the transfer mode. If you transmit text from the capture buffer, the capture of received text into the buffer will be inhibited. Thisw ill prevent changes to your buffer if the receiving system is echoing your text back to you. If you transmit text from a disk file using the non-protocol method, any received echoed text will be captured. If you are transmitting a disk file with XON/XOFF pacing, received control-S and control-Q characters will not be captured. You cannot save the contents of the capture buffer to disk while you are transmitting a disk text file. If the buffer becomes full, a message will be displayed and the buffer will be turned off. The buffer will not be saved automatically to disk and you will not be prompted to save the contents to disk. You may save the buffer to disk after the disk transmission is completed. Figure 9-1 shows a menu of commands in the transfer mode. You can display this menu in the transfer mode by entering a ? whenever the transfer command prompt is displayed. FILE TRANSFER ~~~~~~~~~~~~~ C: Clear buffer D: Disk functions F: Full/half duplex I: Insert auto LF L: Look at status Q: Quit R: Restore buffer T: Timeout N: Normal pace V:Normal-Screen off S: Slow pace X:XON/XOFF pace E: Wait for echo P:Wait for prompt Z: Pause after line 1: Send MMGR file 2: Rcv MMGR file 3: Send XMODEM file 4: Rcv XMODEM file 5: Rcv XMODEM (mod) 6: Send AE XMODEM* 7: Rcv AE XMODEM* *DOS 3.3 version only Figure 9-l. Transfer Mode Menu The C, D, F, I, L, and R commands at the top of the transfer mode menu are the same as those used in the terminal mode and will not be described again. You can use the Q command to exit the transfer mode and re turn to the terminal mode. The T command lets you toggle the timeout value between NORMAL and NONE. For most protocol transfers, use the NORMAL timeout. If sparse random-access files are being transferred, the timeout may have to be inhibited so toggle the NONE option. SEND TEXT FILES (NON-PROTOCOL MODE) You can use the non-protocol mode to transmit text files from your capture buffer or from one of your disk files. This method does not use error detection or correction. It simply sends the contents of your buffer or disk file from the beginning to the end. If transmission noise corrupts some of the characters transmitted, they will appear as uncorrected errors at the receiving end. There are several different options available with non-protocol text transmissions. These options are listed in the transfer mode menu as N, V, S, X, E, P, and Z. These options will be described later. After you enter an option, you will have to specify whether to send text from your buffer or from a disk file. Enter B (for Buffer) or D (for Disk). If you enter D, you will have to enter the filename or pathname of the disk file you wish to send. If the file is not on the currently active disk drive or volume, you may enter a comma followed by D# and/or S# to specify another drive and/or slot. If you are planning to send a disk text file, you may load the file from the disk into your buffer and send it from the buffer instead of transmitting it directly from the disk. This avoids online pauses while the disk reads the next sector or block and reduces the transmission time. You can load the file from the disk into your buffer without exiting the transfer mode. If you are in full-duplex and the receiving system is not echoing your characters, you will not see the transmitted text on your screen. Switch to half-duplex to see the text being sent. When the text transmission is completed, the program will automatically return to the terminal mode. If you want to terminate a transmission while it is in progress, type [ESC]. You can use the I command to enable or disable the sending of a line feed character automatically after each transmitted CR character. If the receiving system requires line feeds, toggle the line feed on. The following is a description of all of the options associated with non-protocol text transmission. N: NORMAL PACE The N option will provide file transmission without speed pacing or handshaking . The file characters will be sent as quickly as possible (but not faster than the hardware baud rate). If the receiving system is echoing your transmission back to you, it will be displayed on your video screen. If your video device cannot keep up with the baud rate in use, your sending rate will be reduced. For example, if your video device can only maintain an effective display speed of 1000 char/sec and your communications hardware is set to 19200 baud (about 1920 char/sec), your actual sending rate will be held to less than 1000 char/sec. V: NORMAL-SCREEN OFF The V option is similar to the N option discussed above except your video screen will be disabled during the transmission. If the receiving system is echoing your transmission back to you, it will not be displayed on your screen. If your video display is limiting your transmission rate, you may use this option to transmit at the maximum rate (your hardware baud rate). S: SLOW PACE The S option transmits text at reduced speed. This accommodates other receiving systems which cannot handle transmissions at the actual hardware baud rate. Your sending rate can be controlled during transmission by depressing a number key from [I] (slow) to [9] (fast). The initial rate is set at a medium speed (equivalent to [5]). X: XON/ XOFF PACE The X option provides text transmission with XON/ XOFF handshaking. If the receiving system sends a control-S (XOFF), your system will stop sending until the receiving system sends a control-Q (XON). If the receiving system has XON/ XOFF handshake capability, it can use this feature to control the pace of your transmissions. E: WAIT FOR ECHO You can use the E option with any receiving system which echoes your transmission back to you, If you select this transmitting option, your file will be sent one character at a time. After each character is sent, your system will wait for that character to be echoed back before the next character is sent. Although this does provide some form of error checking, it is not a reliable error detector because it allows (ignores) characters added by noise. It does not perform any error correction either. This method is used primarily to pace your transmission speed to the capabilities of the receiving system. P: WAIT FOR PROMPT Some receiving systems will send a prompt character or string when they are ready to receive a new line of text from your system. The P option allows you to define a prompt string with a length of 1 to 16 characters. If you just enter [RETURN], the CR character will be used as the prompt character. All other control characters except escape, control-H or control-J may be used in the string. After each line in the text is transmitted, your system will wait for the prompt character or string from the other system before sending the next line of text. If you are sending text through a communications system which delays the echoing of your text, be sure the prompt character or string does not appear in your transmitted text or it may initiate the sending of the next line when it is echoed. You may wish to format your transmitted text to something less than the full screen width so your text will not be wrapped around when the prompt and echoed text are displayed on the same line. For example, if you have an 80-column screen and the prompt string is 4 characters long, you can format your text to less than 76 characters before sending it. Z: PAUSE AFTER LINE The Z option is another pacing control for use with slow receiving systems which cannot handle a continuous flow of text at the hardware baud rate. If you use the Z command, your system will pause after sending each line of text. The pause length can be controlled during tran smission by depressing a number key from [1] (slow) to [9] (fast). The initial rate is set at a medium pause length (equivalent to [5]). You may also use this method for manual line pacing. Set the pause length to the slowest ([1]). Press the space key whenever you want a line transmitted. PROTOCOL SEND/ RECEIVE FILES Protocol file transfers will let you transfer disk files accurately to or from another system with error detection and correction. MODEM MGR supports several types of protocol file transfers. MODEM MGR supports the popular XMODEM transfer protocol. This protocol was developed by Ward Christensen and others and is used in many communications software packages and remote systems which provide download capability of public domain programs. You can transfer files with most of these systems using XMODEM. MODEM MGR also supports a special MMGR protocol which provides protocol transfers between MMGR users having the same operating system (DOS 3.3 or ProDOS). The major differences between this special protocol and the XMODEM protocol are summarized below. 1) The XMODEM protocol uses I28 bytes per transmitted block, while the MMGR protocol uses 256 (DOS 3.3) or 512 (ProDOS) bytes per block. 2) The MMGR protocol uses CRC error checking, while this program's version of XMODEM uses a checksum or CRC. 3) The MMGR protocol can truncate DOS 3.3 files so assigned but unused sectors at the end of a file are not transmitted. 4) The MMGR protocol does not transmit unused blocks in random-access text files. This provides minimum transmission time and efficient disk storage. 5) The MMGR protocol automatically sets the proper DOS 3.3 or ProDOS file type at the receiving system, while XMODEM does not. 6) XMODEM blocks are numbered starting at block 1, while the MMGR blocks start at 0. 7) XMODEM blocks must be sent sequentially, while blocks can be sent in any order with MMGR. 8) XMODEM does not allow missing blocks, while MMGR allows purposely skipped blocks. (However, blocks missed by transmission errors are detected). 9) XMODEM can transfer files between different operating systems, but MMGR allows DOS 3.3 to DOS 3.3 or ProDOS to ProDOS only. MODEM MGR also supports other protocol file transfers through the use of modules. This is described later in this chapter. TRUNCATED FILES Some disk files have more sectors or blocks assigned on the disk than necessary . This occurs sometimes when a long file on a disk is replaced with a shorter file having the same name. The same number of sectors or blocks allocated to the long file will be allocated to the shorter file although some sectors or blocks at the end of the file will not contain any data associated with the new file. If you transmit a DOS 3.3 file with the MMGR protocol, only those DOS 3.3 sectors which contain data associated with that file will be transmitted. Any remaining unused sectors will not be transferred. This reduces the transfer time and the disk space used by the received file. This is done automatically unless the file is a text file. If the DOS 3.3 text file is a sequential-access text file, you must identify it as such in order to obtain file truncation. If you identify it as a random-access text file, the file will not be truncated when it is transmitted. Whenever you save your buffer to disk, it is saved as a sequential-access text file. Most DOS 3.3 word processor text files are also sequential text files. If you specify a DOS 3.3 random-access text file as being sequential, some or all of the file might not be transferred. If you specify a DOS 3.3 sequential-access file as being random, it will be transferred ok (possibly with some extra sectors). If you are in doubt as to the type of DOS 3.3 text file, enter R (for Random), or enter [RETURN] to default to random-access. MODEM MGR truncates all ProDOS sequential text files when they are written to disk from the capture buffer. It will be assumed that most other programs which write ProDOS sequential text files will also truncate them. Therefore, this program will transmit ProDOS files as is. If you wish to truncate a ProDOS text file, load it into the text buffer, use the editor to delete at least one character, and write it back to disk with the same pathname. 1: SEND MMGR FILE Enter the 1 command to send a file using the MMGR protocol. The other system you are communicating with should be running the MODEM MGR program with the same operating system. Since DOS 3.3 and ProDOS disk files have a different format, you cannot use the MMGR protocol to transfer files between DOS 3.3 and ProDOS operating systems. If you must transfer files between a DOS 3.3 user and a ProDOS user, try the XMODEM protocol instead. When you enter the 1 command to send the file, the other user should enter the 2 command to receive the file using the same protocol. After the command is entered, the filename or pathname will be requested of both users. The file should be on the currently logged drive or current prefix or you may enter a comma followed by D# or S# after the filename to specify another drive or slot. If the file exists, the file type will be displayed. If it is a DOS 3.3 text file, the program will ask you whether it is a random or sequential text file. If you don't know what type of text file it is, just enter a [RETURN] or R (for Random). You will then see the following message: ^X to cancel Waiting for NAK Your system will now wait for a NAK character from the receiving system to show it is ready to receive. However, before it sends a NAK, the receiving system must know the file type of the file you are going to transmit. The file type will be sent automatically from your system to the receiving system. You may see a few periods (dots) on your screen while this is being accomplished. After the file type is received, the receiving system will send a NAK and the file transfer will commence. If you do not receive a NAK within 80 seconds, the transfer will be cancelled. If everything has proceeded correctly, you will then see the following on your video screen and your disk drive will read data from the file to be transmitted. Received NAK Sending 0000 The 0000 means block 0 will be transmitted next. If a DOS 3.3 random-access file is being transmitted, the first block may be something else besides 0000. As additional blocks are sent, you will see their block numbers displayed as hexadecimal numbers. The first block must be transmitted within 20 seconds after receipt of the initial NAK or the receiving system will time out and quit. If you are sending a random-access file, the blocks which do not contain data will not be sent. If you are sending a sparse random-access file, there may be a long period of disk activity before any blocks are sent at all. As each block is successfully received, the receiving system will send an ACK character to request the next block. (You will not see the ACK displayed.) If an error occurs, the receiving system will send a NAK character and the same block will be retransmitted. When this occurs, you will see the same block number repeated on your display. If neither an ACK nor a NAK are received within 10 seconds, the same block will be re-transmitted. After 16 DOS 3.3 or eight ProDOS blocks (4096 bytes) are successfully transmitted, your disk drive will read an additional 4096 bytes. There will be a pause when your system is doing a disk read and when the receiving system is doing a disk save. If the receiving system is using MODEM MGR also, it will do a disk save every 4096 bytes. Both operations will probably occur consecutively (not simultaneously), so there may be a double pause after every 16 DOS 3.3 or 8 ProDOS blocks. After the file is successfully transferred, a FILE TRANSMITTED message will be displayed. If the communications link is noisy, a block may be re-transmitted several times before it is successfully received. If it takes more than eight tries, the transfer will be automatically terminated. You can also terminate the transfer by entering a control-X. You will see an I CANCELLED message on the screen. If you see a HE CANCELLED message, it means the transfer was cancelled by the other system. You cannot send any of the MODEM MGR main execution programs. These programs h ave names starting with the letters MDM (if DOS 3.3) or MDP (if ProDOS). 2: RECEIVE MMGR FILE Enter the 2 command to receive a file using the MMGR protocol. The other system you are communicating with should be running a MODEM MGR program under the same operating system as yours and the user there should enter the 1 command to send the file using the same protocol. After you enter the 2 command, you must furnish a filename or pathname. The name does not have to be the same as the name used by the sender's system. The file will be saved on the currently logged drive or you may enter a comma followed by D# or S# after the filename or pathname to specify another drive or slot. If you enter a file name which already exists, you will be asked whether you want to delete the existing file or not. Answer Y (for Yes) to delete it or N (for No) to retain it. If you enter N, you will be asked again for a filename or pathname. You must accomplish all of the above within 80 seconds after the sending system is ready or that system will time out and cancel the transfer. If this occurs, you may see a HE CANCELLED message. If the sender has set his system accordingly, his system will send the file type to your system so the file can be saved automatically as the same type. You may see a few periods (dots) on your video screen while this is happening. After the file type is received and displayed on your video screen, you will see the following message: ^X to cancel Sending NAK- Your system is now sending a NAK character to the sending system to signal you are ready to receive. It may take more than one transmission of the NAK character before the sending system starts to send the file. When this begins, you will probably see the following on your video screen: Receiving 0000 The 0000 means block 0 is being received. A DOS 3.3 random-access file may show a higher starting block number. As additional blocks are received, you will see their block numbers displayed in hexadecimal numbers. If your system does not receive the first block within 20 seconds after your first NAK was sent, your system will time out and cancel the transfer. As each block is successfully received, your system will send an ACK character to request the next block. If a header or CRC error occurs, your system will send a NAK character and the same block will be retran smitted. When re-transmission occurs, you will see the same block number repeated on your display. If a block transmission is interrupted longer than one second, your system will send a NAK for re-transmission. After 16 DOS 3.3 or eight ProDOS blocks are successfully transmitted, your disk drive will save the blocks. There will be a pause when your system is doing a disk save and when the sending system is doing a disk read. After the file is successfully transferred, you will see a FILE RECEIVED message. If the communications link is noisy, you may see some of the following error messages: MISSING BLOCK BAD HEADER BAD CHECKSUM A missing block error occurs if one of the transmitted blocks was not received correctly, but the sender received an erroneous acknowledgment and has sent the next block. When this error is detected, your receiving system will cancel the transfer operation. If a bad header or checksum error occurs, the block associated with the error will be NAKed until it is successfully received within eight retries. If it takes more than 8 tries, the transfer will be automatically cancelled. You can also terminate the transfer by entering a control-X. You will see an I CANCELLED message on your screen. If you see a HE CANCELLED message, it means the transfer was cancelled by the other system. 3: SEND XMODEM FILE Enter the 3 command to send a file using the XMODEM protocol. The other system you are communicating with should be running an XMODEM-compatible transfer program. If the receiving system is using MODEM MGR, the user there should enter command 4. If the receiving user is using a DOS 3.3 or ProDOS operating system, he should be told what type of file is being transferred so he can enter it when necessary. After you enter the 3 command, the filename or pathname will be requested. The file should be on the currently logged drive or prefix or you may enter a comma followed by S# or D# after the name to specify another slot or drive. When the file is found, the file type will be displayed. You will then see the following message: ^X to cancel Waiting for NAK Your system will wait up to 80 seconds for a NAK character from the receiving system to show it is ready to receive. If the NAK is not received within that time, your system will cancel the transfer. If the receiving system user has set his system properly, it will send a NAK and the file transfer will commence. You will then see one of the following on your video screen and your disk drive will read data from the file being transmitted. Received NAK CRC Requested Sending Sending 001 C001 The 001 means the first block will be transmitted. As additional blocks are sent, you will see their block numbers (002, 003, etc.) displayed in hexadecimal numbers. In the ProDOS version, the C may appear before the 001. This means the receiver sent a C instead of a NAK to request CRC instead of a checksum. CRC is discussed later i n this chapter. Your first block must be transmitted within 20 seconds after the receiving system sends its NAK. As each block is successfully received, the receiving system will send an ACK character to request the next block. (The ACK will not appear on your display). If a header or checksum error occurs, the receiving system will send a NAK character and your system will re-transmit the block which was not received correctly. When this occurs, you will see the same block number repeated on your display. After 32 blocks are successfully transmitted, your disk drive will read additional sectors. There will be a pause when your system is doing a disk read and when the receiving system is doing a disk save. If the receiving system is using MODEM MGR also, it will do a disk save every 32 blocks. Both operations will occur consecutively (not simultaneously), so there will be a double pause every 32 blocks. After the file is successfully transferred, you will see a FILE TRANSMITTED message. If the communications link is noisy, a block may be re-transmitted several times before it is successfully received. If it takes more than eight tries, the transfer will be automatically terminated. You can also terminate the transfer by entering a control-X. You will see an I CANCELLED message on the screen. If you see a HE CANCELLED message, it means the transfer was cancelled by the other system. You cannot send a DOS 3.3 file which has a name starting with the letters MDM and you cannot send a ProDOS file which has a name starting with the letters MDP. These letters are used for the MODEM MGR programs. 4: RECEIVE XMODEM FILE Enter the 4 command to receive a file using the XMODEM protocol. The other system you are communicating with should be running an XMODEM compatible program. If the other system is using MODEM MGR, the user there should enter the 3 command to send the file using the XMODEM protocol. After you enter the 4 command, you must enter the filename or pathname for your file to be saved on your disk. It does not have to be the same as the name used by the sender. The file will be saved on the currently logged drive or current prefix or you may enter a comma followed by S# or D# after the name to specify another slot or drive. You will then be asked to enter the filetype (XMODEM does not support the automatic sending of file type). For DOS 3.3, you may select A (Applesoft), B (Binary), I (Integer), or T (Text). For ProDOS you may select BAS, BIN, TXT, AWP, ADB, ASP, $F1, etc. If you enter an existing filename or pathname, you will be asked whether you want to delete the existing file or not. Answer Y (for Yes) to delete it or N (for No) to retain it. If you enter N, you will be asked again for the name and filetype. In the ProDOS version, you will then be asked if you want to send C to request CRC. CRC is discussed later in this chapter. If you are not sure, just enter [RETURN] or N (for No). You will then see one of the following messages: ^X to cancel ^X to cancel Sending NAK- Sending C- Your system is now transmitting a NAK (or C) character to the sending system to signal you are ready to receive. It may take more than one transmission of the NAK character before the sending system starts to send the file. When this begins, you will then see the following on your video screen: Receiving 001 The 001 means the first block is being received. As additional blocks are received, you will see their block numbers (002, 003, etc.) displayed in hexadecimal numbers. If a C appears before the 001, it means CRC is being used. As each block is successfully received, your system will send an ACK character to request the next block. If an error occurs, your system will send a NAK character and the same block will be retransmitted. When this occurs, you will see the same block number repeated on your video screen. After 32 blocks are successfully received, your system will save the 32 blocks to disk. There will be a pause when your system is doing a disk save and when the sending system is doing a disk read. After the file is successfully transferred, you will see a FILE RECEIVED message. If the communications link is noisy, you may see some of the following error messages: MISSING BLOCK BAD HEADER BAD CHECKSUM A missing block error will occur if you did not correctly receive one of the transmitted blocks, but the sender received an erroneous acknowledgment and has sent the next block. When this error is detected, your receiving system will cancel the transfer operation. This type of error message also appears if there are excessive delays during the block transmission. (See the next section on a modified XMODEM file transfer). If a bad header or checksum error occurs, your receiving system will send a negative acknowledge (NAK) signal and the same block will be re-transmitted until it is successfully received or the re-try count exceeds eight. If it takes more than eight tries, the transfer will be automatically terminated. You can also terminate the transfer by entering a control-X. You will see an I CANCELLED message on your screen. If you see a HE CANCELLED message, it means the transfer was cancelled by the other system. 5: RECEIVE XMODEM (MODIFIED) For efficient error detection, MODEM MGR interprets any pause of over one second during a block transmission as an error. Once a block transmission starts, this program expects to receive a continuous flow of data to the end of the block. This does not cause any problems when you are using XMODEM with another computer over direct telephone lines. However, many information systems are using phone networks which do not deliver data in a continuous flow. There are times when the network introduces long pauses in a transmission. If you are using XMODEM, you may see excessive block repeats or a termination of the transfer with a missing block error message. If you enter the 5 command, you can receive a file using a modified XMODEM protocol. This modified method allows a delay of up to approximately 16 seconds during a block reception. Multiple delays are allowed as long as any one delay does not exceed 16 seconds. Since the network characteristics vary as a function of the traffic level, it i s difficult to optimize the modification to fit all situations. You may find conditions where a protocol transfer cannot be performed. The longer allowable delays will also cause longer error detection and recovery times so do not use this option unless it is necessary. If you select the 5 command, the same description given for the 4 command applies. 6: RCV AE XMODEM 7: SEND AE XMODEM In the DOS 3.3 version, there are options to receive or send files with the AE XMODEM protocol. This protocol is supported by several bulletin boards which handle Apple programs. In the ProDOS version, AE XMODEM is supported in a separate module. The use of modules is discussed later in this chapter. TEXT GARBAGE Since the XMODEM protocol transfers disk files, it not only transfers the desired text in a text file, but it also transfers the residual bytes that fill the remainder of the disk sector or block at the end of the file. Normally the operating system determines the end of the text and ignores these trailing characters when a text disk file is read. However, with XMODEM you can transfer a text file from one type of operating system to another type of operating system which use s a different method to determine the end of the text. You may then see the undesired residual characters when the text disk file is read at the destination system. If the residual characters are a string of common end-of-file characters like 00 or control-Z characters, they will either not appear on the display at the destination system when the file is read or they may appear as ^@ or ^Z characters. However, if you have written text to an existing text file before sending it with XMODEM, the residual characters may consist of old text which is similar to the new text. When the destination system reads the transferred file, the residual text will appear at the end of the desired text. It may be difficult to determine where the desired text actually ends and some confusion may occur. If you have received a text file with XMODEM from a DOS 3.3 system to your ProD S system, use the editor to find the ^@ which marks the end of the text and delete all of the text following that character. If you have received a text file with XMODEM from a ProDOS system to your DOS 3.3 system, there is no problem as long as the ProDOS residual characters are all 00s. XMODEM COMPATIBILITY Although the XMODEM protocol has been documented, there are many systems and software packages which have modified versions of XMODEM which may not be compatible with this version (this can be considered another version, also). Some software versions have been designed for a maximum anticipated transfer rate of 1200 bps. At this slow bps rate these versions can write status messages on console screens during reception. However, with 19200 bps transfers, received characters will be missed while they are writing these messages. The MODEM MGR version of XMODEM adds some delays to accommodate these versions. Some XMODEM versions will wait only a few seconds for an ACK after sending a block. If your disk drives take a longer time to save the received blocks, the sending system will re-send the block while you are still doing a disk operation. Duplicate block repeats will be detected and ignored, but this will cause additional delays to get back in synchronization. If your receiving operation seems to falter after a disk save, the other system may need longer delays. MASTER CONTROL When transferring between two individual users, both the XMODEM and MMGR protocols rely on both the sending and receiving users to set the appropriate commands. Unless they are in the same room, it is difficult for one user to determine if the other user has entered the proper commands and is ready for the file transfer or is still trying to figure out which commands to enter. It may be simpler if one user enters the unattended mode (described in Chapter 10). One user can call the unattended system and perform all of the commands to accomplish a XMODEM or MMGR protocol transfer. The advantage of this is one person is in control of both systems and can enter all of the commands for sending and receiving without relying on the other user. SPARSE RANDOM-ACCESS FILES Random-access files do not always have data written in all of the file records. If any one of the disk blocks in a file is composed entirely of records which have never been written, that block does not exist on the disk. Since an applications program has not written data anywhere in the block, there is no reason to use up disk space for it. As an extreme example, suppose a ProDOS random-access file has a record size of 256 bytes and the allowable record numbers range from 0 to 65,535. If you have written data only to record 1 and record 65,534, the blocks containing records 1 and 65,534 are saved to disk, but the blocks containing records 2 through 65,533 have never been saved to disk. Although the file size is over 16,776,704 bytes (over 16 Megabytes), there are only two disk blocks allocated with data (plus an additional three index blocks for a total of five disk blocks). If you want to transfer this file, there is no point in wasting time transferring the disk blocks with non-existent records 2 through 65,533. The only blocks which have to be transferred are the blocks with records 1 and 65,534. If you transmitted all 65,536 existent and non-existent records at 1200 bps, it would take more than 38 hours to transmit the file. If you use the MMGR protocol to transfer this file, only the allocated blocks are transmitted. First, the block with record 1 is read by the program. Since MMGR waits until 4096 bytes are read before transmitting, the program will then look for the next block with a record. It will take no more than 10 minutes for the operating system to search through the 16 Megabyte file to determine that the next (and last) block to send is the block with record 65,534. After the transfer is completed, the number of blocks used on the receiving system disk will be the same as on the sending system (five blocks for this sparse example). Since the receiving system will time out before the 10-minute period is up, you should use the T command to select the NONE timeout option when a sparse random-access file is being received. With no timeout, the receiving system will initially send NAK for several minutes until the sending system has found enough data to send. OPEN FILES Once you start to receive a file with a protocol transfer, do not remove or swap the destination disk until the transfer is finished. If the transfer is interrupted, wait until all operations appear to be completed and you can display the "Xfer command? -->" prompt before removing the disk. If a FILE OPEN error message is displayed or if you remove the destination disk during a protocol receive operation, delete the file from the disk as soon as you can. INSTALLING THE BINARY2 OR AEXMODEM MODULES The ProDOS version of MODEM MGR uses software modules to support some major new features. You may run these modules by using the : command in the terminal mode. When you enter this command, the following menu will be shown: SELECT MODULE A) AEXMODEM B) BINARY2 V) VT220 Q) QUIT Enter (A, B, V, Q) --> Type the letter corresponding to the module you wish to run. For example, if you want to run the BINARY2 module, type B. You don't have to wait for the menu to appear. You may type the letter immediately after you type the :. For example, to run the VT220 module, type the sequence [ESC] : V as quickly as you can. BINARY II FILE TRANSFER MODULE This module supports the Binary II file-transfer format for ProDOS files. Files will be automatically formatted by this module when they are sent to a host and automatically saved in their original format on disk when they are received from a host. You do not have to perform any additional file conversion. You may combine several ProDOS files from a batch list or all of the files in a directory. This module will also unwind a combined file into the individual ProDOS files as they are received. The operation of this module is similar to the XMODEM operation. This section will describe the major differences only. If you have text in the capture buffer, the buffer will be cleared when you transfer files with this module. A warning will be displayed if your capture buffer is not empty. Use the Q command to quit if you wish to save your capture buffer. This module uses a 24576-byte buffer instead of the 4096-byte buffer used in the XMODEM or MMGR transfers. Any single file that exceeds 24k will be read or written 192 XMODEM blocks at a time. SEND ONE FILE WITH BINARY II If you wish to send one file, wait until the host is ready to receive, then load this module. Select 1 on the menu and enter the pathname of the file you wish to send. If the file is not on the current volume, you may use a volume prefix (preceded with a /). The volume prefix will be stripped from the pathname when it is sent to the host. SEND MULTIPLE FILES WITH BINARY II FROM BATCH LIST You may send multiple files from a batch list containing all of the pathnames o f the files or sub-directories to be sent. Use the editor to prepare this text file and save the list to disk. The list must be not more than 1023 characters in length. Each pathname on the list must be on a separate line and blank lines are not allowed. The files and sub-directories will be sent in the order listed. Slot and drive (S# and D#) suffixes are not allowed. If any of the files you wish to send are not in the current prefix, you may use a volume prefix. The volume prefix will be stripped from the pathname when the file is sent. An example batch list is shown below. (GAMES is a sub-directory and WP is a volume directory). GAMES GAMES/POKER.DOC GAMES/POKER.SYS GAMES/POKER.LIB /WP/BULLETIN /WP/ERRATA After the host is ready to receive, load the module and select 2 on the menu. Next enter the pathname of the batch list. After the batch list is loaded, the program will check each file and sub-directory on the list to determine the total number of disk blocks involved. After a NAK is received from the host, the first file info block will be sent. If the host is also running Binary II and is programmed to check available disk space, the host may cancel the operation if it does not have adequate space to handle the total number of blocks. SEND ALL FILES IN DIRECTORY WITH BINARY II You may send all of the files in the current sub-directory or volume directory as one batch file. The total length of all filenames (number of characters in name plus one) must be not more than 1023 characters. Only non-directory files will be sent; other sub-directories in the current directory will not be sent. After the host is ready to receive, load the module and select 3 on the menu. The program will check each file to determine the total number of disk blocks involved. After a NAK is received from the host, the first file info block will be sent. If the host is also running Binary II and is programmed to check available disk space, the host may cancel the operation if it does not have adequate space to handle the total number of blocks. RECEIVE FILES WITH BINARY II If you wish to receive files, wait until the host is ready to send then load this module. Select 4 on the menu to receive single or multiple files automatically. If the first info block received contains the total disk blocks required, your disk volume will be checked to determine if you have adequate space. If there is not enough disk space, an error message will be displayed and the operation will be cancelled. If a sub-directory is received and that sub-directory does not exist in your current prefix, it will be created. If there is an existing file with the same name as the next file to be received, you will be asked if you wish to delete it. If you do not want to delete it, you will be asked for an alternate name. If you are connected through a phone network which introduces pauses longer than one second, select 5 on the menu instead of 4 to receive blocks which are interrupted by delays. CRC The ProDOS version provides optional CRC error-checking during XMODEM and BINARY II file transfers. This improves the detection of errors over the usual checksum method. When files are received, this program will select checksum or CRC automatically based on the method used by the sender. Some senders will start with CRC then switch to checksum if the receiver doesn't acknowledge within a few tries. Some senders require a C character instead of a NAK from the receiver at startup to select CRC. This program will ask you whether you wish to send C instead of NAK at startup. When sending, this program will send with CRC only if the receiver sends a C instead of a NAK at startup. Whenever CRC is being used, a C will appear at the left of the first block number (COO1). The DOS 3.3 XMODEM, all AE XMODEM, and all unattended mode XMODEM transfers will use checksum only. The MMGR protocol will always use CRC.