INSTALLATION: If you received this from HUE (Harris Users' Exchange), you should have received the following files: 2000KERM*KERM.DOC this documentation 2000KERM*KERMSRV executable Kermit Server -- rename this to be on the 0SYST* qualifier 2000KERM*HARRIS on-line help file giving a brief command summary (must be given Public Read access) 2000KERM*KERM:J jobstream used to recompile KERMSRV 2000KERM*K:SERVE Fortran source for main program 2000KERM*K:SEND Fortran source for sending files (i.e. from Harris) 2000KERM*K:RECV Fortran source for receiving files (i.e. to Harris) 2000KERM*K:COMMND Fortran source implementing remote commands 2000KERM*K:DIRECT Fortran source implementing directory command 2000KERM*K:UTIL Fortran source for Kermit protocol primitives 2000KERM*K:VSUBS Assembler source for miscellaneous subroutines Otherwise, if you received this from Columbia University's Kermit tape or by electronic mail, you will need to compile the source code to create the KERMSRV program. In this case you should have received the following files: H100KER.DOC save this as 2000KERM*KERM.DOC H100KER.JCL save this as 2000KERM*KERM:J H100KER.F77 save this as 2000KERM*K:SOURCE H100KER.ASM save this as 2000KERM*K:VSUBS H100KER.HLP save this as 2000KERM*HARRIS and give it Public Read access Once renamed, the files are as described above. Note that the source files K:SERVE through K:UTIL are collected together into the single file K:SOURCE. Simply type "$JS KERM:J" to compile. ------------------------------------------------------------------------ WHAT IT DOES: "Kermit" programs are used to transfer files between different computers over ordinary serial communications lines. Kermits in various forms exist for almost every type of computer and operating system. One might think of Kermit of as a mutual language by which unlike systems can talk with each other. In order to transfer a file, one only needs to start a Kermit on each of the two machines and then issue simple Kermit commands to get the transfer started. Kermit has mechanisms to maintain the integrity of data even over noisy phone lines where transmissions might otherwise become garbled. A true Kermit has the ability to be both a "local Kermit" and a "remote kermit". In any Kermit session, one Kermit is local and the other is remote. In essence, the local Kermit tells the remote kermit what to do and the remote kermit obeys, regardless of which direction the file is being transferred. In this regard, KERMSRV is not a true Kermit. KERMSRV operates only as a remote Kermit and thus acts on instructions by some other local Kermit. What consequences does this have? For one, Harris to Harris transfers are not possible using KERMSRV on both ends. For another, KERMSRV cannot be used to call up another computer and initiate a file tranfer. In other words, no dial-out Kermit sessions are possible, only dial-in (or direct terminal connection) ones. Furthermore, all interaction with KERMSRV is done only through the local Kermit's "Server" commands. HOW TO USE IT: To begin with, one typically connects to the Harris as if the local computer were a terminal, using the terminal emulation capabilities of the local Kermit to do so. After signing on, the user invokes KERMSRV on the Harris, whereupon the following message will be displayed: SERVER MODE ENABLED -- type the appropriate key sequence to escape back to your local Kermit... The exact key sequence to type depends on the particular version of (local) Kermit being used. For instance, in the case of MS-Kermit on the IBM PC under DOS, one would type a ] followed by a "c" to exit terminal emulation and return to command level of MS-Kermit. Once back at command level, one can SEND or GET files, or perform various other operations using "server" commands. To get a short summary of the server commands which are implemented, try the command "remote help". ------------------------------------------------------------------------ EXAMPLE: To illustrate the use of KERMSRV, I will describe the procedure that Sam, an IBM PC user, might use to transfer files. The details when using other Kermits will differ slightly. dialogue comments -------- -------- C:> mskermit Sam invokes the DOS version of Kermit on his PC IBM PC Kermit-MS V2.29 26 May 86 Kermit-MS> set port 1 Sam sets the characteristics of his communications line with the Harris Kermit-MS> set baud 9600 Kermit-MS> set parity even Kermit-MS> connect Sam begins terminal emulation then signs onto the Harris ^G VOS 5.1.0 WU BIOSTATISTICS ENTER SIGN-ON 1234SQS SAMMY ** GOOD AFTERNOON SAM, IT'S 22 SEP 1986 13:51:21 KERMSRV Sam invokes KERMSRV on the Harris HARRIS KERMIT SERVER -- version 1.02 (Sept 86) SR [logging names of send/receive files to LO] SERVER MODE ENABLED -- type the appropriate key sequence to escape back to your local Kermit... ^]c Sam types control/] followed by the letter "C" to get back to MSKERMIT (may be different in other Kermits) Kermit-MS> REM HELP Sam requests a summary of commands that he can use . . . Kermit-MS> GET Sam prepares to transfer a file from the Harris to the PC Remote Source File: 1234QUAL*TEXTFILE Local Destination File: A:TXT.FIL receiving: in progress . . . receiving: completed Kermit-MS> SEND Sam prepares to tranfer a file from the PC to the Harris Local Source File: PC.FIL Remote Destination File: HARFILE sending: in progress . . . sending: completed Kermit-MS> REM HELP Sam forgot how to quit, so he asks for another command summary . . . Kermit-MS> BYE Sam logs off the Harris and exits back to DOS C:> [end of dialogue] ------------------------------------------------------------------------ SUMMARY OF FEATURES IMPLEMENTED AND NOT IMPLEMENTED IN VERSION 1.06 what it can do: remote operation transfer 7 bit ascii (text) files transfer file groups via wildcard send/get on-line help on-line directory information about files or file groups remote shutdown or logout debugging option to log packet traffic what it can't do: local operation terminal emulation 8th bit prefixing repeat count processing extended block check types JCL (host) commands ------------------------------------------------------------------------ WILDCARD COMMANDS: the wildcard character "?" can be used in the GET and REMOTE DIR commands to operate on groups of files. KERMSRV will attempt to match all disk areanames where ? replaces any substring of zero or more characters. For example, GET ?OO? will get the files OO, FOO, BALOON, and any others containing "OO". REMOTE DIR A? will return directory information on all areanames in the current qualifier beginning with the letter "A". ------------------------------------------------------------------------ TECHNICAL NOTES: This program, KERMSRV, was born of my need to transfer files between our aging Harris 100 and an IBM PC. It implements the "server" portion of the "Kermit" protocol, as described in version 3 of the protocol manual (see reference below). I wrote this program especially for Harris computers which are configured with a "MUX" as opposed to the more recent CNP or DMACP I/O processors, since the Pascal-based Harris Kermit which was already in existence does not accommodate such a configuration. As such, I have not taken advantage of many of the special features offered by those devices (notably timeouts and buffered I/O via "hot read"), but have opted instead for simpler, albeit less efficient, modes of communication. In any case, this program should work properly on a Harris machine in any configuration. Specifically, incoming packets are read using symbolic input mode rather than binary input mode. (For details of these modes, see the VOS I/O services manual under "TTY functions codes".) Binary mode would have been desirable in that it gives the ability to read one character at a time. However, without using "hot read" for buffering, binary reads are not fast enough to keep up at higher baud rates. Since hot I/O is not available on MUX based systems, we have to settle for the record-at-a-time symbolic input mode, and leave the buffering to VOS. The two biggest ramifications are (1) abort and other control characters cannot be trapped and processed individually, and (2) the size of the input buffer is fixed at system generation time, and is often set to 80 characters, regardless of the size of the buffer used in the $I/O call. ------------------------------------------------------------------------ REVISION HISTORY: This program was written using Harris Fortran 77 on a Harris H100-1 computer (VOS 4.1.1 operating system). It was tested at up to 9600 baud against Columbia University's "MSKERMIT" version 2.27 (see below) on an IBM PC/AT running DOS 3.0. I wrote the first version of KERMSRV in January, 1986 version 1.00 Jan, 1986, by Skip Russell : initial release version 1.01 Feb, 1986, by S.R. : brought up to version 5 of the protocol manual (dated April 1984) and tested using MSKERMIT version 2.28; also implemented the following remote commands: -- HELP command to issue summary of available remote commands -- LOGOUT ("bye") command to log off the Harris job -- DIRECTORY command to issue information about a single disk area (for now; plan to add wildcard match in future) version 1.02 Sept, 1986, by S.R. : -- implemented full DIRECTORY command (wildcard character "?") -- tested using MSKERMIT version 2.29 (dated 26 May 86) -- moved to non-SAU Fortran 77 compiler for portablity version 1.03 Nov, 1986, by S.R. : -- brought up to VOS 5.1.0 (required changes in interpretation of file access bits in "REMOTE DIRECTORY" command handler) -- fixed logic in RECVSW to correctly respond to error packets version 1.04 April, 1987, by S.R. : -- added code to allow GETs of file groups using the "?" wildcard character. version 1.05 May, 1987, by S.R. : -- Corrected error in SWOPEN. GETs of file groups failed in cases where the qualifier contained trailing blanks. The fix consisted of enclosing the file name in quotes. version 1.06 June, 1987, by S.R. : -- Added code in RDISK to distinguish between EOF and EOT. Harris disk areas containing embedded EOFs can now be sent without truncating trailing records. The EOF is sent as a record containing the string "". ------------------------------------------------------------------------ BEWARES: -- Many Harris systems treat the XOFF or control-S character as an abort character. If this is the case with your system, ensure that flow control is turned off by the local Kermit before transferring files. -- IBM PC users using MS-Kermit version 2.29 or 2.29a should note that when flow-control is turned off, a NULL character is substituted for the XOFF. Unfortunately, this is also an abort character on many Harris systems. Transfers can usually be made to work by using a RAM disk (VDISK) on the PC or lower baud rates to avoid buffer overflows, while keeping flow-control on. -- MS-Kermit 2.29a and 2.29b (IBM PC under DOS) had a bug where packets of 94 characters were sent despite the request by KERMSRV to limit the packet size to 80. The fix is to manually set the send packet- length to 80. (This has been fixed in MS-Kermit 2.30) ------------------------------------------------------------------------ REFERENCES For a complete discussion of the Kermit design philosophy and detailed descriptions of Kermit commands, see the "KERMIT USER'S GUIDE" by Frank da Cruz, Daphne Tzoar, and Bill Catchings. For a detailed description of the Kermit protocol, see the "KERMIT PROTOCOL MANUAL" by Frank da Cruz and Bill Catchings. These two documents, as well as general information about Kermit, MSKERMIT and other implementations of Kermit for almost any type of computer or operating system, are available for the cost of distribution, from: KERMIT Distribution Columbia University Center for Computing Activities 612 West 115th Street 7th Floor New York, NY 10025 or send electronic mail to: Info-Kermit-Request@CU20B.ARPA ------------------------------------------------------------------------ This document was last revised on February 25, 1988 Skip Russell Division of Biostatistics Washington University in St. Louis electronic mail address: c04689sr@WUVMD.BITNET