@part(VMSMIT,root="KER:KUSER")
@string{-vmsversion="@q<3.2>"}
@Chapter<VAX/VMS KERMIT>
@label<-vmsk>
@Index[VAX/VMS]
@begin<description,leftmargin +12,indent -12,spread 0>
@i(Authors:)@\Robert C. McQueen, Nick Bush, Stevens Institute of Technology

@i(Language:)@\BLISS-32

@i(Version:)@\@value(-vmsversion)

@i(Date:)@\May 6, 1986
@end<description>

@subheading<VAX/VMS Kermit-32 Capabilities At a Glance:>
@begin<format,leftmargin +2,above 1,below 1>
@tabclear()@tabset(3.5inches,4.0inches)
Local operation:@\Yes
Remote operation:@\Yes
Transfers text files:@\Yes
Transfers binary files:@\Yes
Wildcard send:@\Yes
@q<^X/^Y> interruption:@\Yes
Filename collision avoidance:@\Yes
Timeouts:@\Yes 
8th-bit prefixing:@\Yes
Repeat character compression:@\Yes
Alternate block check types:@\Yes
Communication settings:@\Yes
Transmit BREAK:@\No
IBM mainframe communication:@\Yes
Transaction logging:@\Yes
Session logging:@\Yes
Debug logging:@\Yes
Raw transmit:@\No
Login scripts:@\No
Act as server:@\Yes
Talk to server:@\Yes
Advanced commands for servers:@\Yes
Local file management:@\Yes
Command/init files:@\Yes
Attribute packets:@\No
@end<format>

Kermit-32 is a program that implements the Kermit file transfer protocol for
the Digital Equipment Corporation VAX series computers under the VAX/VMS
operating system. It is written in BLISS-32 and MACRO-32, with sources for
all BLISS modules also available as MACRO-32 sources.  Kermit-32 should run
on any VAX/VMS system from version 3 on (Version 3@q<.>1 of Kermit-32
corrected some problems that appeared in earlier versions when run under
VMS version 4).

The first section of this chapter will describe the things you need to know
about the VAX/VMS file system and how Kermit-32 uses it.  The second section
describes the special features of Kermit-32.  The final section contains
information of interest to those who need to install Kermit-32 on a system.

@Section<The VAX/VMS File System>

The two main items of interest of the VAX/VMS file system (for the Kermit user)
are the format of file specifications and the types of files and file data.

@Subheading<VAX/VMS File Specifications>

VAX/VMS file specifications are of the form
@example(NODE::DEVICE:[DIRECTORY]NAME.TYPE;VERSION)
Under version 3.x of VMS, NAME may be up to 9 characters, TYPE may be up to
3 characters and each item in DIRECTORY may be up to 9 character long.  Only
alphanumeric characters may be used in DIRECTORY, NAME and TYPE.
@Comment{
Under version 4.0 (and later) of VMS, NAME, TYPE and each item in DIRECTORY
may be up to 39 characters long, and may contain alphanumeric characters plus
underscore.
}
VERSION is a decimal number indicating the version of the file (generation).
DEVICE may be either a physical or logical device name.  If it is a logical
name, it may be up to 63 characters long and may contain alphanumeric
characters plus dollar signs and underscores.  NODE may be either a logical
name which translates to a DECnet node name or a physical DECnet node name.
In either case, access information can be included (see the DECnet-VMS User's
guide for more information).
The node name is not normally present, since most files are accessed on the
same node where the user's job is running.  The version number is not
normally given (in fact, should not normally be given).  When device and/or
directory are not supplied, they default to the user's current default device
and directory.  Therefore, @q<NAME.TYPE> is normally all that is needed to
specify a file on the user's default device and directory.
This is also all the Kermit-32 will normally send as the name of a file
being transferred.

The node field specifies the name (and access information) for the DECnet
node where the file is located.  Kermit-32 does not transmit the node field
to the target system, but will attempt to honor a node field in an incoming
file name.

The device field specifies a physical or "logical" device upon which the file
is resident.  The directory field indicates the area on the device, for
instance the area belonging to the owner of the file.  Kermit-32 does not
normally transmit the device or directory fields to the target system, but will
attempt to honor device or directory fields that may appear in incoming file
names. It will not create new directories, however, so any directory must
already exist.

The name is the primary identifier for the file.  The type, also called the
"extension", is an indicator which, by convention, tells what kind of file we
have.  For instance @q<FOO.FOR> is the source of a Fortran program named FOO;
@q<FOO.OBJ> might be the relocatable object module produced by compiling
@q<FOO.FOR>; @q<FOO.EXE> could an executable program produced by LINKing
@q<FOO.REL>, and so forth.

@index<Wildcard>
VAX/VMS allows a group of files to be specified in a single file
specification by including the special "wildcard" characters, "@q<*>" and
"@q<%>".  A "@q<*>" matches any string of characters, including no characters
at all; a "@q<%>" matches any single character.  Here are some examples:
@Begin(Description,spread 0.5,leftmargin +8, indent -8)
@q<*.FOR>@\All files of type @q<FOR> (all Fortran source files) in the
default directory.
	
@q<FOO.*>@\Files of all types with name @q<FOO>.
	
@q<F*.*>@\All files whose names start with F.

@q<F*X*.*>@\All files whose names start with F and contain at least one X.

@q<%.*>@\All files whose names are exactly one character long.

@q<*.%%*>@\All files whose types are at least two characters long.
@End(Description)
Wildcard notation is used on many computer systems in similar ways, and it is
the mechanism most commonly used to instruct Kermit to send a group of files.

@heading<Text Files and Binary Files>

The file system used by VAX/VMS provides for a large number of attributes to
be associated with each file.  These attributes provide some indication of
whether the file is a text file, or is some other type of non-text data.
The two major attributes that affect Pro/Kermit are the record type and
record attribute.  The record type describes how logical records are stored
in the file.  Records may be of some fixed length (specified by another
attribute), or variable length (specified within each record), or stream
(implying no real record divisions).  The record attributes describe
how the breaks between records are to be treated.  For example, a record
attribute of implied carriage return means that any program reading the
file with intentions of printing it out should add a carriage return/line
feed sequence between each record.  Other attributes include FORTRAN
carriage control and print file format.

The "standard" method of storing text in a file under VAX/VMS is to store
one line of text per record (variable length records),
with a carriage return/line feed sequence
implied by the end of the record (implied carriage return).
This is the method Kermit-32 uses to store files it receives when
using FILE TYPE TEXT.  Note that there are other formats which are used to
store text under VAX/VMS, however, the one used be Kermit-32 is the only one
which is handled correctly by all known utility programs under VAX/VMS.  Also,
most programs which work with text files (the editor EDT, for example) place
some limit on the length of the lines which can be handled.  Typically this
is 255.  Kermit-32 can write files with up to 4095 characters on a line, which
means a text file from another system may be transferred and stored correctly
by Kermit-32, but may still be unusable by certain VAX/VMS programs.

