

                                  J M O D E M
                              File Transfer System
                                 Compliments of
                               Richard B. Johnson
                                PROGRAM EXCHANGE
                                 (303) 440-0786
                               December 31, 1988

          General:
          First Let me get this over with.
          MS-DOS is a registered trademark of Microsoft Corporation
          IBM, IBM-PC, IBM-XT, AT, are registered trademarks of
          International Business Machines, Inc. WILDCAT! is a
          trademark of Mustang Software. XMODEM is a public-domain
          file-transfer protocol developed by Ward Christensen.

          JMODEM is released into the public domain. As with most
          public-domain protocols, you are advised that there is no
          implied warranty of any kind. The source-code is provided so
          that you may determine for yourself if this program may
          serve a useful purpose. It is written in Microsoft MASM
          Assembly-language using good standards of engineering
          practice. It does not use any strange or "undocumented"
          functions of the MS-DOS operating system.

                PLEASE UPLOAD THIS FILE (The ARC file) to as many
                BBS systems as you can so that it gets installed
                all around the country.

          Introduction:
          JMODEM is a new file-transfer protocol developed to be used
          as an "external protocol" on BBS systems and personal
          computers using the IBM-PC/AT/XT structure and the MS-DOS
          operating system.

          This file-transfer system features:

                o       16-bit CRC for verification
                o       File size is exactly maintained
                o       Data compression.
                o       Rapid host/remote synchronization.
                o       Variable-length transmission blocks which,
                        if there are few errors, increase to 8192
                        data-bytes in length.
                o       Flow control (automatic)
                o       Hangup protection
                o       Aborted files are saved
                o       Files being overwritten are renamed to
                        ".OLD", rather than deleted.
                o       COM1 - COM4 support.
                o       Interrupt on received characters allows data
                        to be received while the previous block is
                        being written to disk. This provides almost
                        continuous data transmission without long
                        waits between blocks.





                                     - 1 -
          
                                               JMODEM Protocol  Page 2


          JMODEM is not for everyone! It does not have any pretty
          screens to dazzle the user. It is designed to maximize the
          amount of data that can be transferred in a given time (and
          reduce telephone cost). It does this by sending very long
          blocks of data and encoding (compressing) the data wherever
          possible. Since long blocks of data are subject to many
          transmission errors, a 16 bit CRC is used to determine the
          data integrity. As many as ten retries are made if the data
          is not correctly received. If you have a noisy telephone
          circuit, you will find that JMODEM will abort more often
          than the XMODEM protocol which sends very short blocks. A
          future version that will be downward-compatible with the
          existing version is being developed that will do "heroic"
          retries and will even go down to a 16-byte block-lengths if
          that's what is necessary to get the data transferred.

          Once synchronization between the remote computer and the
          host are established, JMODEM paints a status block on the
          screen that shows how the file transfer is going. The status
          screen shows the block being transmitted (or the last re-
          ceived), the length of the block, and the total bytes having
          been transmitted (or received). A special synchronization
          routine is used so that the first block is not thrown away
          as happens so often in XMODEM type routines. During the
          synchronization routine, where the host is waiting for the
          user to enter the proper file parameters (a 30 second wait).
          You can abort immediately by sending a control X (^X). After
          actual file transfer begins, ie. when you see the status
          window on the screen, no input from the keyboard is pos-
          sible. You send a control BREAK to abort the transmission
          (or ^C). In this case, the program will abort after the
          block being sent/received is complete. This could take 15 or
          more seconds with long blocks so be patient.

          In the event that carrier is lost (the user disconnected),
          the file-transfer program will also abort. This, too, could
          take as long as 15 seconds. JMODEM has logic to determine if
          the modem carrier was present when it started. This will
          allow you to transfer files between computers with a wire
          without having to tie the RLSD lead high.

          How it works:
          The block size starts out at 512 bytes (or the actual bytes
          in the file -- whichever is less). To this is added a 6-byte
          overhead. If the block transfer occurred without any
          retries, the block length is increased by 512 bytes to 1024
          bytes. As long as the transmission was successful without
          incurring any re-tries, the block-length increases to a
          maximum of 8192 bytes. There is still the same 6-byte
          overhead so the maximum block length will actually be 8198
          bytes. Any time there are retries, the block length (on the
          next new string) is decreased by 512 bytes. The string-
          length is never reduced to less than 512 bytes due to





                                     - 2 -
          
                                               JMODEM Protocol  Page 3

          errors. When the last bytes are read from the file, the
          block length may be as little as 7 bytes (one data byte,
          plus the 6 byte overhead). The file size as received will be
          exactly the file size as transmitted. XMODEM will "round-up"
          the file size to the next higher block. This means that MS-
          DOS's COMP (compare) will always fail when you attempt to
          check files that have been sent by XMODEM and many other
          protocols.

          When the file is read, an attempt is made to compress the
          data using the well-known RLL process where multiple bytes
          are compressed into a 4-byte statement.

          For instance a string that looks like this (hex):
                A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0
          Gets compressed into this:
                BB 0F 00 A0
                 |  |  |  |__________ Byte to repeat
                 |  |  |_____________ High byte of repeat length
                 |  |________________ Low byte of repeat length
                 |___________________ Sentinel Byte

          The sentinel-byte (BBH), when encountered in a data stream
          will get expanded to four bytes. Therefore, it is possible
          for the "compressed" data string to actually be longer than
          the original. If this occurs, the original string is sent
          rather than the longer encoded one. Since the kind of data
          sent can be different from block-to-block, it is necessary
          to send a control-byte along with the data so the receiver
          had determine how to operate on the data.

          This is the control structure:

          00 02 00 0B 01 02 03 04 05 06 07 08 09 0A .... 0A EA
           |  |  |  |  |                                 |  |_ CRC
           |  |  |  |  |                                 |____ CRC
           |  |  |  |  |______________________________________ data
           |  |  |  |_________________________________________ rec.
           |  |  |____________________________________________ control
           |  |_______________________________________________ length
           |__________________________________________________ Length

          Two bytes are used for the string length and two bytes are
          used for the CRC. As is standard in memory, the high-byte
          looks "to people using DEBUG" swapped with the low byte. The
          data is transmitted exactly as the memory image.

          The length (a word) begins the string so the receiver may
          know exactly how may bytes to receive.

          The control byte is bit-mapped to 8 possibilities. The ones
          most important are:

                        NORMAL DATA





                                     - 3 -
          
                                               JMODEM Protocol  Page 4

                        COMPRESSED DATA
                        END OF FILE
                        ABORT

          This is now the receiver "knows" what to do with the data.

          The CRC is generated using this polynomial:

          X =  X + X^(2(n-mod 7)).......  Where n = t(n-1)
                                         And t = string length

          It has the advantage of simplicity in assembly-language
          programming and will detect errors with a probability of
          about  one undetected error in 2^132 (which is a very large
          number). It does not correct errors so its not important to
          use some "standard" function to generate the CRC.

          Support for COM3 and COM4 have been added on revision level
          V1.05 . Note that the standards for port locations are de-
          facto standards only and may not be the ports actually used
          in your computer. Please modify the communications port
          structures at the beginning of the assembly-language program
          to match your system parameters if they are different. The
          modifications should be done to the STRUCTURES, not to the
          EQUATES!

          Revision level V1.09 brings musical exit status. If the file
          transfer was successful, the computer plays "victory". If
          the file transfer was aborted, the computer plays "retreat".
          Since the BBS SysOp is unlikely to want his computer to play
          bugle-calls well into the evening, the user has the option
          of turning the music off. This is done by setting an
          environment variable string:

          SET JMODEM=SHUTUP

                ... Will accomplish the desired result.
          Usage:
          This program uses parameters on the command line.

          JMODEM S <filename.typ>       ( Sends a file to COM1:)
          JMODEM R <filename.typ>       ( Receives a file from COM1:)
          JMODEM S1 <filename.typ>      ( Sends a file to COM1:)
          JMODEM R1 <filename.typ>      ( Receives a file from COM1:)
          JMODEM S2 <filename.typ>      ( Sends a file to COM2:)
          JMODEM R2 <filename.typ>      ( Receives a file from COM2:)

          After version 1.05, JMODEM supported communications adapter
          ports 1 through 4.

          In a batch file, <filename.typ> may be a substitution
          character.
          JMODEM S2 %1                  ( Sends a file to COM2:)
          JMODEM R2 %1                  ( Receives a file from COM2:)





                                     - 4 -
          
                                               JMODEM Protocol  Page 5




























































                                     - 5 -
          
                                               JMODEM Protocol  Page 6

                      Setting up a Communications Program
                        External File-Transfer Protocol.

          On my system, TELIX resides in the C:\TELIX directory. A
          copy of JMODEM.COM is also in that directory. TELIX passes
          the filename as the %3 parameter. Therefore the contents of
          JUP.BAT is:

                        C:\TELIX\JMODEM S1 %3

          The contents of JDOWN.BAT are:

                        C:\TELIX\JMODEM R1 %3

          If I wished to receive in the "batch" mode, I could make a
          file like this. Notice that some communications programs do
          not allow multiple file names. Note that the comments "!"
          are NOT ALLOWED in a DOS batch file.

                        :DO_LOOP                   ! Return here
                        IF "%3" == "" GOTO DONE    ! More parameters?
                        C:\TELIX\JMODEM R1 %3      ! Execute JMODEM
                        IF ERRORLEVEL 1 GOTO DONE  ! Abort on error
                        SHIFT                      ! %4 becomes %3
                        GOTO DO_LOOP               ! Continue
                        :DONE                      ! Exit batch file

          If you do not know what "%" parameters are used to pass the
          file name, all you have to do is make a "dummy" batch file
          that contains the following:

                        @ECHO OFF
                        ECHO %1
                        ECHO %2
                        ECHO %3
                        ECHO %4
                        ECHO %5
                        PAUSE

          When this is executed, you will see something like this:

                1200
                1
                FILENAME.TYP
                ECHO is off
                ECHO is off
                Strike a key when ready . . .

          The first line contains "1200" which is the baud rate. This
          means that the %1 parameter contains the baud rate.

          The second line contains "1" which is the communications
          adapter port being used. This means that the port is being
          passed as the %2 parameter.





                                     - 6 -
          
                                               JMODEM Protocol  Page 7


          The third line contains "FILENAME.TYP" which is the file
          name. This means that the file name is being passed as the
          %3 parameter.

          The fourth and fifth lines contain nothing to echo so DOS
          replies the current state of the echo function which is
          "off".

          PCPLUS handles the file name passing a little bit different.
          If I execute the same "dummy" batch file from the PCPLUS
          directory, the response is:

                FILENAME.TYP
                ECHO is off
                ECHO is off
                ECHO is off
                ECHO is off
                Strike a key when ready . . .

          This shows us that PCPLUS passes the file name as the first
          parameter and there are no other parameters. However, If I
          put more parameters on the command line within PCPLUS, they
          will get sent to the batch file. The response is:

                FILENAME.001
                FILENAME.002
                FILENAME.003
                FILENAME.
                ECHO is off
                Strike a key when ready . . .

          Therefore PCPLUS allows up to four file names to be passed
          providing there's room on the command line.

          Notice that these two communications programs check the
          default directory for the external protocol batch file
          FIRST! Therefore you must make certain that there are no
          other similarly-named batch files in the current directory
          or within the current path. Failure to do so will cause the
          improper execution of the wrong batch file. Lets say that
          the path was "C:\DOS;C:\TOOLS;C:\PCPLUS;C:\TELIX;C:\QMODEM".
          If you named all your JMODEM external protocol batch files
          with the same name, and you were attempting to use an
          external file transfer protocol from QMODEM, the batch file
          designed to operate with PCPLUS would be the first one
          "found" and executed since the search-path will search the
          \PCPLUS directory before the \QMODEM directory. You prevent
          the execution of the incorrect batch file by calling them
          slightly different names.

          When setting up external protocols, remember to configure
          the communications program so that it prompts you for the
          file names. Unlike some protocols, JMODEM does not transfer





                                     - 7 -
          
                                               JMODEM Protocol  Page 8

          the file name. You can use any file name that you wish. You
          must pass the file name to JMODEM since it must know the
          name of the file being transmitted or received. There are no
          defaults.























































                                     - 8 -
          
                                               JMODEM Protocol  Page 9

                            Setting up a BBS System
                        External File-Transfer Protocol.


          If you are running a WILDCAT! bulletin board, the external
          protocol files can be set up like this:

                        (JUP.BAT)
                        CD D:\WILDCAT\PROTOCOL
                        IF EXIST TRANSFER.BAD DEL TRANSFER.BAD
                        JMODEM R1 %3
                        IF ERRORLEVEL 1 GOTO END
                        COPY %3 %4
                        :END
                        DEL %3

                        (JDOWN.BAT)
                        CD D:\WILDCAT\PROTOCOL
                        IF EXIST TRANSFER.BAD DEL TRANSFER.BAD
                        JMODEM S1 %3
                        IF ERRORLEVEL 1 GOTO BAD
                        GOTO END
                        :BAD
                        COPY ALL.OK TRANSFER.BAD
                        :END

          There are many variations available. Since WILDCAT! supports
          batch-mode downloading, you could set up the batch file like
          this:

                        (JDOWN.BAT)
                        CD D:\WILDCAT\PROTOCOL
                        IF EXIST TRANSFER.BAD DEL TRANSFER.BAD
                        :DO_LOOP
                        IF "%3" == "" GOTO END
                        JMODEM S1 %3
                        IF ERRORLEVEL 1 GOTO BAD
                        SHIFT
                        GOTO DO_LOOP
                        :BAD
                        COPY ALL.OK TRANSFER.BAD
                        :END

          WILDCAT! checks the \PROTOCOL directory to see if the file
          TRANSFER.BAD has been created. If it exists, it announces
          that the file transfer has failed. It also announces "Error
          with external protocol .. ". It does this when, in fact,
          WILDCAT!  has made an error itself. In many cases WILDCAT!
          will "find" the file TRANSFER.BAD when it DOES NOT EXIST! In
          spite of this bug, WILDCAT! is one of the most reliable BBS
          systems supporting external protocols.

          When setting up batch files remember that there is also a
          bug in all DOS versions. The "IF ERRORLEVEL " statement does





                                     - 9 -
          
                                              JMODEM Protocol  Page 10

          NOT test the actual value of ERRORLEVEL! Instead it checks
          to see if the returned value is EQUAL or GREATER than the
          tested value. If you were to put the statement:

                        IF ERRORLEVEL 0 GOTO GOOD

          .... in a batch file, the execution would ALWAYS branch to
          label "GOOD" regardless of the actual ERRORLEVEL returned!
          More about bugs when we get to the "BAD BBS" section towards
          the end.

          JMODEM does not require any information about handshaking.
          It will look at the modem port and figure out for itself
          what to do.

          In the event that the modem carrier is lost, JMODEM will
          abort. Since JMODEM only checks the modem port occasionally,
          it may take several seconds to abort when the carrier is
          lost. It is impossible for a user to get at the DOS level
          through JMODEM. Do NOT use the CTTY command in the external
          protocol batch files. JMODEM returns ERRORLEVEL 1 if there
          was any error in transmission or reception. It returns
          ERRORLEVEL 0 (no error) otherwise. It does not delete files
          that have been partially received although it properly
          closes them. The system operator can arrange the batch files
          to delete them if required.

          When JMODEM attempts to create a file that already exists it
          can't ask the user if the old one should be deleted since
          the user is probably not in a terminal program at the time.
          Therefore, JMODEM renames the other file to <filename.OLD>
          and creates the new file. In the event that <filaname.OLD>
          exists, it is deleted before the rename operation occurs.

          If you don't know what parameters are being sent to external
          protocols, you can make a dummy batch file to check them
          using the DOS's echo command just as explained in the user
          interface previous to this "BBS" section. You can't see the
          parameters being echoed from a remote terminal. You must be
          present at the BBS board terminal to test those parameters
          unless you modify the dummy command file like this:

                        @ECHO OFF
                        ECHO %1>COM1
                        ECHO %2>COM1
                        ECHO %3>COM1
                        ECHO %4>COM1
                        ECHO %5>COM1

          If you find that your system passes the file name as %3,
          your "upload" (receive) batch file would contain this:

                        JMODEM R1 %3






                                     - 10 -
          
                                              JMODEM Protocol  Page 11

          Your "download" (send) batch file would contain this:

                        JMODEM S1 %3

          In these examples, it is assumed that you are using
          communications adapter port "1".





















































                                     - 11 -
          
                                              JMODEM Protocol  Page 12

                                  The BAD BBS
                                    Problem.

          Believe it or not, there are several very fine running BBS
          systems in use that do not properly handle external proto-
          cols. MS-DOS provides the proper mechanism for loading and
          executing "child" programs from within the "parent"
          programs. This is function 4BH of the "DOS" INT 21H DOS
          interface. Instead of using this function, these poorly-
          behaved programs perform the external file-transfer protocol
          in the following (or similar) manner:

                (1) Make a DOS call to find the file-size of the
          external file-transfer protocol.

                (2) Free up an array of memory from "string-space"
          within the program that is large enough to copy the external
          file transfer contents into it. As assumption about the
          data-space required by the external file transfer program is
          made based upon the "block-size" information that has been
          entered during configuration.

                (3) Loads the file into string-space memory.

                (4) If its an ".EXE" file, ignore the header.

                (5) CALL the first byte of code!

                If JMODEM is run in this environment, it WILL crash
          the system. JMODEM assumes that it has been placed in memory
          by MS-DOS and that an entire segment (64k) is available to
          run. JMODEM uses two buffers that are almost 32k in length!
          One of the buffers is used to support data compression and
          expansion. The other is used for the interrupt buffer.

          If you have such a BBS system and you wish to run JMODEM,
          you can make a simple modification to the source-code, and
          re-compile to produce a version which is a bit slower to
          initialize and exit, but is guaranteed to leave all memory
          and registers EXACTLY as they were when JMODEM got control.
          This is done by saving and restoring all registers.
          Additionally, any data space that will be modified is copied
          to a file called VIRTUAL.MEM, then restored from that file
          just before JMODEM exits.

          You modify the source-code by finding the "BAD_BBS" equate
          near the beginning of the file. This is normally set to
          "FALSE". You set this to "TRUE". Then you recompile in the
          following manner:

                MASM JMODEM;
                LINK JMODEM;
                EXE2BIN JMODEM.EXE JMODEM.COM
                DEL JMODEM.EXE





                                     - 12 -
          
                                              JMODEM Protocol  Page 13


          Do NOT attempt to execute the ".EXE" version. You must
          change JMODEM to a ".COM" file. If you do not have
          EXE2BIN.COM to make the change, you can use DOS's DEBUG to
          do the same thing. You do it this way:

          F:\DEV> debug jmodem.exe      ; DOS command line
          -rcx                          ; Examine CX register
          CX 1239                       ; Debug says the size was 1239
          :

          -h 1239,100                   ; Calculate 1239H - 100H
          1339  1139                    ; Sum = 1339H, dif = 1139H
          -rcx                          ; Examine register again
          CX 1239                       ; Is 1239H
          :1139                         ; Change to 1139H
                                        ; .. subtract 100H
          -njmodem.com                  ; Name new SAVE file name
          -w                            ; Write to file

          Writing 1139 bytes            ; Debug prompts
          -q                            ; Exit

          F:\DEV>                       ; Back to DOS

          When you use this version of JMODEM, it will take a little
          while longer to load and exit because it must write a 64k
          block of memory to a file and read / delete in upon exit.































                                     - 13 -
          
                                              JMODEM Protocol  Page 14

                            When things don't work!

          The early versions of JMODEM assumed that it was being
          properly loaded either by COMMAND.COM, the resident command
          processor, or by a "parent" process that properly executes
          the DOS function 1BH (the EXEC function). Much to my
          surprise, I found that much BBS system software is not
          written properly. Starting at version V1.10, I included the
          "BAD_BBS" routines to help overcome some of the loading
          problems that these BBS systems have. In some cases this
          work-around was successful and in others it was not. In
          version V1.13, I included some tests that verify whether or
          not JMODEM has been loaded properly. Instead of crashing the
          system, JMODEM now prints an error message and exits. These
          error messages can help you find out what the problem is
          and, hopefully, obtain a solution.

          Presently, when JMODEM is loaded one of the first things it
          does is make a DOS call to give up all memory except that
          which contains the code. If DOS returns an error, it means
          that JMODEM was not loaded properly and therefore doesn't
          own any memory to give up! If an error message appears
          telling you that JMODEM doesn't own any memory, you must
          contact the writer of your BBS system software to obtain a
          version that has this bug fixed. There will be no way to
          execute JMODEM in this kind of environment without risking
          serious system crashes.

          The next thing JMODEM does is make a DOS call, requesting
          64k (-1) bytes of memory for its necessary buffer space. If
          this DOS call fails, a message is printed stating that there
          is not enough memory available for JMODEM. In this case, you
          simply reconfigure your BBS software to provide enough
          memory for the external protocol. On some BBS systems, this
          is done by defining "block-size". Generally, you just
          specify the largest number that your BBS software will
          accept and therefore force the BBS system software to
          allocate a large block of memory for the external protocol.

          Although the code size of JMODEM is small (around 4k), it
          requires just as much memory as other external protocols.
          The memory is used for three major buffers:
                (1) Data buffer  8198 bytes
                (2) Encode/decode buffer 32,767 bytes
                (3) Interrupt buffer 20,000 bytes

          These buffers are put in a separate segment so a wild bit-
          stream input cannot cause a system crash. The index used for
          addressing memory in the interrupt buffer simply wraps
          around past 64k, back to zero. Of course you get data errors
          when this happens, but no crash, and if the incoming bit-
          stream ends before a time-out, the error is recoverable.
          When satellite links lose lock, the result is usually a 20
          to 30 second burst of noise (random bit-stream). At 9600





                                     - 14 -
          
                                              JMODEM Protocol  Page 15

          baud, you can easily overflow a buffer if it is not large
          enough or is not allowed to wrap. Alternative methods are to
          limit the size of the buffer and check the limit every time
          a byte is put in the buffer. JMODEM doesn't do this for two
          reasons. The first is the increased software overhead (the
          check must be made for every byte in the interrupt service
          routine) and the second is that you may be waiting for an
          ACK. JMODEM always preserves the last byte in the buffer so
          that, even with a noisy reverse-channel, the ACK/NAK can be
          extracted.

          These are the error messages and what they mean.

          JMODEM error message:
          Specified file "" not found

          This means that no file name was passed to JMODEM on the
          command line during a download.

          JMODEM error message:
          Specified file "\D:PATH\FILENAME.TYP" not found

          This means that an incorrect file name was passed to JMODEM
          on the command line during a download.

          JMODEM error message:
          Specified file "" Can't be created.

          This means that no file name was passed to JMODEM on the
          command line during an upload.

          JMODEM error message:
          Specified file "\D:PATH\FILENAME.TYP" Can't be created.

          This means that an incorrect file name was passed to JMODEM
          on the command line during an upload or:

                o       The path doesn't exist
                o       The drive doesn't exist
                o       Not enough file handles
                        Put FILES=40 in CONFIG.SYS and reboot
                o       Attempt to write to a network drive
                        If you are not networked, do NOT install SHARE

          JMODEM error message:
          File transfer aborted!

          This is a normal abort. If the user didn't abort then the
          active communications adapter port is not being passed to
          JMODEM correctly.









                                     - 15 -
          
                                              JMODEM Protocol  Page 16

          JMODEM error message:
          Modem carrier failed.

          Modem either was not online or the user hung up during
          protocol execution.

          JMODEM error message:
          Can't execute, no free RAM!

          A poorly-written BBS system attempted to load the program as
          a subroutine and execute it. Contact the BBS software
          writer.

          JMODEM error message:
          This program was already loaded over resident code.
          The system will probably crash!

          A poorly-written BBS system just loaded JMODEM over its own
          code!

          JMODEM error message: Can't create file VIRTUAL.MEM
          JMODEM error message: Can't write file VIRTUAL.MEM
          JMODEM error message: Can't close file VIRTUAL.MEM
          JMODEM error message: Can't open file VIRTUAL.MEM
          JMODEM error message: Can't delete file VIRTUAL.MEM

          When compiled with the BAD_BBS system conditional set to
          "TRUE", JMODEM was unable to do the required file I/O
          because something was screwed up by the BBS software or
          there were not enough file handles available. Enter FILES=40
          in CONFIG.SYS and reboot. This can also happen if SHARE is
          installed and no network exists. Do NOT use SHARE if you are
          not networked!

          JMODEM error message:
          DOS reports that JMODEM was improperly loaded and does not
          own the memory it is using!

          The BBS system software is either improperly configured or
          improperly written for external protocols. Contact the
          writer of the BBS system software.

          JMODEM error message:
          Not enough free memory for JMODEM to use!

          The BBS system software is not properly configured to give
          JMODEM the memory it requires to execute. Check the BBS
          system software documentation and reconfigure.

          If you have problems using JMODEM with your system, you can
          call the PROGRAM EXCHANGE and leave a message You can also
          test your communications program's external file-transfer
          protocols by transferring files (hopefully uploading) to the
          PROGRAM EXCHANGE. Currently there are hundreds of boards





                                     - 16 -
          
                                              JMODEM Protocol  Page 17

          that are using this protocol and the number is growing every
          day. Most problems encountered are found to be caused by
          incorrect file names being sent to JMODEM (the wrong "%"
          parameters). A simple batch file to test these parameters
          will go a long way towards solving the problems.

                                Richard B. Johnson
                                PROGRAM EXCHANGE
                                (303) 440-0786
                                Boulder Colorado
                                80303

          - Finis -














































                                     - 17 -
          

