💾 Archived View for gemini.spam.works › mirrors › textfiles › magazines › NIA › nia-69.phk captured on 2022-06-12 at 13:39:05.
-=-=-=-=-=-=-
Founded By: | _ _______
Guardian Of Time | __ N.I.A. _ ___ ___ Are you on any WAN? are
Judge Dredd | ____ ___ ___ ___ ___ you on Bitnet, Internet
------------------+ _____ ___ ___ ___ ___ Compuserve, MCI Mail,
\ / ___ ___ ___ ___ ___________ Sprintmail, Applelink,
+---------+ ___ ___ ___ ___ ___________ Easynet, MilNet,
| 15TUE91 | ___ ______ ___ ___ ___ FidoNet, et al.?
| File 69 | ___ _____ ___ ___ ___ If so please drop us a
+---------+ ____ _ __ ___ line at
"smells like fish ___ _ ___ elisem@nuchat.sccsi.com
tastes like chicken" __
_ Network Information Access
Other World BBS Ignorance, There's No Excuse.
NIA Issue 69 Volume 2
Welcome to NIA069. Due to the vast amount of information we recieved
you can expect to see NIA070 very soon after this release date.
==============================================================================
Table_Of_Contents
1. The Future of the Internet................................Jane M. Fraser
2. Tekno DCS HELP [02]..........................................Judge Dredd
3 Computer Security Techniques [04].......................Guardian Of Time
4. Kermit Manual [01].......................................Malefactor [OC]
5. Department Of The Army Field Manual [02]....................Death Jester
6. World News Sept 1990-Jan 1991...................Face 2 Face Publications
7. Comments From Editors...........................................JD & GOT
==============================================================================
/ /
/ File 01 / NIA069 /
/ The Future of the Internet /
/ Jane M. Fraser /
/ /
The Internet is network of computer networks used primarily by
educational and research establishments. The parts of the Internet
that have been funded by federal resources (for example, NSFNET) may
be used only for activities that support education and research.
Other parts have not been so funded, and usage is not restricted.
Various proposals have been made to extend the Internet to more
institutions, to allow commercial use on all parts of the Internet,
and to increase the bandwidth of the federally supported part of the
network.
On November 29 through December 1, I was one of approximately 150
attendees at a conference addressing various issues about the future
of the Internet. I have always felt very confused about what is the
Internet, what are the restrictions on usage, what different parts of
the network are doing, and what options are open for the future. I
learned one fact for certain at this conference: almost everyone else
is confused also.
I will report on some of the specifics of what happened at the
conference, putting emphasis on aspects I think will be of most
interest to the readers of the Calendar, but I am also confident that,
no matter how careful I am, this report will contain errors.
The conference, Information Infrastructure for the 1990s, was
sponsored by two programs at the John F. Kennedy School of Government
at Harvard University: Science, Technology and Public Policy and
Strategic Computing and Telecommunications in the Public Sector. The
two primary organizers were Lewis Branscomb and Jerry Mechling. The
two-and-a-half days were heavily packed with presentations of
commissioned papers, comments by panels of discussants, and open
discussion from the floor.
The main points the conference reinforced for me are, first, the
growing importance of computer networks for fast communication and,
second, the growing importance, for many users, of interconnectivity
of networks. The first needs little comment. The second may be of
importance more to some sectors, especially academics, than to others.
Academics and researchers often want to communicate with a wide range
of people and, thus, want to be able to send electronic mail to people
on many different networks. Some companies may want their employees to
communicate only within the company, not with those outside it, but
others find interorganizational communication to be very important.
Some networks already interconnect (although not completely), for
example, AT&T Mail, CompuServe, and the Internet. Others are
isolated, for example, Prodigy. Many barriers, institutional and
technical, make it difficult to interconnect networks, but, I believe,
there will be increasing demand from users to do so.
At the federal level, a proposal has been put forth for federal
funding of NREN, the National Research and Education Network, which
would, roughly, be an extremely high bandwidth version of the
Internet. (The latter sentence is undoubtedly not error free.) Most
uses of supercomputers, almost by definition, require and generate
huge amounts of data. For example, at the conference, we viewed a
short tape of a simulation of the formation of a thundercloud. Remote
access to supercomputers has always been cited as a justification for
investing federal money in the Internet, and this again is one of the
major reasons cited for the need for NREN. Indeed, the ability to
create and manage a network at the data speeds being contemplated is
itself viewed as a research issue.
However, other participants argued that "low-end" use, that is, use
not requiring high bandwidth, is also an appropriate topic for
research. As the network expands and usage grows (which is happening
at an amazing rate), questions arise about the ability of existing
mechanisms to handle traffic. These participants argued that the
networking of the large numbers of computers on the Internet (and its
affiliates) is also worthy of attention, even without the addition of
more bandwidth. This discussion of the importance of low-end use was
naturally related to issues of allowing more general access to the
Internet, for example, for K through 12 educational institutions.
Currently, most academic users of the Internet receive access through
their institution's connection. While the institution itself bears
considerable cost, most academic end users do not receive a bill for
usage. Internet connectivity to researchers is viewed by many
academic institutions as being analogous to the library (for which
usage fees are generally not charged to the end user or to the end
user's academic unit), rather than analogous to the phone (for which
such usage fees are charged). The user (or the academic unit) usually
must provide a terminal or personal computer. Here at OSU, the
computer magnus provides Internet access for anyone who requests it.
(Actually, this is not quite accurate; magnus accounts will shortly be
available to all OSU users.) One paper, "Pricing the NREN: The
Efficient Subsidy," by Gerald Faulhaber, presented an economist's
arguments against current pricing and subsidization schemes.
Several commercial enterprises have been created (for example, PSI) to
provide Internet access for commercial enterprises. Recall that
commercial use is allowed as long as the use is in support of research
and education. For example, a researcher at a commercial enterprise
can communicate with researchers at academic institutions on research
topics. A company can also communicate with researchers about its
products. Two commercial users on different commercial networks must
be very careful, however, since their communication with each other
might traverse parts of the network on which commercial traffic is
forbidden. However, it is often difficult for the user to predict what
route a message will take. If all this seems arcane and unclear, it
is. Many people (including Alison Brown of the Ohio Supercomputer
Center) are working to make these aspects less arcane and more clear.
One paper, "The Strategic Future of the Mid-Level Networks," by
Paulette Mandelbaum and Richard Mandelbaum, explored various possible
models for relationships between commercial and educational
enterprises on the Internet.
A portion of the conference had an Ohio focus. Jerry Mechling visited
Ohio this summer and interviewed many people in order to write a case
paper, which was presented and discussed at the conference, An
Information Infrastructure Strategy for Ohio. Partly because of this,
we had a fairly sizeable Ohio contingent at the conference: Gerald
Anglin (Litel), Alison Brown (Ohio Supercomputer Center), Sally
Cousino (Ohio Bell), Nick Farmer (Chemical Abstracts), myself (CAST),
Jerry Hammett (State of Ohio), Don Olvey (OCLC), Tim Steiner (State of
Ohio), and Ron Vidmar (State of Ohio). I found one of the most
successful parts of the conference to be our caucuses, both before and
after the conference.
Other papers presented at the conference included "Information
Infrastructure for the 1990s: A Public Policy Perspective," by Lewis
Branscomb; "Technology Issues in the Design of the NREN," by Leonard
Kleinrock; "Life after Internet: Making Room for New Applications," by
Larry Smarr and Charles Catlett; "A Coming of Age: Design Issues in
the Low-end Internet," by Ken Klingenstein; and "The NREN as
Information Market: Dynamics of Public, Private, and Voluntary
Publishing," by Brian Kahin. Copies of all the papers are available
for loan from the CAST office.
There were also smaller sessions involving presentations on current
uses of the Internet. One presentation was by Allan Weis, from
Advanced Network and Services, Inc., ANS, a "nonprofit organization
dedicated to the advancement of education and research." ANS is funded
by IBM and MCI to help build computer networks.
As with all conferences, some of the most important discussions went
on in the hallways and at meals and some of the most important results
were the contacts made. Despite my dismay at finding myself at a
conference with presenters who were all white males (including one who
addressed the group as "gentlemen"), I think the conference was
excellently organized and run. I applaud the organizers for focussing
us on such an important issue: information infrastructure for the
1990s.
==============================================================================
/ /
/ File 02 / NIA068 /
/ Tekno DCS Help /
/ Part 2 of 2 /
/ Judge Dredd /
/ /
This is the 2nd part of the DCS help. Enjoy.
help accounting
Resource Accounting provides a transaction file of system usage information
for both the user and the system. The collected data allows you to bill
individual users for resources used and to measure overall system usage.
To tailor the accounting information and format it to your application, you can
write a report program. This program accesses the transaction file, reads the
required data fields, and writes a report for you.
For more information, type:
HELP ACCOUNTING START Starting Resource Accounting
HELP ACCOUNTING STOP Stopping Resource Accounting
HELP ACCOUNTING SET Changing accounting parameters
HELP ACCOUNTING SHOW Displaying accounting information
See the RSX-11M-PLUS and Micro/RSX System Management Guide for more
information.
help ascii
Octal Values for the ASCII Character Set -- ASCII is a code used to
translate letters, numbers, and symbols that people can understand into
a code which the computer can use. Most RSX-11M-PLUS and Micro/RSX functions
requiring numerical values for characters use octal ASCII.
000 NUL 020 DLE 040 SP 060 0 100 @ 120 P 140 ` 160 p
001 SOH 021 DC1 041 ! 061 1 101 A 121 Q 141 a 161 q
002 STX 022 DC2 042 " 062 2 102 B 122 R 142 b 162 r
003 ETX 023 DC3 043 # 063 3 103 C 123 S 143 c 163 s
004 EOT 024 DC4 044 $ 064 4 104 D 124 T 144 d 164 t
005 ENQ 025 NAK 045 % 065 5 105 E 125 U 145 e 165 u
006 ACK 026 SYN 046 & 066 6 106 F 126 V 146 f 166 v
007 BEL 027 ETB 047 ' 067 7 107 G 127 W 147 g 167 w
010 BS 030 CAN 050 ( 070 8 110 H 130 X 150 h 170 x
011 HT 031 EM 051 ) 071 9 111 I 131 Y 151 i 171 y
012 LF 032 SUB 052 * 072 : 112 J 132 Z 152 j 172 z
013 VT 033 ESC 053 + 073 ; 113 K 133 [ 153 k 173 {
014 FF 034 FS 054 , 074 < 114 L 134 \ 154 l 174 |
015 CR 035 GS 055 - 075 = 115 M 135 ] 155 m 175 }
016 SO 036 RS 056 . 076 > 116 N 136 ? 156 n 176 ~
017 SI 037 US 057 / 077 ? 117 O 137 _ 157 o 177 DEL
See also HELP ASCII DECIMAL for the decimal values required by EDT and
HELP ASCII HEXADECIMAL for hexadecimal values.
help bad
The Bad Block Locator Utility (BAD) tests disks and DECtapes for
the location and number of bad blocks. BAD then records this bad
block information on the volume. Then you use the Monitor
Console Routine (MCR) command INI, which allocates the bad
blocks to the bad block file [0,0]BADBLK.SYS. The bad blocks are
marked as in-use and therefore cannot be allocated to other
files.
You can use BAD in its task version, which runs at the same time
as other tasks, or in its standalone version included in
[6,54]BRUSYS.SYS, which runs by itself on the computer. The
standalone version is required if you have a system with a single
disk drive.
The command line for BAD is shown next.
Format
ddnn:[/switch[...]]
Parameters
ddnn
Specifies a physical device.
switch
Specifies an optional switch that qualifies the BAD command line. Multiple
BAD switches for a device must be specified on one line. If you do not
specify any switch, BAD begins its pattern checking of individual blocks.
For more information on BAD switches, type HELP BAD SWITCHES.
help basic
PDP-11 BASIC-PLUS-2 is a layered product supported on RSX-11M/M-PLUS
systems. To invoke BASIC-PLUS-2, type the BP2 command: >BP2.
BASIC-PLUS-2 may be installed under a name other than BP2. In this
case, type the three-character name assigned by your system manager.
HELP is available on BASIC-PLUS-2 concepts, statements, functions, and
commands. You can get HELP both at the MCR command level and
within the BASIC environment. For BASIC-PLUS-2 V2.0, HELP topics
available at the MCR command level are:
ARRAYS CONSTANTS DIRECTIVES LABELS QUALIFIERS
CHARACTER CONVENTIONS EXPRESSIONS LINE STATEMENTS
COMMANDS DATA_TYPES HELP MODIFIERS VARIABLES
COMMENTS DEBUGGER IMMEDIATE
HELP on these topics, plus associated subtopics, also is available
within the BASIC environment.
To access HELP text from the MCR command level, type: >HELP/BP2 topic.
To access HELP files within the BASIC environment, first invoke BASIC
with the BP2 command and then type HELP in response to the
BASIC-PLUS-2 prompt.
help bck
RMSBCK copies standard RMS-11 files from one medium to another
(disk-to-disk or disk-to-tape), translating the data into a
special backup format. The backup copy contains the source
file's attributes (with the exception of file placement).
Backup files can be accessed properly only by the RMSRST utility
(type HELP RST for more information). User programs cannot
change backup data.
RMSBCK can use magnetic tapes with ANSI-standard labels only.
However, the backup data written by the utility between the
labels may not comply with ANSI standards.
To invoke installed RMSBCK:
BCK [command-string]
To invoke uninstalled RMSBCK:
RUN $RMSBCK
Type HELP BCK COMMAND for an explanation of RMSBCK's command line.
Type HELP BCK SWITCHES for an explanation of RMSBCK's switches.
See the RMS-11 Utilities manual for more information.
help bru
The Backup and Restore Utility (BRU) allows you to back up and restore
Files-11 volumes. You can use BRU to transfer files from a volume to a
backup volume (or volumes) to ensure that a copy is available in case
the original files are destroyed. If the original files are destroyed,
or if for any other reason the copy needs to be retrieved, you can
restore the backup files with BRU. In the process of copying, BRU also
reorganizes and compresses files for efficient storage and access.
You can use BRU stand alone as well as on line. BRUSYS is the
standalone version.
BRU can also be invoked through the DIGITAL Command Language (DCL)
command BACKUP.
The command line for BRU is shown next.
Format
/qualifier[...] indevice[,...][filespec[,...]] outdevice[,...]
Parameters
qualifier
Specifies any of the command qualifiers. If two or more qualifiers are
specified, they must be contiguous, that is, separated with a slash only.
You can use a shorter form of a qualifier as long as it is unique.
All BRU
qualifiers are unique to three characters.
indevice
Specifies the input device you want to transfer files from. In a backup
operation, the input device contains the files you want to safeguard. In
a restore operation, the input device contains the backup set you are
restoring.
Devices are specified in the following form:
ddnn:
filespec
Specifies the file specification used to select particular files or
categories of files to back up or restore. A file specification takes the
following form:
[directory]filename.type;version
outdevice
Specifies the output device you want to transfer the files to. In a
backup operation, the output device contains the backup set you want to
create. In a restore operation, the output device is the disk that
receives the files you are restoring.
The format of outdevice is the same as for indevice (described
previously). A file specification may not be placed after the output
device.
Type HELP BRU STANDALONE for more information on standalone BRU.
Type HELP BRU QUALIFIERS for a list of the qualifiers for BRU.
Type HELP BRU EXAMPLES for examples of BRU operations.
help cda
CDA helps you determine the cause of system crashes by analyzing and
formatting a memory dump created by the Executive Crash Dump Module.
You can use switches to select the information that CDA formats and
lists.
The general form of the command line is:
>CDA [listfile/sw],[binaryfile/sw]=[symbolfile/STB],crash-input[/sw]
listfile the human-readable CDA output listing
binaryfile a copy of the binary data the crash dump module writes
on the crash dump device
symbolfile the symbol definition file (RSX11M.STB) for the crashed system
crash-input the source of the binary input to CDA; you specify the
crash dump device or a binary file created by CDA
in a previous analysis
For more CDA information, type:
HELP CDA LIST (for the list file switches)
HELP CDA BINARY (for the binary file switch)
HELP CDA ANALYSIS (for the crash-input file switches)
See the RSX-11M/M-PLUS Crash Dump Analyzer Reference Manual for more
information.
help cmp
The File Compare Utility (CMP) compares two ASCII text files. The files are
compared line by line to determine whether parallel records are identical.
The command line for CMP is shown next.
Format
[outfile[/switch[...]]=] infile1,infile2
Parameters
outfile
Specifies the file specification for the output file. The format for
entering file specifications is as follows:
ddnn:[directory]filename.type;version
switch
Specifies switches that you apply to the output file specification.
Some of the switches can be negated and some are mutually exclusive.
infile1
Specifies the file specification for the input file to be compared to
infile2. The file name of this file must be specified. The default file
type is MAC.
infile2
Specifies the file specification for the input file to be compared to
infile1. You do not need a complete file specification. The specifications
for infile1 are used as defaults for any unspecified portions of in file2.
Type HELP CMP SWITCHES for descriptions of the CMP switches.
help cnv
RMSCNV reads records from an RMS-11 file of any type and converts
them into another RMS-11 file of any type. RMSCNV uses standard
RMS-11 file access methods. For initial indexed file loading,
use RMSIFL (type HELP IFL).
To invoke installed RMSCNV:
CNV [command-string]
To invoke uninstalled RMSCNV:
RUN $RMSCNV
Type HELP CNV COMMAND for an explanation of RMSCNV's command line.
Type HELP CNV SWITCHES for an explanation of RMSCNV's switches.
See the RMS-11 Utilities manual for more information.
help cobol
COBOL[/qualifier[,s] filespec
The default extension on filespec is .CBL.
Command Qualifiers:
/[NO]ANSI_FORMAT /[NO]LIST[:filespec]
/[NO]CHECK[:arg] /[NO]NAMES:xx
ALL /[NO]OBJECT:filespec
[NO]BOUNDS /[NO]OVERLAY_DESCRIPTION
NONE /[NO]SHOW:[NO]MAP
[NO]PERFORM /[NO]SKELETON
/CODE:[NO]CIS /[NO]SUBPROGRAM
/[NO]CROSS_REFERENCE /TEMPORARY:device
/[NO]DEBUG /[NO]TRUNCATE
/[NO]DIAGNOSTICS[:filespec] /[NO]WARNINGS:[NO]INFORMATIONAL
The COBOL command invokes the COBOL-81 compiler if it is installed in
your system. See your system manager to determine if the COBOL-81
compiler is installed.
For additional information on a qualifier, type HELP COBOL qualifier.
COBOL can also be used to invoke PDP-11 COBOL (COBOL/C11). For more
help on COBOL/C11, type HELP COBOL C11.
help configure
Reconfiguration is the process of physically and logically connecting and
disconnecting various system resources. By reconfiguring your system, you can
define a set of hardware resources that are accessible from the online
system.
The reconfiguration services consist of three components: a command
interface (CON), a loadable driver (RD:), and a privileged reconfiguration task
(HRC). You must have enough space in memory to contain both CON and HRC at the
same time; otherwise, CON commands fail.
To use the reconfiguration services, invoke the command interface by typing
CON. Then, enter CON commands at the CON> prompt.
Additional help is available on the following commands:
BUILD CLEAR DISPLAY ESTATUS
HELP IDENT LINK LIST
OFFLINE OFFLINE_MEMORY ONLINE ONLINE_MEMORY
SET SWITCH UNLINK
To display information about a command, type HELP CONFIGURE commandname.
help coral
CORAL
The CORAL command invokes the PDP-11 CORAL 66 Compiler.
The general form of the CORAL command is:
COR[AL] [object],[listing]=source1[,source2...][/qualifiers]
where object, listing, source1, source2 ... are standard file specifications.
Qualifiers are not position-sensitive; they may be placed after any file
specification in the command line.
Qualifiers:
/BC /CR /IE /IS /LI /NL /OP /OS
/PI /PS /RO /SP /TE /TR /WI
For information on a particular qualifier, type HELP CORAL qualifier.
help cot
The console output task (COT..) communicates with the Console Logger.
The following is a list of the privileged commands you can use:
SET /COLOG (nonprivileged) Displays Console Logging status
SET /COLOG=ON Starts Console Logging
SET /COLOG=OFF Stops Console Logging
SET /COLOG/COTERM=TTnn: Reassigns the console terminal
SET /COLOG/COTERM Enables the console terminal
SET /COLOG/NOCOTERM Disables the console terminal
SET /COLOG/LOGFILE=filename Reassigns the console log file
SET /COLOG/LOGFILE= Opens a new version of the current log
file
SET /COLOG/LOGFILE Opens a new version of the file
LB:[1,4]CONSOLE.LOG
SET /COLOG/NOLOGFILE Disables the console log file
The /COTERM, /NOCOTERM, /LOGFILE, and /NOLOGFILE options can be
specified with each other, with SET /COLOG, or with SET /COLOG=ON.
See the RSX-11M-PLUS and Micro/RSX System Management Guide for
more information on the Console Logger and the COT... task.
help def
The DEFINE LOGICALS (DFL) command assigns, deletes, and displays
logical name assignments. Logical names can be assigned to devices,
all or part of a file specification, and to other logical names.
Formats:
DFL = ! Deletes all local logical assignments
DFL ens=lns[/keyword(s)] ! Creates logical name assignments
DFL =[lns][/keyword] ! Deletes logical name assignments
DFL [/keyword(s)] ! Displays logical name assignments
Keywords (privileged options):
/ALL /GR
/TERM /GBL or /SYSTEM
/LOGIN /FINAL
For more information on the keywords, type: HELP DFL keyword
For help on the DFL command formats, type: HELP DFL CREATE
HELP DFL DISPLAY
HELP DFL DELETE
help des
RMSDES is an interactive utility that allows you to design and
create RMS-11 sequential, relative, and indexed files. To design
a file, you specify the file's attributes: 1) interactively, by
using the RMSDES SET command, or 2) from an existing, external
file, by using the RMSDES GET command, or 3) by using an indirect
command file to execute RMSDES commands.
DES Invokes installed RMSDES for an
interactive session
DES filename[.ext] [type] Invokes RMSDES and creates a file
from an existing file
DES @filename[.CMD] Invokes RMSDES by using an indirect
command file
RUN $RMSDES Invokes uninstalled RMSDES
After you have invoked RMSDES, you can type HELP or ? to
obtain additional information.
See also the RMS-11 Utilities manual for more information.
help dsp
RMSDSP displays a concise description of any RMS-11 file, including
container files, that is, RMS-11 files that were backed up to an ANSI-
labeled magtape using RMSBCK (type HELP BCK for more information).
To invoke installed RMSDSP:
DSP [command-string]
To invoke uninstalled RMSDSP:
RUN $RMSDSP
Type HELP DSP COMMAND for an explanation of RMSDSP's command line.
Type HELP DSP SWITCHES for an explanation of RMSDSP's switches.
See the RMS-11 Utilities manual for more information.
help dsc
The Disk Save and Compress Utility (DSC) copies a Files-11 disk either to
disk or to tape and from DSC-created tape back onto disk. At the same time,
DSC reallocates and consolidates the disk data storage area: it concatenates
files and their extensions into contiguous blocks whenever possible and,
therefore, reduces the number of retrieval pointers and file headers required
for the same files on the new volume.
DSC copies files that are randomly scattered over a disk volume to a new
volume, without the intervening spaces. This eliminates unused space between
files and reduces the time required to access them.
The command line for DSC is shown next.
Format
outdev[,...][filelabel1][/switch[...]]=indev[,...][filelabel2][/swit
ch[...]]
Parameters
outdev
Specifies the physical volume or volumes to which data is copied. The
format for outdev is as follows:
ddnn:
filelabel1
Identifies the output disk's Volume ID, the tape file, or the tape set
that DSC creates in a data transfer.
switch
Specifies one or more of the optional DSC switches.
indev
Specifies the physical volume or volumes, in the same format as outdev,
from which data is copied.
filelabel2
Identifies the DSC-created tape file that is being transferred to disk or
is being compared.
For a list of the DSC switches, type HELP DSC SWITCHES.
help dmp
The File Dump Utility (DMP) enables the user to examine the contents of a
specific file or volume of files. The output may be formatted in ASCII,
octal, decimal, hexadecimal, or Radix-50 form and dumped to any suitable
output device such as a line printer, terminal, magnetic tape, DECtape,
or disk.
You can dump the header and/or virtual blocks of a file, portions of blocks,
or the virtual records of a file.
DMP operates in two basic modes: file mode and device mode. File mode is
used to dump virtual records or virtual blocks, and device mode is used
to dump logical blocks (the /BL switch is a required parameter in device m
ode).
The command line for DMP is shown next.
Format
[outfile][/switch[...]][=inspec][/switch[...]]
Parameters
outfile
Specifies the output file. The format for entering file specifications is
as follows:
ddnn:[directory]filename.type;version
switch
Specifies any of the DMP switches.
inspec
Specifies the input device and file or input device only.
Type HELP DMP SWITCHES for a description of the DMP switches.
help dte
Data Terminal Emulation (DTE) allows you to log into another DIGITAL computer
system from a terminal connected to a Micro/RSX or RSX-11M-PLUS system.
The other DIGITAL system can be an RSX-11M/M-PLUS system, a VAX/VMS system
running VAX-11/RSX, a Professional Personal Computer, or a Micro/RSX system.
Once a local RSX terminal is logged in to an external system, the external
system becomes the host system. The host system views the system running DTE as
remote. Once you have logged into the host system through DTE, you can use the
File Transfer Utility (MFT) to copy and delete files between the local and the
host systems.
Additional HELP is available on the topics summarized below. To access this
information, type HELP DTE topic.
Topics: CONNECT DISCONNECT SET_HOST
HOOKUP FILE_TRANSFER DCL_COPY
DCL_DELETE MCR_COPY MCR_DELETE
help edi
EDI is a line-oriented editor that allows you to create and modify text files.
EDI operates on most ASCII text files.
EDI accepts commands that determine its mode of operation and control its
actions on input files, output files, and working text buffers.
The command line for EDI is shown next.
Format
filespec
Parameter
filespec
Specifies a file specification in the following format.
ddnn:[directory]filename.type;version
After EDI has identified the input file or created the new file, it is ready
for commands.
EDI runs in two control modes: Edit (command) mode and Input (text) mode.
Edit mode is invoked automatically when you specify an existing file.
In edit mode, EDI issues an asterisk (*) prompt. EDI acts upon commands and
data to open and close files; to bring lines of text from an open file; to
change, delete, or replace information in an open file; or to insert single
or multiple lines anywhere in a file.
Input mode is invoked automatically at program startup if you specify a
nonexistent file.
When in input mode, EDI does not issue an explicit prompt. Lines that you
enter at the terminal are treated as text and are inserted into the output
file. When you complete each input line by pressing the RETURN key, EDI
sends a line feed to the terminal.
To switch from edit mode to input mode, enter the Insert command and press
the RETURN key. To return to edit mode, press the RETURN key as the only
character on an input line. EDI will issue the asterisk prompt, which
signifies edit mode.
EDI provides two modes you can use to access and manipulate lines of text in
the input file. (A line is defined as a string of characters terminated by
pressing the RETURN key.) The two modes are as follows:
Line-by-line mode Allows access to one line of text at a time. Backing up
is not allowed.
Block mode Allows free access within a block of lines, on a line-by-
line basis. Backing up within a block is allowed. Backing
up to previous blocks is not allowed. Block mode is the
default text access mode.
Type HELP EDI COMMANDS for a list of the EDI commands.
help edt
EDT, the DEC Editor, has its own HELP files, which you can access from
within EDT, using the EDT HELP command. To access EDT from MCR, use a
command in the following form:
EDT[/qualifiers] [outfile,][journal][=] infile[,command]
The optional output filespec permits you to give a new name to the
outfile. The journal filespec permits you to give a new name to the
journal file. The equals ( = ) is required if you use either or both
of these two filespecs. The infile is the file you wish to edit.
The optional command filespec refers to a file of EDT commands you
may wish to have read in and executed before you start editing.
There are two qualifiers to the EDT command: /RO and /RECOVER.
EDT/RO infile means you wish read-only access to the file.
EDT/RECOVER infile recovers edits from an editing session that had
been interrupted by a system crash or other problem.
See the EDT Editor Manual for more information on EDT.
help error_logger
The RSX error logging system consists of four tasks: ELI, ERRLOG, RPT, and
CFL. All command descriptions in these help files use MCR syntax. If your
system's Command Line Interpreter (CLI) is DCL, you may wish to use DCL
commands to operate error logging. For help with DCL commands, type HELP.
The Error Log Interface (ELI) task controls the operation of the error
logging task (ERRLOG). ELI turns error logging on and off, changes
error limits, and names error log files and backup files. ERRLOG also
provides a warning whenever one of the error limits is reached.
The Report Generator task (RPT) produces error log reports based on
information in control file modules.
The Control File Language (CFL) compiler compiles the error log control
file modules used by RPT.
Type HELP ERROR_LOG ELI for more information about ELI commands.
Type HELP ERROR_LOG WARNINGS for more information about error limits.
Type HELP ERROR_LOG CFL for information about the CFL commands.
Type HELP ERROR_LOG RPT for more information about the RPT commands
that generate error log reports.
help executive
Help is available for all Executive directives. Type
HELP EXECUTIVE macrocall
for help on the directive that corresponds to the macro call. (Note
that the terminating $ should be eliminated from the macro call when
requesting help. For example, type HELP EXECUTIVE ABRT for help on
the ABRT$ directive.)
You can also type
HELP EXECUTIVE directivename
where directivename is the name of the directive. Remember that many
directives have similar names. Type the full name of the directive as
a single word with underscores between words. For example:
HELP EXECUTIVE SEND_REQUEST_AND_CONNECT
Type HELP EXECUTIVE DIRECTIVES for a list of the directives and their
macro call names.
Type HELP EXECUTIVE DIC for information on the Directive Identification
Codes and HELP EXECUTIVE ERRORS for a list of the error codes returned
in the Directive Status Word.
help fcs
File Control Services (FCS) is a collection of record management
macros and subroutines used to maintain and manipulate data
files. FCS, in contrast to RMS-11, supports only sequential and
fixed record length file organizations. This HELP file contains
brief summaries of the MACRO-11 assembly language interface to
FCS. See also, HELP FCS:
BIGBUFFERS ERRORS ALL FDB INTRO
DATA-STRUC ERRORS err FLUSH MACRO
DATA-SET ERRORS nnn FILES-11 USER-TASK
ERRORS EXAMPLE FILE-SPEC
Code Name Meaning
--------- -------
err Indicates a three-character error code name.
nnn Indicates a three-digit octal error code number.
help flx
The File Transfer Utility Program (FLX) allows you to use foreign volumes
(not in Files-11 format) in DIGITAL's DOS-11 or RT-11 format. FLX converts
the format of a file to the format of the volume the file is being
transferred to.
FLX can be used to initialize and list directories of cassettes and RT-11 or
DOS-11 file-structured volumes. FLX can also be used to delete files from
RT-11 or DOS-11 formatted volumes.
FLX performs file transfers (and format conversions, as appropriate) as
follows:
o DOS-11 to Files-11 and DOS-11 volumes
o Files-11 to DOS-11, Files-11, and RT-11 volumes
o RT-11 to RT-11 and Files-11 volumes
FLX supports all Files-11 devices, including RSX-format cassettes. The
cassettes are volumes that you have initialized using the MCR command
INITVOL or the DCL command INITIALIZE. DOS-11 and RT-11 volumes are
initialized using FLX. On RSX-11M-PLUS operating systems, DOS-11 and RT-11
volumes must be mounted with foreign characteristics before you can use
FLX.
The general format for entering FLX command lines is shown next.
Format
[ddnn:[[directory]]/switch[...]=]infile[,...]/switch[...]
Parameters
ddnn
Specifies the device for the FLX output.
directory
Specifies the directory on the output device.
Do not specify a directory if the output device is in RT-11 format.
switch
Specifies one of the FLX switches.
infile
Specifies the input file specification.
The format for entering file specifications is as follows:
ddnn:[directory]filename.type;version
The directory is not specified for RT-11 volumes.
FLX provides three types of switches for file transfers:
Volume format Specifiy the format of the volume on which files are stored;
that is, Files-11, DOS-11, or RT-11 volumes.
Transfer mode Provide the means for specifying the format of a file on a
non-Files-11 volume. Files can be in formatted ASCII,
formatted binary, or file image format.
Control Provide control functions useful during file transfers.
Using file control switches, you can specify, for example,
the number of blocks to be allocated to an output file or
the directory for an output file.
Type HELP FLX SWITCHES for a list and description of the FLX switches.
help fmt
The Disk Volume Formatter (FMT) utility formats and verifies disk cartridge,
disk pack, fixed media disk, and flexible disk volumes under any RSX-11M-PLUS
operating system that includes online formatting support in the Executive.
In general, FMT performs the following functions:
o Writes a complete header for each sector of the volume it is formatting.
o Verifies the address contents of each sector header.
o Sets the density for RX02 (DY-type) diskettes.
o Lets you specify an error limit for the volume being formatted. FMT
terminates processing when the error limit is reached.
o Lets the Bad Block Locator task run (spawn) if your system permits
spawned tasks.
FMT can also be invoked through the DCL command INITIALIZE/FORMAT.
The command line for FMT is shown next.
Format
ddnn:[/switch[...]]
Parameters
ddnn
Specifies the volume you are formatting.
switch
Specifies an FMT switch. Not all switches can be used with all device
types.
To terminate FMT, press CTRL/Z following the FMT prompt.
Type HELP FMT SWITCHES for a list of the FMT switches.
help fortran
F77 [obj-file] [,list-file] = input-file[,s][/switch[,s]]
You can also use the F77 command in interactive mode, which
permits you to enter multiple compilation commands (lines).
To invoke the interactive mode (if you have installed the
image of the FORTRAN-77 compiler as F77), you simply type:
F77 <RET>
Regardless of the name under which the PDP-11 FORTRAN-77
compiler is installed, the compiler displays the following prompt:
F77>
You may use the following format to enter the command:
F77>[obj-file] [,list-file] = input-file[,s][/switch[,s]]
F77>[obj-file] [,list-file] = input-file[,s][/switch[,s]]
F77> ...
F77> ...
F77> ?Z
Many switchs have a negative form that negates the action
specified by the positive form. You can obtain the negative
generally by following the required slash with a minus sign
or the characters NO. For example, /-SP or /NOSP.
/[NO]CK /CO:n
/[NO]DE /[NO]F77
/ID /[NO]I4
/LA (effective in the MCR interactive mode only)
/LI:n /[NO]RO
/SP /[NO]TR:arg
/[NO]ST[:arg] ALL
ALL BLOCKS
NONE LINES
SOURCE NAMES
SYNTAX NONE
/[NO]WF:n /WR
Type HELP FORTRAN switch for more information.
help ifl
RMSIFL reads records from any type of RMS-11 file and loads them into
an existing, empty, indexed file. RMSCNV also populates indexed files,
but in a nonoptimized fashion (type HELP CNV).
To invoke installed RMSIFL:
RMSIFL [command-string]
To invoke uninstalled RMSIFL:
RUN $RMSRMSIFL
Type HELP IFL COMMAND for an explanation of RMSIFL's command line.
Type HELP IFL SWITCHES for information on RMSIFL's switches.
See the RMS-11 Utilities manual for more information.
help indirect
The Indirect Command Processor allows CLI command lines to be
placed in a file. The file is then executed as though the command lines
were entered from a terminal. Indirect also supports other
numeric and string manipulation commands.
A summary of commands and special symbols can be obtained by typing
HELP INDIRECT SUMMARY
Individual command descriptions can be obtained by typing
HELP INDIRECT commandname
Operators (relational and arithmetic) are described at
HELP INDIRECT OPERATORS
Special symbol descriptions can be obtained by typing
HELP INDIRECT symbolname
NOTE: symbolname does not include the <sym> angle brackets.
A list of Indirect error messages, including their severity class numbers,
can be obtained by typing
HELP INDIRECT MESSAGES
help open
OPE[N] memory-address [+ n] [/keyword]
OPE[N] memory-address [- n] [/keyword]
Keywords: /AFF=[CPx,UBy] /CPU=CPx
/DRV=dd: /KNL
/KNLD /KNLI
/REG=region-name /TASK=taskname
/TASKD /TASKI
+ or - n One or more optional octal numbers to be added to or
subtracted from the memory address.
The OPENREGISTER command allows you to examine and modify a word of mem
ory.
To open a location within a task, the task must be fixed in memory.
This is a privileged command.
For information on the keywords, type HELP OPEN keyword.
For help on the OPEN command display format, type HELP OPEN DISPLAY.
>delete the TOP when e editing on the O!!!!!!
MCR -- Not logged in
help iox
The I/O Exerciser (IOX) detects I/O problems on the disk, terminal, and tape
units in your hardware configuration. IOX tests the hardware (and accompanying
software) by performing repeated operations to the same unit.
IOX exercises devices on two kinds of volumes: non-file-structured (NFS) and
file-structured (Files-11). They are defined as follows:
NFS Volumes All tapes and terminals, some disks.
Files-11 Volumes Disks initialized with the MCR command INITIALIZE.
They have a home block and a Files-11 structure.
Additional help is available on the following topics:
Running an I/O exercise Type HELP IOX RUN
IOX commands Type HELP IOX COMMANDS
IOX operating modes Type HELP IOX MODES
IOX reports Type HELP IOX OUTPUT
help help indirect
The Indirect Command Processor allows CLI command lines to be
placed in a file. The file is then executed as though the command lines
were entered from a terminal. Indirect also supports other
numeric and string manipulation commands.
A summary of commands and special symbols can be obtained by typing
HELP INDIRECT SUMMARY
Individual command descriptions can be obtained by typing
HELP INDIRECT commandname
Operators (relational and arithmetic) are described at
HELP INDIRECT OPERATORS
Special symbol descriptions can be obtained by typing
HELP INDIRECT symbolname
NOTE: symbolname does not include the <sym> angle brackets.
A list of Indirect error messages, including their severity class numbers,
can be obtained by typing
HELP INDIRECT MESSAGES
help lbr
The Librarian Utility Program (LBR) allows you to create, update, modify,
list, and maintain library files. LBR organizes files into library modules
so that you have rapid and convenient access to your files.
Library files contain two directory tables: the EPT and the MNT. The EPT
contains entry point names that consist of global symbols defined as entry
points in MACRO source programs. The MNT contains names of the modules in
the library. Both tables are ordered alphabetically.
Their are three types of libraries: object library files which contain
object files, macro library files which contain source macro files, and
universal library files which contain modules inserted from any kind of file
whether it be a program or text.
The general command line for LBR is shown next.
Format
outfile[,listfile]=infile[,...]
The format for entering file specifications is as follows:
ddnn:[directory]filename.type;version[/switch]
For a list of the LBR switches, type HELP LBR SWITCHES.
help macro
The Macro Assembler (MAC) utility program assembles one or more
MACRO-11 language source files into an object file. The command line
syntax is:
>MAC file.OBJ[/sw],file.LST[/sw]=file.MAC[/sw],file.MAC[/sw]. . .
or
>MAC
MAC>file.OBJ[/sw],file.LST[/sw]=file.MAC[/sw],file.MAC[/sw]. . .
MAC>?Z ! or another command line if another assembly is to be done
Type HELP MAC SWITCHES for a list of available switches.
help mag
The Magtape Control Task, MAG, lets you control magnetic tapes.
The format for the MAG command is as follows:
>MAG SET mmnn:/keyword[/keyword/keyword...] (mmnn: is the magtape unit)
MAG supports the following switches:
/BS Block size for magtape
/CC Type of carriage control
/EOF Specifies that MTAACP should return IE.EOF
/EOT Specifies that MTAACP should return IE.EOT
/EOV Specifies that MTAACP should return IE.EOV
/INITIALIZE Specifies the volume label with which the tape will
be initialized
/POS Specifies the number of files to spaced
/RS Specifies the record size
/REWIND Rewinds magtape to BOT
Type HELP MAG <switch> for more information on each switch.
See Appendix G of the IAS/RSX-11 I/O Operations Reference Manual for details.
help odt
The On-Line Debugging Tool (ODT) is an interactive debugging aid that is
added to a task by the Task Builder /DA (debugging aid) switch or the
/DEBUG qualifier to the LINK command. ODT receives control when you start
your task. ODT can:
o Control task execution
o Display or alter the contents of memory locations or registers
o Search and fill memory
o Perform calculations
You can execute your task gradually or in steps, set breakpoints, open
locations for examination, display bytes or words (in various formats),
and modify task locations. Thus, you can examine and modify your task
while running it, without rebuilding it. For a complete explanation of
ODT, see the RSX-11M-PLUS and Micro/RSX Debugging Reference Manual.
For more information, type HELP ODT subject:
COMMAND INTERNAL_REGISTER OPERATOR
DISPLAY INTERRUPT RETURN
GENERAL_REGISTER LINKING VARIABLE
help pip
The Peripheral Interchange Program (PIP) is a file utility program that
transfers data files from one standard Files-11 device to another. PIP also
performs file control functions. You invoke PIP file control functions by
means of switches and subswitches.
The command line for PIP differs for each function. Therefore, the comm and
line formats are described with the PIP switches.
Type HELP PIP SWITCHES for a list of the PIP switches and subswitches.
help pmd
PMD is the Postmortem Dump task. When a task aborts, PMD generates
a dump of its header and address space to aid in debugging.
You can make a task eligible for a Postmortem Dump in any of three ways:
o Build the task with the TKB switch /PM or the DCL command LINK/POSTMORTEM
o Install the task with the /PMD=YES switch or DCL command INSTALL/POSTMORTEM
o Abort the task with the /PMD switch or the DCL command ABORT/POSTMORTEM
Postmortem Dumps are written on the system disk in directory [1,4] in the file
taskname.PMD and are automatically spooled by PMD. (Note that the print
spooler automatically deletes all files with the type .PMD after printing
them.)
PMD also produces Snapshot Dumps of running tasks (see HELP PMD SNAPSHOT).
help print
PRI [[queuename:][jobname][/jobsw]=]file[/filesw] . . .
The PRINT command submits one or more files for printing. The files are
grouped together into a single print job and are all printed
together.
The optional queuename parameter allows you to submit your job to a queue
other than the default queue PRINT. The optional jobname parameter allows you
to give your print job a name. If you do not specify a job name, the name of
the first file in the job is used as the job name.
The following job switches are available:
/[NO]AD jobname queuename:
/AF /[NO]JO /[NO]RES
/CO:jobcopies /LE:pagelength /[NO]TR
/[NO]FL /[NO]LO
/FO:formnumber /PA:n=files
/[NO]HO /PRIO:priority
If you specify a job switch, the equal sign (=) is required in the PRI command.
The following file switches are available:
/CO:filecopies /[NO]DE /[NO]TR
help queue
QUE [queue:][job]/cmd
QUE /EN:n/cmd
The QUE command allows you to control the system's queues, jobs in the queues,
and the files that make up the jobs in the queues. The available commands
are listed below. For additional help, see HELP QUE command.
AS DEA FU LI STA
BA DEL HO MOD STO
BR EN IN REL UNBA
CR FI KIL SP UNSP
help rms
RMS-11 (Record Management Services for the PDP-11) is one of two file
systems supplied on RSX operating systems. It uses a series of user-callable
subroutines that implement sequential, relative, and indexed file
organizations. RMS-11 is accessible from MACRO-11, BASIC-PLUS-2, COBOL-11,
and other DIGITAL languages.
To display a list of RMS-11 error code explanations, type HELP RMS ERRORS.
Additional help is available on the following topics:
BCK (file back-up) CNV (file conversion)
DES (interactive file design) DEF (file definition)
DSP (file display) IFL (indexed file load)
RST (file restoration)
To obtain help on these topics, type HELP topic.
See also HELP RMS MACROS (for a list of RMS-11 macros) and HELP FCS (for
information on File Control Services (the alternate file system).
help rst
RMSRST restores files from magtape or disk that were backed up
using RMSBCK (type HELP BCK for more information) and produces
standard RMS-11 files as output. The structure, content, and
attributes of the restored files are those of the original files
when they were backed up. However, file placement will not be
restored.
To invoke installed RMSRST:
RST [command-string]
To invoke uninstalled RMSRST:
RUN $RMSRST
Type HELP RST COMMAND for an explanation of RMSRST's command line.
Type HELP RST SWITCHES for an explanation of RMSRST's switches.
See the RMS-11 Utilities manual for more information.
help shadow_recording
The SHADOW (SHA) command invokes the Shadow Recording control task.
Format:
>SHA command parameterlist
Commands:
ABORT ddnn: Stops shadow recording of a shadowed pair wh
ile
catch-up is in progress.
CONTINUE ddnn: TO ddxx: Restarts shadow recording on a pair of disks that
was previously being shadowed.
DISPLAY Displays all shadowed disk pairs.
START ddnn: TO ddxx: Starts shadow recording and initiates a catch-up
on the specified disk pair.
STOP ddnn: Stops shadow recording of a disk pair.
Parameters:
ddnn: Specifies the primary volume
ddxx: Specifies the secondary volume (which must be mounted as
foreign)
help slp
help submit
SUBMIT [[queuename:][jobname][/jobsw]=]file[/filesw] . . .
The SUBMIT command submits one or more batch files for processing on a
batch processor. The files are grouped into a single batch job and are
executed one after the other without interruption.
The optional queuename: switch allows you to submit your job to a queue
other
than the default BATCH. The optional jobname switch allows you to give y
our
job a name. If you do not specify a job name, the name of the first file
in the
job is used as the job name.
The following additional job switches are available:
/AF: /[NO]HO /[NO]LO
/[NO]PRIN:queue /PRIO:priority /[NO]RES
The following file switches are available:
/[NO]DE /[NO]TR
help sysgen
SYSGEN is the indirect command procedure used to tailor and build a version
of the RSX-11M-PLUS operating system for a particular installation. The SYSGEN
procedure asks questions about both the softw
are features you wish to include in your system, and about your system's
hardware configuration. SYSGEN uses that information to assemble and task
build an RSX-11M-PLUS operating system specifically tailored to your needs.
You should read both the System Generation and Installation Guide
and the Release Notes for this release of your operating system before
attempting to run the SYSGEN procedure. Attempts to run SYSGEN
without first consulting the documentation may yield undesired results.
You should also be familiar with the features and structure of
the RSX-11M-PLUS operating system before attempting to generate your own
system so you will understand the consequences of choosing or omitting
the various system options.
help syslib
SYSLIB is an object library containing various support routines that can be
included in a task. These HELP files describe most of the routines. To obtain
expanded information on any of the following SYSLIB routines, type:
HELP SYSLIB routine
The System Library contains the following types of support routines:
Register Handling Routines (For help, type HELP SYSLIB REGISTER)
Arithmetic Routines (For help, type HELP SYSLIB ARITHMETIC)
Data Conversion Routines (For help, type HELP SYSLIB DCONV)
Formatting Routines (For help, type HELP SYSLIB FORMAT)
Dynamic Memory Management
Routines (For help, type HELP SYSLIB DMEMORY)
Virtual Memory Management
Routines (For help, type HELP SYSLIB VMEMORY)
GCML Get Command Line Routine (For help, type HELP SYSLIB GCML)
EGCML Extended GCML Routine (For help, type HELP SYSLIB EGCML)
help tdx
TDX (Catch-All Task)
The RSX-11M-PLUS and Micro/RSX operating systems include a catchall task (TDX).
TDX "catches" commands that are not recognized by the DIGITAL Command
Language (DCL) or the Monitor Console Routine (MCR). If MCR receives an
unrecognized command, it searches for a task with that name and passes the
command line to TDX. TDX allows you to run uninstalled tasks and abbreviate
command names.
Any task installed with the task name ...CA. is treated as a catchall
task. The catchall task image is in the system library directory (usually
directory [3,54]) and is named TDX.TSK. Once installed, TDX checks the typed
command against its list of commands. If the commands match, TDX translates the
command into a valid MCR command.
TDX supports the following commands:
ATS CHD CHU CLR CRE CVT DEL DIR
DLG DLN FRE PUR SHQ SYS TDX TYP
For more information on each of the TDX pseudo-commands, type:
HELP TDX command
help tktn
TKTN is the Task Termination Notification program. When a task
aborts, TKTN displays the cause of the abort and the contents of the
task's registers on the terminal from which the task was running.
TKTN also displays device driver messages on the console, notifying
the operator when a device is not ready or when a device has been
dismounted.
See the RSX-11M-PLUS MCR Operations Manual or the RSX-11M-PLUS
Command Language Manual for a description of the TKTN messages.
help vmr
The Virtual Monitor Console Routine (VMR) is a privileged system task
that allows you to configure an RSX-11M-PLUS system image file.
VMR commands are a subset of Monitor Console Routine (MCR) commands.
VMR commands differ from MCR commands in that they are directed to the
disk image of a system rather than to the current running system. The
system image file that you configure by using VMR commands can later be
bootstrapped.
Before you run VMR, you need to be sure that certain requirements are met.
For help on preparing to run VMR, type HELP VMR PREPARATION.
You can use three methods to invoke VMR. For help on these methods, type
HELP VMR INVOKING.
After you invoke VMR, you can enter VMR commands. HELP is available for
the following commands:
ALT ASN CAN CON DEV INS LOA LUN
PAR REA RED REM RUN SAV SET TAS
TIM UNF UNL
For more information, type HELP VMR commandname.
help vfy
The File Structure Verification Utility (VFY) for Files-11 volumes provides
the ability to perform the following tasks:
o Check the readability and validity of a file-structured volume (default
function).
o Print the number of available blocks on a file-structured volume (the
Free switch (/FR)).
o Search for files in the index file that are not in any directory; that is,
files that are "lost" in the sense that they cannot be accessed by file
name (the Lost switch (/LO)).
o Validate directories against the files they list (the Directory Validation
switch (/DV)).
o List all files in the index file, showing the file ID, file name, and
owner (the List switch (/LI)).
o Mark as "used" all the blocks that appear to be available but are actually
allocated to a file (the Update switch (/UP)).
o Rebuild the storage allocation bit map so that it properly reflects the
information in the index file (the Rebuild switch (/RE)).
o Restore files that are marked for deletion (the Delete switch (/DE)).
o Delete bad file headers (the Header Delete switch (/HD)).
o Perform a read check on every allocated block on a file-structured volume
(the Read Check switch (/RC)).
There should be no other activity on the volume while VFY is executing. In
particular, activities that create new files, extend existing files, or
delete files should not be attempted while VFY is executing a function.
The command line for VFY is shown next.
Format
listfile,scratchdev=indev/switch
Parameter
listfile
Specifies the output file specification as follows:
ddnn:[directory]filename.type;version
scratchdev
Specifies the device on which the scratch file produced by VFY i
s to
be written. This parameter is in the following format:
ddnn:
indev
Specifies the volume to be verified in the same format as scratchdev.
If you do not specify the volume, the default is SY0.
switch
Specifies the function to be performed by VFY. Type HELP VFY SWITCHES
for a list of the VFY switches.
help zap
The Task/File Patch Program (ZAP) allows you to directly and modify task
image and data files on a Files-11 volume. Using ZAP, you can patch these
files interactively without reassembling and rebuilding the task.
ZAP performs many of the functions performed by the RSX-11 online debugging
utility, ODT. Thus, working knowledge of ODT is helpful in using ZAP.
ZAP provides the following features:
o Operating modes that allow you to access specific words and bytes in a
file, modify locations in a file, list the disk block and address
boundaries for each overlay segment in a task image file on disk, and open
a file for reading only.
o A set of internal registers that include eight Relocation Registers.
o Single-character commands that, with other command line elements, allow
you to open and close locations in a file and to display and manipulate
the values in those locations.
Except in read-only mode, the results of ZAP commands are permanent.
Although the ZAP program is relatively straightforward to use, patching
locations in a task image file requires knowing how to use the map (or
memory allocation file) generated by the Task Builder (TKB) and the listings
generated by the MACRO-11 assembler. These maps and listings provide
information you need to access the locations whose contents you want to
change.
The ZAP command line format is shown next.
Format
ddnn:[directory]filename.type;version/switch
After you enter the file specification, ZAP prompts with an underscore (_).
You terminate ZAP by entering the X command. This command exits you from ZAP
and returns control to your command line interpreter (CLI). For more
information on ZAP command line elements, type HELP ZAP ELEMENTS.
For more information on ZAP switches, type HELP ZAP SWITCHES.
ZAP provides two addressing modes and two access modes. For more information
on ZAP addressing and access modes, type HELP ZAP MODES.
---
okay, this with Part 01 (Refer: NIA068) is all the basic help on DCS.
==============================================================================
/ /
/ File 03 / NIA069 /
/ Computer Crime: System Security Controls [4] /
/ Guardian Of Time /
/ /
THE BASIC CONCEPT
Computer security reviews to identify and evaluate vulnerabilities,
calculate risks, and select controls have been conducted assuming
differences and uniqueness from one computer center to another b/c of their
one-of-a-kind development. Differences in physical facilities, computer
configurations, types or modes of computer usage, organization patters, and
computer application envrionmental factors have all been emphasized.
However, similarities in the use and security of computers are appearing in
many areas:
: Almost every computer center has secure area needs for housing of at
least one computer in one room and peripherals in the same or adjacent
room.
: Almost every well-run computer center has a procedure for physical access
control to facilities.
: Every well-run computer center has a procedure to assure secure backup
copies of data files and computer programs stored on computer media,
documentation, and computer supplies.
: Every computer center has logs and journals of computer usage and
performance that have importance for security.
: Every computer center has computer programs that contain controls to prevent
erroneous processing.
: Every computer center has computer programs requiring legal ownership
protection as indicated in SECTION III.
: Every well-designed computer center has some form of fire
detection/suppression capabilities.
: Every computer center has staff in positions of trust.
A new concept of baselines of security controls can be developed from these and
many other similar enviroments and vulnerabilities. A baseline of security
controls is a set of generally used controls meeting commonly desired control
objectives that should be present in every well-run computer center. The
justification for having them is derived from common usage and prudent
management rather than from explicit identification of vulnerabilities and
reduction of risk. If a baseline control is not selected for use, its absence
should be recorded or alternatives should be selected and justified.
A control objective is a condition or event that is to be avoided, deterred,
detected, prevented or recovered from. Examples are as follows:
: Avoid violations of laws and regulations
: Detect unathorized system use
: Prevent unauthorized access to sensitive areas.
A control is the policy, method, practice, device or programmed mechanism to
accomplish a control objective. A control has implentation variants that are
established in the detailed specifications for the control in a particular use.
Baseline controls have never before been identified, and it is not known how
many would qualify universally or w/in any specific organization. However, the
baseline concept is now feasible b/c of the control selection experience gained
as the computer security field matures. The 82 controls found in the study of
seven computer field sites are offered in Section VI as a preliminary step in
identifying baseline controls.
A baseline of security need not be a rigid, unalterable set of control
objectives and their required controls and variants. The purpose of a baseline
is to specify a minimum set of controls such that if a control is omitted,
there would be explicit reasons identified why it is absent or why an
alternative control is equivalent. If these exeptions from a baseline are
acceptable to the authority ultimately responsible for security, the baseline
could still be said to be the accepted criterion. In fact, this
exeption-taking is the process by which baselines evolve. When enough support
for an exception exists, a baseline is changed to include the exception as part
of the baseline.
A single, clear-cut baseline is improbable. As espoused by different experts
and organizations, baselines may be different. For example, differing
baselines may be established by insurance companies, banks and manufacturers.
Security experts, auditors and consultants may have differences of opinion over
inclusion of a control in a baseline but little disagreement about control
objectives. In addition, some controls and even some control objectives will
become obsolete as technology changes and advances. For these reasons, a
baseline is not identified as standard. Whereas a baseline may be called a
standard w/in any one domain (e.g., federal standards established by the US,
the US Department of Commerce, National Bureau of Standards, or a particular
company), the acceptance of general standards should be reserved for American
National Standards Institute adoption.
BENEFITS OF BASELINE CONTROLS
The success of the baseline concept lies in obtaining concurrence and
acceptance of a sufficient number of generally used controls by computer
security administrators and, in turn, by the management responsible for the
expenditure of resources for computer security. Certainly enough controls are
now identified in extensive security literature and exist as commercial
products. management must be willing to accept a recommended control justified
only by having a security administrator show that it is part of a baseline.
Prudent management will be motivated to do this out of trust in the security
administrator, the prospect of saving time, the reduction of expenses for
evaluation and study, and the contentment of knowing that the organization is
protected by generally used controls.
Baseline security will allow organizations to avoid unnecessary expenditure of
resources to engage in detailed study of already resolved problems and
selection of solutions by extensive justification efforts, data gathering, and
analysis. It will facilitate providing simple, inpexpensive, effective
safeguards comprehensively before difficult, new problems are attacked. As
computer-using orgainzations adopt the baseline approach for selection of
controls used most successfully by other organizations. This practice , they
will increasingly rely on the best security controls used most successfully by
other organizations. This practice will further advance the baseline concept
by encouraging uniformly high quality security. In addition, this will
stimulate and facilitate a formalized theory of computer security, putting it
on a par w/ other theories in computer technology. The training of computer
security specialists will likewise be formalized and advanced.
Identification of generally used controls and their variants will stabilize and
enlarge the security products market to stimulate a wider range of less
expensive control products that require few model types and options. for
example, when procedures are developed and accepted for cryptography use, then
cryptographic products will become more uniform and cost less.
FUTURE DEVELOPMENT OF BASELINE CONCEPTS
This report alone is not sufficient to assure the feasibility of baseline
concepts. The control objectives and controls identified from the seven field
site visits may form a baseline nucleus b/c they are explicitly documented as
currently in use in several computer centers, and representatives of all seven
sites agreed on their common usage. The literature abounds w/ descriptions of
controls, each usually recommended by one or two authors and not ncecessarily
supported by widespread use. The Systems Auditability and Control Reports from
the Institute of Internal Auditors identifies 300 controls and a set of control
objectives based on a survey of 1,500 computer-using enterprises. However, one
conclusion of these 1977 reports was a significant lack of common usage. Only
a few organizations were found to be using any particular control.
It is hoped that the baseline concepts will not be seen as alternatives to
quantitative and qualitative risk assessment methods now in use. Baseline
controls would be selected before such assessments take place so that the
obvious, accepted, routine controls could be applied before risk assessments
are used. Therefore, assessments can be started further along in the controls
selection process.
When protection from intentionally caused losses is of concern, a game
strategy must be used. The intelligent opponent will normally not attack
where effective controls are in place but will seek vulnerabilities resulting
from a lack of controls. In other words, losses will tend to occur where
victims have not thought to put controls. It must be assumed that an
intelligent opponent will know as much about published baselines as their
originators do and will take advantage of any deficiencies. Therefore, the
baseline concepts are esentially foreced on potential victims. These
vulnerable organizations must establish full baseline protection as routine,
prudent operation to be able to concerntrate on those vulnerabilities created
by the special circumstances and new environmental factors brought about by
use of new technology and new applications. After all, that is what
intelligent opponents will also be concentrating on after being rebuffed by
baseline controls.
The baseline concepts have a solubrious effect on errors and omissions; they
can mitigate unintentional threats. Unlike intentional acts, sources of errors
and omissions can only affect specific vulnerabilities. Therefore, an
escalated game strategy is not required. Prevention of accidental loss
results mostly from control of intentionally caused loss.
Formal bodies for identifying baseline controls might include the American
National Standards Institute, but based on its historical practice the
institute would probably standardize only a few of the most significant
controls such as cryptographic algorithms or uninterruptable power supplies.
The Generally Accepted Accounting Practices adopted by the American Institute
of Certified Public Accountants might be an interesting model to build on.
However, this would require a publicly and legally recognized professional body
in a narrowly defined, highly controlled (certified) practice. The computer
field is probably too highly diversified and changing to fast for the necessary
stability and consolidation of professionalism for a similar concept to work
for adoption of baselines in the near future.
The baseline concepts must therefore evolve slowly over a long period to
achieve a state close to general concurrence. Recognition of the baseline
concepts at this early stage should facilitate their development. It can be
argued that the number of generally used controls is insufficient to form good
baselines. However, the similarity of control needs has never been tested. In
fact, all current methods of selection of controls have been based on the
opposite assumption that every situation is unique. Assuming at least some
commonlity of needs and controls, a biginning based on potential benefits of
baseline concepts may produce sufficient results to counter such arguments.
The types of number of control objectives and controls in each category
described in this report will change as the computer security field matures,
new potential threats arise, and the technology changes. Control objectives
and controls will be moved from special to selective to baseline categories,
some controls will be dropped or replaced, and new controls will be developed.
Today, few control objectives and controls have been achieved explicit,
generally used, baseline status b/c the concept is new and differences rather
than similarities have been emphasized at computer centers. In the future,
baselines should grow and become more strongly accepted. Special controls
could decrease; many will become baseline controls as security needs become
more commonly known. This would occur as selection of controls becomes more
strongly based on what others are doing under similar circumstances.
Justification for recommendations will increasingly be based on the concept
that "we should do this, b/c company X is doining it"
[END OF SECTION IV COMPUTER SECURITY CONTROLS AND THE LAW]
==============================================================================
/ /
/ File 04 / NIA069 /
/ KERMIT PROTOCOL MANUAL /
/ Part 01 of 02 /
/ Fifth Edition /
/ /
/ Frank da Cruz /
/ /
/ Columbia University Center for Computing Activities /
/ New York, New York 10027 /
/ /
/ 3 April 1984 /
/ /
/ Submitted By: /
/ Malefactor Of Organized Crime /
/ Dedicated To: /
The Mentor
Copyright (C) 1981,1982,1983,1984
Trustees of Columbia University in the City of New York
Permission is granted to any individual or institution to copy or
use this document and the programs described in it, except for
explicitly commercial purposes.
Preface to the Fourth Edition Page 1
Preface to the Fourth Edition
The fourth edition (November 1983) of the KERMIT Protocol Manual incorporates
some new ideas that grew from our experience in attempting to implement some of
the features described in earlier editions, particularly user/server functions.
These include a mechanism to allow batch transfers to be interrupted gracefully
for either the current file or the entire batch of files; a "capability mask";
a protocol extension for passing file attributes. In addition, numbers are now
written in decimal notation rather than octal, which was confusing to many
readers. Also, several incompatible changes were made in minor areas where no
attempts at an implementation had yet been made; these include:
- The format and interpretation of the operands to the server commands.
- Usurpation of the reserved fields 10-11 of the Send-Init packet, and
addition of new reserved fields.
Most of the remaining material has been rewritten and reorganized, and much new
material added, including a section on the recommended vocabulary for documen-
tation and commands.
The previous edition of the Protocol Manual attempted to define "protocol ver-
sion 3"; this edition abandons that concept. Since KERMIT development is an
unorganized, disorderly, distributed enterprise, no requirement can be imposed
on KERMIT implementors to include a certain set of capabilities in their im-
plementations. Rather, in this edition we attempt to define the basic
functionality of KERMIT, and then describe various optional functions.
The key principle is that any implementation of KERMIT should work with any
other, no matter how advanced the one or how primitive the other. The capabily
mask and other Send-Init fields attempt to promote this principle.
FIFTH EDITION
The fifth edition (March 1984) attempts to clarify some fine points that had
been left ambiguous in the 4th edition, particularly with respect to when and
how prefix encoding is done, and when it is not, and about switching between
block check types. A mechanism is suggested (in the Attributes section) for
file archiving, and several attributes have been rearranged and some others ad-
ded (this should do no harm, since no one to date has attempted to implement
the attributes packet). A more complete protocol state table is provided, a
few minor additions are made to the collection of packet types.
A FEW WORDS...
Before deciding to write a new version of KERMIT, please bear in mind that the
philosophy of KERMIT has always been that is not, and never should become, a
commercial product, sold for profit. Its goal is to promote communication and
sharing, and KERMIT itself should be freely shared, and not sold. Media and
reproduction costs may be recouped if desired, but profit should not be the mo-
tive. Vendors of commercial software, however, may request permission to in-
clude KERMIT with, or in, their programs provided certain conditions are met,
including that credit for the protocol be given to Columbia and that the price
of the product not be raised substantially beyond media and reproduction costs
Preface to the Fourth Edition Page 2
for inclusion of KERMIT. Contact the KERMIT group at Columbia if you have any
questions about this. Prospective KERMIT implementors should check with us in
any case, to be sure that someone else has not already done, or started to do,
the same thing you propose to do.
KERMIT is distributed from Columbia University on magnetic tape. Complete or-
dering instructions can be found in the Kermit Users Guide. Direct inquiries
about KERMIT to:
KERMIT Distribution
Columbia University Center for Computing Activities
7th Floor, Watson Laboratory
612 West 115th Street
New York, NY 10025
ACKNOWLEDGEMENTS
Bill Catchings and I designed the basic KERMIT protocol at Columbia University
in 1981. For ideas, we looked at some of the ANSI models (X3.57, X3.66), the
ISO OSI model, some real-world "asynchronous protocols" (including the Stanford
Dialnet project, the University of Utah TTYFTP project), as well as at file
transfer on full-blown networks like DECnet and ARPAnet.
Bill wrote the first two programs to implement the protocol, one for the
DEC-20, one for a CP/M-80 microcomputer, and in the process worked out most of
the details and heuristics required for basic file transfer. Meanwhile, Daphne
Tzoar and Vace Kundakci, also of Columbia, worked out the additional details
necessary for IBM mainframe communication.
Much credit should also go to Bernie Eiben of Digital Equipment Corporation for
promoting widespread use of KERMIT and for adding many insights into how it
should operate, and to Nick Bush and Bob McQueen of Stevens Institute of Tech-
nology, for many contributions to the "advanced" parts of the protocol, and for
several major KERMIT implementations.
Thanks to the many people all over the world who have contributed new KERMIT
implementations, who have helped with KERMIT distribution through various user
groups, and who have contributed to the quality of the protocol and its many
implementations by reporting or fixing problems, criticizing the design, or
suggesting new features.
DISCLAIMER
No warranty of the software nor of the accuracy of the documentation surround-
ing it is expressed or implied, and neither the authors nor Columbia University
acknowledge any liability resulting from program or documentation errors.
Introduction Page 3
1. Introduction
This manual describes the KERMIT protocol. It is assumed that you understand
the purpose and operation of the Kermit file transfer facility, described in
the Kermit Users Guide, and basic terminology of data communications and com-
puter programming.
1.1. Background
The KERMIT file transfer protocol is intended for use in an environment where
there may be a diverse mixture of computers -- micros, personal computers,
workstations, laboratory computers, timesharing systems -- from a variety of
manufacturers. All these systems need have in common is the ability to com-
municate in ASCII over ordinary serial telecommunication lines.
KERMIT was originally designed at Columbia University to meet the need for file
transfer between our DECSYSTEM-20 and IBM 370-series mainframes and various
microcomputers. It turned out that the diverse characteristics of these three
kinds of systems resulted in a design that was general enough to fit almost any
system. The IBM mainframe, in particular, strains most common assumptions
about how computers communicate.
1.2. Overview
The KERMIT protocol is specifically designed for character-oriented transmis-
sion over serial telecommunication lines. The design allows for the restric-
tions and peculiarities of the medium and the requirements of diverse operating
environments -- buffering, duplex, parity, character set, file organization,
etc. The protocol is carried out by KERMIT programs on each end of the serial
connection sending "packets" back and forth; the sender sends file names, file
contents, and control information; the receiver acknowledges (positively or
negatively) each packet.
The packets have a layered design, more or less in keeping with the ANSI and
ISO philosophies, with the outermost fields used by the data link layer to
verify data integrity, the next by the session layer to verify continuity, and
the data itself at the application level.
Connections between systems are established by the ordinary user. In a typical
case, the user runs KERMIT on a microcomputer, enters terminal emulation, con-
nects to a remote host computer (perhaps by dialing up), logs in, runs KERMIT
on the remote host, and then issues commands to that KERMIT to start a file
transfer, "escapes" back to the micro, and issues commands to that KERMIT to
start its side of the file transfer. Files may be transferred singly or in
groups.
Basic KERMIT provides only file transfer, and that is provided for sequential
files only, though the protocol attempts to allow for various types of sequen-
tial files. Microcomputer implementations of KERMIT are also expected to
provide terminal emulation, to facilitate the initial connection.
More advanced implementations simplify the "user interface" somewhat by allow-
ing the KERMIT on the remote host to run as a "server", which can transfer
files in either direction upon command from the local "user" Kermit. The serv-
Introduction Page 4
er can also provide additional functionality, such as file management, mes-
sages, mail, and so forth. Other optional features also exist, including a
variety of block check types, a mechanism for passing 8-bit data through a
7-bit communication link, a way to compressing a repeated sequence of charac-
ters, and so forth.
As local area networks become more popular, inexpensive, and standardized, the
demand for KERMIT and similar protocols may dwindle, but will never wither away
entirely. Unlike hardwired networks, KERMIT gives the ordinary user the power
to establish reliable error-free connections between any two computers; this
may always be necessary for one-shot or long-haul connections.
Definitions Page 5
2. Definitions
2.1. General Terminology
TTY: This is the term commonly used for a device which is connected to a com-
puter over an EIA RS-232 serial telecommunication line. This device is most
commonly an ASCII terminal, but it may be a microcomputer or even a large
multi-user computer emulating an ASCII terminal. Most computers provide
hardware (RS-232 connectors and UARTs) and software (device drivers) to support
TTY connections; this is what makes TTY-oriented file transfer protocols like
KERMIT possible on almost any system at little or no cost.
LOCAL: When two machines are connected, the LOCAL machine is the one which you
interact with directly, and which is in control of the terminal. The "local
Kermit" is the one that runs on the local machine. A local Kermit always com-
municates over an external device (the micro's communication port, an assigned
TTY line, etc).
REMOTE: The REMOTE machine is the one on the far side of the connection, which
you must interact with "through" the local machine. The "remote Kermit" runs
on the remote machine. A remote Kermit usually communicates over its own
"console", "controlling terminal", or "standard i/o" device.
HOST: Another word for "computer", usually meaning a computer that can provide
a home for multiple users or applications. This term should be avoided in KER-
MIT lore, unless preceded immediately by LOCAL or REMOTE, to denote which host
is meant.
SERVER: An implementation of remote Kermit that can accept commands in packet
form from a local Kermit program, instead of directly from the user.
USER: In addition to its usual use to denote the person using a system or
program, "user" will also be used refer to the local Kermit program, when the
remote Kermit is a server.
2.2. Numbers
All numbers in the following text are expressed in decimal (base 10) notation
unless otherwise specified.
Numbers are also referred to in terms of their bit positions in a computer
word. Since KERMIT may be implemented on computers with various word sizes, we
start numbering the bits from the "right" -- bit 0 is the least significant.
Bits 0-5 are the 6 least significant bits; if they were all set to one, the
value would be 63.
A special quirk in terminology, however, refers to the high order bit of a
character as it is transmitted on the communication line, as the "8th bit".
More properly, it is bit 7, since we start counting from 0. References to the
"8th bit" generally are with regard to that bit which ASCII transmission sets
aside for use as a parity bit. KERMIT concerns itself with whether this bit
can be usurped for the transmission of data, and if not, it may resort to
"8th-bit prefixing".
Definitions Page 6
2.3. Character Set
All characters are in ASCII (American national Standard Code for Information
Interchange) representation, ANSI standard X3.4-1968. All implementations of
KERMIT transmit and receive characters only in ASCII. The ASCII character set
is listed in Appendix V.
ASCII character mnemonics:
NUL Null, idle, ASCII character 0.
SOH Start-of-header, ASCII character 1 (Control-A).
SP Space, blank, ASCII 32.
CR Carriage return, ASCII 13 (Control-M).
LF Linefeed, ASCII 10 (Control-J).
CRLF A carriage-return linefeed sequence.
DEL Delete, rubout, ASCII 127.
A control character is considered to be any byte whose low order 7 bits are in
the range 0 through 31, or equal to 127. In this document, control characters
are written in several ways:
Control-A
This denotes ASCII character 1, commonly referred to as "Control-A".
Control-B is ASCII character 2, and so forth.
CTRL-A This is a common abbreviation for "Control-A". A control character is
generally typed at a computer terminal by holding down the key marked
CTRL and pressing the corresponding alphabetic character, in this case
"A".
?A "Uparrow" notation for CTRL-A. Many computer systems "echo" control
characters in this fashion.
A printable ASCII character is considered to be any character in the range 32
(SP) through 126 (tilde).
2.4. Conversion Functions
Several conversion functions are useful in the description of the protocol and
in the program example. The machine that Kermit runs on need operate only on
integer data; these are functions that operate upon the numeric value of single
ASCII characters.
char(x) = x+32 Transforms the integer x, which is assumed to lie in the range
0 to 94, into a printable ASCII character; 0 becomes SP, 1 be-
comes "!", 3 becomes "#", etc.
unchar(x) = x-32
Transforms the character x, which is assumed to be in the
printable range (SP through tilde), into an integer in the
range 0 to 94.
ctl(x) = x XOR 64
Maps between control characters and their printable represen-
tations, preserving the high-order bit. If x is a control
Definitions Page 7
character, then
x = ctl(ctl(x))
that is, the same function is used to controllify and uncon-
trollify. The argument is assumed to be a true control charac-
ter (0 to 31, or 127), or the result of applying CTL to a true
control character (i.e. 63 to 95). The transformation is a
mnemonic one -- ?A becomes A and vice versa.
2.5. Protocol Jargon
A Packet is a clearly delimited string of characters, comprised of "control
fields" nested around data; the control fields allow a KERMIT program to deter-
mine whether the data has been transmitted correctly and completely. A packet
is the unit of transmission in the KERMIT protocol.
ACK stands for "Acknowledge". An ACK is a packet that is sent to acknowledge
receipt of another packet. Not to be confused with the ASCII character ACK.
NAK stands for "Negative Acknowledge". A NAK is a packet sent to say that a
corrupted or incomplete packet was received, the wrong packet was received, or
an expected packet was not received. Not to be confused with the ASCII charac-
ter NAK.
A timeout is an event that can occur if expected data does not arrive within a
specified amount of time. The program generating the input request can set a
"timer interrupt" to break it out of a nonresponsive read, so that recovery
procedures may be activated.
System Requirements Page 8
3. System Requirements
The KERMIT protocol requires that:
- The host can send and receive characters using 7- or 8-bit ASCII en-
coding over an EIA RS-232 physical connection, either hardwired or
dialup.
- All printable ASCII characters are acceptable as input to the host
1
and will not be transformed in any way . Similarly, any intervening
network or communications equipment ("smart modems", TELENET, ter-
minal concentrators, port selectors, etc) must not transform or swal-
low any printable ASCII characters.
- A single ASCII control character can pass from one system to the
other without transformation. This character is used for packet
synchronization. The character is normally Control-A (SOH, ASCII 1),
but can be redefined.
- If a host requires a line terminator for terminal input, that ter-
minator must be a single ASCII control character, such as CR or LF,
distinct from the packet synchronization character.
- When using a job's controlling terminal for file transfer, the system
must allow the KERMIT program to set the terminal to no echo, in-
finite width (no "wraparound" or CRLF insertion by the operating
system), and no "formatting" of incoming or outgoing characters (for
instance, raising lowercase letters to uppercase, transforming con-
trol characters to printable sequences, etc). In short, the terminal
must be put in "binary" or "raw" mode, and, hopefully, restored af-
terwards to normal operation.
- The host's terminal input processor should be capable of receiving a
single burst of 40 to 100 characters at normal transmission speeds.
This is the typical size of packet.
Note that most of these requirements rule out the use of KERMIT through IBM
3270 / ASCII protocol converters.
KERMIT does not require:
- That the connection run at any particular baud rate.
- That the system can do XON/XOFF or any other kind of flow control.
System- or hardware-level flow control can help, but it's not neces-
sary. See section 5.7.
- That the system is capable of full duplex operation. Any mixture of
_______________
1
If they are translated to another character set, like EBCDIC, the KERMIT
program must be able to reconstruct the packet as it appeared on the communica-
tion line, before transformation.
System Requirements Page 9
half and full duplex systems is supported.
- That the system can transmit or receive 8-bit bytes. KERMIT will
take advantage of 8-bit connections to send binary files; if an 8-bit
connection is not possible, then binary files may be sent using an
optional prefix encoding.
Printable Text versus Binary Data Page 10
4. Printable Text versus Binary Data
For transmission between unlike systems, files must be assigned to either of
two catagories: printable text or binary.
A printable text file is one that can make sense on an unlike system -- a docu-
ment, program source, textual data, etc. A binary file is one that will not
(and probably can not) make sense on an unlike system -- an executable program,
numbers stored in internal format, etc. On systems with 8-bit bytes, printable
2
ASCII files will have the high order bit of each byte set to zero (since ASCII
is a 7-bit code) whereas binary files will use the high order bit of each byte
for data, in which case its value can vary from byte to byte.
Many computers have no way to distinguish a printable file from a binary file
-- especially one originating from an unlike system -- so the user may have to
give an explicit command to Kermit to tell it whether to perform these conver-
sions.
4.1. Printable Text Files
A primary goal of KERMIT is for printable text files to be useful on the target
system after transfer. This requires a standard representation for text during
transmission. KERMIT's standard is simple: 7-bit ASCII characters, with
"logical records" (lines) delimited by CRLFs. It is the responsibility of sys-
tems that do not store printable files in this fashion to perform the necessary
conversions upon input and output. For instance, IBM mainframes might strip
trailing blanks on output and add them back on input; UNIX would prepend a CR
to its normal record terminator, LF, upon output and discard it upon input. In
addition, IBM mainframes must do EBCDIC/ASCII translation for text files.
No other conversions (e.g. tab expansion) are performed upon text files. This
representation is chosen because it corresponds to the way text files are
stored on most microcomputers and on many other systems. In many common cases,
no transformations are necessary at all.
4.2. Binary Files
Binary files are transmitted as though they were a sequence of characters. The
difference from printable files is that the status of the "8th bit" must be
preserved. When binary files are transmitted to an unlike system, the main ob-
jective is that they can be brought back to the original system (or one like
it) intact; no special conversions should be done during transmission, except
to make the data fit the transmission medium.
For binary files, eight bit character transmission is permissible as long as
the two Kermit programs involved can control the value of the parity bit, and
_______________
2
There are some exceptions, such as systems that store text files in so-
called "negative ASCII", or text files produced by word processors that use the
high order bit to indicate underline or boldface attributes.
Printable Text versus Binary Data Page 11
no intervening communications equipment will change its value. In that case,
the 8th bit of a transmitted character will match that of the original data
byte, after any control-prefixing has been done. When one or both sides cannot
control the parity bit, a special prefix character may be inserted, as
described below.
Systems that do not store binary data in 8-bit bytes, or whose word size is not
a multiple of 8, may make special provisions for "image mode" transfer of bi-
nary files. This may be done within the basic protocol by having the two sides
implicitly agree upon a scheme for packing the data into 7- or 8-bit ASCII
characters, or else the more flexible (but optional) file attributes feature
may be used. The former method is used on PDP-10 36-bit word machines, in
which text is stored five 7-bit bytes per word; the value of the "odd bit" is
sent as the parity bit of every 5th word.
File Transfer Page 12
5. File Transfer
The file transfer protocol takes place over a transaction. A transaction is an
exchange of packets beginning with a Send-Init (S) packet, and ending with a
3
Break Transmission (B) or Error (E) packet , and may include the transfer of
one or more files, all in the same direction. In order to minimize the unfor-
seen, KERMIT packets do not contain any control characters except one specially
designated to mark the beginning of a packet. Except for the packet marker,
only printable characters are transmitted. The following sequence charac-
terizes basic Kermit operation; the sender is the machine that is sending
files; the receiver is the machine receiving the files.
1. The sender transmits a Send-Initiate (S) packet to specify its
parameters (packet length, timeout, etc; these are explained below).
2. The receiver sends an ACK (Y) packet, with its own parameters in the
data field.
3. The sender transmits a File-Header (F) packet, which contains the
file's name in the data field. The receiver ACKs the F packet, with
no data in the data field of the ACK (optionally, it may contain the
name under which the receiver will store the file).
4. The sender sends the contents of the file, in Data (D) packets. Any
data not in the printable range is prefixed and replaced by a print-
able equivalent. Each D packet is acknowledged before the next one
is sent.
5. When all the file data has been sent, the sender sends an End-Of-
File (Z) packet. The receiver ACKs it.
6. If there is another file to send, the process is repeated beginning
at step 3.
7. When no more files remain to be sent, the sender transmits an End-
Of-Transmission (B) packet. The receiver ACKs it. This ends the
transaction, and closes the logical connection (the physical connec-
tion remains open).
Each packet has a sequence number, starting with 0 for the Send Init. The ack-
nowledgment (ACK or NAK) for a packet has the same packet number as the packet
being acknowledged. Once an acknowledgment is successfully received the packet
number is increased by one, modulo 64.
If the sender is remote, it waits for a certain amount of time (somewhere in
the 5-30 second range) before transmitting the Send-Init, to give the user time
to escape back to the local KERMIT and tell it to receive files.
_______________
3
A transaction should also be considered terminated when one side or the
other has stopped without sending an Error packet.
File Transfer Page 13
5.1. Conditioning the Terminal
KERMIT is most commonly run with the user sitting at a microcomputer, connected
through a communications port to a remote timesharing system. The remote KER-
MIT is using its job's own "controlling terminal" for file transfer. While the
microcomputer's port is an ordinary device, a timesharing job's controlling
terminal is a special one, and often performs many services that would inter-
fere with normal operation of KERMIT. Such services include echoing (on full
duplex systems), wrapping lines by inserting carriage return linefeed sequences
at the terminal width, pausing at the end of a screen or page full of text,
displaying system messages, alphabetic case conversion, control character in-
tepretation, and so forth. Mainframe KERMIT programs should be prepared to
disable as many of these services as possible before packet communication
begins, and to restore them to their original condition at the end of a trans-
action. Disabling these services is usually known as "putting the terminal in
binary mode."
KERMIT's use of printable control character equivalents, variable packet
lengths, redefinable markers and prefixes, and allowance for any characters at
all to appear between packets with no adverse effects provide a great deal of
adaptability for those systems that do not allow certain (or any) of these fea-
tures to be disabled.
5.2. Timeouts, NAKs, and Retries
If a KERMIT program is capable of setting a timer interrupt, or setting a time
limit on an input request, it should do so whenever attempting to read a packet
from the communication line, whether sending or receiving files. Having read a
packet, it should turn off the timer.
If the sender times out waiting for an acknowledgement, it should send the same
packet again, repeating the process a certain number of times up to a retry
limit, or until an acknowledgement is received. If the receiver times out
waiting for a packet, it can send either a NAK packet for the expected packet
or another ACK for the last packet it got.
If a packet from the sender is garbled or lost in transmission (the latter is
detected when the sequence number increases by more than 1, modulo 64, the
former by a bad checksum), the receiver sends a NAK for the garbled or missing
packet. If an ACK or a NAK from the receiver is garbled or lost, the sender
ignores it; in that case, one side or the other will time out and retransmit.
A retry count is maintained, and there is a retry threshold, normally set
around 5. Whenever a packet is resent -- because of a timeout, or because it
was NAK'd -- the counter is incremented. When it reaches the threshold, the
transaction is terminated and the counter reset.
If neither side is capable of timing out, a facility for manual intervention
must be available on the local KERMIT. Typically, this will work by sampling
the keyboard (console) periodically; if input, such as a CR, appears, then the
same action is taken as if a timeout had occurred. The local KERMIT keeps a
running display of the packet number or byte count on the screen to allow the
user to detect when traffic has stopped. At this point, manual intervention
should break the deadlock.
File Transfer Page 14
Shared systems which can become sluggish when heavily used should adjust their
own timeout intervals on a per-packet basis, based on the system load, so that
file transfers won't fail simply because the system was too slow.
Normally, only one side should be doing timeouts, preferably the side with the
greatest knowledge of the "environment" -- system load, baud rate, and so
forth, so as to optimally adjust the timeout interval for each packet. If both
sides are timing out, their intervals should differ sufficiently to prevent
collisions.
5.3. Errors
During file transfer, the sender may encounter an i/o error on the disk, or the
receiver may attempt to write to a full or write-protected device. Any con-
dition that will prevent successful transmission of the file is called a "fatal
error". Fatal errors should be detected, and the transfer shut down grace-
fully, with the pertinent information provided to the user. Error packets
provide a mechanism to do this.
If a fatal error takes place on either the sending or receiving side, the side
which encountered the error should send an Error (E) packet. The E packet con-
tains a brief textual error message in the data field. Both the sender and
receiver should be prepared to receive an Error packet at any time during the
transaction. Both the sender and receiver of the Error packet should halt, or
go back into into user command mode (a server should return to server command
wait). The side that is local should print the error message on the screen.
There is no provision for sending nonfatal error messages, warnings, or infor-
mation messages during a transaction. It would be possible to add such a fea-
ture, but this would require both sides agree to use it through setting of a
bit in the capability mask, since older KERMITs that did not know about such a
feature would encounter an unexpected packet type and would enter the fatal er-
ror state. In any case, the utility of such a feature is questionable, since
there is no guarantee that the user will be present to see such messages at the
time they are sent; even if they are saved up for later perusal in a "message
box", their significance may be long past by the time the user reads them. See
the section on Robustness, below.
5.4. Heuristics
During any transaction, several heuristics are useful:
1. A NAK for the current packet is equivalent to an ACK for the pre-
vious packet (modulo 64). This handles the common situation in
which a packet is successfully received, and then ACK'd, but the ACK
is lost. The ACKing side then times out waiting for the next packet
and NAKs it. The side that receives a NAK for packet n+1 while
waiting for an ACK for packet n simply sends packet n+1.
2. If packet n arrives more than once, simply ACK it and discard it.
This can happen when the first ACK was lost. Resending the ACK is
necessary and sufficient -- don't write the packet out to the file
again!
File Transfer Page 15
3. When opening a connection, discard the contents of the line's input
buffer before reading or sending the first packet. This is espe-
cially important if the other side is in receive mode (or acting as
a server), in which case it may have been sending out periodic NAKs
for your expected SEND-INIT or command packet. If you don't do
this, you may find that there are sufficient NAKs to prevent the
transfer -- you send a Send-Init, read the response, which is an old
NAK, so you send another Send-Init, read the next old NAK, and so
forth, up to the retransmission limit, and give up before getting to
the ACKs that are waiting in line behind all the old NAKs. If the
number of NAKs is below the cutoff, then each packet may be trans-
mitted multiply.
4. Similarly, before sending a packet, you should clear the input buff-
er (after looking for any required handshake character). Failure to
clear the buffer could result in propogation of the repetition of a
packet caused by stacked-up NAKs.
5.5. File Names
The syntax for file names can vary widely from system to system. To avoid
problems, it is suggested that filenames be represented in the File Header (F)
packet in a "normal form", by default (that is, there should be an option to
override such conversions).
1. Delete all pathnames and attributes from the file specification.
The file header packet should not contain directory or device names;
if it does, it may cause the recipient to try to store the file in
an inaccessible or nonexistent area, or it may result in a very
strange filename.
2. After stripping any pathname, convert the remainder of the file
specification to the form "name.type", with no restriction on length
(except that it fit in the data field of the F packet), and:
a. Include no more than one dot.
b. Use digits, uppercase letters only in name and type.
Special characters like "$", "_", "-", "&", and so forth should be disallowed,
since they're sure to cause problems on one system or another.
The recipient, of course, cannot depend upon the sender to follow this conven-
tion, and should still take precautions. However, since most file systems em-
body the notion of a file name and a file type, this convention will allow
these items to be expressed in a way that an unlike system can understand. The
particular notation is chosen simply because it is the most common.
The recipient must worry about the length of the name and type fields of the
file name. If either is too long, they must be truncated. If the result
(whether truncated or not) is the same as the name of a file that already ex-
ists in the same area, the recipient should have the ability to take some spe-
cial action to avoid writing over the original file.
KERMIT implementations that convert file specifications to normal form by
default should have an option to override this feature. This would be most
File Transfer Page 16
useful when transferring files between like systems, perhaps used in conjunc-
tion with "image mode" file transfer. This could allow, for instance, one UNIX
system to send an entire directory tree to another UNIX system.
5.6. Robustness
A major feature of the KERMIT protocol is the ability to transfer multiple
files. Whether a particular KERMIT program can actually send multiple files
depends on the capabilities of the program and the host operating system (any
KERMIT program can receive multiple files).
If a KERMIT program can send multiple files, it should make every attempt to
send the entire group specified. If it fails to send a particular file, it
should not terminate the entire batch, but should go on the the next one, and
proceed until an attempt has been made to send each file in the group.
Operating in this robust manner, however, gives rise to a problem: the user
must be notified of a failure to send any particular file. Unfortunately, it
is not sufficient to print a message to the screen since the user may not be
physically present. A better solution would be to have the sender optionally
keep a log of the transaction, giving the name of each file for which an at-
tempt was made, and stating whether the attempt was successful, and if not, the
reason. Additional aids to robustness are described in the Optional Features
section, below.
5.7. Flow Control
On full duplex connections, XON/XOFF flow control can generally be used in con-
junction with KERMIT file transfer with no ill effects. This is because XOFFs
are sent in the opposite direction of packet flow, so they will not interfere
with the packets themselves. XON/XOFF, therefore, need not be implemented by
the KERMIT program, but can done by the host system. If the host system
provides this capability, it should be used -- if both sides can respond
XON/XOFF signals, then buffer overruns and the resulting costly packet
retransmissions can be avoided.
Beware, however, of the following situation: remote Kermit is sending periodic
NAKs, local system is buffering them on the operating system level (because the
user has not started the local end of the file transfer yet); local line buffer
becomes full, local systems sends XOFF, remote starts buffering them up on its
end, user finally starts file transfer on local end, clears buffer, local
operating system sends XON, and then all the remotely buffered NAKs show up,
causing the packet echoing problem described above, despite the buffer clear-
ing.
Flow control via modem signals can also be used when available.
Note that flow control should not be confused with "handshake" or "line
turnaround" techniques that are used on simplex or half-duplex communication
lines.
File Transfer Page 17
5.8. Basic KERMIT Protocol State Table
The KERMIT protocol can be described as a set of states and transitions, and
rules for what to do when changing from one state to another. State changes
occur based on the type of packets that are sent or received, or errors that
may occur. Packets always go back and forth; the sender of a file always sends
data packets of some kind (init, header, data) and the receiver always returns
ACK or NAK packets.
Upon entering a given state, a certain kind of packet is either being sent or
is expected to arrive -- this is shown on top of the description of that state.
As a result of the action, various responses may occur; these are shown in the
EVENT column. For each event, an appropriate ACTION is taken, and the protocol
enters a NEW STATE.
The following table specifies basic KERMIT operation. Timeouts and error con-
ditions have been omitted from the following table for simplicity, but the ac-
tion is as described above. Server operation and some of the advanced features
are also omitted. A full-blown state table is given subsequently.
File Transfer Page 18
STATE EVENT ACTION NEW STATE
-- SEND STATES --
Send Send-Init Packet
S Get NAK,bad ACK (None) S
Get good ACK Set remote's params, open file SF
(Other) (None) A
Send File-Header Packet
SF Get NAK,bad ACK (None) SF
Get good ACK Get bufferful of file data SD
(Other) (None) A
Send File-Data Packet
SD Get NAK,bad ACK (None) SD
Get good ACK Get bufferful of file data SD
(End of file) (None) SZ
(Other) (None) A
Send EOF Packet
SZ Get NAK,bad ACK (None) SZ
Get good ACK Get next file to send SF
(No more files) (None) SB
(Other) (None) A
Send Break (EOT) Packet
SB Get NAK,bad ACK (None) SB
Get good ACK (None) C
(Other) (None) A
-- RECEIVE STATES --
Wait for Send-Init Packet
R Get Send-Init ACK w/local params RF
(Other) (None) A
Wait for File-Header Packet
RF Get Send-Init ACK w/local params
(previous ACK was lost) RF
Get Send-EOF ACK (prev ACK lost) RF
Get Break ACK C
Get File-Header Open file, ACK RD
(Other) (None) A
Wait for File-Data Packet
RD Get previous
packet(D,F) ACK it again RD
Get EOF ACK it, close the file RF
Get good data Write to file, ACK RD
(Other) (None) A
File Transfer Page 19
-- STATES COMMON TO SENDING AND RECEIVING --
C (Send Complete) start
A ("Abort") start
Packet Format Page 20
6. Packet Format
6.1. Fields
The KERMIT protocol is built around exchange of packets of the following for-
mat:
+------+-----------+-----------+------+------------+-------+
| MARK | char(LEN) | char(SEQ) | TYPE | DATA | CHECK |
+------+-----------+-----------+------+------------+-------+
where all fields consist of ASCII characters. The fields are:
MARK The synchronization character that marks the beginning of the packet.
This should normally be CTRL-A, but may be redefined.
LEN The number of ASCII characters within the packet that follow this
field, in other words the packet length minus two. Since this number
is transformed to a single character via the char() function, packet
character counts of 0 to 94 (decimal) are permitted, and 96 (decimal)
is the maximum total packet length. The length does not include end-
of-line or padding characters, which are outside the packet and are
strictly for the benefit of the operating system or communications
equipment, but it does include the block check characters.
SEQ The packet sequence number, modulo 64, ranging from 0 to 63. Sequence
numbers "wrap around" to 0 after each group of 64 packets.
TYPE The packet type, a single ASCII character. The following packet types
are required:
D Data packet
Y Acknowledge (ACK)
N Negative acknowledge (NAK)
S Send initiate (exchange parameters)
B Break transmission (EOT)
F File header
Z End of file (EOF)
E Error
T Reserved for internal use
The NAK packet is used only to indicate that the expected packet was
not received correctly, never to supply other kinds of information,
such as refusal to perform a requested service. The NAK packet always
has an empty data field. The T "packet" is used internally by many
KERMIT programs to indicate that a timeout occurred.
DATA The "contents" of the packet, if any contents are required in the given
type of packet, interpreted according to the packet type. Control
characters (bytes whose low order 7 bits are in the ASCII control range
0-31, or 127) are preceded by a special prefix character, normally "#",
and "uncontrollified" via ctl(). A prefixed sequence may not be broken
across packets. Logical records in printable files are delimited with
CRLFs, suitably prefixed (e.g. "#M#J"). Logical records need not cor-
respond to packets. Any prefix characters are included in the count.
Packet Format Page 21
Optional encoding for 8-bit data and repeated characters is described
later.
CHECK A block check on the characters in the packet between, but not includ-
ing, the mark and the block check itself. The check for each packet is
computed by both hosts, and must agree if a packet is to be accepted.
A single-character arithmetic checksum is the normal and required block
check. Only six bits of the arithmetic sum are included. In order
that all the bits of each data character contribute to this quantity,
bits 6 and 7 of the final value are added to the quantity formed by
bits 0-5. Thus if s is the arithmetic sum of the ASCII characters,
then
check = char((s + ((s AND 192)/64)) AND 63)
This is the default block check, and all Kermits must be capable of
performing it. Other optional block check types are described later.
The block check is based on the ASCII values of all the characters in
the packet, including control fields and prefix characters. Non-ASCII
systems must translate to ASCII before performing the block check cal-
culation.
6.2. Terminator
Any line terminator that is required by the system may be appended to the
packet; this is carriage return (ASCII 15) by default. Line terminators are
not considered part of the packet, and are included for in the count or check-
sum. Terminators are not necessary to the protocol, and are invisible to it,
as are any characters that may appear between packets. If a host cannot do
single character input from a TTY line, then a terminator will be required when
sending to that host. The terminator can be specified in the initial connec-
tion exchange.
Some KERMIT implementations also use the terminator for another reason
-- speed. Some systems are not fast enough to take in a packet and decode it
character by character at high baud rates; by blindly reading and storing all
characters between the MARK and the EOL, they are able to absorb the incoming
characters at full speed and then process them at their own rate.
6.3. Other Interpacket Data
The space between packets may be used for any desired purpose. Handshaking
characters may be necessary on certain connections, others may require screen
control or other sequences to keep the packets flowing.
Packet Format Page 22
6.4. Encoding, Prefixing, Block Check
MARK, LEN, SEQ, TYPE, and CHECK are control fields. Control fields are always
literal single-character fields, except that the CHECK field may be extended by
one or two additional check characters. Each control field is encoded by
char() or taken literally, but never prefixed. The control fields never con-
tain 8-bit data.
The DATA field contains a string of data characters in which any control
characters are encoded printably and preceded with the control prefix. The
decision to prefix a character in this way depends upon whether its low order 7
bits are in the ASCII control range, i.e. 0-31 or 127. Prefix characters that
appear in the data must themselves be prefixed by the control prefix, but un-
like control characters, these retain their literal value in the packet.
The treatment of the high order ("8th") bit of a data byte is as follows:
- If the communication channel allows 8 data bits per character, then
the original value of the 8th bit is retained in the prefixed charac-
ter. For instance, a data byte corresponding to a Control-A with the
8th bit set would be send as a control prefix, normally "#", without
the 8th bit set, followed by ctl(?A) with the 8th bit set. In binary
notation, this would be
00100011 10000001
In this case, the 8th bit is figured into all block check calcula-
tions.
- If the communication channel or one of the hosts required parity on
each character, and both sides were capable of 8th-bit prefixing,
then the 8th bit will be used for parity, and must not be included in
the block check. 8th bit prefixing is an option feature described in
greater detail in Section 8, below.
- If parity is being used but 8th-bit prefixing is not being done, then
the value of the 8th bit of each data byte will be lost and binary
files will not be transmitted correctly. Again, the 8th bit does not
figure into the block check.
The data fields of all packets are subject to prefix encoding, except S, I, and
A packets, and their ACKs (see below).
Initial Connection Page 23
7. Initial Connection
Initial connection occurs when the user has started up a Kermit program on both
ends of the physical connection. One Kermit has been directed (in one way or
another) to send a file, and the other to receive it.
The receiving Kermit waits for a "Send-Init" packet from the sending Kermit.
It doesn't matter whether the sending Kermit is started before or after the
receiving Kermit (if before, the Send-Init packet should be retransmitted
periodically until the receiving Kermit acknowledges it). The data field of
the Send-Init packet is optional; trailing fields can be omitted (or left
blank, i.e. contain a space) to accept or specify default values.
The Send-Init packet contains a string of configuration information in its data
field. The receiver sends an ACK for the Send-Init, whose data field contains
its own configuration parameters. The data field of the Send-Init and the ACK
to the Send-Init are literal, that is, there is no prefix encoding. This is
because the two parties will not know how to do prefix encoding until after the
configuration data is exchanged.
It is important to note that newly invented fields are added at the right, so
that old KERMIT programs that do not have code to handle the new fields will
act as if they were not there. For this reason, the default value for any
field, indicated by blank, should result in the behavior that occurred before
the new field was defined or added.
1 2 3 4 5 6 7 8 9 10...
+------+------+------+------+------+------+------+------+------+-------
| MAXL | TIME | NPAD | PADC | EOL | QCTL | QBIN | CHKT | REPT | CAPAS
+------+------+------+------+------+------+------+------+------+-------
The fields are as follows (the first and second person "I" and "you" are used
to distinguish the two sides). Fields are encoded printably using the char()
function unless indicated otherwise.
1. MAXL The maximum length packet I want to receive, a number up to 94
(decimal). You respond with the maximum you want me to send. This
allows systems to adjust to each other's buffer sizes, or to the con-
dition of the transmission medium.
2. TIME The number of seconds after which I want you to time me out while
waiting for a packet from me. You respond with the amount of time I
should wait for packets from you. This allows the two sides to ac-
commodate to different line speeds or other factors that could cause
timing problems. Only one side needs to time out. If both sides
time out, then the timeout intervals should not be close together.
3. NPAD The number of padding characters I want to precede each incoming
packet; you respond in kind. Padding may be necessary when sending
to a half duplex system that requires some time to change the direc-
tion of transmission, although in practice this situation is more
commonly handled by a "handshake" mechanism.
4. PADC The control character I need for padding, if any, transformed by
ctl() (not char()) to make it printable. You respond in kind. Nor-
mally NUL (ASCII 0), some systems use DEL (ASCII 127). This field is
Initial Connection Page 24
to be ignored if the value NPAD is zero.
5. EOL The character I need to terminate an incoming packet, if any. You
respond in kind. Most systems that require a line terminator for
terminal input accept carriage return for this purpose (note, because
there is no way to specify that no EOL should be sent, it would have
been better to use ctl() for this field rather than char(), but it's
too late now).
6. QCTL (verbatim) The printable ASCII character I will use to quote control
characters, normally and by default "#". You respond with the one
you will use.
The following fields relate to the use of OPTIONAL features of the KERMIT
protocol, described in section 8.
7. QBIN (verbatim) The printable ASCII character I want to use to quote
characters which have the 8th bit set, for transmitting binary files
when the parity bit cannot be used for data. Since this kind of
quoting increases both processor and transmission overhead, it is
normally to be avoided. If used, the quote character must be in the
range ASCII 33-62 ("!" through ">") or 96-126 ("`" through "~"), but
different from the control-quoting character. This field is inter-
preted as follows:
Y I agree to 8-bit quoting if you request it.
N I will not do 8-bit quoting.
& (or any other character in the range 33-62 or 96-126) I want to
do 8-bit quoting using this character (it will be done if the
other Kermit puts a Y in this field, or responds with the same
prefix character, such as &). The recommended 8th-bit quoting
prefix character is "&".
Anything Else : 8-bit quoting will not be done.
Note that this scheme allows either side to initiate the request, and
the order does not matter. For instance, a micro capable of 8-bit
communication will normally put a "Y" in this field whereas a
mainframe that uses parity will always put an "&". No matter who
sends first, this combination will result in election of 8th-bit
quoting.
8. CHKT Check Type, the method for detecting errors. "1" for single-charac-
ter checksum (the normal and required method), "2" for two-character
checksum (optional), "3" for three-character CRC-CCITT (optional).
If your response agrees, the designated method will be used; other-
wise the single-character checksum will be used.
9. REPT The prefix character I will use to indicate a repeated character.
This can be any printable character in the range ASCII 33-62 or
96-126, but different from the control and 8th-bit prefixes. SP (32)
denotes no repeat count processing is to be done. Tilde ("~") is the
recommended and normal repeat prefix. If you don't respond iden-
tically, repeat counts will not be done. Groups of at least 3 or 4
identical characters may be transmitted more efficiently using a
repeat count, though an individual implementation may wish to set a
different threshhold.
Initial Connection Page 25
10-?. CAPAS
A bit mask, in which each bit position corresponds to a capability of
KERMIT, and is set to 1 if that capability is present, or 0 if it is
not. Each character contains a 6-bit field (transformed by CHAR()),
whose low order bit is set to 1 if another capability byte follows,
and to 0 in the last capability byte. The capabilities defined so
far are:
#1 Reserved
#2 Reserved
#3 Ability to accept "A" packets (file attributes)
The capability byte as defined so far would then look like:
bit5 bit4 bit3 bit2 bit1 bit0
+----+----+----+----+----+----+
| #1 | #2 | #3 | -- | -- | 0 |
+----+----+----+----+----+----+
If all these capabilities were "on", the value of the byte would be
70 (octal). When capabilities 4, 5 and 6 are added, the capability
mask will look like this:
bit5 bit4 bit3 bit2 bit1 bit0 bit5 bit4 bit3 bit2 bit1 bit0
+----+----+----+----+----+----+ +----+----+----+----+----+----+
| #1 | #2 | #3 | #4 | #5 | 1 | | #6 | -- | -- | -- | -- | 0 |
+----+----+----+----+----+----+ +----+----+----+----+----+----+
Next 4: Reserved Fields
Sites that wish to add their own parameters to the initial connection
negotiation must start at the 5th field after the last capability
byte. Any intervening fields may be left blank (that is, they may
contain the space character). These fields are reserved for future
use by the standard KERMIT protocol.
The control, 8th-bit, and repeat prefixes must be distinct.
The receiving Kermit responds with an ACK ("Y") packet in the same format to
indicate its own preferences, options, and parameters. The ACK need not con-
tain the same number of fields as the the Send-Init. From that point, the two
KERMIT programs are "configured" to communicate with each other for the
remainder of the transaction. In the case of 8th-bit quoting, one side must
specify the character to be used, and the other must agree with a "Y" in the
same field, but the order in which this occurs does not matter. Similarly for
checksums -- if one side requests 2 character checksums and the other side
responds with a "1" or with nothing at all, then single-character checksums
will be done, since not all implementations can be expected to do 2-character
checksums or CRCs. And for repeat counts; if the repeat field of the send-init
and the ACK do not agree, repeat processing will not be done.
All Send-Init fields are optional. The data field may be left totally empty.
Similarly, intervening fields may be defaulted by setting them to blank. Ker-
mit implementations should know what to do in these cases, namely apply ap-
propriate defaults. The defaults should be:
MAXL: 80
Initial Connection Page 26
NPAD: 0, no padding
PADC: 0 (NUL)
EOL: CR (carriage return)
QCTL: the character "#"
QBIN: none, don't do 8-bit quoting
CHKT: "1", single-character checksum
REPT: No repeat count processing
MASK: All zeros (no special capabilities)
There are no prolonged negotiations in the initial connection sequence -- there
is one Send-Init and one ACK in reply. Everything must be settled in this ex-
change.
The very first Send-Init may not get through if the sending Kermit makes wrong
assumptions about the receiving host. For instance, the receiving host may re-
quire certain parity, some padding, handshaking, or a special end of line
character in order to read the Send-Init packet. For this reason, there should
be a way for the user the user to specify whatever may be necessary to get the
first packet through.
A parity field is not provided in the Send-Init packet because it could not be
of use. If the sender requires a certain kind of parity, it will also be send-
ing it. If the receiver does not know this in advance, i.e. before getting the
Send-Init, it will not be able to read the Send-Init packet.
Optional Features Page 27
8. Optional Features
The foregoing sections have discussed basic, required operations for any KERMIT
implementation. The following sections discuss optional and advanced features.
8.1. 8th-Bit and Repeat Count Prefixing
Prefix quoting of control characters is mandatory. In addition, prefixing may
also be used for 8-bit quantities or repeat counts, when both KERMIT programs
agree to do so. 8th-bit prefixing can allow 8-bit binary data pass through
7-bit physical links. Repeat count prefixing can improve the throughput of
certain kinds of files dramatically; binary files (particularly executable
programs) and structured text (highly indented or columnar text) tend to be the
major beneficiaries.
When more than one type of prefixing is in effect, a single data character can
be preceded by more than one prefix character. Repeat count processing can
only be requested by the sender, and will only be used by the sender if the
receiver agrees. 8th-bit prefixing is a special case because its use is nor-
mally not desirable, since it increases both processing and transmission over-
head. However, since it is the only straightforward mechanism for binary file
transfer available to those systems that usurp the parity bit, a receiver must
be able to request the sender to do 8th-bit quoting, since most senders will
not normally do it by default.
The repeat prefix is followed immediately by a single-character repeat count,
encoded printably via char(), followed by the character itself (perhaps
prefixed by control or 8th bit quotes, as explained below). The repeat count
may express values from 0 to 94. If a character appears more than 94 times in
a row, it must be "cut off" at 94, emitted with all appropriate prefixes, and
"restarted". The following table should clarify Kermit's quoting mechanism
(the final line shows how a sequence of 120 consecutive NULs would be encoded):
Quoted With
Character Representation Repeat Count for 6
A A ~(A ["(" is ASCII 40 - 32 = 6]
?A #A ~(#A
'A &A ~(&A
'?A &#A ~(&#A
# ## ~(##
'# &## ~(&##
& #& ~(#&
'& &#& ~(&#&
~ #~ ~(#~
'~ &#~ ~(&#~
NUL #@ ~~#@~:#@ [120 NULs]
A represents any printable character, ?A represents any control character, 'x
represents any character with the 8th bit set. The # character is used for
control-character quoting, and the & character for 8-bit quoting. The repeat
count must always precede any other prefix character. The repeat count is
taken literally (after transformation by unchar(); for instance "#" and "&" im-
mediately following a "~" denote repeat counts, not control characters or 8-bit
characters. The control quote character "#" is most closely bound to the data
character, then the 8-bit prefix, then the repeat count; in other words, the
Optional Features Page 28
order is: repeat prefix and count, 8-bit quote, control quote, and the data
character itself. To illustrate, note that &#A is not equivalent to #&A.
When the parity bit is available for data, then 8th-bit quoting should not be
done, and the 8th bit of the prefixed character will have the same value as the
8th bit of the original data byte. In that case, the table looks like this:
Quoted With
Character Representation Repeat Count for 6
'A 'A ~('A
'?A #'A ~(#'A
'# #'# ~(#'#
'& '& ~('&
'~ #'~ ~(#'~
Note that since 8th bit quoting is not being done, "&" is not being used as an
8th bit prefix character, so it does not need to be quoted with "#". Also,
note that the 8th bit is set on the final argument of the repeat sequence, no
matter how long, and not on any of the prefix characters.
Finally, remember the following rules:
- Prefixed sequences must not be broken across packets.
- Control, 8th-bit, and repeat count prefixes must be distinct.
- Data fields of all packets must pass through the prefix encoding
mechanism, except for S, I, and A packets, and ACKs to those packets.
In the first rule above, note that a prefixed sequence means a single character
and all its prefixes, like ~%&#X, not a sequence like #M#J, which is two
prefixed sequences.
8.2. Server Operation
A KERMIT server is a KERMIT program running remotely with no "user interface".
All commands to the server arrive in packets from the local KERMIT. SERVER
operation is much more convenient than basic operation, since the user need
never again interact directly with the remote KERMIT program after once start-
ing it up in server mode, and therefore need not issue complementary SEND and
RECEIVE commands on the two sides to get a file transfer started; rather, a
single command (such as SEND or GET) to the local KERMIT suffices. KERMIT ser-
vers can also provide services beyond file transfer.
Between transactions, a Kermit server waits for packets containing server com-
mands. The packet sequence number is always set back to 0 after a transaction.
A Kermit server in command wait should be looking for packet 0, and command
packets sent to servers should also be packet 0. Certain server commands will
result in the exchange of multiple packets. Those operations proceed exactly
like file transfer.
A KERMIT server program waiting for a command packet is said to be in "server
command wait". Once put into server command wait, the server should never
leave it until it gets a command packet telling it to do so. This means that
after any transaction is terminated, either normally or by any kind of error,
Optional Features Page 29
the server must go back into command wait. While in command wait, a server may
elect to send out periodic NAKs for packet 0, the expected command packet.
Since the user may be disconnected from the server for long periods of time
(hours), the interval between these NAKs should be significantly longer than
the normal timeout interval (say, 30-60 seconds, rather than 5-10). The peri-
odic NAKs are useful for breaking the deadlock that would occur if a local
program was unable to time out, and sent a command that was lost. On the other
hand, they can cause problems for local KERMIT programs that cannot clear their
input buffers, or for systems that do XON/XOFF blindly, causing the NAKs to
buffered in the server's host system output buffer, to be suddenly released en
masse when an XON appears. For this reason, servers should have an option to
set the command-wait wakeup interval, or to disable it altogher.
Server operation must be implemented in two places: in the server itself, and
in any KERMIT program that will be communicating with a server. The server
must have code to read the server commands from packets and respond to them.
The user KERMIT must have code to parse the user's server-related commands, to
form the server command packets, and to handle the responses to those server
commands.
8.2.1. Server Commands
Server commands are listed below. Not all of them have been implemented, and
some may never be, but their use should be reserved. Although server-mode
operation is optional, certain commands should be implemented in every server.
These include Send-Init (S), Receive-Init (R), and the Generic Logout (GL)
and/or Finish (GF) commands. If the server receives a command it does not un-
derstand, or cannot execute, it should respond with an Error (E) packet con-
taining a message like "Unimplemented Server Command" and both sides should set
the packet sequence number back to 0, and the server should remain in server
command wait. Only a GL or GF command should terminate server operation.
Server commands are as follows:
S Send Initiate (exchange parameters, server waits for a file).
R Receive Initiate (ask the server to send the specified files).
I Initialize (exchange parameters).
X Text header. Allows transfer of text to the user's screen in response to a
generic or host command. This works just like file transfer except that
the destination "device" is the screen rather than a file. Data field may
contain a filename, title, or other heading.
C Host Command. The data field contains a string to be executed as a command
by the host system command processor.
K KERMIT Command. The data field contains a string in the interactive com-
mand language of the KERMIT server (normally a SET command) to be executed
as if it were typed in at command level.
G Generic Kermit Command. Single character in data field (possibly followed
by operands, shown in {braces}, optional fields in [brackets]) specifies
the command:
I Login [{*user[*password[*account]]}]
C CWD, Change Working Directory [{*directory[*password]}]
L Logout, Bye
F Finish (Shut down the server, but don't logout).
D Directory [{*filespec}]
Optional Features Page 30
U Disk Usage Query [{*area}]
E Erase (delete) {*filespec}
T Type {*filespec}
R Rename {*oldname*newname}
K Copy {*source*destination}
W Who's logged in? (Finger) [{*user ID or network host[*options]}]
M Send a short Message {*destination*text}
H Help [{*topic}]
Q Server Status Query
P Program {*[program-filespec][*program-commands]}
J Journal {*command[*argument]}
V Variable {*command[*argument[*argument]]}
Note that field length encoding is used within the data field of all
Generic command packets, but not within the data fields of the other pack-
ets, such as S, I, R, X, K, and C.
Asterisk as used above ("*") represents a single-character length field, en-
coded using char(), for the operand that follows it; thus lengths from 0 to 94
may be specified. This allows multiple operands to be clearly delimited
regardless of their contents.
All server commands that send arguments in their data fields should pass
through the prefix encoding mechanism. Thus if a data character or length
field happens to correspond to an active prefix character, it must itself be
prefixed. The field length denotes the length of the field before prefix en-
coding and (hopefully) after prefix decoding. For example, to send a generic
command with two fields, "ABC" and "ZZZZZZZZ", first each field would be
prefixed by char() of its length, in this case char(3) and char(8), giving
"#ABC(ZZZZZZZZ". But "#" is the normal control prefix character so it must be
prefixed itself, and the eight Z's can be condensed to 3 characters using a
repeat prefix (if repeat counts are in effect), so the result after encoding
would be "##ABC(~(Z" (assuming the repeat prefix is tilde ("~"). The recipient
would decode this back into the original "#ABC(ZZZZZZZZ" before attempting to
extract the two fields.
Since a generic command must fit into a single packet, the program sending the
command should ensure that the command actually fits, and should not include
length fields that point beyond the end of the packet. Servers, however,
should be defensive and not attempt to process any characters beyond the end of
the data field, even if the argument length field would lead them to do so.
8.2.2. Timing
KERMIT does not provide a mechanism for suspending and continuing a trans-
action. This means that text sent to the user's screen should not be frozen
for long periods (i.e. not longer than the timeout period times the retry
threshold).
Between transactions, when the server has no tasks pending, it may send out
periodic NAKs (always with type 1 checksums) to prevent a deadlock in case a
command was sent to it but was lost. These NAKs can pile up in the local
"user" Kermit's input buffer (if it has one), so the user Kermit should be
prepared to clear its input buffer before sending a command to a server.
Meanwhile, servers should recognize that some systems provide no function to do
Optional Features Page 31
this (or even when they do, the process can be foiled by system flow control
firmware) and should therefore provide a way turn off or slow down the command-
wait NAKs.
8.2.3. The R Command
The R packet, generally sent by a local Kermit program whose user typed a GET
command, tells the server to send the files specified by the name in the data
field of the R packet. Since we can't assume that the two Kermits are running
on like systems, the local (user) Kermit must parse the file specification as a
character string and let the server to check it. If the server can open and
read the specified file, it sends a Send-Init (S) packet -- not an acknowledge-
ment! -- to the user, and then completes the file-sending transaction, as
described above.
If the server cannot send the file, it should respond with an error (E) packet
containing a reason, like "File not found" or "Read access required".
8.2.4. The K Command
The K packet can contain a character string which the server interprets as a
command in its own interactive command language. This facility is useful for
achieving the same effect as a direct command without having to shut down the
server, connect back to the remote system, continue it (or start a new one),
and issue the desired commands. The server responds with an ACK if the command
was executed successfully, or an error packet otherwise. The most likely use
for the K packet might be for transmitting SET commands, e.g. for switching be-
tween text and binary file modes.
8.2.5. Short and Long Replies
Any request made of a server may be answered in either of two ways, and any
User Kermit that makes such a request should be prepared for either kind of
reply:
- A short reply. This consists of a single ACK packet, which may con-
tain text in its data field. For instance, the user might send a
disk space query to the server, and the server might ACK the request
with a short character string in the data field, such as "12K bytes
free". The user KERMIT should display this text on the screen.
- A long reply. This proceeds exactly like a file transfer (and in
some cases it may be a file transfer). It begins with one of the
following:
* A File-Header (F) packet (optionally followed by one or more At-
tributes packets; these are discussed later);
* A Text-Header (X) packet.
* A Send-Init (S) Packet, followed by an X or F packet.
After the X or F packet comes an arbitrary number of Data (D) pack-
Optional Features Page 32
ets, then an End-Of-File (Z) packet, and finally a Break-Transmission
(B) packet, as for ordinary file transfer.
A long reply should begin with an S packet unless an I-packet exchange has al-
ready taken place, and the type 1 (single-character) block check is being used.
8.2.6. Additional Server Commands
The following server commands request the server to perform tasks other than
sending or receiving files. Almost any of these can have either short or long
replies. For instance, the Generic Erase (GE) command may elicit a simple ACK,
or a stream of packets containing the names of all the files it erased (or
didn't erase). These commands are now described in more detail; arguments are
as provided in commands typed to the user KERMIT (subject to prefix encoding);
no transformations to any kind of normal or canonic form are done -- filenames
and other operands are in the syntax of the server's host system.
I Login. For use when a KERMIT server is kept perpetually running on a dedi-
cated line. This lets a new user obtain an identity on the server's host
system. If the data field is empty, this removes the user's identity, so
that the next user does not get access to it.
L Logout, Bye. This shuts down the server entirely, causing the server it-
self to log out its own job. This is for use when the server has been
started up manually by the user, who then wishes to shut it down remotely.
For a perpetual, dedicated server, this command simply removes the server's
access rights to the current user's files, and leaves the server waiting
for a new login command.
F Finish. This is to allow the user to shut down the server, putting its
terminal back into normal (as opposed to binary or raw) mode, and putting
the server's job back at system command level, still logged in, so that the
user can connect back to the job. For a perpetual, dedicated server, this
command behaves as the L (BYE) command.
C CWD. Change Working Directory. This sets the default directory or area
for file transfer on the server's host. With no operands, this command
sets the default area to be the user's own default area.
D Directory. Send a directory listing to the user. The user program can
display it on the terminal or store it in a file, as it chooses. The
directory listing should contain file sizes and creation dates as well as
file names, if possible. A wildcard or other file-group designator may be
specified to ask the server list only those files that match. If no
operand is given, all files in the current area should be shown.
U Disk Usage Query. The server responds with the amount of space used and
the amount left free to use, in K bytes (or other units, which should be
specified).
E Erase (delete). Delete the specified file or file group.
T Type. Send the specified file or file group, indicating (by starting with
an X packet rather than an F packet, or else by using the Type attribute)
that the file is to be displayed on the screen, rather than stored.
Optional Features Page 33
R Rename. Change the name of the file or files as indicated. The string in-
dicating the new name may contain other attributes, such as protection
code, permitted in file specifications by the host.
K Copy. Produce a new copy of the file or file group, as indicated, leaving
the source file(s) unmodified.
W Who's logged in? (Finger). With no arguments, list all the users who are
logged in on the server's host system. If an argument is specified,
provide more detailed information on the specified user or network host.
M Short Message. Send the given short (single-packet) message to the in-
dicated user's screen.
P Program. This command has two arguments, program name (filespec), and
command(s) for the program. The first field is required, but may be left
null (i.e. zero length). If it is null, the currently loaded program is
"fed" the specified command. If not null, the specified program is loaded
and started; if a program command is given it is fed to the program as an
initial command (for instance, as a command line argument on systems that
support that concept). In any case, the output of the program is sent back
in packets as either a long or short reply, as described above.
J Journal. This command controls server transaction logging. The data field
contains one of the following:
+ Begin/resume logging transactions. If a filename is given, close any
currently open transaction and then open the specified file as the new
transaction log. If no name given, but a log file was already open,
resume logging to that file. If no filename was given and no log was
open, the server should open a log with a default name, like
TRANSACTION.LOG.
- Stop logging transactions, but don't close the current transaction log
file.
C Stop logging and close the current log.
S Send the transaction log as a file. If it was open, close it first.
Transaction logging is the recording of the progress of file transfers. It
should contain entries showing the name of each file transferred, when the
transfer began and ended, whether it completed successfully, and if not,
why.
V Set or Query a variable. The command can be S or Q. The first argument is
the variable name. The second argument, if any, is the value.
S Set the specified variable to the specified value. If the value is
null, then undefine the variable. If the variable is null then do
nothing. If the variable did not exist before, create it. The server
should respond with an ACK if successful, and Error packet otherwise.
Q Query the value of the named variable. If no variable is supplied,
display the value of all active variables. The server responds with
either a short or long reply, as described above. If a queried vari-
Optional Features Page 34
able does not exist, a null value is returned.
Variables are named by character strings, and have character string values,
which may be static or dynamic. For instance, a server might have built-in
variables like "system name" which never changes, or others like "mail
status" which, when queried, cause the server to check to see if the user
has any new mail.
8.2.7. Host Commands
Host commands are conceptually simple, but may be hard to implement on some
systems. The C packet contains a text string in its data field which is simply
fed to the server's host system command processor; any output from the proces-
sor is sent back to the user in KERMIT packets, as either a short or long
reply.
Implementation of this facility under UNIX, with its forking process structure
and i/o redirection via pipes, is quite natural. On other systems, it could be
virtually impossible.
8.2.8. Exchanging Parameters Before Server Commands
In basic KERMIT, the Send-Init exchange is always sufficient to configure the
two sides to each other. During server operation, on the other hand, some
transactions may not begin with a Send-Init packet. For instance, when the
user sends an R packet to ask the server to send a file, the server chooses
what block check option to use. Or if the user requests a directory listing,
the server does not know what packet length to use.
The solution to this problem is the "I" (Init-Info) packet. It is exactly like
a Send-Init packet, and the ACK works the same way too. However, receipt of an
I packet does not cause transition to file-send state. The I-packet exchange
simply allows the two sides to set their parameters, in preparation for the
next transaction.
Servers should be able to receive and ACK "I" packets when in server command
wait. User KERMITs need not send "I" packets, however; in that case, the serv-
er will assume all the defaults for the user listed on page 25, or whatever
parameters have been set by other means (e.g. SET commands typed to the server
before it was put in server mode).
User Kermits which send I packets should be prepared to receive and ignore an
Error packet in response. This could happen if the server has not implemented
I packets.
8.3. Alternate Block Check Types
There are two optional kinds of block checks:
Type 2
A two-character checksum based on the low order 12 bits of the arithmetic
sum of the characters in the packet (from the LEN field through the last
data character, inclusive) as follows:
Optional Features Page 35
1 2
--------+--------------+-------------+
...data | char(b6-b11) | char(b0-b5) |
--------+--------------+-------------+
For instance, if the 16-bit result is 154321 (octal), then the 2 character
block check would be "C1".
Type 3
Three-character 16-bit CRC-CCITT. The CRC calculation treats the data it
operates upon as a string of bits with the low order bit of the first
character first and the high order bit of the last character last. The in-
itial value of the CRC is taken as 0; the 16-bit CRC is the remainder after
16 12 5
dividing the data bit string by the polynomial X +X +X +1 (this calcula-
tion can actually be done a character at a time, using a simple table
lookup algorithm). The result is represented as three printable characters
at the end of the packet, as follows:
1 2 3
--------+---------------+--------------+-------------+
...data | char(b12-b15) | char(b6-b11) | char(b0-b5) |
--------+---------------+--------------+-------------+
For instance, if the 16-bit result is 154321 (octal), then the 3 character
block check would be "-C1". The CRC technique chosen here agrees with many
hardware implementations (e.g. the VAX CRC instruction). A useful refer-
ence on table-driven CRC calculations can be found in "Byte-wise CRC
Calculations" by Aram Perez in IEEE MICRO, June 1983, p.40.
The single-character checksum has proven quite adequate in practice. The other
options can be used only if both sides agree to do so via Init packet (S or I)
exchange. The 2 and 3 character block checks should only be used under con-
ditions of severe line noise and packet corruption.
Since type 2 and 3 block checks are optional, not all KERMITs can be expected
to understand them. Therefore, during initial connection, communication must
begin using the type 1 block check. If type 2 or 3 block checks are agreed to
during the "I" or "S" packet exchange, the switch will occur only after the
Send-Init has been sent and ACK'd with a type 1 block check. This means that
the first packet with a type 2 or 3 block check must always be an "F" or "X"
packet. Upon completion of a transaction, both sides must switch back to type
1 (to allow for the fact that neither side has any way of knowing when the
other side has been stopped and restarted). The transaction is over after a
"B" or "E" packet has been sent and ACK'd, or after any error that terminates
the transaction prematurely or abnormally.
A consequence of the foregoing rule is that if a type 2 or 3 block check is to
be used, a long reply sent by the server must begin with a Send-Init (S)
packet, even if an I packet exchange had already occurred. If type 1 block
checks are being used, the S packet can be skipped and the transfer can start
with an X or F packet.
A server that has completed a transaction and is awaiting a new command may
send out periodic NAKs for that command (packet 0). Those NAKs must have type
1 block checks.
Optional Features Page 36
The use of alternate block check types can cause certain complications. For
instance, if the server gets a horrible error (so bad that it doesn't even send
an error packet) and reverts to command wait, sending NAKs for packet 0 using a
type 1 block check, while a transfer using type 2 or 3 block checks was in
progress, neither side will be able to read the other's packets. Communication
can also grind to a halt if A sends a Send-Init requesting, say, type 3 block
checks, B ACKs the request, switches to type 3 and waits for the X or F packet
with a type 3 block check, but the ACK was lost, so A resends the S packet with
a type 1 block check. Situations like this will ultimately resolve themselves
after the two sides retransmit up to their retry threshhold, but can be rec-
tified earlier by the use of two heuristics:
- The packet reader can assume that if the packet type is "S", the
block check type is 1.
- A NAK packet never has anything in its data field. Therefore, the
block check type can always be deduced by the packet reader from the
length field of a NAK. In fact, it is the value of the length field
minus 2. A NAK can therefore be thought of as a kind of "universal
synchronizer".
These heuristics tend violate the layered nature of the protocol, since the
packet reader should normally be totally unconcerned with the packet type
(which is of interest to the application level which invokes the packet
reader). A better design would have had each packet include an indicator of
the type of its own block check; this would have allowed the block check type
to be changed dynamically during a transaction to adapt to changing conditions.
But it's too late for that now...
8.4. Interrupting a File Transfer
This section describes an optional feature of the KERMIT protocol to allow
graceful interruption of file transfer. This feature is unrelated to server
operation.
To interrupt sending a file, send an EOF ("Z") packet in place of the next data
packet, including a "D" (for Discard) in the data field. The recipient ACKs
the Z packet normally, but does not retain the file. This does not interfere
with older Kermits on the receiving end; they will not inspect the data field
and will close the file normally. The mechanism can be triggered by typing an
interrupt character at the console of the sending KERMIT program. If a
(wildcard) file group is being sent, it is possible to skip to the next file or
to terminate the entire batch; the protocol is the same in either case, but the
desired action could be selected by different interrupt characters, e.g. CTRL-X
to skip the current file, CTRL-Z to skip the rest of the batch.
To interrupt receiving a file, put an "X" in the data field of an ACK for a
data packet. To interrupt receiving an entire file group, use a "Z". The user
could trigger this mechanism by typing an interrupt character by typing, say,
CTRL-X and CTRL-Z, respectively, at the receiving KERMIT's console. A sender
that was aware of the new feature, upon finding one of these codes, would act
as described above, i.e. send a "Z" packet with a "D" code; a sender that did
not implement this feature would simply ignore the codes and continue sending.
In this case, and if the user wanted the whole batch to be cancelled (or only
one file was being sent), the receiving KERMIT program, after determining that
Optional Features Page 37
the sender had ignored the "X" or "Z" code, could send an Error (E) packet to
stop the transfer.
The sender may also choose to send a Z packet containing the D code when it
detects that the file it is sending cannot be sent correctly and completely
-- for instance, after sending some packets correctly, it gets an i/o error
reading the file. Or, it notices that the "8th bit" of a file byte is set when
the file is being sent as a text file and no provision has been made for trans-
mitting the 8th bit.
8.5. Transmitting File Attributes
The optional Attributes (A) packet provides a mechanism for the sender of a
file to provide additional information about it. This packet can be sent if
the receiver has indicated its ability to process it by setting the Attributes
bit in the capability mask. If both sides set this bit in the Kermit
capability mask, then the sender, after sending the filename in the "F" packet
and receiving an acknowledgement, may (but does not have to) send an "A" packet
to provide file attribute information.
Setting the Attributes bit in the capability mask does not indicate support for
any particular attributes, only that the receiver is prepared to accept the "A"
packet.
The attributes are given in the data field of the "A" packet. The data field
consists of 0 or more subfields, which may occur in any order. Each subfield
is of the following form:
+-----------+--------------+------+
| ATTRIBUTE | char(LENGTH) | DATA |
+-----------+--------------+------+
where
ATTRIBUTE is a single printable character other than space,
LENGTH is the length of the data characters (0 to 94), with 32 added to
produce a single printable character, and
DATA is length characters worth of data, all printable characters.
No quoting or prefixing is done on any of this data.
More than one attribute packet may be sent. The only requirement is that all
the A packets for a file must immediately follow its File header (or X) packet,
and precede the first Data packet.
There may be 93 different attributes, one for each of the 93 printable ASCII
characters other than space. These are assigned in ASCII order.
! (ASCII 33)
Length. The data field gives the length in K (1024) bytes, as a
printable decimal number, e.g. "!#109". This will allow the receiver
to determine in advance whether there is sufficient room for the
file, and/or how long the transfer will take.
Optional Features Page 38
" (ASCII 34)
Type. The data field can contain some indicator of the nature of the
file. Operands are enclosed in {braces}, optional items in
[brackets].
A[{xx}] ASCII text, containing no 8-bit quantities, logical records
(lines) delimited by the (quoted) control character sequence
{xx}, represented here by its printable counterpart (MJ =
CRLF, J = LF, etc). For instance AMJ means that the ap-
pearance of #M#J (the normal prefixed CRLF sequence) in a
file data packet indicates the end of a record, assuming the
current control prefix is "#". If {xx} is omitted, MJ will
be assumed.
B[{xx}] Binary. {xx} indicates in what manner the file is binary:
8 (default) The file is a sequence of 8-bit bytes, which
must be saved as is. The 8th bit may be sent "bare", or
prefixed according to the Send-Init negotiation about
8th-bit prefixing.
36 The file is a PDP-10 format binary file, in which five
7-bit bytes are fit into one 36-bit word, with the final
bit of each word being represented as the "parity bit" of
every 5th character (perhaps prefixed).
D{x} Moved from here to FORMAT attribute
F{x} Moved from here to FORMAT attribute
I[{x}] Image. The file is being sent exactly as it is represented
on the system of origin. For use between like systems.
There are {x} usable bits per character, before prefixing.
For instance, to send binary data from a system with 9-bit
bytes, it might be convenient to send three 6-bit characters
for every two 9-bit bytes. Default {x} is 8.
# (ASCII 35)
Creation Date, expressed as "[yy]yymmdd[ hh:mm[:ss]]" (ISO standard
julian format), e.g. 831009 23:59. The time is optional; if given,
it should be in 24-hour format, and the seconds may be omitted, and a
single space should separate the time from the date.
$ (ASCII 36)
Creator's ID, expressed as a character string of the given length.
% (ASCII 37)
Account to charge the file to, character string.
& (ASCII 38)
Area in which to store the file, character string.
' (ASCII 39)
Password for above, character string.
( (ASCII 40)
Optional Features Page 39
Block Size. The file has, or is to be stored with, the given block
size.
) (ASCII 41)
Access:
N New, the normal case -- create a new file of the given name.
S Supersede (overwrite) any file of the same name.
A Append to file of the given name.