There is no standard format for storing binary files.  Basically, any record
format with no record attributes are used for binary files.  Since programs
which work with binary files under VAX/VMS expect to see some particular
format, more infomation is needed for transfer of binary files than for
transfer of text files.  The current version of Kermit-32 is not capable of
transferring all types of binary files which were created on a VAX/VMS system
to another system and retrieving them intact, nor is it capable of transferring
all of types binary files created on a VAX/VMS system to another VAX/VMS, P/OS,
or RSX-11M/M+ system intact.  However, certain formats of binary files can be
transferred, and binary files from some other systems may be transferred to a
VAX and recovered intact.

Binary files which are created on a VAX (or other Files-11 systems)
with fixed 512 byte records (a fairly common format) can be transferred
using Kermit-32.  The only required action is to set the file type
to "fixed" in the receiving Kermit-32.

Using two programs supplied with Kermit-32, it is possible to
transfer almost any type of sequential file between VAXen, or
between a VAX and a P/OS or RSX-11M/M+ system.  These two
programs (VMSHEX and VMSDEH) will convert the binary files to text
(using a variation on Intel hex format).  The resulting text file
can be transferred like any other, and finally "dehexified" reproducing
the original file, with the major attributes intact.  Unfortunately,
the text files tend to be about twice the size of the original binary
files, so the transfers take a bit longer than regular text files.
On the plus side, the
text versions of the files can be transferred to any system
with a Kermit and still retrieved intact.  They can also be transferred
over 7-bit data paths without any problems.
The bootstrap procedure (described below), makes use of hexified versions
of the binary file which makes up Kermit-32.

@heading<Using the VAX to Archive Microcomputer Files>

You can use Kermit to send textual files from a microcomputer or any 8-bit
system to a VAX/VMS system with no special provisions, since Kermit-32 stores
incoming files as text files (variable length records with implied carriage
returns) unless it is explicitly told otherwise.
But Kermit-32 has no automatic way of distinguishing an incoming
binary file from an incoming text file.
It turns out that because of the method used by Kermit-32 for storing text
files, a binary file can be stored like a text file so long as it does not
contain a string of more than 4095 characters between carriage return, line
feed sequences, and ends with a carriage return line feed.  Since most binary
files do not have these characteristics, you must inform Kermit-32 that a file
it is about to receive is to be stored as a binary file.
This is done using the SET FILE TYPE BINARY command.  This instructs Kermit-32
to store the data it receives in the file without checking for carriage return,
line feed sequences.  The file it creates will be variable record length, with
no record attributes.  Each record will contain 510 bytes of data, except the
last, which will contain whatever amount is left before the end of the file.
This allows Kermit-32 to correctly return exactly the data it was sent when
the file is returned to the original system.

Note that because of the need to use a different file type for binary files,
it is not possible to use a "wildcard send" command to
send a mixture of text and binary files to a VAX system unless the text files
are not intended for use on the VAX;
rather, you must send all text files with Kermit-32's file type set
to text, and all binary files with the file type set to binary.

Once you get the foreign file into the VAX system, stored with the correct
file type, you need take no
special measures to send it back to its system of origin.  This is because
Kermit-32 honors the record type and attributes of the file as it is stored
on the VAX.  In fact, SET FILE TYPE BINARY or TEXT only affects how Kermit-32
receives files - it does not affect how Kermit-32 transmits files.

@heading<Files Kermit-32 Cannot Handle>

The Kermit protocol can only accommodate transfer of @i<sequential> files,
files which are a linear sequence of bytes (or words).

Some files on a VAX/VMS system are not sequential,
and cannot be successfully sent or
received by Kermit-32.  These are mainly indexed data files, but can also
include other files which require more than just the data in the file to be
completely reconstructed.
External control information
and file attributes are not transmitted.

@Section<Program Operation>

Kermit-32's prompt is normally "@q(Kermit-32>)".
If a foriegn command is defined to run Kermit-32 (eg. KERMIT := $KERMIT),
Kermit-32 will accept a single command on the command line, like this:
@begin[example]
$
$ @ux[Kermit send foo.bar]

  @i(the file is sent)

$
$ @ux[MCR Kermit send foo.bar]

  @i(the file is sent)

$
@End(Example)
You can run the program interactively to issue several commands, like this:
@Begin(Example)
$
$ @ux[Run SYS$SYSTEM:Kermit]
VMS Kermit-32 version @value(-vmsversion)
Default terminal for transfers is: _TTA1:

Kermit-32>@ux[send foo.*]

  @i(files are sent)

Kermit-32>@ux[statistics]

  @i(performance statistics are printed)

Kermit-32>@ux[receive]

  @i(files are received)

Kermit-32>@ux[exit]
$
@end[example]

Command keywords may be abbreviated to their shortest prefix that sets them
apart from any other keyword valid in that field.

Kermit-32 provides most of the commands possible for an "ideal" Kermit program,
as described in the main part of the @i(Kermit User Guide).  The following
sections will concentrate on system-@|dependent aspects of Kermit-32.

@section<Conditioning Your Job for Kermit>

@index<Interference>
@index<Message Interference>
Kermit-32 does as much as it can to condition your line for file transfer.
It saves all your terminal settings, and restores them after use.
However, there are some sources of interference over which Kermit-32 has
no control.  In particular, messages issued by other processes in your
job could
become mingled with Kermit packets and slow things down or stop them entirely.
This is a fairly rare occurance and can be easily avoided by not running any
other process which wishes to perform I/O to your terminal while you are
running Kermit-32.

Normally, when Kermit-32 is run, it assumes you wish to use it in remote mode
and perform file transfers over the terminal line which controls your job.
This can be overridden, however, by defining a logical name which equates to
some other terminal line in the system.  The default terminal line to be used
for file transfers is determined by the first of the following logical names
which translates to a terminal line which is available for use by your
process: KER$COMM, SYS$INPUT, SYS$OUTPUT, and SYS$COMMAND.  If none of these
logical names translate to an available terminal line, there is no default
terminal line and a SET LINE command must be used before any transfer command
is performed.  Note that this is the typical case in a batch job.

Kermit-32 will also default the type of parity to be used on the communication
line to that which is set on its default terminal line when it is started.
This means that if all communication at a site is normally done using even
parity (for example), Kermit-32 will also use even parity.

