Columbia Kermit

home *** CD-ROM | disk | FTP | other *** search

/ Columbia Kermit / kermit.zip / perkinelmeridris / pe7kerdoc.txt < prev next >

Wrap

Text File | 2020-01-01 | 26KB | 624 lines

1. IDRIS KERMIT Authors: Dan L. Eisner, C. Steven Mayfield, of the Perkin-Elmer Corp. (Garden Grove, CA). Based on the C KERMIT of Bill Catchings, Bob Cattani, Chris Maio, Columbia University with fixes and contributions from many others. Bootstrap procedures coverted by Chris Lent of the Cooper Union (New York, NY) Documentation: Dan L. Eisner, Perkin-Elmer Corp.(Garden Grove, CA). Based on documentation by Walter Underwood, Ford Aerospace (Palo Alto, CA) Chris Lent, Cooper Union (New York, NY). Version: 1.1(0) Date: December 5, 1986 IDRIS PERKIN-ELMER 7000 SERIES KERMIT AT A GLANCE: Local operation: Yes Remote operation: Yes Transfers text files: Yes Transfers binary files: Yes Multiple file send: Yes ^X/^Y Interruption: No Filename collision avoidance: No Timeouts: Yes 8th-bit Prefixing: Yes Repeat character compression: Yes Alternate block check types: Yes Communications settings: Yes Terminal Emulation: No IBM Mainframe communications: Yes Transaction logging: No Debug logging: Yes Raw Transmit: No Login scripts: No Act as server: (GET,SEND,FINISH) Yes Talk to server: (GET,SEND,FINISH) Yes Advanced commands for servers: No Command/init files: No Handle file attributes: No Long Packets Support: No Sliding Windows Support: No A sample, working implementation of the Kermit "kernel" was written in the C language, and widely distributed in the Kermit Protocol Manual. This kernel was intended merely to illustrate the protocol, and did not include a "user interface", nor some of the fancy features like server support, 8-bit quoting, file warning, timeouts, etc. Several sites have added the necessary trappings to make this a production version of Kermit, usually under the UNIX operating system. The keyword style of user/program interaction favored by Kermit (program types prompt, user types command followed by operands, program types another prompt, etc) is contrary to the UNIX style, so UNIX implementations have a style more familiar to UNIX users. C versions of Kermit are running successfully on VAX and PDP-11 UNIX systems, IBM 370 compatible mainframes under Amdahl UTS, and the SUN Microsystems MC68000-based and other workstations. This version for the IDRIS system uses the same interface. NOTE After attempting to conditionalize the UNIX versions, the conditionals were not used. The required interface to IDRIS required too many changes to the UNIX version. Instead a version to complile and run on a IDRIS system was completed. A few additions to the UNIX version were added. These additions are 8-bit quoting and repeat count prefixing. 1.1 The IDRIS File system IDRIS File Specifications IDRIS filespecs are of the form $ dir1/dir2/dir3/ ... /filename where the tokens delimited by slashes form a path name, and by convention are each limited to 14 characters in length. The final token in a path is the actual file name. By convention, it is of the form name.type, but there is nothing special about the dot separating name and type; to UNIX it's just another character, and there may be many dots in a filename. In the tradition of IDRIS, here's the UNIX Kermit "man page". INAME Kermit - file transfer, virtual terminal over tty link SYNOPSIS kermit -r[diutplb] kermit -s[fdiutplb] file ... kermit -g[fdiutplb] file.... kermit -x[dviutpl] kermit -f[dtpl] DESCRIPTION Kermit provides reliable file transfer and primitive virtual terminal communication between machines. It has been implemented on many different computers. The files transferred may be arbitrary ASCII data (7-bit characters) and may be of any length. Binary (8-bit) files may also be transferred under most conditions. The file transfer protocol uses small (96 character) checksummed packets, with ACK/NACK responses and timeouts. Kermit currently uses a ten second timeout and eight retries. The IDRIS Kermit command line is in the style of TAR. The arguments are a set of flags and, if this is a Send or Get operation a list of one or more files. Kermit has four modes, Send, Receive, Get and Server. These modes are for file transfer. These modes are specified by the first flag, which should be s,r,g, or x, respectively. Exactly one mode must be specified. The d<integer number> flag (debug) makes Kermit a bit more verbose. The states Kermit goes through are printed along with other traces of its operation. A second parameter of an integer number must be present with the d flag. A value greater than 1 will cause Kermit to give an even more detailed trace. The i flag (image) allows slightly more efficient file transfer between IDRIS machines. Normally (on Kermits defined to run on IDRIS systems) newline is mapped to CRLF on output, CR's are discarded on input, and bytes are sent 7 bits. If this is set, no mapping is done on newlines, and all eight bits of each byte are sent or received. This is the default for all other Kermits. The parity is determined from the hardware or the input command line and the 8-bit quote flag is internally set with respect to the parity setting. This determination of the parity produces image transfers if the receiving or sending Kermit supports the 8-bit quote mode. If the image mode is not supported (by either side) and image mode is requested by one of the sides, the transfer is aborted and an error message is sent. The u flag (upercase) turns off the file name conversion. Normally (the default) file names are converted from lower case to upper case on transfers out of the IDRIS machine and converted from upper case to lower case when a file name is received by the IDRIS machine. The u flag when off causes the file name to be not converted (case conversion only). The t flag (turnaround) tells Kermit while in protocol mode (sending or receiving) to wait for a turnaround character (XON) from the other host after receiving every packet. This is necessary to run Kermit with a half duplex host such as an IBM mainframe. The p<char> flag (parity) allows parity to be set on outgoing packets and stripped on incoming ones. This is useful for communicating with IBM hosts or over networks, such as TELENET, that usurp the parity bit. The possible values for parity are mark, space, even, odd or none (the default). The l<device string> flag (line) specifies the tty line that Kermit should use to communicate with the other machine. This is specified as a regular filename, like "/dev/tty1". If no l option is specified, /dev/lnk0 is used. The b<integer number> flag (baud) sets the baud rate for the terminal line. This means that the baud rate of the terminal line will be set to the given speed. Valid rates are 110, 150, 300, 1200, 2400, 4800, and 9600. The normal number of stop bits is one except for 110 baud which is set to two. The v flag (verbose) allows the output of informational messages during a get operation. The number of packets are displayed along with informational messages that are normally present with the send and receive commands. The v flag also causes the version number of IDRIS Kermit to be printed. The file arguments are only meaningful to a Send or Get Kermit. The Receiving Kermit will attempt to store the file with the same name that was used to send it. IDRIS Kermits normally convert outgoing file names to uppercase and incoming ones to lower case (see the u flag). To disable this feature, turn on the u flag. If a filename contains a slash (/) Kermit will strip off the leading part of the name through the last slash. There may be multiple file names on the command line. If "wild cards" are included in the file name the command line must be passed thru the shell processor to expand the file names. The Get command passes the complete file name string to the remote processor and it is up to the remote processor to parse the file names (including wild-cards). 1.2 Program Operation EXAMPLE For this example we will assume two IDRIS machines. We are logged onto "IDRISa" (the local machine), and want to communicate with "IDRISb" (the remote machine). There is a modem on "/dev/tty3". We want to connect to "IDRISb", then transfer "file1" to that machine. We type: * cu -l/dev/tty3 -s1200 cu answers recv Now we dial the remote machine and connect the modem. Anything typed on the terminal will be sent to the remote machine and any output from that machine will be displayed on our terminal. We hit RETURN, get a "login:" prompt and login. Now we need to start a Kermit on the remote machine so that we can send the file over. First we start up the remote, (in this case receiving) Kermit, then the local, (sending) one. Remember that we are talking to IDRISb right now. We type: kermit r (there is now a Receive Kermit on IDRISb) We type \ (the escape character) and then the letter q to kill the local (Connecting) cu We type: kermit -s -l/dev/tty3 file1 Kermit answers: Sending file1 as FILE1 When the transmission is finished, Kermit will type either "Send complete", or "Send failed.", depending on the success of the transfer. If we now wanted to transfer a file from IDRISb (remote) to IDRISa (local), we would use these commands: cu -l/dev/tty3 -s1200 (connected to IDRISb) kermit -s file9 \q (talking to IDRISa again) kermit -r -l/dev/tty3 After all the transfers were done, we should connect again, log off of IDRISb, kill the Connect Kermit and hang up the phone. 1.3 IDRIS KERMIT FEATURES FEATURES Kermit can interact strangely with the tty driver. In particular, a tty with "hangup on last close" set (stty hup), will reset to 300 Baud between Kermit commands. It will also hang up a modem at that time. It is better to run with "stty -hup", and use "stty 0" to explicitly hang up the modem. The Kermit Protocol uses only printing ASCII characters, Ctrl-A, and CRLF. Ctrl-S/Ctrl-Q flow control can be used "underneath" the Kermit protocol. Since BREAK is not an ASCII character, Kermit cannot send a BREAK to the remote machine. On some systems, a BREAK will be read as a NUL. This Kermit does have timeouts when run under IDRIS, so the protocol is stable when communicating with "dumb" Kermits (that don't have timeouts). 1.4 IDRIS KERMIT ERROR MESSAGES DIAGNOSTICS Diagnostics are of three formats. "Kermit usage" are errors detected due to usage errors. "Kermit" errors are during file receiving and abort the program. Messages without a prefix are informational messages. A listing of errors follow: Kermit usage: Invalid command line. Not enough arguments Kermit was called without any arguments. Kermit usage: Cannot open <device>. The file named in the line argument did not exist or had the wrong permissions. Kermit usage: Only one command allowed -g ! r ! s ! x. The command line contained two commands. Kermit usage: Finish with server or receive? The finish flag was turned on along with the server or receive flag. This usage is incompatable with each other. The receive or server is told to finish from the remote Kermit and not from the local Kermit. Kermit usage: Improper parity call out. The command line p flag did not contain a 'n' or 'e' or 'o' or 'm' or 's'. Kermit usage: File name required. The input command line did not contain a file name as required by the requested conmmand (get or send). Kermit usage: Bad line speed. The baud rate inputed was not a valid baud rate. Kermit usage: Get failed. The Get command failed. Kermit usage: Send failed. The Send command failed. Kermit usage: Receive failed. The Receive command failed. Kermit usage: Finish failed. The Finished command failed. Get done. The Get command completed. Send done. The Send command completed. Receive done. The Receive command completed. Finish done. The Finish command completed. Requesting <inputed file name> as <converted file name> The Get command is stating the files that it will be using. If file name conversion is in effect the data output will show the conversion. The inputed file name is what the user requested, The converted file name is what the system is sending to the other system. Kermit: Cannot open file <file name> The open file request from the Send command could not be completed. The file may not exist or the user does not have access to the file. Sending <typed file name> as <converted file name> The Send command is stating the files that it will be using. Receiving <received file name> as <outputed file name> The receive processor is stating the file names that it has received and the file names it will be storing the data into. Sending <inputed file name> as <outputed file name> The send processor is stating the file names that it will be using in the send process. <integer number> / <integer number> The send packet routine is showing the total count of packets it has sent versus the total count of error packets that have been sent or received. Kermit: Abort with error from remote host: <text from remote Kermit> The remote Kermit detected an error and is notifying the local Kermit what hat error was. REMOTE ERRORS Invalid server command A g packet was received and the command has not been implemented or the command is not valid. Unknown packet type The server received a packet which it did not recognize. Cannot create <file name> The receiving Kermit could not create the file being sent to it. Cannot open file <file name> The remote server could not open the file for sending. Binary file transfer not supported The send-init parameters detected that binary file transfers were not possible. The parity bit is on and 8-bit quoting is off and image has been requested is an example of this error. The debug output messages are not listed. 1.5 INSTALLATION OF IDRIS KERMIT 1.5.1 Bootstrapping from the communication line Two methods exist for transferring the Kermit bootstrap programs to the Perkin-Elmer 7000 Series computer. One method is to use a terminal emulation package resident on the PE-7000 to "download" the two files PE7BOO.BAS and PE7KER.BOO. Perkin-Elmer supports the 'cu' command for terminal emulation with the 7000 Series computer. The 'cu' program will log characters coming into the RS-232 port, BUT ONLY if correctly instructed by the REMOTE host. The sequence is as follows: PE7000 User: Comments $ cu -l/dev/tty2 -s9600 <--User calls up terminal Emulator recv <--PE is ready termulate Remote host ready <--Remote computer prompts login:j.user password: Welcome to N-IX System 3.141592 Release 2.718 . $ # Well, let's assume some Unix-ish remote computer environment . . [ By some means the user constructs a procedure to type a backslash, a greater-than, a filename (the name the file will be on the PE-7000), and a carriage-return line-feed. The procedure then lists a file (at 1200 baud or lower) and finally types a backslash, a period and a carriage-return line-feed sequence. (Of course, all this must be done without actually typing the \> sequence during the construction!) The backslash greater-than filename sequence tell cu to start logging the terminal session to the filename given and stop displaying anything else. The terminal session will renew with the backslash period carriage-return linefeed and close the logfile.] [ Output required from remote host ] \>pe7ker.bas <---No space between > and [List the pe7ker.bas file.] <--- filename \. [On UNIX this can be done with the following Bourne shell script] $ cat >feedcu.sh # feedcu.sh # Usage feedcu.sh filename echo '\''>'$1 cat $1 echo '\''.' <control-d> $ # and that's all folks [Note that when you type the backslash in 'cu' it is not echoed until the next character is typed. ] $ # So to download pe7boo.bas go $ # Make feedcu.sh executable $ chmod 0755 feedcu.sh $ feedcu.sh pe7boo.bas \> pe7boo.sh <---- PE-7000 indicate <---- transfer in progress $ # When done check on the file. The filename on the PE-7000 may have spaces before or after it. You may have to download repeatedly to get a workable copy of pe7boo.sh $ exit [ and \q ] to quit the cu emulator. MAKE SURE TO HANG UP THE PHONE! The same procedure is repeated for pe7ker.boo, which is an text-encoded version of the pe7ker.exe program. The other manner is comparatively more simple but requires more of the remote host. First start a login running on one of the RS-232 ports of the PE-7000, as described in Vol. 2 Section 6 of the 7000 Series User's Guide. Then with some other host (usually a PC running MS-KERMIT 2.29 or above) you login to the 7000 Series system and type : $ cat >pe7boo.bas and then use the ASCII uploading function, TRANSMIT, to send the pe7boo.bas. (Most commercial terminal emulator packages have some sort of ASCII upload function.) Similarly after you've verified that pe7boo.bas was uploaded correctly, upload pe7ker.boo. 1.5.2 DECODING .BOO files Now that the files, pe7boo.bas and pe7ker.boo are on the PE-7000, type the following command: $ basic -rpe7boo.bas and after about 10 minutes the file PE7KER.EXE will be produced. Please note the file name is in UPPERCASE. The next task is to retransfer pe7ker.boo with PE7KER.EXE so that you are assure of a good working copy. Lastly, so you won't have to repeat this may a backup and put it somewhere safe and away from the computer area. Note also that the .BOO format is also used to bootstrap the MS-DOS version of Kermit and is compatible with the programs MSBPCT.BAS and MSBMKB.EXE. 1.5.3 PHONE PE7PHO.EXE is a Hayes modem control program for the PE-7000. PE7PHO.BOO is a .BOO encoded version of PE7PHO.EXE. To convert PE7PHO.BOO to PE7PHO.EXE do the following steps: [Bootstrap procedure for PE7PHO.EXE] $ basic Perkin-Elmer 7000 Series Computer Basic ver. 1.30 (c) 1983 PERKIN-ELMER All Rights Reserved (c) 1981, 1982 Hemenway Corp. All Rights Reserved ready load "pe7boo.bas" ready list 65 65 k$="pe7ker.boo":rem filename case significant ready 65 k$="pe7pho.boo" run PE7BOO.BAS Version 2.3a (Derived from IBM-PC MSBPCT.BAS) PE7PHO.EXE Outputting to PE7PHO.EXE Null: 14 Null: 2 Null: 3 Null: 2 [ And so on for five minutes ... ] Null: 4 Null: 4 Null: 5 Processing complete, elapsed time: 02:11:58 to 02:16:41 Output in PE7PHO.EXE ready system basic terminated $ chmod +x PE7PHO.EXE $ ./PE7PHO.EXE Phone usage: No arguments given. $ [End of PE7PHO.EXE bootstrap procedure ] 1.5.4 USING THE PHONE PROGRAM Phone is designed to intialize dial and hangup a Hayes modem attached to a serial port. The command line options are listed following: Usage: $ PE7PHO.EXE -i -d -v -l -b -a -p -h -c where i=init modem <flag>, d=debug level <number>, v=verbose <flag>, l=line <device>, b=baud rate <number>, a=answer <flag>, p=phone number <string>, h=hang-up request <'a' or 'o'>, c=direct connect <'a' or 'o'> 1.5.4.1 Sample session The following session show dialing with PHONE in verbose mode, connecting for a terminal session with 'cu' and then hanging up the phone with PHONE. $ PE7PHO.EXE -v -l/dev/tty0 -b1200 -p 5551212 Phone: Initializing the modem Phone: Dialing 5551212 Phone: Connect at 1200 Baud $ cu -l/dev/tty0 -s 1200 recv [ And the terminal session starts] ... [ Continues] ... [ and ends] \q <--- to quit cu type '\q' $ # Now to hangup the phone $ PE7PHO.EXE -v -l/dev/tty0 -b1200 -ho Phone: Hanging up $ # Done. [End of example] 1.6 RECOMPILING FROM SOURCE If it possible to transfer the text files which make up IDRIS Kermit and PHONE, PE7INC.H, PE7TTY.H, PE7STD.H, PE7SYS.H, PE7MAI.C, PE7PTA.C, PE7PTB.C, and PE7PHO.C, the source may be re-compiled using the shell script routines (and the optional 'C' compiler). The scripts PE7KER.MAK and PE7PHO.MAK will reproduce a PHONE and KERMIT executable. 1.7 FUTURE CONSIDERATIONS With the generality of the current UNIX C-Kermit it may be possible to merge the IDRIS Kermit into the C-Kermit distribution along the lines of the Macintosh and VAX/VMS C-Kermit's. If 'C' becomes popular on the PE-7000, more development may be seen.