
-=*=- -=*=- -=*=- -=*=- [ 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 <S>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 <R>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 <N>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 <R>eceive and <S>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).