There are two things to keep in mind when using Kermit-32 in local mode (where
the file transfers are done over a different terminal line from where commands
are typed):
@begin(itemize,spread 0.5)
Under VAX/VMS, every terminal line has an owner UIC and protection code
associated with it.  This UIC and protection is used to determine who can
allocate (and therefore use) the terminal line when they are not logged in
on that line.  Therefore, in order for Kermit-32 to be able to perform
file transfers over a terminal line other than the one on which you are
logged in, the field of the protection code for the terminal which applies
to your job (based on your UIC and the owner UIC of the terminal) must allow
your job access to the terminal.  You may need to request your system manager
to change the protection for a terminal line to allow you to use it with
Kermit-32 in local mode.

Terminal lines which have been declared as modem control lines will have the
phone "hung up" whenever the terminal line becomes free (deallocated).  This
means that if you do not use the DCL ALLOCATE command to allocate the terminal
line to your job before entering Kermit-32, exiting Kermit-32 will cause the
terminal line to "hang up" the modem.  If you do wish to get to DCL after
having used Kermit-32 to connect a modem control line which you do not have
allocated, you can use the PUSH command to spawn a subprocess running DCL.
@end<itemize>

@Section<Kermit-32 Commands>

This section describes the Kermit-32 commands -- in detail where they differ
from the "ideal" Kermit, briefly where they coincide.  Kermit-32 has the
following commands:
@Begin(Format,spread 0)
@tabclear()@tabset(1.25inches)
@>@@@\  synonym for "take".
@>BYE@\  to remote server.
@>CONNECT@\  as terminal to remote system.
@>EXIT@\  from Kermit-32.
@>FINISH@\  Shut down remote server.
@>GET@\  remote files from server.
@>HELP@\  with Kermit-32.
@>LOCAL@\  prefix for local file management commands.
@>LOG@\  remote terminal session.
@>LOGOUT@\  remote server.
@>PUSH@\  to DCL command level.
@>QUIT@\  from Kermit-32.
@>RECEIVE@\  files from remote Kermit.
@>REMOTE@\  prefix for remote file management commands.
@>SEND@\  files to remote Kermit.
@>SERVER@\  mode of remote operation.
@>SET@\  various parameters.
@>SHOW@\  various parameters.
@>STATISTICS@\  about most recent file transfer.
@>TAKE@\  Kermit-32 commands from a file.
@End(format)

@subsection<Commands for File Transfer>

Kermit-32 provides the standard SEND, RECEIVE, and GET commands for
transferring files using the Kermit protocol.

@Heading<The SEND Command>
@Index[Initial Filespec]@Index[SEND]
Syntax: 

Sending a file or files:
 @display(@q<SEND @i{filespec}>)

The SEND command causes a file or file group to be sent from the VAX to the
other system.
If @i{filespec} contains wildcard characters then all matching files will be
sent, in alphabetical order (according to the ASCII collating sequence) by
name.
If @i{filespec} does not contain any wildcard characters, then the single file
specified by @i{filespec} will be sent.

@Subheading<@ @ SEND Command General Operation:>

@Index<Normal Form for File Names>
Files will be sent with at least their VAX/VMS file name and type
(for instance @q<FOO.BAR>).  If a SET FILE NAMING FULL command has been given,
Kermit-32 will also send the device name, directory name and version number
(for instance @q<USER$DISK:[JOE]FOO.BAR;25>).  If a SET FILE NAMING
UNTRANSLATED command has been given, Kermit-32 will send the file name, type
and version number (for instance @q<FOO.BAR;25>).  If a SET FILE NAMING
NORMAL_FORM command has been given (this is the initial default), Kermit-32
will only send the file name and type.

Each file will be sent according to the record type and attributes recorded
in its file descriptor.  Kermit-32 attempts to translate all formats of
text file (including those with FORTRAN or print carriage control) to a
format usuable on any system.  Note that there is no need to set the
FILE TYPE parameter for sending files, since Kermit-32 always uses the
information from the file descriptor to determine how to send the file.

@Index<Parity>@Index<Eighth-Bit Prefix>@Index<Binary Files>
If communication line parity is being used (see SET PARITY), Kermit-32 will
request that the other Kermit accept a special kind of prefix notation for
binary files.  This is an advanced feature, and not all Kermits have it; if the
other Kermit does not agree to use this feature, binary files cannot be sent
correctly.  This includes executable programs (like @q<.EXE> files, CP/M
@q<.COM> files), relocatable object modules (@q<.OBJ> files), as well as any
text file containing characters with the eighth bit on.

@Index<Repeated Character Compression>
Kermit-32 will also ask the other Kermit whether it can handle a special prefix
encoding for repeated characters.  If it can, then files with long strings of
repeated characters will be transmitted very efficiently.  Columnar data,
highly indented text, and binary files are the major beneficiaries of this
technique.

If you're running Kermit-32 locally, for instance dialing out from a VAX
to another system using an autodialer, you should have already run Kermit on
the remote system and issued either a RECEIVE or a SERVER command.
Once you give Kermit-32 the SEND command, the name of each file will be
displayed on your screen as the transfer begins.
If the file is successfully transferred, you will
see "@q<[OK]>", otherwise there will be an error message.

During local operation, you can type Control-A@Index<Control-A> at any point
during the transfer to get a brief status report.
@index<Control-X>@index<Control-Z>@Index<Cancelling a File Transfer> You may
also type Control-X or Control-Z to interrupt the current file or file group.

@Heading<The RECEIVE Command>
@Index[RECEIVE]
Syntax:  @q<RECEIVE [@i{filespec}]>

The RECEIVE command tells Kermit-32 to receive a file or file group from the
other system.  If only one file is being received, you may include the optional
@i{filespec} as the name to store the incoming file under; otherwise, the name
is taken from the incoming file header.  If the name in the header is not
a legal VAX/VMS file name, Kermit-32 will normally replace the illegal
characters with "X" (see SET FILE NAMING NORMAL_FORM).

@index<DELETE>@index<UNDELETE>@index<Version>
If an incoming file has the same name as an
existing file, Kermit-32 just creates a new version of the same name and
type, for instance @q<FOO.BAR;3, FOO.BAR;4>.

Incoming files will all be stored with the prevailing file type,
ASCII by default,
which is appropriate for text files.  @Index<Binary Files> If you are asking
Kermit-32 to receive binary files from a microcomputer or other 8-bit system,
you must first type SET FILE TYPE BINARY.  Otherwise, an error may occur
when receiving the file, or a carriage return, line feed will be added to
the end of the file and the file will be useless when sent back to the system
of origin.

