home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
archives
/
perkinelmeridris.zip
/
pe7kerdoc.txt
< prev
next >
Wrap
Text File
|
1986-12-08
|
27KB
|
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.