HFISCHER%USC-ECLB%SRI-NIC@sri-unix.UUCP (01/10/84)
A number of folks have expressed an interest in a version of the IBM PC Kermit
program which also functions as a server. Intense pressure at my company
(Litton Data Systems) to be able to do something with all of our PC's so that
managers could collect their status reports automatically prompted me to make
an initial test release of the PC (and Heath) Kermit (with server added).
I have succeeded in modifying PCK20.asm to become both the regular local
Kermit and additionally a server. As a server, the program (the same
identical program) can function as an unattended remote, either controlled by
its own console, or with the DOS-2 CTTY command, over the communications
line.
The modified kermit is in my directory for those who would like to test it.
At Arpanet site "USC-ECLB" FTP file <HFischer>pck20.new for the modified
assembler code, and file <HFischer>pck20.exe for the 8-bit mode .exe file.
If you'd rather have the file some other way, there are two choices; mail me
a floppy (Herman Fischer, Litton Data Systems, 8000 Woodley, ms 44-30,
Van Nuys, CA 91409) or contact me by net or phone (we could put my PC into
server mode and transmit the .exe file directly).
Please let me know of any problems, or questions in getting it up. My
telephone number is 213/902-5139 (but I will be out of town next week and the
week after, net accessible next week but not at all the week after).
I have tested it using the resources available in my company (my test setup is
a Sytek local area network with 9600 baud communications between multiple
PC's). Obviously there are many combinations of equipment which are still to
be tried.
If you must run under DOS 1, then you can only load the kermit server on the
serving machine's console (because DOS 1 cannot redirect commands over comm
links). When you load kermit, after setting the baud rates, parity, or
whatever, issue the command "server". This places your machine in a receive
state, whereby callers can send to you, receive from you (default directory
only). Don't let remote callers issue "finish" or "logout" because that'll
return your machine to DOS, and then subsequent callers cannot access kermit
without your presence to reload it.
It is much more sexy to use DOS 2 CTTY to redirect your keyboard to the comm
line. Then the caller can use dir, edlin, type, and just about all programs
which use DOS (not BIOS) calls. (BASIC uses BIOS calls, so it won't cooperate
with CTTY.) If your machine has CTTY COM1 issued, then the caller can do
whatever he wants, including loading and running PC Kermit. For PC Kermit,
your caller must type in a command to load Kermit and override the DOS 2 CTTY
redirection (because your comm line probably needs set baud and other
preparatory commands, and the server command, and because PC kermit uses
BIOS console I/O (lest it not run on DOS 1 any more)). Once the remote caller
is ready, to load kermit, he MUST do it (or invoke batch files) as thus:
"kermit < yourfile.xx > con:"
where yourfile.xx contains something like:
"set baud 9600
server".
He then does his "^]C" and tells his kermit what to send/receive/finish. When
finished, he again can connect and operate the remote PC's DOS (those programs
not using BIOS, of course). Wildcards work as usual. Drive id's work, but are
tricky, for example, because getting a file from a sepecified drive of the
server will stuff the file onto the default drive of the recipient.
If the owner stumbles back into the office with the "serving machine", since
we have ">con:" on the kermit statement he will see the ongoing transactions.
I have modified the program so that a ^C issued at the main console of the
serving machine will abort the program and return to DOS. Also, that means
now that a ^C at any point while sending or receiving, even if you are not a
server, will abort the program (you might have to follow the ^C by a bunch of
enter depressions, depending on where you caught the program hanging).
I will next try to think of some way to make this Kermit version do some type
of elementary mailing task with unix go-betweens.
Herm Fischer (HFischer@eclb)
-------