@Index<Parity>@Index<Eighth-Bit Prefix>
If parity is being used on the communications line,
then 8th-bit prefixing will be requested.  If the other
side cannot do this, binary files cannot be transferred correctly.

If an incoming file does not arrive in its entirety, Kermit-32 will normally
discard it; it will not appear in your directory.  You may change this behavior
@Index<Incomplete File Disposition>
by using the command SET INCOMPLETE KEEP, which will cause as much of the file
as arrived to be saved in your directory. 

If you are running Kermit-32 locally, you should already have issued a
SEND command @foot(@i<not> SERVER -- use the GET command to receive files from
a Kermit server.) to the remote Kermit, and then escaped back to Kermit-32.
As files arrive, their names will be displayed on your screen.
You can type Control-A during the transfer for a brief status report.

@Index<Control-X>@Index<Control-Z>@Index<Cancelling a File Transfer>
If a file arrives that you don't really want, you can attempt to cancel it
by typing Control-X; this sends a cancellation request to the
remote Kermit.  If the remote Kermit understands this request (not all
implementations of Kermit support this feature), it will comply;
otherwise it will continue to send.  If a file group is being sent, you can
request the entire group be cancelled by typing Control-Z.

@Heading<The GET Command>

Syntax: @q<GET [@i{remote-filespec}]>

The GET command requests a remote Kermit server to send the file or file group
specified by @i<remote-filespec>.  This command can be used only when Kermit-32
is local, with a Kermit server on the other end of the line specified by SET
LINE.  This means that you must have CONNECTed to the other system, logged in,
run Kermit there, issued the SERVER command, and escaped back to the VAX.

The remote filespec is any string that can be a legal file specification for
the remote system; it is not parsed or validated locally.  Any leading spaces
before the remote filespec are stripped, and lower case characters are raised
to upper case.

As files arrive, their names will be displayed on your screen.
As in the RECEIVE command, you may type Control-A to get a brief status
report, ^X to
request that the current incoming file be cancelled, ^Z to request that the
entire incoming batch be cancelled.

If the remote Kermit is not capable of server functions, then you will probably
get an error message back from it like "Illegal packet type".  In this case,
you must connect to the other Kermit, give a SEND command, escape back, and
give a RECEIVE command.

@Heading<The STATISTICS Command>
Give statistics about the most recent file transfer.

@Heading<The TAKE Command>

Syntax: @q(TAKE )@i<filespec>

The TAKE command tells Kermit-32 to execute commands from the specified
file.  You may also use the VMS notation "@@" to specify a command file.

@subsection<Server Operation>

@Heading<The SERVER Command>
@Index<Server>

The SERVER command puts a remote Kermit-32 in "server mode", so that it
receives all further commands in packets from the local Kermit.  The Kermit-32
server is capable (as of this writing) of executing the following remote server
commands:  SEND, GET, FINISH, BYE, REMOTE DIRECTORY, REMOTE CWD,
REMOTE SPACE, REMOTE DELETE, REMOTE TYPE, REMOTE HELP, REMOTE COPY,
REMOTE RENAME, REMOTE SEND_MESSAGE, REMOTE WHO, and REMOTE HOST.

Any nonstandard parameters should be selected with SET commands before putting
Kermit-32 into server mode, in particular the file type. The Kermit-32
server can send all files in the correct manner automatically.
However, if you need to ask Kermit-32
to receive binary files you must issue the SET FILE TYPE BINARY
command before putting it into server mode, and then you must only send
binary files.  You cannot send a mixture of text files and 8-bit binary files
to a Kermit-32 server unless the files are not for use on the VAX.

@Heading<Commands for Servers>

When running in local mode, Kermit-32 allows you to give a wide range of
commands to a remote Kermit server, with no guarantee the that the remote
server can process them, since they are all optional features of the protocol.
Commands for servers include the standard @q<SEND>, @q<GET>, @q<BYE>,
@q<LOGOUT> and @q<FINISH> commands, as well as the @q<REMOTE> command.

Syntax: @q<REMOTE @i{command}>

Send the specified command to the remote server.  If the server does not
understand the command (all of these commands are optional features of the
Kermit protocol), it will reply with a message like "Unknown Kermit server
command".  If does understand, it will send the results back, and they will be
displayed on the screen.  The REMOTE commands are:
@begin<description>
COPY @i<filespec>@\Copy file.  The server is asked to make a copy of the
specified file.  Kermit-32 will prompt for the new file name on a separate
line.  Both filespecs must be in the correct format for the remote system.
Kermit-32 does not parse or validate the file specifications.  Any leading
spaces will be stripped and lower case characters converted to upper case.
Note that this command simply provides for copying a file within the server's
system - it does not cause a file to be transferred.

CWD [@i<directory>]@\Change Working Directory.  If no directory name is
provided, the server will change to the default or home directory.  Otherwise,
you will be prompted for a password, and the server will attempt to change to
the specified directory.  The password is entered on a separate line, and does
not echo as you type it.  If access is not granted, the server will provide a
message to that effect.  Note that while not all server Kermits require
(or accept) a password to change the working directory, Kermit-32 will always
ask for one when a directory name is provided.

DELETE @i<filespec>@\Delete the specified file or files.  The names of the
files that are deleted will appear on your screen.

DIRECTORY [@i<filespec>]@\The names of the files that match the given
file specification will be displayed on your screen, perhaps along with size
and date information for each file.  If no file specification
is given, all files from the current directory will be listed.

DISK_USAGE [@i<directory>]@\Display information about disk usage in the
given directory (or by the given user).  If no directory is provided,
disk usage information is provided for the current working directory (or user).
This is the same as the REMOTE SPACE command.

EXIT@\Requests the
server to leave Kermit, allowing the terminal to be used for normal commands.

FINISH@\Requests the server to return to the Kermit prompt, allowing statistics
to be obtained about the transfers.

HELP [@i<topic>]@\Provide information about the given topic.  If no topic is
given, provide a list of the functions that are available from
the server.  Some servers may ignore the topic and always display the same
information.

HOST [@i<command>]@\Pass the given command to the server's host command
processor, and display the resulting output on your screen.

LOGIN @i<user-id>@\Supply information to the server Kermit to indicate what
user-id, account and password are to be used.  The server Kermit may use
this to validate the user's access to the system as well as for billing
purposes. It may also use this information to provide the user with access
to files on its system.

LOGOUT@\Request the server to exit Kermit and logout its job (or process).
This command is identical to the LOGOUT command.

RENAME @i<filespec>@\Change the name on the specified file (or files).
Kermit-32 will prompt for the new file specification on the next line.
Both file specifications must be valid for the server's system.

