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