home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / c / rmxker.hlp < prev    next >
Text File  |  2020-01-01  |  5KB  |  97 lines
  1. This is an unofficial (as of April 1985) version of the Columbia
  2. University KERMIT communications program, for RMX-86 systems.  It is
  3. designed to enable file fransfer between dissimilar computer systems
  4. over standard RS232 serial lines.  For more information on KERMIT, or
  5. versions that run on other computers, contact:
  6.         KERMIT Distribution
  7.         Columbia University Center for Computer Activities
  8.         612 West 115th Street
  9.         New York, N.Y.  10025
  10.  
  11.     I wrote this RMX86 version because I needed to transfer some
  12. binary files between two RMX systems with different size floppy drives,
  13. and the IRAFT program generated over 5 Mb of diagnostics (in a file called
  14. /world/ERRORS) while attampting to do the transfer.  Also, I had hoped
  15. to fix the problem where in VTP if the remote system sends data to rapidly,
  16. some characters are lost.  Unfortunately, that turns out to be a bug in
  17. the I/O system. RMX only supports flow control in hardware, NOT is software.
  18. Therefore the two terminal lines on a 286/10 board for example, lose data
  19. if the sending system is too fast.
  20.  
  21. I have tried to write the program with an eye toward a complete
  22. KERMIT implementation, but so far have only implemented those parts that
  23. I really needed.  Noteably missing are wildcard file specs, SERVER mode,
  24. and many of the SET commands (including IBM mode).  I have used the program
  25. between two RMX systems and between RMX and VAX/VMS.  I have plans to
  26. implement wildcard file specs and SERVER mode, but not for a while.
  27.  
  28. I have included all the PLM source modules, and four command files,
  29. so one can build, or modify, or just see how the program was written.  Sorry
  30. the comments in the source code are so sparce. Also sometimes they may be out
  31. of date (i.e. wrong). The first command file (LOG.CSD) simply assigns logical
  32. names used by the next csd files.  If these are not right for your system,
  33. please change this file accordingly.  COMPILE.CSD then compiles all (or some)
  34. of the source modules. Next, KERMIT.CSD binds it into an executable module.
  35. Since I have never been able to figure out what size mempool to specify, I
  36. chose a large random number.  Finally, SAVE.CSD is the command file that
  37. made this floppy.
  38.  
  39. The following is a list of special notes particular to this version
  40. of KERMIT(rmx-v1.0).
  41.  
  42. 1.    The second terminal line on the local system must be already attached
  43.     and is refered to by its logical name (for example, :t3:).  This
  44.     allows you to choose which other terminal line you want to use if you
  45.     have more than two.
  46.  
  47. 2.    KERMIT allows you to set the BAUD RATE, but does not clean up on exit.
  48.     This means you can use KERMIT to permenently change the BAUD RATE
  49.     of any attached terminal line.
  50.  
  51. 3.    While HELP is available, I have not spent a lot of time on it, and
  52.     therefore some help information is not available, and some may describe
  53.     a feature which is not yet implemented.  However, if you type a
  54.     command which KERMIT understands but is not yet implemented, it tells
  55.     you.
  56.  
  57. 4.    IMPORTANT......Since KERMIT sits in a loop waiting for input
  58.     characters, it may adversely effect a multi-user RMX system.  I
  59.     have some ideas on how to improve this, but have not yet implemented it.
  60.  
  61. 5.    KERMIT is supposed to strip off directory information from file
  62.     specs, and optionally not do this.  This is not implemented, file
  63.     specs as entered are passed to the recieving end.  Therefore, you
  64.     must be in the appropriate subdirectory when sending to a non RMX
  65.     system.  This will be fixed in a future major release.
  66.  
  67. 6.    While this KERMIT can not send multiple files yet, it can recieve
  68.     them from another version of KERMIT.
  69.  
  70. 7.    Since I do not own any terminal lines with hardware flow control, I
  71.     have not implemented setting it.  But it should not be too hard to add.
  72.  
  73. 8.    While this KERMIT can not be in SERVER mode, I have added the commands
  74.     to allow it to communicate with one that is in SERVER mode.  (i.e.
  75.     GET, BYE, and FINISH)
  76.  
  77. 9.    I have not tested must of the error recovery in system services.  This
  78.     means that if a system error causes a command to fail, the program may
  79.     not clean up properly. It is a prudent practice to exit from kermit
  80.     and restart it to be sure.  Certain types of errors I know I can not
  81.     properly clean up after, and they automatically exit from KERMIT.
  82.  
  83. 10.    I have not implemented either local or remote commands (like dir
  84.     or attachfile), and do not have plans for that in the near future.
  85.  
  86.  
  87. If you find any errors, or better yet if you fix or implement something
  88. new, let me know at the following address:
  89.  
  90.     Dr. Robert Schamberger
  91.     Wilson Lab
  92.     Dryden Road
  93.     Cornell University
  94.     Ithaca, New York  14853
  95.     (607)-256-3314
  96.  
  97.