SEND_MESSAGE @i<destination-address>@\Request the server to send a single
line message to the specified destination address (which might be a
user-id, terminal designator, or some other item, depending upon the server
Kermit).  Kermit-32 will prompt for the single line message on the next line.

SPACE [@i<directory>]@\Display information about disk usage in the
given directory (or by the given user).  If no directory is provided,
disk usage information is provided for the current working directory (or user).
This is the same as the REMOTE DISK_USAGE command.

STATUS@\Display information about the status of the server.

TYPE @i<filespec>@\Display the contents of the specified file on your screen.

WHO [@i<user-id>]@\Display information about the given user.  If no user-id
is given, display information about the currently active users.  Kermit-32
will prompt for options for selecting what information to display and/or
formatting parameters.  The format of both the user-id and the options
are dependent upon the server Kermit.
@end<description>

@Subsection<Commands for Local File Management>

Syntax: @q<LOCAL [@i{command}]>

Execute the specified command on the local system -- on the VAX/VMS system
where Kermit-32 is running.  These commands provide some local file management
capability without having to leave the Kermit-32 program.
These commands are very similar to the REMOTE commands in function and syntax.
They are all executed locally, and are available when Kermit-32 is either
local or remote.  The arguments to these commands are the same as the
arguments expected from the user Kermit when Kermit-32 is processing a
command in server mode.
@begin<description>
COPY @i<filespec>@\Make a copy of the given file (or files).  Kermit-32
will prompt for the new file specification.  The command is actually
performed by using the DCL COPY command (COPY/LOG @i<old-file> @i<new-file>),
and any options which are valid on the DCL COPY command may be included.

CWD [@i<directory>]@\Change working directory, or, in VAX/VMS terminology,
change the default device/directory.  This command takes the same arguments
as the DCL SET DEFAULT command (i.e., a device and directory, only a
directory, or only a device).  If no argument is given, the default
device and directory are reset to that in effect when Kermit-32 was run.
The new default device and directory will be typed out.

DELETE @i<filespec>@\Delete the specified file or files.  This command
is performed by using the DCL DELETE command (DELETE/LOG @i<filespec>).
Therefore, any options which are valid on the DCL DELETE command
may be included.

DIRECTORY [@i<filespec>]@\Provide a directory listing of the specified files.
This command is performed by using the DCL DIRECTORY command
(DIRECTORY @i<filespec>), so any options valid for the DCL DIRECTORY command
may be included.

DISK_USAGE [@i<uic>]@\Display disk usage information for the given UIC.  If
no UIC is given, display disk usage information for the process UIC.
This command is performed by using the DCL SHOW QUOTA command (SHOW QUOTA or
SHOW QUOTA/USER=@i<uic>).

HELP@\Display the help message describing the server commands which are
available.

HOST @i<DCL command>@\Perform the given DCL command.  The command should
not perform any action which will require more input.  Any output resulting
from the command will be typed on the terminal.

RENAME @i<filespec>@\Change the name of the specified file.  Kermit-32
will prompt for the new name on the next line.  This command is performed
by using the DCL RENAME command (RENAME/LOG @i<old-file> @i<new-file>), so
any options which are valid on the DCL RENAME command may be included.

SEND_MESSAGE @i<terminal-name>@\Send a single line message to the given
terminal.  Kermit-32 will prompt for the message on the next line.  Since
this command is performed using the DCL REPLY command
@example(REPLY/TERMINAL=@i<terminal-name> "@i<message>")
OPER priveleges are needed to perform it.

TYPE @i<filespec>@\Display the contents of the specified file or
files at your terminal.
Each file will be preceded by its name in angle brackets.
@end<description>

@Subsection<The CONNECT Command>

Syntax: @q<CONNECT [@i{terminal-name}]>

Establish a terminal connection to the system connected to the terminal line
specified here or in the most recent SET LINE command, using full duplex
echoing and no parity unless otherwise specified in previous SET commands.  Get
back to Kermit-32 by typing the escape character followed by the letter C.  The
escape character is Control-Close-Square-Bracket (@q<^]>) by default.
When you type the escape character, several single-@|character commands
are possible:

@Begin(Description,leftmargin +6,indent -4, spread 0)
@q<C>@\Close the connection and return to Kermit-32.

@q<Q>@\If a session log is active, temporarily Quit logging.

@q<R>@\Resume logging to the session log.

@q<S>@\Show status of the connection.

@q<0>@\Send a null character.

@q<?>@\List all the possible single-character arguments.

@q<^]> (or whatever you have set the escape character to be):@\Typing the
escape character twice sends one copy of it to the connected host.
@End(Description)
You can use the SET ESCAPE command to define a different escape character, and
SET PARITY, and SET LOCAL_ECHO to change those
communication-@|line-@|oriented parameters.
Type the SHOW LINE command for information
about your current communication settings.

Kermit-32 does not have any special autodialer interface.  It assumes that the
connection has already been made and the line assigned.  

@Subsection<The SET and SHOW Commands>

@Heading<The SET Command>

Syntax: @q<SET @i{parameter} [@i{option} [@i{value}]]>

Establish or modify various parameters for file transfer or terminal
connection.  You can examine their values with the SHOW command.  The following
parameters may be SET:
@Begin(Format,spread 0)
@tabclear()@tabset(2.0inches)
@>BLOCK_CHECK@\  Packet transmission error detection method
@>DEBUGGING@\  Record or display state transitions or packets
@>DELAY@\  How long to wait before starting to send
@>ESCAPE@\  Character for terminal connection
@>FILE@\  For setting file parameters like file type
@>HANDSHAKE@\  For establishing half duplex line turnaround handshake
@>IBM_MODE@\  For communicating with an IBM mainframe
@>INCOMPLETE_FILE@\  What to do with an incomplete file
@>LINE@\  Terminal line to use for file transfer or CONNECT
@>LOCAL_ECHO@\  For terminal connection, ON or OFF
@>MESSAGE@\  The type of typeout to be done during transfers
@>PARITY@\  Character parity to use
@>PROMPT@\  Change the program's command prompt
@>RECEIVE@\  Various parameters for receiving files
@>REPEAT_QUOTE@\ Character to use for repeat compression
@>RETRY@\  How many times to retry a packet before giving up
@>SEND@\  Various parameters for sending files
@end(Format)

Those SET commands which differ from the "ideal" Kermit are now described in
detail.

@Subheading<SET DEBUGGING>
@Index<Debugging>
Syntax: @q<SET DEBUGGING @i{options}>

