-=*=- -=*=- -=*=- -=*=- [ What's an Xmodem Anyway? ]- -=*=- -=*=- -=*=- -=*=- Several times a day, as I pass the system and take a quick glance just to make sure that all is well, I see some messages pertaining to file transfers and that someone is having a problem or two getting the Xmodem routines to run. So perhaps a quick review of what's SUPPOSED to happen will help those that haven't used Xmodem file transfers much. First, two definitions: Sender: the computer system which will transmit information to the receiver, much like a radio station sends a signal to the radio receiver in our car. Receiver: the computer system which will accept or receive information from the sender. Using these definitions, then, when you ask PICS, which is running on THIS system, to send a file, PICS becomes the sender and your computer is the receiver. To make a file available for others, such as those in the NEWIN section, you will need to make YOUR machine the sender and PICS the receiver. The Xmodem (or Christensen) protocol is designed to produce error free file transfers by locking the sending and receiving machines together in such a way that any errors in a block or record are detected. When an error is found in this way, the receiving machine asks the sending machine to try again. This may happen several times in a single block, but usually the reason for the error is noise on the phone line that is gone when the block is re-sent. Consequently, the limit of 10 errors in a single block rarely causes a premature termination. In fact, most terminations occur in the first block, usually because the two machines never got synchronized. That interlock, so critical to the success of the protocol, is established when the receiving machine tells the sender that it is ready, but the sender MUST ALREADY BE WAITING FOR THAT ACKNOWLEDGEMENT. So, to get a file from PICS to your system, follow these steps: -------------------------------------------------------------- 1. Tell PICS to end (from the Files sub-system). 2. Tell PICS which file you want. 3. PICS will verify that the file does exist and if you have enough access time to complete the transfer. If all goes well, PICS will announce the approximate time the transfer will take, and then say that it is ready for the transfer to begin. 4. Tell YOUR COMPUTER that you want it to RECEIVE a file. This usually involves some commands which include the file name and maybe the type of protocol (Xmodem) that will be used. The exact form of the command can be found in your documentation. 5. Your computer will then do some checking of its own. If all goes well, your computer tells PICS that it's ready to receive and the transfer will proceed. 6. After the transfer is complete, PICS will return to normal command mode for your next instruction. To send a file from your system to PICS, follow these steps: ----------------------------------------------------------- 1. Tell PICS to eceive (from the Files sub-system). 2. Tell PICS the name of the file you intend to send it. 3. PICS will make sure the file doesn't already exist and that the name is valid. If all goes well, PICS will announce the amount of disk space available, and then say that it is ready for the transfer to begin. 4. Tell YOUR COMPUTER that you want it to SEND a file. This usually involves some commands which include the file name and maybe the type of protocol (Xmodem) that will be used. Again, the exact form of the command will be found in your documentation. 5. Your computer will then try to find the file. It it does, it starts waiting for PICS to say it's ready to receive. WHAT? PICS already said it was ready, right? Partially. PICS told YOU it was ready, but while you were telling your machine to send a file, PICS was counting to itself. About 4 seconds after PICS tells you it is ready, it starts sending a code that your computer will interpret as a ready signal. PICS will send this code several times before it finally gives up. 6. When your computer detects that PICS is ready, it starts sending the file. 7. When the transfer is complete, PICS will ask for a short description of the file you sent for the benefit of other users. That's where the information in the ewin function comes from. ----------------------------------------------------------------------------- In addition to the regular transfers (done with 128 byte blocks) there is also the 1K Xmodem protocol. This is the same as the regular way, except that the blocks are larger, thereby reducing the amount of time that it takes to send a large file. When sending a number of files the Batch mode can be used to automatically send the file names and files both ways. When batch mode is used, PICS will always use CRC and 1K protocols. While the terms "upload" and "download" aren't usually used in PICS, they correspond to eceive and end respectively, i.e. "upload" means to send a file from a remote system to a host ( you to PICS, so PICS is receiving), and "download" means to send a file from a host to a remote system (from PICS to you, so PICS is sending). In both cases, PICS is acting as the host system. For those interested in the technical aspects of the error checking, I'll just say that PICS will automatically detect cyclic redundancy code (CRC) or checksum modes during send operations (as requested by your machine), and that during receive operations, PICS will try both modes until something works or it times out (preference is given to CRC for accuracy).