Record the packet traffic, either on your terminal or in a file.  Some
reasons for doing this would be to debug a version of Kermit that you are
working on, to record a transaction in which an error occurred for evidence
when reporting bugs, or simply to vary the display you get when running
Kermit-32 in local mode.  Options are:
@Begin(Description)
ON@\Display each incoming and outgoing packet (lengthy).

OFF@\Don't display or record debugging information (this is the normal mode).
If debugging was in effect, turn it off.
@End(Description)
The debugging information is recorded in the file specified by the most recent
LOG DEBUGGING command.

@Subheading<SET ESCAPE>
@Index<Escape Character for CONNECT>
@q<SET ESCAPE @i{octal-number}>

Specify the control character you want to use to "escape" from remote
connections back to Kermit-32.  The default is 35 (Control-]).  The number is
the octal value of the ASCII control character, 1 to 37 (or 177), for instance
2 is Control-B.  After you type the escape character, you must follow it by a
one of the single-@|character "arguments" described under the CONNECT command,
above.

@Subheading<SET FILE>
Syntax: @q<SET FILE @i{parameter keyword}>

Establish file-related parameters:
@Begin(Description,leftmargin +8,indent -8)
TYPE @i<keyword>@\@Index<File Type>Type of file for VAX/VMS file output.
The choices are ASCII, BINARY, or FIXED.
@Begin(Description,leftmargin +8,indent -8)
ASCII@\Store the file as a standard VAX/VMS text file.  Any file received
is stored as variable length records with carriage return, line feed sequences
implied between records.  This is the format preferred by most utility programs
under VAX/VMS.  An error will occur if any line is more than 4096 characters
long.  Note that lines are only terminated by carriage return, line feed
sequences.  A carriage return that is not followed by a line feed or a line
feed that is not preceded by a carriage return is not considered the end of a
line, and is included within the body of a record.

BINARY@\Store the file as a binary file.  Any file received is stored as
variable length records with no record attributes.  Kermit-32 actually will
write 510 bytes in each record except the last.  This makes each record take
up one disk block (510 data bytes plus two bytes of record length).  The
last record is written containing only as much data is left to the end of the
file.  Any file which is just a stream of bytes can be stored as a BINARY file,
and recovered intact later.  This is the preferred file type for use in
archiving files.

FIXED@\Store the file as a fixed length binary fle.  Any file received is
stored as fixed length 512 byte records with no record attributes.  This is
the format used for binary files such as VAX/VMS "EXE" files and RSX-11M/M+
"TSK" files.  Since even the last record of the file is written with 512
bytes (even if it is not filled), this format does not necessarily maintain
the correct length of a file.  It should normally only be used for files
which are coming from a VAX/VMS system which are currently stored in fixed
512 byte records.
@End(Description)

@Index<Normal Form for File Names>
NAMING @i<keyword>@\Determine the form of names to be sent with outgoing
files and determine the translation performed on incoming file names.
The choices are FULL, NORMAL_FORM and UNTRANSLATED.
@Begin(Description,leftmargin +8,indent -8)
FULL@\Kermit-32 will send full file names (including device, directory,
file name, file type and version number).  When receiving a file, Kermit-32
will perform no translation of the file name (which must therefore be a
legal VAX/VMS file specification).

NORMAL_FORM@\Kermit-32 will send only the file name and file type. When
receiving a file, Kermit-32 will convert the file specification received to
contain only uppercase letters, digits, and at most one period.  Any other
characters will be translated to "@q<X>".  There will be at most 9 characters
before the period (if any), and at most 3 characters afterwards.  This forces
the file name to be a valid VAX/VMS file specification.  Note that standard
VAX/VMS file names and types are already normal form, and therefore do not
need translation.  This is the default.

UNTRANSLATED@\Kermit-32 will send only the file name and file type. When
receiving a file, Kermit-32 will not perform any conversions on the
file specification, which therefore must be a legal VAX/VMS file specification.
@End(Description)
@End(Description)

@subheading<SET HANDSHAKE>
@index<Handshake>
Syntax: @q<SET HANDSHAKE @i(o)>

Sets the half duplex line turnaround handshake character to the ASCII
character whose octal value is @i(o).  Normally required for communication
with half duplex systems like IBM mainframes.

@subheading<SET IBM_MODE>
@index<IBM>
Syntax: @q<SET IBM_MODE ON @i(or) OFF>

When IBM_MODE is set to ON, Kermit-32 will override the parity and local echo
settings and use odd parity, local echo on, and also enable a handshake
character of XON (control-Q, ASCII 021 octal).  This feature allows Kermit-32
to talk with certain systems (notably some IBM mainframes), which require
waiting for a XON before sending data.

The various features selected by this command can be overriden subsequently
by SET PARITY, SET LOCAL_ECHO, and SET HANDSHAKE commands.

@Subheading<SET LINE>
Syntax: @q<SET LINE [@i(terminal-name)]>

Specify the terminal name to use for file transfer or CONNECT; the
@i<terminal-name> can be up to 16 characters long.
If you issue this command using other than your job's controlling terminal,
you will be running Kermit-32 @i<locally>, and you
must log in to the remote system and run Kermit on that side in order to
transfer a file.  If you don't issue this command, Kermit-32 determines whether
it is to run locally or @i<remotely> based on the default terminal line
found when Kermit-32 is started.  Kermit-32 uses a list of logical names to
determine which terminal should be the default terminal line.  The first of
these names which translates to a terminal which is available (i.e., not
allocated by some other process) is used.  The logical names Kermit-32 tries
are KER$COMM, SYS$INPUT, SYS$$OUTPUT, and SYS$COMMAND.  If none of these
translate to an available terminal, Kermit-32 is running @i<detached>, and
a terminal must be specified by the SET LINE command before any actions
can be performed.  If a terminal is found, Kermit-32 is running locally
if this is a terminal other than the one controlling the job (i.e., different
from SYS$COMMAND), otherwise Kermit-32 is running remotely.
You can also select the line directly in the CONNECT command;
the command @example(CONNECT TTA0) is equivalent to
@begin<example>
SET LINE TTA0
CONNECT
@end<example>

If you type SET LINE with no argument, you will deassign any previous
assigned line and revert to remote mode.

@subheading<SET SERVER_TIMOUT>
Syntax: SET SERVER_TIMEOUT @i<number>

This specifies the number of seconds between
timeouts during server command wait, 0 specifies that no timeouts should occur
during server command wait.  When a Kermit server times out, it sends a NAK
packet.  Some systems cannot clear piled-@|up NAKs from their input buffers; if
you're using such a system to communicate with a Kermit-32 server, and you
expect to be leaving the server idle for long periods of time, you should use
this command to turn off server command-@|wait timeouts.

@Heading<The SHOW Command>
@Index<SHOW>
Syntax: @q<SHOW> [@i<option>]

The SHOW command displays various information:
@Begin(Description,spread 0.5)
ALL@\All parameters.

BLOCK_CHECK_TYPE@\The block check type being requested.

COMMUNICATIONS@\Parameters affecting the terminal line being used for
communication.

DEBUGGING@\Debugging mode in effect, if any.

DELAY@\The number of seconds Kermit-32 will delay before starting a SEND or
RECEIVE command when in remote mode.

ESCAPE@\The current escape character for the CONNECT processing.

FILE_PARAMETERS@\File type, file naming, and incomplete file disposition.

INCOMPLETE_FILE_DISPOSITION@\The action to take when a transfer is aborted.

LINE@\Terminal line in use.

LOCAL_ECHO@\Whether characters should be echoed locally when CONNECTed.

PACKET@\For incoming and outbound packets.

PARITY@\The parity type in use.

RECEIVE@\For inbound packets.

RETRY@\The number of retries to be done on bad packets.

SEND@\For outbound packets.
@End(Description)

@subsection<Program Management Commands>
@Heading<The HELP Command>

Syntax: @q<HELP [@i{topic} {@i<subtopic>}]> 

Typing HELP alone prints a brief summary of Kermit-20 and its commands.
You can also type
@Begin(Example)
HELP @i<command>
@End(Example)
for any Kermit-20 command, e.g. "help send" or "help set parity" to get more
detailed information about a specific command.

@Heading<The EXIT and QUIT Commands>
@Index<EXIT>@Index<CONTINUE>@Index<Control-C>
Syntax: @q<EXIT>

Exit from Kermit-32.
You can also exit from the Kermit-32 when it is waiting for a command by
typing a control-Z.  When Kermit-32 is running remotely, two control-Y's
will abort the transfer, bringing Kermit-32 back to command mode.  The
two control-Y's must be typed together, as if a timeout occurs between them
the first is ignored.  When Kermit-32 is running locally, two control-Y's
will stop Kermit-32 and return you to DCL.  You will be able to CONTINUE
if you do not perform any command which runs a program.  However, after
continuing, control-A, control-X and control-Z will no longer be accepted
as commands.

@Index<QUIT>
@q<QUIT> is a synonym for EXIT.

@Heading<The LOG Command>

Syntax: @q<LOG> [@i<option> [@i<filespec>]]

Log the specified option to the specified file:
@begin<description>
SESSION@\During CONNECT log all characters
that appear on the screen to the specified file.  During CONNECT, the session
log can be temporarily turned off during the remote session by typing the
escape character followed by Q (for Quit logging), and turned on again by
typing the escape character followed by R (for Resume logging).

TRANSACTIONS@\During file transfer, log the progress of each file.
Transaction logging is recommended for long or unattended file transfers, so
that you don't have to watch the screen.  The log may be inspected after the
transfer is complete to see what files were transferred and what errors may
have occurred.

DEBUGGING@\Log debugging info to the specified file.
If no SET DEBUGGING command was previously issued, the file will be opened
and no information written.  If DEBUGGING is turned on (either via the
SET DEBUGGING command or by typed control-D during a local transfer), the
packet debugging information will be written to the file.
Packet format
is described in the @i<Kermit Protocol Manual>.

@end<description>
Any log
files are closed when you EXIT or QUIT from Kermit.
You may explicitly close a log file and terminate
logging by using the LOG command without a file specification.

@Section<Raw Download>

@index<Raw Download>
"Raw Download" is the term commonly used to describe the capture of a remote
file on the local system, without any kind of error detection or correction.
This allows you to obtain files from remote systems that do not have Kermit,
but with the risk of loss or corruption of data.

Kermit-32 provides raw downloading via the LOG SESSION command during CONNECT
to a remote system.  The session log is described above.  To use session
logging to capture a file:
@begin<enumerate>
Run Kermit on the VAX/VMS system.

SET LINE to the terminal line through which you will be connected to the remote
system.

Perform any required SET commands to condition Kermit for communication with
the remote system.

CONNECT to the remote system and log in.

Condition your job on the remote system not to pause at the end of a
screenful of text, and give whatever commands may be necessary to achieve a
"clean" terminal listing -- for instance, disable messages from the system or
other users.

Type the appropriate command to have the desired file displayed at the
terminal, @i<but do not type the terminating carriage return>.  On most
systems, the command would be "type", on Unix it's "cat".

Escape back to Kermit-32 and give the LOG SESSION command with the file
specification where you wish to store the data.

CONNECT back to the remote system and type a carriage return.  The file will be
displayed on your screen and recorded in the session log file.

Escape back to Kermit-32 and give the LOG SESSION command without a file
specification.
@end<enumerate>
The file you specified will contain everything that was typed on your screen.
You will probably find
that some editing necessary to remove extraneous prompts, messages, padding
characters, or terminal escape sequences, or to fill
in lost or garbled characters.

@section<Installation of Kermit-32>

Kermit-32 may be installed either by rebuilding the entire program
from the sources, or by making use of the distributed copy of the program.
When being built from sources, it may be built using either a BLISS-32
compiler or just the MACRO-32 assembler.

@Heading<Files>
Kermit-32 is built from a number of BLISS-32 sources and one MACRO-32
source.  In order to make it possible for sites without BLISS-32 to
build, MACRO-32 sources generated by BLISS-32 are also included for all
of the BLISS modules.  In the normal distribution of Kermit-32, all of
the files start with the prefix "VMS".  This will need to be changed
to "KER" in order to build the program properly.  The following files
are distributed as part of Kermit-32:
@Begin<Description>
@q<VMSTT.BLI>@\Common BLISS source for the terminal text output support.

@q<VMSGLB.BLI>@\Common BLISS source for the global storage
for @q<VMSMSG.BLI>.

@q<VMSMSG.BLI>@\Common BLISS source for the protocol
handling module.

@q<VMSCOM.REQ>@\Common BLISS require file which defines various common
parameters.  This is required by @q<VMSMSG.BLI>.
This file must be renamed to @q<KERCOM.REQ>.

@q<VMSMIT.BLI>@\BLISS-32 source for the command
parser, and some basic support routines.

@q<VMSFIL.BLI>@\BLISS-32 source for the file I/O.

@q<VMSTRM.BLI>@\BLISS-32 source for the terminal
processing.  This handles the driving of the terminal line for the transfers
and the connect command processing.

@q<VMSSYS.BLI>@\System interface routines for the Kermit
generic command processing.

@q<VMSGEN.MAR>@\Macro-32 source file that contains the REMOTE command
text that is given to VMS.
Sites desiring to change what DCL commands are used to process the various
generic server commands can make those changes in this source.  This
also contains the text of the help message returned in response to the
server generic help command.

@q<VMSERR.MSG>@\MESSAGE source for error messages used by VAX/VMS Kermit.

@q<VMSERR.REQ>@\BLISS-32 require file which defines the error codes. This
is REQUIREd by the BLISS-32 sources.

@q<VMSMIT.RNH>@\RUNOFF source for the help files for VAX/VMS Kermit.  When this
is run through RUNOFF with /VARIANT=SYSTEM, it produces a @q<.HLP>
(@q<VMSSYS.HLP>) file suitable for inserting into the system help library
(@q<SYS$HELP:HELPLIB.HLB>) to provide a KERMIT topic for the system HELP
command.  When run through RUNOFF without the /VARIANT=SYSTEM, it produces a
@q<.HLP> file (@q<VMSUSR.HLP>) to be stored on @q<SYS$HELP:> for use by the
Kermit HELP command.

@q<VMSSYS.HLP>@\RUNOFF output file for system wide Kermit HELP.

@q<VMSUSR.HLP>@\RUNOFF output file for Kermit's HELP command.

@q<VMSINS.COM>@\Command file to build and install VAX/VMS Kermit.

@q<VMSMIT.EXE>@\The executable (binary) file of VAX/VMS Kermit.  Note
that this is only included when it is possible.  This may be either
a copy of the @q<.EXE> file which was transferred to a TOPS-10 or TOPS-20
system using Kermit with Kermit-10 (or -20) using FILE BYTE-SIZE 8-BIT,
or a direct copy of the @q<.EXE> file (if the file is either
on a native VAX/VMS tape or is residing on a VAX/VMS system).

@q<VMSMIT.HEX>@\A hexifed version of @q<.EXE> file for VMS Kermit.  This file
can be dehexified using the supplied program.  In the hexified form, the
file should be transferrable over any medium which handles normal text.
This is the most reliable copy of the executable version of VMS Kermit.

@q<VMSHEX.MAR>@\Source for the hexification program.  This is the program
which was used to produce @q<VMSMIT.HEX>.  It can also be used to produce
hexified version of any (or at least almost any) Files-11 file.  The
dehexification program should then be able to reproduce a copy of the
original file with the file parameters correctly set.
Note that the format used for the hexified files is basically Intel hex
format.  There are some additional records used to store the record format,
etc.  Also, the file name as typed to the prompt from VMSHEX is stored
in the hexified version of the file for use by the dehexification program.
By doing this, it is possible to store more than one binary file with
a single hexified file.

@q<VMSDEH.MAR>@\Source for the dehexification program.

@q<VMSV3.MEM>@\Documentation on the changes between versions @q<2.0> and
@q<3.0> of Kermit-32, and additional installation information.
@End<Description>

As distributed, Kermit-32 should work on any VAX/VMS system (version 3.0
and later).  Customization is possible with or without a BLISS-32 compiler.
Default parameter values may be changed by changing the appropriate
LITERALs in the BLISS-32 source for VMSMSG, or the actual values which
are stored in the routine MSG_INIT in the MACRO-32 source for VMSMSG.

Sites can also easily change the commands which are used for processing
the generic server functions (REMOTE commands when running as a server).
The text which makes up these commands is in the file @q<VMSGEN.MAR>,
along with the text of the REMOTE HELP message.  This allows a site to
make use of local programs for performing some of the commands (perhaps
using FINGER to perform the WHO command, etc.).

@Heading<Building Kermit-32 from sources>
A command file is included which will build Kermit-32 from either
the BLISS-32 or MACRO-32 sources and optionally install Kermit-32 on
the system.  This file (@q<VMSINS.COM>) has not been extensively tested,
however it should work on most systems.  It is also a good example of
what needs to be done to compile each file and load the entire program.
It also contains the commands necessary to install a version of Kermit-32
on the system once the @q<.EXE> and @q<.HLP> files are generated.

@Heading<Using Kermit-32 to install a new version of itself>
If you already have a version of Kermit-32 running on a VAX/VMS system,
you can use it to transfer a new version of itself from another
system.  If you have no need to build Kermit-32 from sources (because
you have no local modifications), you can just transfer the new @q<VMSMIT.EXE>
(or @q<VMSMIT.HEX>), and the new help file @q<VMSMIT.RNH>.

If you have
access to a system which has a copy of @q<VMSMIT.EXE>, you can transfer it
simply by setting the FILE TYPE to FIXED on the receiving Kermit.  Make
sure that the sending Kermit is willing to send the file as a binary file.
If the sending Kermit is another copy of Kermit-32, you don't need to
do anything.  If the sending Kermit is Kermit-10 or Kermit-20, make sure
the file will be sent as an eight-bit binary file by using SET FILE BYTE-SIZE
EIGHT.  If some other Kermit is sending the file, make sure to give it
whatever command is necessary to ensure that it sends eight-bit binary
data from the file.  Also, if the originating system is not a VAX/VMS,
TOPS-10 or TOPS-20 system, make sure that the file was stored on that
system correctly to start out with.  Normally, the file @q<VMSMIT.EXE> will
only be available from a VAX/VMS, TOPS-10 or TOPS-20 system.

If you only have access to a copy of @q<VMSMIT.HEX>, you will need to transfer
that file (as a normal ASCII text file).  You will also need a copy of
@q<VMSDEH.MAR>.  After you have obtained both files, you can produce
a copy of the @q<.EXE> file as follows.  First compile VMSDEH by using
the command @q<MACRO VMSDEH>.  Then load it by @q<LINK VMSDEH>.  Now
run VMSDEH and when it asks for a file name, type @q<VMSMIT.HEX>.
The program will run for a short time and produce the @q<.EXE> file.

The system wide and user help files are produced from @q<VMSMIT.RNH> by
RUNOFF.  To produce the user help file (the one used by Kermit-32's HELP
command), type:
@Begin<example>
$ RUNOFF VMSMIT.RNH/OUTPUT=KERUSR.HLP
$ LIBARARY/CREATE/HELP SYS$HELP:KERMIT.HLB KERUSR.HLP
@End<example>
To produce the system wide help file and install it in the system help library
type:
@Begin<example>
$ RUNOFF VMSMIT.RNH/OUTPUT=KERSYS.HLP/VARIANT=SYSTEM
$ LIBRARY/REPLACE/HELP SYS$HELP:HELPLIB.HLB KERSYS.HLP
@End<example>
This allows the DCL HELP command to provide information on Kermit-32.