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           ___           _       ___
 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.



 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

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

                          /                    /
                          /  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

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

 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.




    Specifies a physical device.

    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:


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.

     /qualifier[...] indevice[,...][filespec[,...]] outdevice[,...]


     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.
     qualifiers are unique to three characters.

     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

     Devices are specified in the following form:


     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:


     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

 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
 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

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.


     [outfile[/switch[...]]=] infile1,infile2


     Specifies the file specification for the output file.  The format for
     entering file specifications is as follows:


     Specifies switches that you apply to the output file specification.
     Some of the switches can be negated and some are mutually exclusive.

     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.

     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

 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

 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
        SET             SWITCH            UNLINK

 To display information about a command, type HELP CONFIGURE commandname.

help 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.


 /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
 SET /COLOG/LOGFILE                     Opens a new version of the file
 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.

   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.




    Specifies the physical volume or volumes to which data is copied. The
    format for outdev is as follows:


    Identifies the output disk's Volume ID, the tape file, or the tape set
    that DSC creates in a data transfer.

    Specifies one or more of the optional DSC switches.

    Specifies the physical volume or volumes, in the same format as outdev,
    from which data is copied.

    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

 The command line for DMP is shown next.



     Specifies the output file. The format for entering file specifications is
     as follows:


     Specifies any of the DMP switches.

     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.




     Specifies a file specification in the following format.


 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:


 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

 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

 The general format for entering FLX command lines is shown next.




     Specifies the device for the FLX output.

     Specifies the directory on the output device.

     Do not specify a directory if the output device is in RT-11 format.

     Specifies one of the FLX switches.

     Specifies the input file specification.

     The format for entering file specifications is as follows:


     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.




     Specifies the volume you are formatting.

     Specifies an FMT switch.  Not all switches can be used with all device

 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:


 Regardless of the name under which the PDP-11 FORTRAN-77
 compiler is installed, the compiler displays the following prompt:


 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:


 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


 Individual command descriptions can be obtained by typing

        HELP INDIRECT commandname

 Operators (relational and arithmetic) are described at


 Special symbol descriptions can be obtained by typing

        HELP INDIRECT symbolname
 NOTE: symbolname does not include the  angle brackets.

 A list of Indirect error messages, including their severity class numbers,
 can be obtained by typing


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
 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


 Individual command descriptions can be obtained by typing

        HELP INDIRECT commandname

 Operators (relational and arithmetic) are described at


 Special symbol descriptions can be obtained by typing

        HELP INDIRECT symbolname

 NOTE: symbolname does not include the  angle brackets.

 A list of Indirect error messages, including their severity class numbers,
 can be obtained by typing


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.



     The format for entering file specifications is as follows:


 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]. . .
 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  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:

     DISPLAY            INTERRUPT           RETURN

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

 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

 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

 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.


        >SHA command parameterlist


   ABORT ddnn:              Stops shadow recording of a shadowed pair wh
                            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.


       ddnn:   Specifies the primary volume
       ddxx:   Specifies the secondary volume (which must be mounted as

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
than the default BATCH. The optional jobname switch allows you to give y
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

 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

 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

 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

 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.




        Specifies the output file specification as follows:


        Specifies the device on which the scratch file produced by VFY i
s to
        be written. This parameter is in the following format:


        Specifies the volume to be verified in the same format as scratchdev.
        If you do not specify the volume, the default is SY0.

        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

 The ZAP command line format is shown next.



 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                 /
              /                                                  /


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

:  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.


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.


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"


      /                                                                 /
      /                         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


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.


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

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:

        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      "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

   - All  printable  ASCII  characters are acceptable as input to the host
     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


   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
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-

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


   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
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.


   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

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

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-

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

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


  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-

  | 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

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,

          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-

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-

   - 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...

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

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-

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

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

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

   - 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

        * 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

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

    -   Stop  logging transactions, but don't close the current transaction log
    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,

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

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
      --------+--------------+-------------+ | 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
      --------+---------------+--------------+-------------+ | 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

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

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"

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 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

          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

) (ASCII 41)

          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.

* (ASCII 42)

          A   ASCII, normal ASCII encoding with any necessary prefixing, etc.
          H   Hexidecimal "nibble" encoding.
          E   EBCDIC (sent as if it were a binary file).
          X   Encrypted.
              Huffman Encoded for compression.  First x bytes of the  file  are
              the key.

# (ASCII 43)
          Disposition  (operands  are specified in the syntax of the receiver's
          host system):

          M{user(s)}      Send the file as Mail to the specified user(s).

          O{destination}  Send the file as  a  lOng  terminal  message  to  the
                          specified destination (terminal, job, or user).

          S[{options}]    Submit  the  file  as a batch job, with any specified

          P[{options}]    Print  the  file  on  a  system  printer,  with   any
                          specified  options,  which  may  specify a particular
                          printer, forms, etc.

          T               Type the file on the screen.

          L[{aaa}]        Load the file into memory at the  given  address,  if

          X[{aaa}]        Load  the  file  into memory at the given address and
                          eXecute it.

          A               Archive the file; save the file together with the at-
                          tribute packets that preceded it, so that it  can  be
                          sent  back  to  the system of origin with all its at-
                          tributes intact.  A file stored in this way should be
                          specially marked so that the  KERMIT  that  sends  it
                          back will recognize the attribute information as dis-
                          tinct from the file data.

, (ASCII 44)
          Protection.    Protection  code  for  the  file, in the syntax of the
          receiver's host file system.  With no operand, store according to the

Optional Features                                                       Page 40

          system's default protection for the destination area.

- (ASCII 45)
          Protection.    Protection  code  for  the  file  with  respect to the
          "public" or "world", expressed generically in a 6-bit quantity  (made
          printable by char()), in which the bits have the following meaning:

          b0: Read Access
          b1: Write Access
          b2: Execute Access
          b3: Append Access
          b4: Delete Access
          b5: Directory Listing

          A  one  in the bit position means allow the corresponding type of ac-
          cess, a zero means prohibit it.  For example, the letter "E" in  this
          field  would  allow  read,  execute,  and  directory  listing  access
          (unchar("E") = 69-32 = 37 = 100101 binary).

. (ASCII 46)
          Machine and operating system of origin.  This is useful  in  conjunc-
          tion  with the archive disposition attribute.  It allows a file, once
          archived, to be transferred among different types of systems, retain-
          ing its archive status, until it finds its way to a machine with  the
          right  characteristics  to de-archive it.  The systems are denoted by
          codes; the first character is the major system designator, the second
          designates the specific model or operating system.  A third character
          may be added to make further  distinctions,  for  instance  operating
          system version.  The systems below do not form a complete collection;
          many more can and probably will be added.

          A   Apple microcomputers

              1   Apple II, DOS
              2   Apple III
              3   Macintosh
              4   Lisa

          B   Sperry (Univac) mainframes

              1   1100 series, EXEC

          C   CDC mainframes

              1   Cyber series, NOS

          D   DEC Systems

              1   DECsystem-10/20, TOPS-10
              2   DECsystem-10/20, TOPS-20
              3   DECsystem-10/20, TENEX
              4   DECsystem-10/20, ITS
              5   DECsystem-10/20, WAITS
              6   DECsystem-10/20, MAXC
              7   VAX-11, VMS
              8   PDP-11, RSX-11
Optional Features                                                       Page 41

              9   PDP-11, IAS
              A   PDP-11, RSTS/E
              B   PDP-11, RT-11
              C   Professional-300, P/OS
              D   Word Processor (WPS or DECmate), WPS

          D   Honeywell mainframes

              1   MULTICS systems
              2   DPS series, running CP-6

          F   Data General machines

              1   RDOS
              2   AOS

          G   PR1ME machines, PRIMOS

          H   Hewlett-Packard machines

              1   HP-1000, RTE
              2   HP-3000, MPE

          I   IBM 370-series and compatible mainframes

              1   VM/CMS
              2   MVS/TSO
              3   DOS
              4   MUSIC
              5   GUTS
              6   MTS

          J   Tandy microcomputers, TRSDOS

          K   Atari micros, DOS

          L-T Reserved

          U   Portable Operating or File Systems

              1   UNIX
              2   Software Tools
              3   CP/M-80
              4   CP/M-86
              5   CP/M-68K
              6   MP/M
              7   Concurrent CP/M
              8   MS-DOS
              9   UCSD p-System
              A   MUMPS

/ (ASCII 47)
          Format of the data within the packets.

          A{xx}           Variable  length delimited records, terminated by the
                          character sequence {xx}, where xx is a string of  one

Optional Features                                                       Page 42

                          or more control characters, represented here by their
                          unprefixed  printable  equivalents,  e.g. MJ for ?M?J

          D{x}            Variable length undelimited records.    Each  logical
                          record  begins  with  an  {x}-character ASCII decimal
                          length field (similar to ANSI tape format "D").   For
                          example,  "D$"  would indicate 4-digit length fields,
                          like "0132".

          F{xxxx}         Fixed-length  undelimited  records.    Each   logical
                          record is {xxxx} bytes long.

          R{x}            For record-oriented transfers, to be used in combina-
                          tion  with  one  of  the  formats  given above.  Each
                          record begins (in the case of  D  format,  after  the
                          length field) with an x-character long position field
                          indicating the byte position within the file at which
                          this record is to be stored.

          M{x}            For record-oriented transfers, to be used in combina-
                          tion  with  one  of the formats given above.  Maximum
                          record length for a variable-length record.

0 (ASCII 48)
          Special system-dependent parameters for storing the file on the  sys-
          tem of origin, for specification of exotic attributes not covered ex-
          plicitly by any of the KERMIT attribute descriptors.  These are given
          as  a  character  string  in the system's own language, for example a
          list of DCB parameters in IBM Job Control Language.

1-@ (ASCII 49-64)

Other attributes can be imagined, and can be added later if needed.    However,
two important points should be noted:

   - The  receiver may have absolutely no way of honoring, or even record-
     ing, a given attribute.  For instance, CP/M-80 has no slot for  crea-
     tion  date  or  creator's ID in its FCB; the DEC-20 has no concept of
     block size, etc.

   - The sender may have no way of determining the correct values  of  any
     of  the  attributes.  This is particularly true when sending files of
     foreign origin.

The "A" packet mechanism only provides a way to send certain information  about
a  file to the receiver, with no provision or guarantee about what the receiver
may do with it.  That information may be  obtained  directly  from  the  file's
directory entry (FCB, FDB, ...), or specified via user command.

The  ACK  to  the  "A"  packet  may in turn have information in its data field.
However, no complicated negotiations about file attributes may take  place,  so
the  net  result  is that the receiver may either refuse the file or accept it.
The receiver may reply to the "A" packet with any of the following codes in the
data field of the ACK packet:

Optional Features                                                       Page 43

  (empty data field) I accept the file, go ahead and send it.

        I  refuse  the  file  as specified, don't send it; {xxx} is a string of
        zero or more of the attribute characters listed above, to specify  what
        attributes I object to (e.g. "!" means it's too long, "&" means I don't
        have write access to the specified area, etc).

        I  agree to receive the file, but I cannot honor attributes {xxx}, so I
        will store the file according to my own defaults.

Y       (degenerate case of Y{xxx}, equivalent to , above)

How the receiver actually replies is an implementation  decision.    A  NAK  in
response  to the "A" packet means, of course, that the receiver did not receive
the "A" correctly, not that it refuses to receive the file.

8.6. Advanced KERMIT Protocol State Table

The simple table presented previously is sufficient  for  a  basic  KERMIT  im-
plementation.  The following is a state table for the full Kermit protocol, in-
cluding  both server mode and sending commands to a server Kermit.  It does not
include handling of the file attributes packet (A).   Note  that  states  whose
names  start  with "Send" always send a packet each time they are entered (even
when the previous state was the same).  States whose name  starts  with  "Rec",
always  wait for a packet to be received (up to the timeout value), and process
the received packet.  States whose names do not include either send or  receive
do  not  process  packets  directly.  These are states which perform some local
operation and then change to another state.

The initial state is determined by the user's  command.    A  "server"  command
enters  at Rec_Server_Idle.  A "send" command enters at Send_Init.  A "receive"
command (the old non-server version, not a "get" command) enters  at  Rec_Init.
Any  generic command, the "get" command, and the "host" command enter at either
Send_Server_Init or Send_Gen_Cmd, depending upon the expected response.

Under "Rec'd Msg", the packet type of the incoming message is  shown,  followed
by the packet number in parentheses; (n) means the current packet number, (n-1)
and  (n+1)  mean  the  previous  and next packet numbers (modulo 64), (0) means
packet number zero. Following the packet number may be slash and a letter,  in-
dicating  some special signal in the data field.  For instance Z(n)/D indicates
a Z (EOF) packet, sequence number n, with a "D" in the data field.

Under "Action", "r+" means that the retry count  is  incremented  and  compared
with  a  threshhold; if the threshhold is exceeded, an Error packet is sent and
the state changes to "Abort".  "n+" means that  the  packet  number  is  incre-
mented, modulo 64, and the retry count, r, is set back to zero.

Optional Features                                                       Page 44

State   Rec'd Msg       Action                  Next state

Rec_Server_Idle -- Server idle, waiting for a message

    Set n and r to 0

        I(0)            Send ACK                Rec_Server_Idle
        S(0)            Process params,
                         ACK with params, n+    Rec_File
        R(0)            Save file name          Send_Init

        K, C or G(0)    Short reply:
                         ACK(0)/reply           Rec_Server_Idle
                        Long reply:
                         init needed            Send_Init
                         init not needed, n+    Open_File

        Timeout         Send NAK(0)             Rec_Server_Idle
        Other           Error                   Rec_Server_Idle

Rec_Init -- Entry point for non-server RECEIVE command

    Set n and r to 0

        S(0)            Process params, send
                         ACK with params, n+    Rec_File
        Timeout         Send NAK(0), r+         Rec_Init
        Other           NAK                     Abort

Rec_File -- Look for a file header or EOT message

        F(n)            Open file, ACK, n+      Rec_Data
        X(n)            Prepare to type on
                         screen, ACK, n+        Rec_Data
        B(n)            ACK                     Complete
        S(n-1)          ACK with params, r+     Rec_File
        Z(n-1)          ACK, r+                 Rec_File
        Timeout         NAK, r+                 Rec_File
        Other           NAK                     Abort

Rec_Data -- Receive data up to end of file

        D(n)            Store data, ACK, n+;
                         If interruption wanted
                         include X or Z in ACK  Rec_Data
        D(n-1)          Send ACK, r+            Rec-Data
        Z(n)            Close file, ACK, n+     Rec_File
        Z(n)/D          Discard file, ACK, n+   Rec_File
        F(n-1)          Send ACK, r+            Rec_Data
        X(n-1)          Send ACK, r+            Rec_Data
        Timeout         Send NAK, r+            Rec_Data
        Other           Send E                  Abort

Optional Features                                                       Page 45

Send_Init -- Also entry for SEND command

    Set n and r to 0, send S(0) with parameters

        Y(0)            Process params, n+      Open_File
        N, Timeout      r+                      Send_Init
        Other           r+                      Send_Init

Open_File -- Open file or set up text to send


Send_File -- Send file or text header

    Send F or X(n)

        Y(n), N(n+1)    Get first buffer of     Send_Data or Send_Eof if
                         data, n+                empty file or text
        N, Timeout      r+                      Send_File
        Other                                   Abort

Send_Data -- Send contents of file or textual information

    Send D(n) with current buffer

        Y(n), N(n+1)    n+, Get next buffer     Send_Data or Send_Eof if
                                                 at end of file or text
        Y(n)/X or Z     n+                      Send_Eof
        N, Timeout      r+                      Send_Data
        Other                                   Abort

Send_Eof -- Send end of file indicator

    Send Z(n); if interrupting send Z(n)/D

        Y(n), N(n+1)    Open next file, n+      Send_File if more, or
                                                Send_Break if no more
                                                 or if interrupt "Z".
        N, Timeout      r+                      Send_Eof
        Other                                   Abort

Send_Break -- End of Transaction

    Send B(n)

        Y(n), N(0)                              Complete
        N(n), Timeout                           Send_Break
        Other                                   Abort

Optional Features                                                       Page 46

Send_Server_Init - Entry for Server commands which expect large response.

    Send I(0) with parameters

        Y(0)            Process params          Send_Gen_Cmd
        N, Timeout      r+                      Send_Server_Init
        E               Use default params      Send_Gen_Cmd
        Other                                   Abort

Send_Gen_Cmd - Entry for Server commands which expect short response (ACK)

    Send G, R or C(0)

        S(0)            Process params,
                         ACK with params, n+    Rec_File
        X(1)            Setup to type on
                         terminal, n+           Rec_Data
        Y(0)            Type data on TTY        Complete
        N, Timeout      r+                      Send_Gen_Cmd
        Other                                   Abort

Complete -- Successful Completion of Transaction

        Set n and r to 0;
        If server, reset params, enter Rec_Server_Idle
        otherwise exit

Abort -- Premature Termination of Transaction

    Reset any open file, set n and r to 0

        If server, reset params, enter Rec_Server_Idle
        otherwise exit

Exit, Logout states
        Exit or Logout

Note that the generic commands determine the next state as follows:

   1. If  the  command  is  not supported, an error packet is sent and the
      next state is "Abort".

   2. If the command generates a response which can be fit into  the  data
      portion  of  an  ACK,  an  ACK  is  sent  with  the  text (quoted as
      necessary) in the data portion.

   3. If the command generates a large response or must send a file, noth-
      ing is sent from the Rec_Server_Idle state, and the  next  state  is
      either  Send_Init  (if either no I message was received or if alter-

Optional Features                                                       Page 47

      nate  block  check types are to be used), or Open_File (if an I mes-
      sage was received and the single character  block  check  is  to  be

   4. If  the  command  is  Logout,  an  ACK  is sent and the new state is

   5. If the command is Exit, an ACK is sent and the new state is Exit.

KERMIT Commands                                                         Page 48

9. KERMIT Commands

The  following  list  of KERMIT commands and terms is suggested.  It is not in-
tended to recommend a particular style of command parsing, only  to  promote  a
consistent vocabulary, both in documentation and in choosing the names for com-

9.1. Basic Commands

SEND    This verb tells a Kermit program to send one or more files from its own
        file structure.

RECEIVE This  verb  should tell a Kermit program to expect one or more files to

GET     This verb should tell a user Kermit to send one or more  files.    Some
        Kermit  implementations  have separate RECEIVE and GET commands; others
        use RECEIVE for both purposes, which creates confusion.

Since it can be useful, even necessary, to specify different names  for  source
and destination files, these commands should take operands as follows (optional
operands in [brackets]):

SEND local-source-filespec [remote-destination-filespec]
        If  the destination file specification is included, this will go in the
        file header packet, instead of the file's local name.

RECEIVE [local-destination-filespec]
        If the destination filespec is given, the incoming file will be  stored
        under that name, rather than the one in the file header pakcet.

GET remote-source-filespec [local-destination-filespec]
        If  the destination filespec is given, the incoming file will be stored
        under that name, rather than the one in the file header packet.

If a file group is being sent or received, alternate names should not be used.

9.2. Program Management Commands

EXIT    Leave the KERMIT program, doing  whatever  cleaning  up  must  be  done
        -- deassigning of devices, closing of files, etc.

QUIT    Leave  the  KERMIT  program without cleaning up, in such a manner as to
        allow further manipulation of the files and devices.

PUSH    Preserve the current KERMIT environment and enter  the  system  command

TAKE    Read and execute KERMIT program commands from a local file.

LOG     Specify  a  log for file transfer transactions, or for terminal session

KERMIT Commands                                                         Page 49

9.3. Terminal Emulation Commands

CONNECT This  verb,  valid  only  for a local Kermit, means to go into terminal
        emulation mode; present the illusion of being directly connected  as  a
        terminal  to the remote system.  Provide an "escape character" to allow
        the user to "get back" to the local system.  The escape character, when
        typed, should take a single-character argument; the following are  sug-

            0   (zero) Transmit a NUL
            B   Transmit a BREAK
            C   Close the connection, return to local KERMIT command level
            P   Push to system command processor
            Q   Quit logging (if logging is being done)
            R   Resume logging
            S   Show status of connection
            ?   Show the available arguments to the escape character
            (a  second  copy  of  the  escape  character):  Transmit the escape
                character itself

        Lower case equivalents should be accepted.  If any invalid argument  is
        typed, issue a beep.

Also see the SET command.

9.4. Special User-Mode Commands

These commands are used only by Users of Servers.

BYE     This  command  sends  a message to the remote server to log itself out,
        and upon successful completion, terminate the local Kermit program.

FINISH  This command causes the remote server to shut  itself  down  gracefully
        without logging out its job, leaving the local KERMIT at KERMIT command
        level, allowing the user to re-CONNECT to the remote job.


            /                 File 05 / NIA069                    /
            /  DEPARTMENT OF THE ARMY FIELD MANUAL Part 02 of 02  /
            /              Explosives and Demolitions             /
            /                      extract.                       /
            /         HEADQUATERS, DEPARTMENT OF THE ARMY         /
            /                    February 1971                    /
            /                                                     /
            /                Typed by: Death Jester               /
            /                Date Typed In: 01DEC90               /

              Section III.  STEEL-CUTTING CHARGES [Part 02 of 02]

3-7.  Cutting Steel With Explosives

   a. IMPORTANT FACTORS.  In the preparation of steel-cutting charges,
the factors of type, size and placement of the explosive are important
for successful operations.  The confinement or tamping of the charge is
rarely practical or possible.  Formulas for the computation of the size
of the charge vary with the type of steel--structural, high carbon, and
so forth.  Placement of the charge in direct contact with the target is
more important with steel than with other materials.
      (1)  FORMULA FOR STRUCTURAL STEEL.  Charges to cut I-beams,
builtup girders, steel plates, columns, and other structural steel
sections are computed by formal as follows:
         P = 3/8 A or P = 0.375 A where,
         P = pounds of TNT required,
         A = cross-section area, in square inches, of the steel member to
be cut, and
         3/8 = 0.375 = constant
        (a) The formula below is recommended for the computation of
block cutting charges for high-carbon or alloy steel, such as that found
in machinery.
         P = D}
         P = pounds of TNT
         D = diameter or thickness in inches of section to be cut.
        (b) For round steel bars, such as concrete reinforcing rods,
where the small size makes charge placement difficult or impossible and
for chains, cables, and steel rods, of a diameter of 2 inches or less,
         P = D
         P = pounds of TNT
         D = diameter in inches of section to be cut.
Such steel, however, may be cut by "rule of thumb:"
     For round bars up to 1 inch in diameter, use 1 pound TNT.
     For round bars over 1 inch up to 2 inches in diameter, use 2 pounds
     of TNT.
      (3) RAILROAD RAIL.  The height of ralroad rail is the critical
dimension for calculating explosive required.  Rails 5 inches or more in
height may be cut with 1 pound of TNT.  For rails less than 5 inches in
height, 1/2 pound of TNT is adequate.
      (4) PROBLEM:
Determine the amount of TNT required to cut the steel I-beam shown in
figure 3-5.  THe solution is given in the figure.
      (5) PROBLEM:
How much TNT is needed to cut the steel chain in figure 3-6?  The
solution is given in figure 3-6.  Notice that the link is to be cut in
two places (one cut on each side) to cause complete failure.  If the
explosive is long enough to bridge both sides of the link, or large
enough to fit snugly between the two links, use one charge; but if it is
not, use two separately primed charges.
      (6) USE OF THE TABLE IN MAKING CALCULATIONS.  Table 3-1 shows the
correct weight of TNT necessary to cut steel sections of various
dimensions calculated from the formula P = 3/8 A.
In using this table:
        (a) Measure separately the rectangular sections of members.
        (b) Find the corresponding charge for each section by using the
        (c) Total the charges for the sections.
        (d) Use the next larger given dimension if dimensions of section
        do not appear in the table.
      (7) SOLUTION.
The problem in figure 3-5 may be solved as folows:
Charge for flanges:           Charge for web:
    width = 5 inches              height = 11 inches
    thickness = 1/2 inch          thickness = 3/8 inch
Charge from table =           Charge from table =
   1.0  pounds                   1.6 pounds
     Total charge: 2 flanges = 2 x 1.0 = 2.0 pounds
                         web = 1 x 1.6 = 1.6 pounds
                                         3.6 pounds
     Use 4 pounds of TNT.

plastic explosives (M5A1 or M112) charges or sheet explosive (M118 or
M186) charges, which may be cut to fit the target and attached to the
surface of the target with little or no air gap, the following formulas,
based upon optimum charge configuration and optimum contact with the
target, may be used.  The following charge calculations are based upon
the dimensions of the target, and with some practice these charges may
be calculated, prepared, and placed in less time than the charges
calculated by the formulas listed above.  Thes charges may also be
prepared in advance for transportation to the site by wrapping them in
aluminum foil or heavy paper.  The wrapper should be removed when the
charge is attached to the target.  When preparing these charges the
explosive should be cut to the proper dimensions, not molded, as molding
the explosive will reduce its density thereby decreasing its
      (1) RIBBON CHARGE METHOD.  The charge, if properly calculated and
placed, cuts stell with considerably less explosive than standard
charges.  It is effective on noncircular steel targets up to 3 inches
thick (fig 3-7).  Although this charge is based upon the used of C4
plastic explosive, sheet explosive may be used provided the 1/4- by 3 by
12-inch sheets of flexible explosive are used intact and complete
charges are at least 1/2 inch thick.
        (a) CALCULATION.  The effectiveness of the explosive depends
upon the width and thickness of the explosive.  THe thickness of the
charge is one half the thickness of the stell.  The width of the charge
is three times the thickness of the charge.  The length of the charge
should be equal to the length of the desired cut.
        (b) EXAMPLE.  Determine the thickness and width of a ribbon
charge for cutting a steel plate 1 inch thick.
   Charge thickness = 1/2 steel thickness
   Charge thickness = 1/2(1) = 1/2 inch
   Charge width = 3 times charge thickness
   Charge width = 3(1/2) = 3/2 = 1 1/2 inches
Charge is 1/2 inch thick and 1 1/2 inches wide.
        (c) DETONTATION.  The ribbon charge may be detonated from the
center or from either end.  It may be necessary when the charge
thickness is small (less than 3/4 inch) to place extra explosive around
or over the blasting cap.
        (d) USE OF STRUCTURAL STEEL SECTIONS.  The ribbon charge
(computed by formula given in (b) above) has proven applicable to
cutting structural steel sections (fig 3-8).
On wide-flange or I-beams of less than 2 inches of steel thickness, a
C-shaped charge is placed on one side to cut the web and half the top
and bottom flanges.  THe other sides of these flanges are cut by two
offset ribbon charges, placed so that once edge is opposite the center
of th C-shaped charge as shown in A, figure 3-8.  For beams with steel
thickness of 2 inches and over, the offset charges are placed so that
one edge is opposite the edge of the C-shaped charge as shown in B,
figure 3-8.  FOr acceptable results, the charges must be detonated at
the SAME INSTANT.  This is accomplished by priming the charges with
three exactly EQUAL LENGTHS of detonating cord with blasting caps
attached and placed in the charges as shown in C, figure 3-8.  The
detonating cord primer may be initiated by an electric or nonelectric
system.  Simultaneous detonation may also be accomplished with M6
electric blasting caps wired in series in the same circuit.
BARS.  This method of steel cutting utilizes the destructive effect of
the end split or cross fracture formed in steel at the end of a charge
opposite the end where detonation was initiated.  This technique may be
used on round, square, or rectangular milled steel bars up to 8 inches
square or 8 inches diameter.  The cross fracture method uses a charge
cut in the shape of a triangle and is called a SADDLE CHARGE (fig 3-9).
        (a) CALCULATION.  The dimensions of the saddle charge are
computed from the dimensions of the target as follows:
      Thickness of charge = 1 inch (thickness of M112 block of plastic
      Base of charge = 1/2 circumference of target.
      Long axis of charge = Circumference of target.
        (b) EXAMPLE.  Determine the dimensions of a charge for cutting a
shaft 18 inches in circumference (may be measured with a string).
      Thickness = 1 inch
      Base = 1/2 x 18 = 9 inches
      Long axis = 18 inches
Charge is 9 inches at base, 18 inches at long axis, and 1 inch thick.
        (c) DETONATION.  Detonation of the saddle charge is by the
placement of a military electric or nonelectric blasting cap at the apex
of the long axis.
        (d) PLACEMENT.  The long axis of the saddle charge should be
parallel with the long axis of the target.  THe charge should be cut to
the correct shape and dimensions and then molded around the target,
taking care to insure that the charge is in intimate contact with the
target.  This may be accomplished by taping the charge to the target.

      (3) STRESS WAVE METHOD (DIAMOND CHARGE).  This method of steel
cutting utilizes the destructive effect of tensile fractures induced
through the interaction of two colliding shock wave fronts from an
explosive charge simultaneously detonated at opposite ends.  This
techniquie may be used on high carbon steel or steel alloy bars either
circular or square in cross section.  The stress wave method uses a
charge cut in the shape of a diamond, and thus called a diamond charge
(fig 3-10).
        (a) CALCULATION.  The dimensions of the diamond charge are
computed from the dimensions of the target as follows:
     Thickness of charge = 1 inch (thickness of M112 block of plastic
     Long axis of charge = Circumference of target.
     Short axis of charge = 1/2 the circumference of the target.
        (b) EXAMPLE.  Determine the size of a charge for cutting a steel
alloy shaft 15 inches in circumference.
     Thickness = 1 inch
     Long axis = 15 inches
     Short axis = 1/2 x 15 = 7 1/2 inches
Charge is 15 inches at long axis, 7 1/2 inches at short axis, and 1 inch
        (c) DETONATION.  The detonation of diamond charge must be done
SIMULTANEOUSLY from both short axis ends.  This may be done by priming
with two pieces of detonating cord of the SAME LENGTH with nonelectric
blasting caps crimped to the ends.  The detonating cord primers may be
detonated with an electric or nonelectric blasting cap.  Simultaneous
detonation may also be accomplished with M6 electric blasting caps wired
in series in the same circuit.
        (d) PLACEMENT.  Wrap the explosive completely around the target
so that the ends of the long axis touch.  It may be necessary to
slightly increase the dimensions of the charge so this may accomplished.
If necessary to insure complete contact with the target, tape the charge
to the target.

3-9.  Charge Placement

   a. STEEL SECTIONS.  The size and type of a steel section determine
the placement of the explosive charge.  Some elongated sections may be
cut by placing the explosive on one side of the section completely along
the proposed line of rupture.  In some steel trusses in which the
individual memebers are fabricated from two or more primary sections,
such as angle irons or bars separated by space washers or gusset plates,
the charge must be placed with the opposing portions of the charge
offset the same distance as the thickness of the section being cut to
produce a shearing action (para 3-8b(1)(d)).  Heavier I-beams, wide
flange beams, and columns may also require auxilliary charges placed on
the outside of the flanges.  Care must be taken to insure that opposing
charges are never directly opposite each other, otherwise they tend to
neutralize the explosive effect.

   b. RODS, CHAINS, AND CABLES.  Block explosive, often difficult to
emplace, is not recommended for cutting steel rods, chains, and cables
if plastic explosive is available.

   c. STEEL MEMBERS AND RAILROD RAILS.  Charge placement for cutting
these are found in figures 3-11 and 4-39.

   d. BUILT-UP MEMBERS.  Built-up members frequently have an irregular
shape, which makes it difficult to obtain a close contact between the
explosive charge and all of the surface.  If it is impractical to
distribute the charge properly to obtain close contact, the amount of
explosive should be increased.

   e. IRREGULAR STEEL SHAPES.  Composition C4 is a good explosive for
cutting irregular steel shapes because it is easily molded or pressed
into place to give maximum contact.  In the case of the M5A1 block
charge, which uses C4, a light coating of adhesive compound or
automotive grease (GAA) applied to the steel surface will help hold the
explosive on the target.  The M112 block, which also uses C4, and the
M118 sheet explosive have an adhesive coating on one side, which makes
placement easier.

   f. SECURING EXPLOSIVES IN PLACE.  All explosives except adhesive
types must be tied, taped, wedged in place unless they rest on
horizontal surfaces and are not in danger of being jarred out of place.

   g. PRECAUTIONS.  In cutting steel, the charge should be placed on the
same side as the firing party, as explosive charges throw steel
fragments (missiles) long distance at high velocities.

                        Section IV.  PRESSURE CHARGES

3-10.  Size of Charge

The pressure charge is used for the demolition of reinforced concrete
T-beam bridge superstructures.  Since it requires the use of more
explosives than breaching charges, with comparable placement, it has
been replaced by the breaching charge (para 3-12 - 3-14).

   a. FORMULA FOR TAMPED PRESSURE CHARGES.  The amount of TNT required
for a tamped pressure charge is calculated by the formula below.  If
explosive other than TNT is used, the calculated value must be divided
by the relative effectiveness factor.
     P = 3H}T
     P = pounds of TNT required for each beam (stringer)
     H = height of beam (including thickness of roadway) in feet
     T = thickness of beam in feet.

   b. FORMULA FOR UNTAMPED PRESSURE CHARGES.  The valure calculated for
P by the above formula is increased by one-third if the pressure charge
is not tamped to a minimum of 10 inches (P = 4H}T).

3-11.  Charge Placement and Tamping

   a. PLACEMENT.  The correct amount of explosive is placed on the
roadway over the centerline of each stringer (fig 3-12) and alined
between the ends of the span.  If a curb or sied rail prevents placing
the charge directly above the outside stringer, it is placed against
the curb or side rail.  This does not require an increase in the size of
the explosive charge (See also para 4-22).

   b. TAMPING.  Pressure charges should be tamped whenever possible.
Effective tamping require a minimum of 10 inches of material.  All
charges are primed to fire simultaneously.


3-12.  Critical Factors and Computation

Breaching charges are applied chiefly to the destruction of concrete
slab bridges, bridge beams, bridge piers, bridge abutments, and
permanent field fortifications.  The size and shape, placement, and
tamping or confinement of the breaching charge are critical factors--
the size and confinement of the explosive being relatively more
important because of strength and bulk of the material to be breached.
High explosive breaching charges detonated in or against a target must
produce and transmit enough energy to the target to crater and spall the
material.  THe metal reinforcing bars in reinforced concrete are not cut
by breaching charges.  If it is necessary to remove or cut the
reinforcement, the necessary steel cutting formula is used after the
concrete is breached.

   a. CALCULATION FORMULA.  The size of a charge required to breach
concrete, masonry, rock or similar material is calculated by the formula
below.  By proper adjustment of the P-value, the charge size for any
explosive may be readily determined.
     P = R(cubed) KC where;
     P = pounds of TNT required,
     R = breaching radius (b below),
     K = material factor, given in table 3-4, which reflects the
         strength, hardness and mass of the material to be demolished (c
     C = a tamping factor, given in figure 3-13, which depends on the
         location and tamping of the charge (d below)

   b. BREACHING RADIUS R.  The breaching radius R is the distance in
feet from an explosive in which all material is displaced or destroyed.
The breaching radius for external charges is the thickness of the mass
to be breached.  The breaching radius for internal charges is one-half
the thickness of the mass to be breached if the charge is placed midway
into the mass.  If holes are drilled less than halfway into the mass,
the breaching radius becomes the longer distance from center of the
charge to the outside of the mass.  For example, if a 4-foot wall is to
be breached by an internal charge placed 1 foot into the wall, the
breaching radius is 3 feet.  If it is to be breached by a centered
internal charge, the breaching radius is 2 foeet.  The breaching radius
is 4 feet is an external charge is used.  Values of R are rounded off to
the next highest 1/2-foot for external charges, and to the next highest
1/4-foot for internal charges.

   c. MATERIAL FACTOR K.  K is the factor that reflects the strength and
hardness of the material to be breached.  Table 3-2, gives values for
the factor K for various types and thicknesses of material.  If the type
of material in the object is in doubt, it is always assumed to be of the
stronger type.  Concrete is assumed to be reinforced, unless it is known
not to be.

        MATERIAL         !  BREACHING RADIUS  !  K   !
Ordinary earth           !     All values     ! 0.07 !
Poor masonry, shale,     ! Less than 5 ft     ! 0.32 !
hardpan: Good Timber     ! 5 ft or more       ! 0.29 !
and earth construction   !                    !      !
Good masonry             ! 1 ft or less       ! 0.88 !
ordinary concrete        ! 1.5-2.5 ft         ! 0.48 !
rock                     ! 3.0-4.5 ft         ! 0.40 !
                         ! 5.0-6.5 ft         ! 0.32 !
                         ! 7 ft or more       ! 0.27 !
Dense concrete           ! 1 ft or less       ! 1.14 !
first-class masonry      ! 1.5-2.5 ft         ! 0.62 !
                         ! 3.0-4.5 ft         ! 0.52 !
                         ! 5.0-6.5 ft         ! 0.41 !
                         ! 7 ft or more       ! 0.35 !
Reinforced concrete      ! 1 ft or less       ! 1.76 !
(concrete only: Will not ! 1.5-2.5 ft         ! 0.96 !
cut reinforcing steel)   ! 3.0-4.5 ft         ! 0.80 !
                         ! 5.0-6.5 ft         ! 0.63 !
                         ! 7 ft or more       ! 0.54 !

   d. TAMPING FACTOR C.  The value of the tamping factor C depends on
the location and the tamping of the charge.  Figure 3-13 shows typical
methods for placing charges and gives values of C to be used in the
breaching formula with both tamped and untamped charges.  In selecting a
value of C from figure 3-13, a charge should be tamped with a solid
material such as sand or earth or tamped by water is not considered full
tamped unless it is covered to a depth equal to or greater than the
breaching radius.

   e. USE OF FIGURE IN MAKING CALCULATIONS.  Figure 3-14 gives the
amount of TNT required to breach reinforced concrete targets.  The
amounts of TNT in the table were calculated from the formula
P = R(cubed)KC.  To use the figure:
      (1) Measure thickness of concrete.
      (2) Decide how the charge will be placed against the target.
Compare the method of placement with the diagrams at the top of the
figure.  If there is any question as to which column to use, always use
the column that will give the greater amount of explosive.
      (3) For explosive other than TNT, use the relative effectiveness
factor (table 1-2).

   f. EXAMPLE.  Using figure 3-14, calculate the amount of TNT required
to breach a reinforced concrete wall 7 feet thick with an untamped
charge placed at a distance R above the ground.  From the figure the
required amount of TNT is 334 pounds.

values given in figure 3-13 may be used to calculate breaching charges
for obstacles of material other than reinforced concrete by multiplying
the valure obtained from figure 3-14 by the proper conversion factor
given in table 3-3.  To use the table ---
      (1) Determine the type of material in the object.  If in doubt
assume the material to be of the stronger type, e.g. assume concrete
reinforced, unless known otherwise.
      (2) Using figure 3-14, determine the amount of explosive that
would be required if the object were made of reinforced concrete.
      (3) Using table 3-3, determine  the appropriate conversion factor.
      (4) Multiply the number of pounds of explosive by the conversion

   h. EXAMPLE.  Using figure 3-14 and table 3-3, determine the amount of
TNT required to breach an ordinary masonry pier 4 1/2 feet thick with an
untamped charge placed 4 feet below the waterline.  If the pier were
made of reinforced concrete, 146 pounds of TNT would be required to
breach it (fig 3-14).  The conversion factor (table 3-3) is 0.5.
Therefore 146 x 0.5 = 73 pounds of TNT are required to breach the pier.

3-13.  Placement and Number of Charges

   a. PLACEMENT.  In the demolition of piers and walls, the position for
the placement of explosive charges are rather limited.  Unless a
demolition chamber is available, the charge (or charges) may be placed
against once face of the target either at ground level, somewhat above
ground level, or beneath the surface.  A charge placed above ground
level is more effective than one placed directly on the ground.  When
several charges are required to destroy a pier, slab, or wall and
elevated charges are desired, they are distributed equally at no less
than one breaching radius high from the base of the object to be
demolished.  In this manner, the best use is obtained from the shock
reflection surface is necessary for spalling to occur (see para 3-2).
All charges are thoroughly tamped with damp soil or filled sandbags if
time permits.  (Tamping must be equal to or greater than the breaching
radius.)  For piers, slabs, or walls partially submerged in water,
charges are placed equal to or greater than the breaching radius below
the waterline (fig 3-13).

   b. CHARGE CONFIGURATIONS. In order to transmit the maximum
destructive shock into the target, the explosive charge should be placed
in the shape of a flat square with the flat side to the target.  The
thickness of the charge is dependent upon the amount of explosive and is
given in table 3-4.

Amount of explosive         !  Thickness of charge
Less than 5 lbs             !      1 inch
5 lbs to less than 40 lbs   !      2 inches
40 lbs to less than 300 lbs !      4 inches
300 lbs or more             !      5 inches
*These are approximate values

   c. NUMBER OF CHARGES.  The number of charges required to demolish a
pier, slab, or wall is calculated be the formula:
     N = W/2R where,
     N = number of charges,
     W = width of pier, slab, or wall, in feet,
     R = breaching radius in feet (para 3-12b).
     2 = constant
If the calculated value of N is less that 1 1/4, use one charge; if it
is 1 1/4 to less than 2 1/2, use 2 charges; if it is 2 1/2 or more,
round off to nearest whole number.  In breaching concrete beam bridges,
each beam is breached individually.

3-14.  Opposed (Counterforce) Charge

This special breaching techniqure is effective against comparatively
small cubical or columnar concrete and masonry objects 4 feet or less in
thickness and wideth.  It is not effective against piers or long
obstacles.  The obstacle must also have at least three free faces or be
free standing.  If constructed of plastic explosive properly placed and
detonated, counterforce charges produce excellent results with a
relatively small amount of explosive.  Their effectiveness results from
simultaneous detonation of two charges placed directly opposite eache
other and as neer the center of the target as possible (fig 3-15).

   a. CHARGE CALCULATION.  The size is computed from the diameter or
thickness of the target in feet, as --
     The amount of explosive = 1 1/2 x the thickness of the target in
     feet (1 1/2 pounds per foot).
Fractional measurements are rounded off to the next higher foot prior to
multiplication.  Fot example, a concrete target measuring 3 feet 9
inches thick requires 1 1/2 x 4 = 6 pounds of plastic explosive
(composition C4).

   b. PREPARATION AND EMPLACEMENT.  Divide the calculated amount of
explosive in half to make two identical charges.  The two charges MUST
be placed diametrically opposite each other.  This requires
accessibility to both sides of the target so that the charges may be
placed flush against the respective target sides.

   c. PRIMING.  The simultaneous explosion of both charges is mandatory
for optimum results.  Crimp nonelectric blasting caps to equal lengths
of detonating cord.  Prime both charges at the center rear point; then
form a V with the free ends of detonating cord and attach an electric or
nonelectric means of firing.  Simultaneous detonation may also be
accomplished with M6 electric blasting caps wired in series in the same


3-15.  Critical Factors

   a. SIZE.  Road craters, to be effective obstacles, must be too wide
for spanning by track-laying vehicles and too deep and steep sided for
any vehicle to pass through them.  Blasted road craters will not stop
modern tanks indefinitely, because repeated attempts by the tank to
traverse the crater will pull loose soil from the slopes of the crater
into the bottom reducing both the depth of the crater and angle of the
slopes.  Road craters are considered effective antitank obstacles if the
tank requires three or more passes to traverse the crater, thereby
providing sufficient time for antitank weapons to stop the tank.  Road
craters must also be large enough to tie into natural or manmade
obstacles at each end.  The effectiveness of blasted road craters may be
improved by placing log hurdles on either side, by digging the face on
the friendly side nearly vertical, by mining the site with antitank and
antipersonnel mines.

   b. EXPLOSIVE.  All military explosives may be used for blasting
antitank craters.  A special 40-pound cratering charge, ammonium
nitrate, sued in a waterproof metal container, is used when available
(para 1-4).

   c. SIZE AND PLACEMENT OF CHARGE.  In deliberate cratering, holes are
bored to specific depths and spaced according to computation by formula,
as described below.  In ditching, test shots are made and the diameter
and depth are increased as required.

   d. CONFINEMENT OF CHARGE.  Charges at cratering sites and antitank
ditching sites are placed in boreholes and properly stemmed.  Those at
culvert sites are tamped with sandbags.

Hard-surfaced pavement of roads and airfields is breached so that holes
may be dug for cratering charges.  This is done effectively exploding
tamped charges on the pavement surface.  A 1-pound charge of explosive
is used for each 2 inches of pavement thickness.  It is tamped with
material twice as thick as the pavement.  The pavemenmt may also be
breached by charges placed in boreholes drilled or blasted through it.
(A shaped charge readily blasts a small diameter borehole through the
pavement and into the subgrade.)  Concrete should not be breached at an
expansion joint, because the concrete will shatter irregularly.

   f. BOREHOLES FOR CRATERING CHARGES.  Boreholes for cratering charges
may be dug by using motorized post hole augers or diggers.  Boreholes
may also be made by use of the earth rod kit (para 1-41) or by a
mechanically drivin pin, widened with a detonating cord wick (para

   g. BLASTING BOREHOLES WITH SHAPED CHARGES.  Standard shaped charges
may be used to blast boreholes in both paved and unpaved surfaces for
rapid road cratering with explosives.  The 15-pound M2A4 shaped charge
detonated at 3 1/2 foot standoff and the 40-pound M3A1 shaped charge
detonated at 5-foot standoff will blast boreholes of up to 9-foot open
depths with 7-inch and larger diameters in both reinforced concrete
pavements and gravel surfaced roads.  For maximum effectiveness, M3A1
shaped charges should be used to blast boreholes in thick, reinforced
concrete pavements laid on dense high-strength base courses.  The M2A4
shaped charges may be used effectively to blast cratering charge
boreholes in reinforced concrete pavement of less than 6-inch thickness
laid on thin base courses or to blast boreholes in unpaved roads.  Most
any kind of military explosive, including the cratering charges, can be
loaded directly into boreholes made by the M3A1 and the M2A4 shaped
charges.  Shaped charges do not always produce open boreholes capable of
being loaded directly with 7-inch diameter cratering charges without
removal of some earth or widening of narrow areas.  Many boreholes
having narrow diameters but great depth can be widened simply by
knocking material from the constricted areas with a pole or rod or by
breaking off the shattered surface concrete with a pick or crowbar.  For
road cratering on asphalt or concrete surfaced roadways, blasting the
boreholes with shaped charges will expedite the cratering task by
eliminating the requirement for first breaching the pavement with
explosive charges (table 3-5).

3-16.  Hasty Road Crater

This method (fig 3-16) takes the least amount of time for construction,
based upon number and depth of boreholes, but produces the least
effective barrier because of its depth and shape.  The method described
below forms a V-shaped crater, about 6 to 7 feet deep and 20 to 25 feet
wide extending about 8 feet beyond each end crater.  The sides have
slopes of 25 degrees to 35 degrees.  Modern U.S. combat tanks (the M48
and M60) require an average of four passes to traverse hasty road
craters.  Craters formed by boreholes less than 5 feet deep and loaded
with charges less than 50 pounds are ineffective against tanks.  The
following hasty cratering method has proved satisfactory:

   a. Dig all boreholes to the same depth; at least 6 feet.  Space the
holes 5 feet apart center-to-center across the road.  The formula for
the computation of the number of holes is : N = L-16/5 + 1, where

L = length of crater in feet measured across the roadway.  Any
fractional number of holes is rounded off to the next highest number.

   b. Load the boreholes with 10 pounds of explosive per foot of depth.

   c. Prime all charges with detonating cord and connect them to fire
simultaneously.  Under ground charges should always be primed with
detonating cord branch lines.  A dual firing system should be used.

   d. If the standard cratering charge is used, place a 1-pound priming
charge on the side of the charge for dual priming.  For hasty cratering,
if standard cratering charges are used, each charge must be supplemented
with 10 pounds of additional explosive to total 50 pounds of explosive
per borehole.
      Note.  Each cratering charge must be carefully inspected for
possible water damage prior to emplacement.

   e. Stem all boreholes with suitable material.
3-17.  Deliberate Road Crater

This cratering method (fig 3-17) produces road craters that are more
effective than those resulting from the hasty method as they require an
average of eight passes to be crossed by modern U.S. tanks.  The crater
produced is V-shaped, approximately 7 feet deep, 25 feet wide, with side
slopes about 30 degrees to 37 degrees.  The crater extends about 8 feet
beyond the end holes.  The method of placing charges is as follows:

   a. Bore the holes 5 feet apart, center-to-center, in a line across
the roadway.  The end holes are 7 feet deep and the others are
alternately 5 feet and 7 feet deep.  The formula for the computation of
the number of holes is :
     N = L-16/5 + 1
     L = length of crater in feet measured across roadway
Any fractional number of holes is rounded off to the next highest
number.  Two 5-foot holes must not be made next to each other.  If they
are so calculated, one of them must be a 7-foot hole.  The resulting two
adjacent 7-foot holes may be placed anywhere along the line.

   b. Place 80 pounds of explosive in the 7-foot holes and 40 pounds of
explosive in the 5-foot holes.

   c. Prime the charges as for hasty cratering.  Dual priming of the
7-foot holes may be accomplished by independent priming of each of the
two cratering charges, if used.

   d. Stem all holes with suitable material.

3-18.  Relieved Face Road Crater

This cratering method (fig 3-18) produces road craters that are more
effective obstacles to modern tanks than the standard V-shaped craters.
This technique produces a trapezoidal-shaped crater about 7 feet deep
and 25 to 30 feet wide with unequal side slopes.  In compact soil, such
as clay, the relieved face cratering method will provide and obstace
shaped as shown in A, figure 3-18.  The side nearest the enemy slopes at
about 25 degrees from the road surface to the bottom while that on the
opposite side or friendly side is about 30 degrees to 40 degrees steep.
The exact shape, however depends of the type of soil found in the area
of operations.  The procedure is as follows:

   a. On dirt or gravel surfaced roads, drill two rows of boreholes 8
feet apart, spacing the boreholes on 7-foot centers.  On hard surfaced
roads, drill the two rows 12 feet apart.  The number of charges for the
friendly side row can be calculated by the formula N = L-10/7 + 1, where
L = length of crater in feet measured across the width of the road.
Any fractional number of holes should be rounded off to the next highest
number.  Stagger the boreholes in the other row, as shown in B, figure
3-18.  This row will always contain one less borehole than the other

   b. Make the boreholes on the friendly side 5 feet deep and load with
40 pounds of explosive, and those on the enemy side 4 feet deep and
load with 30 pounds of explosive.

   c. Prime the charges is each row separately for simultaneous
detonation.  There should be a delay of detonation of 1/2 to 1 1/2
seconds between rows, the row on the enemy side being detonated first.
Best results will be obtained if the charges on the friendly side are
fired while the earth moved in the first row is still in the air.
Standard delay caps may be used for delay detonation.
   d. Acceptable results may be obtained by firing both rows
simultaneously, if adequate means are sufficient time for delay firing
are not available.  However the resulting crater will not have the same
depth and trapezoidal shape as described above.

   e. To prevent misfires from the shock and blast of the row of charges
on the enemy side (detonated first), the detonation cord mains and
branch lines of the row on the friendly side (detonated last) must be
protected by a covering of about 6 inches of earth.

3-19.  Angled Road Crater Method

This method is useful against tanks traveling in defiles or road cuts
where the must approach the crater straightaway and is the most
effective cratering method.  The road crater is blasted using either the
hast or deliberate cratering methods described in paragraphs 3-16 and
3-17, except the boreholes are drilled across the roadway at about a 45
degree angle as shown in figure 3-19.  Because of the angle at which
tanks must attempt to cross an angled crater, they tend to slip sideways
and ride off their tracks.

3-20.  Blasting Permafrost and Ice

blasting requires about 1 1/2 to 1 times the number of boreholes and
larger charges than those calculated by standard formulas for moderate
climates.  Frozen soil, when blasted breaks into large clods 12 to 18
inches thick and 6 to 8 feet in diameter.  A the charge has
insufficient force to blow these clods clear of the hole, they fall back
into it when the blast subsides.  Testing to determine the number of
boreholes needed should be made before extensive blasting is attempted.
In some cases, permafrost may be as difficult to blast as solid rock.
      (2) METHOD OF MAKING BOREHOLES.  Boreholes are made by three
methods--use of standard drilling equipment, steam pount drilling
equipment, and shaped charges.  Standard drill equipment has one serious
defect--the air holes in the drill bits freeze and there is no known
method of avoiding it.  Steam point drilling is satisfactory in sand,
silt or clay, but not in gravel.  Charges must be placed immediately
upon withdrawl of the steam point, otherwise the area around the hole
thaws out and plugs it.  Shaped charges also are satisfactory for
producing boreholes, especially for cratering.  Table 3-5 shows the size
of boreholes in permafrost and ince made by M3A1 and M2A4 shaped
      (3) EXPLOSIVES.  A low velocity explosive like ammonium nitrate,
satisfactory for use in arctic temperatures, should be used, if
available.  The heaving quality of low velocity explosives will aid in
clearing the hole of large boulders.  If only high velocity explosives
are available, charges should be tamped with water and permitted to
freeze.  Unlesss high velocity explosives are thoroughly tamped, they
tend to blow out of the borehole.

      (1) ACCESS HOLES.  These are required for water supply and
determining the thickness of ice for the computation of safe bearing
pressures for aircraft and vehicles.  As ice carries much winter
traffic, its bearing capacity must be ascertained rapidly when forward
movements are required.  Small diameter access holes are made by shaped
charges.  On solid lake ice, the M2A4 penetrates 7 feet and the M3A1, 12
feet.  These charges will penetrate farther but the penetration
distances were tested in only ice approximately 12 feet thick.  If the
regular standoff is used, a large crater formes at the top, which makes
considerable probing necessary to finde the borehole.  If a standoff of
42 inches or more is used with the M2A4 shaped charge, a clean hole
without a top crater is formed.  Holes made by the M2A4 average 3 1/2
inches in diameter, while those made by the M3A1 average 6 inches.
      (2) ICE CONDITIONS.  In the late winter after the ice has aged, it
grows weaker and changes color from blue to white.  Although the
structure of ice varies and its strength depends on age, air
temperature, and conditions of the original formation, the same size and
type of crater is formed regardless of the standoff distance.  If the
lake or river is not frozen to the bottom, the blown hole will fill with
shattered ice and clearing will be extremely difficult.  Under some
conditions, shaped charges may penetrate to a depth much less than that
indicated in table 3-5.
      (3) SURFACE CHARGES.  Surface craters may be made with ammonium
nitrate cratering charges or demolition blocks.  For the best effects,
the charges are placed on the surface of cleared ice and tamped on top
with snow.  The tendency of ice to shatter more rapidly than soil should
be considered when charges are computed.
        (a) Charges are placed underwater by first making boreholes in
the ice with boreholes in the ice with shaped charges, and then placing
the charge below th ice.  An 80-pound charge of M3 demolition blocks
under ice 4 1/2 feet thick forms a crater 40 feet in diameter.  This
crater, however, is filled with floating ice particles, and at
temperatures around 20 degrees F. freezes over in 40 minutes.
        (b) A vehicle obstacle may be cratered in ice by sinking
boreholes 9 feet apart in staggered rows.  Charges (tetrytol or plastic)
are suspended about 2 feet below the bottom of the ice by means of cord
with sticks bridging the tops of the holes.  The size of the charge
depends upon the thickness of the ice.  An obstacle like this may retard
or halt enemy vehicles for approximately 24 hours at temperatures around
-24 degrees F.

3-21.  Cratering at Culverts

A charge detonated to destroy a culvert not more than 15 feet deep may,
at the same time, produce an effective road crater.  Explosive charges
should be primed for simultaneous firing and thoroughly tamped with
sandbags.  Culverts with 5 feet or less of fill may be destroyed by
explosive charges placed in the same manner as in hasty road cratering.
Concentrated charges equal to 10 pounds per foot of depth are placed in
boreholes at 5-foot intervals in the fill above and alongside the

3-22.  Antitank Ditch Cratering

   a. CONSTRUCTION.  In open country, antitank ditches are constructed
to strengthen prepared defensive positions.  As they are costly in time
and effort, much is gained if the excavation can be made by means of
cratering charges.  To be effective, an antitank ditch must be wide
enough to stop an enemy tank.  It may be improved by placing a log
hurdle on the enemy side and spoil on the friendly side.  Ditches are
improved by digging the face on the friendly side nearly vertical by
means of handtools (para 3-15a).

   b. DELIBERATE CRATERING METHOD.  The deliberate cratering method
outlined in paragraph 3-17 is adequate for the construction of heavy
tank ditches in most types of soil.

   c. HASTY CRATERING METHOD.  An antitank ditch may be constructed by
placing 50 pounds of cratering explosive in 5-foot holes, and spacing
the holes at 5-foot intervals (fig 3-16).  The ditch crater will be
approximately 8 feet deep and 25 feet wide.
3-23.  Blasting of Ditches

In combat areas, ditches may be constructed to drain terrain flooded by
the enemy or as initial excavations for the preparation of
entrenchments.  Rough open ditches 2 1/2 to 12 feet deep and 4 to 40
feet wide may be blasted in most types of soils.  A brief outline of the
method is given below.

   a. TEST SHOTS.  Before attempting the actual ditching, make test
shots to determine the proper depth, spacing, and weight of charges
needed to obtain the required results.  Make beginning test shots with
holes 2 feet deep and 18 inches apart and then increase the size of the
charge and the depth as required.  A rule of thumb for ditching is to
use 1 pound of explosive per cubic yard of earth in average soil.

   b. ALINEMENT AND GRADE.  Mark the ditch centerline by transit line or
expedient means and drill holes along it.  When a transit or hand level
is used, the grade of the ditch may be accurately controlled by checking
the hole depth every 5 to 10 holes and at each change in grade.  In soft
ground, the holes may be made with a sharp punch, a quicksand punch (fig
3-20) or an earth auger.  Holes are loaded and tamped immediately to
prevent cave-ins and insure that the charges are at proper depth.
Ditches are sloped at a rate of 2 to 4 feet per 100 feet.

      (1) PROPAGATION METHOD.  By this method (fig 3-21) only one charge
is primed-- the charge placed in the hole at one end of the line of
holes made to blast the ditch.  The concussion from this charge
sympathetically detonates the next charge and so on until all are
detonated.  Only 50-60 percent straight commercial dynamite should be
used in this operation.  The propagation method is effective, however,
only in moist or wet soils and may be effectively used in swamps where
the ground is covered by several inches of water.  If more than one line
of charges is required to obtain a wide ditch, the first charge of each
line is primed.  The primed hole is overcharge 1 or 2 pounds.
      (2) ELECTRICAL METHOD.  Any high explosive may be used in ditching
by the electrical firing method which is effective in all soils except
sand, regardless of moisture content.  Each charge is primed with an
electric cap and the caps are connected in leapfrog series (para 2-6b).
Al charges are fired simultaneously.
      (3) DETONATING CORD METHOD.  In this ditching method any high
explosive may be used.  It is effective in any type of soil, except
sand, regardless of moisture content.  Each charge is primed with
detonating cord and connected to a detonating cord main or ring main

      (1) The method of loading for a deep, narrow ditch is illustrated
in figure 3-22.
      (2) The relief method of loading for shallow ditches is depicted
in figure 3-23.  Ditches 1 and 3 are blasted first to relieve ditch 2.
      (3) Figure 3-24 shows the posthole method of loading for shallow
ditches in mud.
      (4) The cross section method of loading to clean and widen ditches
is explained graphically in figure 3-25.

                     Section VII.  LAND CLEARING CHARGES

3-24.  Introduction

In military operations, construction jobs occur in which explosives may
be employed to advantage.  Among these jobs are land clearing, which
includes stump and boulder removal, and quarrying.  The explosives
commonly used are military and commercial dynamite and detonating cord.
The quantity of explosive used is generally calculated by rule of thumb.
Charges may be placed in boreholes in the ground under or at the side of
the target, in the target itself, or on top of the target.  All charges
should be tamped or mudcapped, which is a form of light tamping.

3-25.  Stump Removal

In certain military operations it may be necessary to remove stumps as
well as trees.  Stumps are of two general types, tap- and lateral-rooted
(fig 3-26).  Military Dynamite is the explosive best suited for stump
removal.  A rule of thumb is to use 1 pound per foot of diameter for
dead stumps and 2 pounds per foot for live stumps, and if both tree and
stump are to be removed, to increase the amount of explosive by 50
percent.  Measurements are taken at points 12 to 18 inches above the

   a. TAPROOT STUMPS.  For taproot stumps, one method is to bore a hole
in the taproot below the level of the ground.  The best method is to
place charges on both sides of the taproot to obtain a shearing effect
(fig 3-26).  For best results, tamp the charges.

   b. LATERAL-ROOT STUMPS.  In blasting later-root stumps, drill sloping
holes as shown in figure 3-26.  Place the charge as nearly as possible
under the center of the stump and at a depth approximately equal to the
radius of the stump base.  If for some reason the root formation cannot
be determined, assume that it is the lateral type and proceed

3-26.  Boulder Removal

In the building of roads and airfields or other military construction,
boulders can be removed by blasting.  The most practical methods are
snakeholing, mudcapping, and blockholing.

   a. SNAKEHOLING METHOD.  By this method, a hole large enough to hold
the charg is dug under the boulder.  The explosive charge is packed
under and against the bould as shown in A, figure 3-27.  For charge
size, see table 3-6.

   b. MUDCAPPING METHOD.  For surface or slightly embedded boulders, the
mudcapping method is very effective.  The charge is placed on top or
against the side of the boulder wherever a crack or seam exists that
will aid in breakage, and covered with 10 to 12 inches of mud or clay
(B, fig 3-27).  For charge size, see table 3-6.

   c. BLOCKHOLING METHOD.  This method is very effective of boulders
lying on the surface or slightly embedded in the earth.  A hole is
drilled on top of the boulder deep and wide enough to hold the amount of
explosive indicated in table 3-6.  The charge is then primed, put into
the borehole, and stemmed (C, fig 3-27).

        Table 3-6.  Charge Sizes for Blasting Boulders.
                       ! Pounds of explosive required
Boulder diameter (ft)  !----------------------------------------
                       ! Blockholing ! Snakeholing ! Mudcapping
           3           !     1/4     !     3/4     !      2
           4           !     3/8     !      2      !    3 1/2
           5           !     1/2     !      3      !      6
3-27.  Springing Charges

   a. DEFINITION AND METHOD.  A springing charge is a comparatively
small charge detonated in the bottom of a drilled borehole to form an
enlarged chamber for placing a larger charge.  At times two or more
springing charges in succession may be needed to make the chamber large
enough for the final charge.  Under these conditions at least 2 hours
should be allowed between firing and placing successive charges for the
boreholes to cool unless the sprung holes are cooled with water or
compressed air.

   b. DETONATING CORD WICK.  This is several strands of detonating cord
taped together and used to enlarge boreholes in soils.  One strand
generally widens the diameter of the hole about 1 inch.
      (1) A hole is made by driving a steel rod approximately 2 inches
in diameter into the ground to the depth required.  According to the
rule of thumb, a hole 10 inches in diameter requires 10 strands of
detonating cord.  These must extend the full length of the hole and be
taped or tied together into a "wick" to give optimum results.  The wick
may be placed into the hole by an inserting rod or some field expedient.
Firing may be done electrically or nonelectrically.  An unlimited number
of wicks may be fired at one time by connecting them by a detonated cord
ring main or line main.
      (2) The best results from the use of the detonating cord wick are
obtained in hard soil.  If successive charges are placed in the holes,
excess gases must be blown out andthe hole inspected for excessive heat.

3-28.  Quarrying

Quarrying is the extraction of rock in the natural state.  Militarty
quarries, generally of the open face type, are developed by the single
or multiple bench method.  See TM 5-332 for detailed information.


5-10. General

   a. The destruction of damaged or unserviceable explosives and
demolition materials is accomplished by explosive ordnance disposal
units as specified in AR 75-14, AR 75-15, TM 9-1375-200 and FM 9-16.

   b. Destruction of demolition materials, when subject to capture or
abandonment, will be undertaken by the using of arm only when, in the
judgment of the unit commander concerned, such action is necessary in
accordance with orders of, or policy established by, the Army commander.
The conditions under which destruction will be effected are command
decisions and may vary in each case, dependent upon a number of factors
such as the tactical situation, security classification of the
demolition materials, their quantity and location, facilities for
accomplishing destruction, and time available.  In general, destruction
can be accomplished most effectively by burning or detonation, or a
combination of these.

   c. If destruction to prevent enemy use is resorted to, explosive and
nonexplosive demolition materials must be so completely destroyed that
they cannot be restored to usable condition in the combat zone.  Equally
important, the same essential components of sets and kits must be
destroyed so that the enemy cannot assemble complete ones from undamaged
components by cannibalization.

   d. If destruction of demolition materials is directed, due
consideration should be given to (1) and (2) below.
      (1) Selection of a site that will cause greatest obstruction to
enemy movement and also prevent hazard to friendly troops from fragments
and blast which will occur incidental to the destruction.
      (2) Observation of appropriate safety precautions.

5-11.  Destruction Methods

Demolition materials can be most quickly destroyed by burning or
detonation.  The methods in A and B below, in order of preference, are
considered the most satisfactory for destruction of demolition materials
to prevent enemy use.  For additional information on the destruction of
explosives and ammunition see TM 9-1300-206 and TM 9-1300-214.

      (1) GENERAL.  Packed and unpacked high explosive items such as
linear demolition charges, shaped demolition charges, block demolition
charges, dynamite sticks, detonating cord, firing devices, time blasting
fuse, and similar items may be destroyed quickly and effectively by
burning.  Blasting caps set aside for destruction by burning must be
stacked in separate piles and not with other explosives.
        (a) Stack the explosives in a pile, if possible (not over 2,000
pounds to a pile), over a layer of combustible material.
        (b) Pour FUEL OIL over the entire pile.
        (c) Ignite the pile by means of a combustible train (excelsior
or slow-burning propellant) of suitable length and take cover
immediately.  The danger area for piles being burned in the open is
calculated  from the safe distances given in paragraph 5-2 but never
less than 400 meters.


      (1) GENERAL.  Packed and unpacked high explosive items such as
linear demolition charges, shaped demolition charges, block demoltion
charges, dynamite sticks, detonating cord, blasting caps, firing
devices, time blasting fuse, and similar items may be destroyed by
placing them in piles and detonating them with initiating charges of
TNT, or composition C series explosives, or other explosives having
equivalent potential.
        (a) The explosives should be stacked in piles, if possible (not
over 2,000 pounds to a pile).
        (b) Each 100 pounds of packed explosives (mine, blocks, etc.),
require a 2-pound (minimum) explosive charge to insue complete
detonation of the pile.  For unpacked explosives, a 1-pound (minimum)
explosive charge for each 100 pounds is sufficient.
        (c) Provide for dual priming as explained in chapter 2 to
minimize the possibility of a misfire.  For priming, either a
nonelectric blasting cap crimped to at least 5 feet of time blasting
fuse or an electric cap and firing wire may be used.
        (d) Detonate the charges.  If primed with nonelectric blasting
cap and time blasting fuse, ignite and take cover; if primed with
electric blasting cap, take cover before firing charges.  The danger
area for piles detonated in the open is calculated according to the safe
distance given in paragraph 5-2.

                               APPENDIX D
                         EXPEDIENT DEMOLITIONS

D-1.  Use of Epedient Techniques

These techniques are not presented as a replacement for the standard
demolition methods but for use by experienced blasters in special
projects.  Availability of trained men, time, and material will
generally determine their use.

D-2.  Shaped Charges

   a. DESCRIPTION.  Shaped charges concentrate the energy of the
explosion released on a small area, making a tubular or linear fracture
in the target.  Their versatility and simplicity makes them effective
against many targets, especially those made of concrete or those with
armour plating.  Shaped charges may be improvised (fig D-1).  Because of
the many variables, such as explosive density, configuration, and
density of the cavity liner, consistent results are impossible to
obtain.  Thus experiment, or trial and error, is necessary to determine
the optimum standoff distances.  Plastic explosive is best suited for
this type of charge.  Dynamite and molten TNT, however may be used as an

   b. PREPARATION.  Almost any kind of container is usable.  Bowls,
funnels, cone-shaped glasses (champagne glasses with the stem removed),
and copper, tin, or zinc may be used as cavity linerse; or wine bottles
with a cone in the bottome (champagne or cognac bottles) are excellent.
If none of these is available, a reduced effect is obtained by cutting a
cavity into a plastic explosive block.  Optimum shaped charge
characteristics are --
      (1) Angle of cavity = between 30 degrees and 60 degrees (most HEAT
ammunition has a 42 degree to 45 degree angle).
      (2) Standoff distance = 1 1/2 x diameter of cone
      (3) Height of explosive in container = 2 x height of cone measured
from base of the cone to the top of the explosive.
      (4) Point of detonation = exact top center of charge.  Cover cap,
if any any part of it is exposed or extends above the charge, with a
small quantity of C4 explosive.
     Note. The narrow necks of bottles or the stems of glasses may be
cut by wrapping tem with a piece of soft absorbant type twine or string
soaked in gasoline and lighting it.  Two bands of adhesive tape, one on
each side of the twine or string, will hold it firmly in place.  The
bottle or stemm must be turned continuously with the neck up, to heat
the glass uniformly.  Also, a narrow band of plastic explosive placed
around the nexk and burned gives the same resulte.  After the twine or
plastic has burned, submerge the neck of the bottle in water and tap it
against some object to break it off.  TAPE THE SHARP EDGES OF THE BOTTLE

D-3.  Platter charge

This device utilizes the Miznay-Chardin effect.  It turns a metal plate
into a powerful blunt-nosed projectile (fig D-2).  The platter should be
steel (preferably round, but square is satisfactory) and should weigh
from 2 to 6 pounds.

   a. CALCULATIONS.  Weight of explosives = approximately the weight of
the platter.

      (1) Pack the explosive uniformly behind the platter.  A container
is not necessary if the explosive can be held firmly against the
platter.  Tape is acceptable.
      (2) Prime the charge from the exact rear center.  Cover cap, if
any part is exposed, with a small quantity of C4 explosive to insure
      (3) Aim the charge at the direct center of the target.

   c. EFFECT.  The effective range (primarily a problem of aim) is
approximately 35 yards for a small target.  With practive, a
demolitionist may hit a 55-gallon drum, a relatively small target, at 25
yards about 90 percent of the time.

D-4.  Grapeshot Charge

This charge consists of a container, preferably a No. 10 can,
projectiles (small pieces of steel), buffer material, an explosive
charge, and a blasting cap.  These are assembled as shown in figure D-3.

   a. COMPUTATION.  The weight of the explosive is approximately 1/4 x
the weight of the projectiles.

      (1) Assemble the projectiles, a few inches of buffer
material-earth, leaves, wood, felt, cloth, cardboard, etc., and the
explosive charge.  This should be C4, packed firmly.
      (2) Prime the charge from the exact rear center.  Cover the cap,
if any part is exposed, with a small quantity of C4 to insure
      (3) Aim the charge toward the center of the target.

D-5.  Dust Initiator

This device consists of an explosive charge (powdered TNT or C3; C4 will
not properly mix with the incendiary), an incendiary mix (2 parts of
aluminum powder or magnesium powder to 3 parts ferric oxide), and a
suitable finely-divided organic material (dust) or a volatile fuel such
as gasoline called a surround.  The dust initiator is most effective in
an inclosed space, like a box car or a warehouse or other relatively
windowless structure.  At detonation, the surround is distributed
throughout the air within the target and ignited by the incendiary

      (1) Charge size = 1 pound (1/2 explosive, 1/2 incendiary mix).
      (2) Cover size = 3 to 5 pounds of each 1,000 cubic feet of target.
The one-pound charge will effectively detonate up to 40 pounds of cover.

   b. PREPARATION.  Powdered TNT may be obtained by crushing it in a
canvas bag.  The incendiary mix must be thoroughly  dispersed throughout
the explosive.  A great number of dust materials may be used as cover,
among which are coal dust, cocoa, bulk powdered coffee, confectioners
sugar, tapioca, wheat flour, corn starch, hard rubber dust, aluminum
powder, magnesium powder, and powdered soap.  If gasoline is used, 3
gallons is the maximum, as more will not disperse evenly in the air and
thus give poor results.

D-6.  Improvised Cratering Charge

This charge is a mixture of ammonium nitrate fertilizer containing at
least 33 1/3 percent nitrogen and diesel fuel, motor oil, or gasoline at
a ratio of 25 pounds of fertilizer to a quart of fuel.  The ferilizer
must not be damp.  From this mixture, improvised charges of almost any
sixe or configuration can be made.  Proceed as follows:

   a. Pour the liquid on the fertilizer.

   b. Allow the mixture to soak for an hour.
   c. Place about half the charge in the borehole.  Then place the
primer, a primed 1-pound block of TNT, and add the remainder of the
charge.  (Never leave the charge in the borehole for a long period, as
accumulated moisture reduces its effectiveness.)

   d. Detonate the charge.

D-7.  Ammonium Nitrate Satchel Charge

Although the cratering charge (para D-6) is excellent, it is suitable
only for cratering.  A more manageable charge may be used by mixing
ammonium nitrate fertilizer with melted wax instead of oil.  The primer
is set in place before the mixture hardens.

      (1) Melt ordinary paraffin and stir in ammonium nitrate pellets,
making sure that the paraffin is hot while mixing.
      (2) Before the mixture hardens add a half-pound block of TNT or
its equivalent as a primer.
      (3) Pour the mixture into a container.  Shrapnel material may be
added to the mixture if desired or attached on the outside of the
container to give a shrapnel effect.

   b. USE.  Because the wax and fertilizer may be molded into almost any
size or shape, it may be applied to agreat many demolition projects with
satisfactory effects.


It seems that it is "New and Improved by the U.S. Army!" (censored), chapters
1,4, almost all of 5, and at least 3 appendices have been eliminated.
I'm sorry (yeah right) about no pictures, but what was I to do?
I'd pay close attention to the Appendix D, there is a lot of useful
information in there.

                               'Til Next Time

                                Death Jester.

                     /                                 /
                     /         File 06 / NIA069        /
                     /  World News Sept 1990-Jan 1991  /
                     /    Face-To-Face Publications    /
                     /                                 /

International Symposium on the Prevention And Prosecution of Computer Crime
          HAVANA, Aug. 31 /PRNewswire/ -- A group of experts from around the
          world today unanimously expressed concern, at a symposium held in
          conjunction with the eighth United Nations Congress on the
          Prevention of Crime and Treatment of Offenders, over the lack of a
          comprehensive international strategy to address the serious risks
          posed by the vulnerability of computers and telecommunications to
          criminal activity and reckless misuse.
            "The rapid emergence of the technology and its penetration into
          virtually every aspect of economic, industrial and intellectual
          activity, have significantly outpaced the development of substantive
          standards and norms of behavior for the responsible use of
          computers," said Brian Bawden of Canada, the keynote speaker. "Yet,
          the profound needs of the world community will continue to contribute
          to the ready, if not eager, adoption of technological solutions."
            Ulrich Sieber of Germany, an expert in the emerging field of
          criminal information law, agreed.  "Increasing public dependence on
          computers has magnified the risk immensely," said Sieber, who pointed
          out the need for a close international harmonization of applicable
          law. "Inconsistent national laws and the current lack of mutual
          legal assistance treaties are contributing to the creation of
          `computer crime havens,' which in turn may provoke market
          restrictions and national barriers to the free flow of information,"
          said Sieber.
            Dr. Abdulrahman al-Shenaifi of Saudi Arabia, director general of
          the Saudi Arabian National Information Center, emphasized the global
          character of the problems, given the development of a worldwide
          information economy.  "Lack of international cooperation will not
          only lead to more computer-related crimes, it will imperil the free
          economic development of an international information market," said
            "It is important to realize that effective remedial action is just
          as important to the economic and social interests of developing
          nations as it is to the large industrialized countries," said Tamar
          Oppenheimer, O.C., a former assistant secretary general of the United
          Nations and the moderator of today's symposium.  "It is equally
          important to appreciate that action at the national level is not
          sufficient to achieve the necessary results -- political borders are
          largely transparent to this kind of crime and abuse, but the efforts
          of law enforcement are very much governed by them.  And the task is
          far from simple -- over 170 sovereign states constitute the
          international community."
            "This is everyone's problem -- users of technology, suppliers of
          technology and those who depend on its reliability without even
          realizing their dependency," said Enrique Duhau of Argentina,
          founder and president of two of Argentina's leading hardware and
          software suppliers.  "We in the technology supplier community must
          take a leadership role, or we will have to accept solutions imposed
          by others," said Duhau, a point amply supported in a paper by Chew
          Teck Soon of Singapore, a Coopers & Lybrand partner and an expert in
          information security
            The day's proceedings, titled "International Symposium on the
          Prevention and Prosecution of Computer Crime," will be published.
          The symposium was organized by the Foundation for Responsible
          Computing - Fondation pour une informatique responsable, a non-profit
          membership organization established to assist in the development of
          substantive national and international standards, laws, policies and
          guidelines for the responsible use of computers and
          telecommunications in the public and private sectors.
            /CONTACT:  Brian Bawden of Osler, Hoskin & Harcourt, 416-862-6407,
          or Tamar Oppenheimer of the Foundation for Responsible Computing
          (Austria), 43-222-725754/   16:26 EDT

LeeMah DataCom Offers Defeated Hackers Another Chance;
 Announcing The Second LeeMah Hacker Challenge
            HAYWARD, Calif.--(BUSINESS WIRE FEATURES)--You might think a
          computer security company that had successfully defeated 7,476
          hackers would rest on its laurels, but LeeMah DataCom Security Corp.
          is giving the international hacker community a second chance.
            During its second annual LeeMah Hacker Challenge, the company is
          daring all comers to try to beat its TraqNet security system by
          retrieving a secret message from TraqNet-protected computers in the
          offices of Coopers & Lybrand, the international accounting and
          consulting firm.
            LeeMah is even giving away the password.  John Tuomy, president of
          LeeMah, remarked, ``With most types of computer security, whether
          software or hardware based, the password is all that stands between
          an intruder and everything that is stored on the computer.  LeeMah's
          TraqNet system has several layers of security, so even with the
          password, the odds against a hacker penetrating the system are one
          in 72 quadrillion.''
            Beginning on Aug. 22, hackers and computer enthusiasts who wish to
          try their skill are invited to call either 212/307-6243 (New York),
          or 415/512-7170 (San Francisco).
            The password at either number is 533624.  LeeMah is offering a
          vacation for two to either Tahiti or St. Moritz to the first hacker
          who succeeds in electronically breaking into one of the protected
            Last year, in the first LeeMah Hacker Challenge, hackers were
          given the password and one week to try to retrieve the secret message
          stored on the computer.
            This year, LeeMah has extended the contest to two weeks (Aug. 22 -
          Sept. 5) and more telephone lines will be available, making it
          easier to get access to the protected computer lines.  The protected
          computers will reside in the New York and San Francisco offices of
          Coopers & Lybrand, which is overseeing the contest.
            ``When we announced our Challenge last year, a lot of hackers
          boasted that it was going to be child's play,'' said Tuomy.
            ``When we beat them, some of them said it was because we only had
          one phone line and they couldn't get through.  Now we're giving them
          their best shot.  Those vacations are still waiting.''
            He added, ``The problem with all the coverage of successful hacker
          break-ins is that some people might get the impression that these
          hackers are invincible, or that the FBI arrests of some of them will
          act as a deterrent.  The fact is that the government couldn't
          possibley arrest all the hackers out there, and certainly cannot
          guaranteee the safety of the nation's computers.  We believe strongly
          that computer crime can be prevented, but that businesses have to do
          it themselves.''
            Al Decker, Coopers & Lybrand's partner in charge of information
          technology security services, added, ``Confidential information,
          whether it's the specifications on a new product, a customer list, a
          financial report, or a medical diagnosis, is frequently a company's
          most valuable asset.  Threats to information systems and
          communication networks are real and they are growing.  That's why, in
          order to protect themselves and their customers, and to avoid severe
          business damage, companies of all types must safeguard information
          with the most effective means available.''
            The results of the Challenge will be announced on Sept. 6.
                     CONTACT: Dobbin/Bolgla Associates, New York
                       Gina Fiering or Peter Dobbin, 212/807-1400

AFSA Testifies On Fair Credit Reporting Measures
            WASHINGTON, June 12 /PRNewswire/ -- No new comprehensive changes
          to the Fair Credit Reporting Act (FCRA) are needed, stated Kenneth
          E. Hoerr, chairman and chief executive officer, USA Financial
          Services, Inc., Peoria, Ill., in testimony today on behalf of the
          American Financial Services Association (AFSA).
            Hoerr noted that the credit reporting system in the United States
          works to the benefit of consumers and creditors, and the principal
          law governing credit reporting, FCRA, "still remains a balanced
          approach to the area of credit reporting that has served the credit
          industry and served and protected the consumer well."  Hoerr
          testified today before the House Banking Committee's Subcommittee on
          Consumer Affairs and Coinage, on three bills introduced in the House
          to amend the act (H.R. 4213, H.R. 4122, and H.R. 3740).
            He said that AFSA shares the public concern about unauthorized
          access to consumer credit reporting files.  However, he pointed out
          that current federal law relating to computer crime includes stiff
          penalties for illegal access to computer files.  "Before this
          subcommittee considers enacting a new credit reporting law in the
          interest of consumer privacy, AFSA submits that more examination is
          needed as to how vigorously current laws ... are being enforced," he
            Hoerr also addressed the issue of prescreening -- a marketing
          technique whereby computerized lists of consumers are evaluated
          according to those most likely to desire and qualify for a
          particular product or service.  "We commend the chairman for
          recognizing in H.R. 4213 that prescreening should continue," Hoerr
          said.  "AFSA believes that all consumers benefit from efficient
          marketing techniques like prescreening through greater accessibility
          to consumer credit," he added.  For those consumers who do not wish
          to receive such offers, Hoerr suggested that "a voluntary program
          allowing consumers to opt-out of the marketing of such products may
          be a workable system" and added that such a program is already
          successfully operated by the Direct Marketing Association.  He noted
          that several national creditors are considering a voluntary program
          for credit solicitations and offered to have AFSA bring together
          interestd parties to discuss this concept.
            To assess the level of consumer complaints relating to crediting
          reporting issues, AFSA filed Freedom of Information/Freedom of
          Access Acts requests with the banking or financial institution
          agencies of all 50 states.  Hoerr noted that the responses to date
          from 31 states were included as an appendix to his testimony.  In
          reference to the responses received, Hoerr questioned the need for
          changes to the FCRA: "We have not discovered any significant amount
          of consumer complaints in this area and are confident that the
          additional states not yet responding will not provide any variance
          from our findings.
            "In sum, there seems to be no public unhappiness with the current
          system and no need for significant legislative change," he said.
            AFSA is the national trade association for consumer finance, sales
          finance, and diversified financial services firms that provide
          credit to consumers.  Its members hold one-quarter of all consumer
          credit outstanding.
            /CONTACT:  Judy Kent of the American Financial Services
          Association,  202-289-0400/  12:15 EDT

Illinois Resident Testifies On Credit Reporting Measures
            WASHINGTON, June 12 /PRNewswire/ -- No new comprehensive changes
          to the Fair Credit Reporting Act (FCRA) are needed, stated Peoria
          resident, Kenneth E. Hoerr, chairman and chief executive officer,
          USA Financial Services, Inc., Peoria, Ill., in testimony today on
          behalf of the American Financial Services Association (AFSA).
          Hoerr noted that the credit reporting system in the United States
          works to the benefit of consumers and creditors, and the principal
          law governing credit reporting, FCRA, "still remains a balanced
          approach to the area of credit reporting that has served the credit
          industry and served and protected the consumer well."  Hoerr
          testified today before the House Banking Committee's Subcommittee on
          Consumer Affairs and Coinage, on three bills introduced in the House
          to amend the act (H.R. 4213, H.R. 4122, and H.R. 3740).
            He said that AFSA shares the public concern about unauthorized
          access to consumer credit reporting files.  However, he pointed out
          that current federal law relating to computer crime includes stiff
          penalties for illegal access to computer files.  "Before this
          subcommittee considers enacting a new credit reporting law in the
          interest of consumer privacy, AFSA submits that more examination is
          needed as to how vigorously current laws ... are being enforced," he
            Hoerr also addressed the issue of prescreening -- a marketing
          technique whereby computerized lists of consumers are evaluated
          according to those most likely to desire and qualify for a
          particular product or service.  "We commend the chairman for
          recognizing in H.R. 4213 that prescreening should continue," Hoerr
          said.  "AFSA believes that all consumers benefit from efficient
          marketing techniques like prescreening through greater accessibility
          to consumer credit," he added.  For those consumers who do not wish
          to receive such offers, Hoerr suggested that "a voluntary program
          allowing consumers to opt-out of the marketing of such products may
          be a workable system" and added that such a program is already
          successfully operated by the Direct Marketing Association.  He noted
          that several national creditors are considering a voluntary program
          for credit solicitations and offered to have AFSA bring together
          interestd parties to discuss this concept.
            To assess the level of consumer complaints relating to crediting
          reporting issues, AFSA filed Freedom of Information/Freedom of
          Access Acts requests with the banking or financial institution
          agencies of all 50 states.  Hoerr noted that the responses to date
          from 31 states were included as an appendix to his testimony.  In
          reference to the responses received, Hoerr questioned the need for
          changes to the FCRA: "We have not discovered any significant amount
          of consumer complaints in this area and are confident that the
          additional states not yet responding will not provide any variance
          from our findings.
            "In sum, there seems to be no public unhappiness with the current
          system and no need for significant legislative change," he said.
            AFSA is the national trade association for consumer finance, sales
          finance, and diversified financial services firms that provide
          credit to consumers.  Its members hold one-quarter of all consumer
          credit outstanding.
            /CONTACT:  Judy Kent of the American Financial Services
          Association,  202-289-0400/ 13:47 EDT


[Editors Note: This is the Computer Crimes And Security Manual GOT is typing
 up by chapter, Chapter 4 can be found in this issue of NIA and 1-3 in previous
 NIA issues. -JD]

           MENLO PARK, Calif., Dec. 1 /PRNewswire/ -- The National Institute
          of Justice has published a new resource manual on computer crime in
          an effort to keep auditors, security experts and criminal justice
          agencies one step ahead of malicious hackers and other
          high-technology criminals.
            The "Criminal Justice Resource Manual on Computer Crime" provides
          the latest information on ways to deter, detect, investigate, and
          prosecute perpetrators of computer viruses, telephone intrusions into
          computer networks, programmed fraud, computer larceny, software
          piracy, and more.
            Prepared by information security expert Donn B. Parker and
          computer systems consultant David C. Smith of SRI International, the
          350-page document replaces an SRI-produced manual that has been one
          of the Justice Department's most popular publications but is now more
          than 12 years old.
            Using recently reported computer crime cases as illustrations, the
          updated manual describes the many subsequent advances in computer
          and communications technology -- and their misuse by perpetrators
          ranging from juvenile hackers to career criminals and terrorists.
            Of particular interest to auditors, investigators, and
          prosecutors, the manual explains how to obtain valid evidence of a
          crime, for example, through the design of audit logs that will
          produce records that hold up in court.
            The manual also includes detailed descriptions of the newest
          federal and state laws on computer crime; a glossary of terminology;
          and recommendations for fostering multidisciplinary cooperation and
          reporting of suspected computer crimes.
            A broad-based research and consulting organization, SRI houses one
          of the world's leading consultancies on information security and
          computer crime.  It also operates the International Information
          Integrity Institute, which helps 50 of the world's largest
          corporations develop effective information security practices.
            The new computer crime manual was produced for the U.S. Department
          of Justice by SRI under subcontract to Abt Associates.
            To order the new manual, write to the National Institute of
          Justice, Box 60900, Rockville, Md., 20850.  Or call, 800-851-3420 or
          301-251-5500.  Ask for: "Computer Crime:  Criminal Justice Resource
          Manual," NCJ 118214.  $16.50.
          /CONTACT:  Suzanne Dillon of SRI International, 415-859-2304/ 17:27EST

Biometric Cops: High Tech Securit Guards are Putting a New Lock on Security
            SANTA ANA, Calif.--(BUSINESS WIRE)--Viruses, worms, hackers --
          intruders who forced entry into vulnerable computer stystems cost
          businesses more than $500 million last year in the United States
          alone, according to the Los Angeles-based National Center for
          Computer Crime Data.
            That's a statistic likely to increase dramatically as computer
          usage continues to escalate.
            To the rescue, though, is a new breed of security guard, armed
          with biometric technology, to restrict access to everything from
          corporate data bases and secured areas to cold cash and FAX machines.
          And, the phrase ``hands up|'' suddenly takes on new meaning to make
          sure who's who.
            Biometrics are the physical human traits that make people unique.
          To verify a person's identity, biometric cops can measure hand
          shape, fingerprints, voice patterns, retina geometry, signature
          dynamics and keystroke rhythms -- all virtually foolproof
            To be sure, biometric security is still in its infancy with less
          than two dozen companies in the United States, Europe and Japan
          actively marketing products.  Yet, industry watchers predict the
          market will exceed $25 million by 1991, rocketing along at a 40
          percent annual growth rate.
            Beaming Science Fiction Down to Earth
            It's thought the Greeks, circa 2,000 B.C., were the first to bar
          the door with lock and key.  Now, 4,000 years later, traditional
          locking devices still comprise a majority of the multibillion dollar
          access control systems market around the world.
            True, today's keys might be magnetic-striped tokens or
          microchip-embedded ``smart'' cards.  But, just as the Greeks of
          yesteryear must have discovered to their dismay, keys -- technology
          notwithstanding -- can be lost, stolen or borrowed.  Open sesame|
            Not a problem aboard the Starship Enterprise.  The vehicle's
          computer would verify Mr. Spock's handprint before allowing him
          access to its secrets.  Now, back to the future and down to earth,
          examining physical hand characteristics is one of six currently
          available biometric technologies that offer near fail-safe identity
          verification for subsequent access:
            Hand geometry measures finger length, skin translucency, palm
            thickness and shape;
            Fingerprint systems analyze the unique ridges, loops and
            bifurcations of finger and thumb topology;
            Retina scans read the size, location and pattern of blood vessels
            in the back of the eye;
            Signature dynamics tracks the motions used in the writing process,
            rather than the signature itself;
            Keystroke analysis compares the individual patterns and rhythms of
            typing repetitive character groups;
            Voice verification maps the actual physiology that produces
            not merely sounds or pronunciation.
            In all cases, these biometric portraits are captured by sensor
          devices, converted digitally into algorithms and compared with
          pre-stored authorized profiles.  Access is denied unless a match is
          made.  Additionally, a detailed audit trail automatically documents
          all the particulars.
            Not Being There
            Most of these technologies require physical presence, contact or,
          at least, proximity:  the hand on a sensor pad, the eye into a
          scanner, fingers over a keyboard.  Only one, voice verification,
          offers the opportunity for identification and access from remote
            Indeed, voice verification can handle physical access control for
          buildings, vaults, computer terminals of the executive washroom.
          But, its added value, particularly in today's ``telecommunicating''
          world, is in not being there.
            In fact, it's incalculable how much business is conducted by
          telephone from the desk, from phone booths, from cars and, for that
          matter, from briefcases.  For a rapidly growing number of instances,
          it's crucial to know exactly who's on the line:  bank fund
          transfers, confidential corporate information, stock and commodity
          trades or computer access, just to name a few.  And the horror
          stories abound, healined by teenaged hackers, computer viruses,
          mountains of junk FAX mail and electronic embezzlement.
            Existing telephone security methods consist primarily of passsword
          and dialback systems.  But just like keys, passwords easily can fall
          into the wrong hands.  Dialback procedures only work when the caller
          always originates contact from the same location.  Neither,
          furthermore, keeps fail-safe records of each transaction, completed
          or not.
            Voice Verification Speaks Out
            Until now, voice verification security has been limited to
          dedicated, stand-alone systems confined to local sites.  Used
          primarily to police door entry and exit, these localized systems
          compete with other biometrics such as hand, fingerprint and retinal
          scanners, as well as with traditional badge readers and the old
          standby, armed guards.
            However, Ver-A-Tel, from Alpha Microsystems, Santa Ana, Calif.,
          took a giant step forward as the only commercially available
          biometric security system that can be used over standard dial-in
          telephone lines. A typical Ver-A-Tel microcomputer-based system
          handles as many as 5,000 callers at just about $4 each, connects to
          virtually any PBX (private branch exchange) and scores 99.88 percent
            With Ver-A-Tel, callers need enroll only once by simply recording
          their voices -- using a brief phrase of their choice -- over a
          standard telephone.  Then, when access is sought, the PC-AT
          compatible personal computer scans and analyzes the caller's voice
          and compares it to the authorized vocal pattern on file.
          (Incidentally, Ver-A-Tel automatically adjusts for long-term changes
          in the users' voices.)
            Uniquely, enrollment, access request and verification occur over
          local or long-distance telephone lines.
            When verification is successful, the caller gets through --
          directly or to one of nine pre-selected extensions that could be a
          computer terminal, a FAX machine, an encryption device or a
          higher-security telephone.  The answering person or device is told
          the caller has been verified.  If the caller can't be verified after
          three attempts, Ver-A-Tel politely disconnects and documents the
            Alpha Micro's Ver-A-Tel produces a comprehensive audit trail,
          including who was verified and when, rejections, where the caller
          was transferred, busy signals, whether a modem was detected, or if
          someone answered by voice.  In addition, the centralized access
          control feature enables administrators to instantly remove
          authorization regardless of caller location.
            For guarding secured areas on site, Ver-A-Tel centrally controls
          as many as 250 door locks connected over existing telephone wiring.
          In addition, physical access authorization can be integrated with
          the dial-in enrollment database to effectively and efficiently
          consolidate the entire security system.  The result?  A unified force
          of caller-friendly biometric cops on the beat armed appropriately for
          the Electronic Age.
                     CONTACT:  Alpha Microsystems, Santa Ana
                               Mike Grimes, 714/641-6266
                               Gary Nelson, 714/641-6275
                               Hill and Knowlton, Newport Beach
                               Michaela Brohm, 714/752-1106

Virus Maker Who Hit NASA Computers May be Probed
Toronto Star   (TOR)
Edition:  HOLIDAY
Page:     B3
Origin:   DALLAS
          (Copyright The Toronto Star)
          ---      Virus maker who hit NASA computers may be probed        ---
           DALLAS (Special) - The U.S. space agency has asked Dallas
          authorities to investigate and try to prosecute a former
          Electronic Data Systems Corp. employee suspected of creating a
          computer virus that attacked hundreds of government, university,
          business and even congressional computers, police have reported.
          Since 1988, the widespread electronic bug called Scores has
          infected and wiped out information in Apple Macintosh personal
          computers used by the National Aeronautics and Space
          Administration, the Environmental Protection Agency and other
          government agencies.
          If Dallas authorities believe the evidence is sufficient, the
          suspect could be charged with a third-degree felony under the
          state's five-year-old computer crime law.
          NASA investigators believe a disgruntled employee of EDS, a Plano,
          Texas-based computer services and data processing firm, created
          the Scores virus, planted it in his employer's computers and then
          resigned before the infection broke out.

New Crime Busters Tote Calculators
Credit:   CP
Toronto Star   (TOR)
Edition:  HOLIDAY
Page:     B5
Origin:   WINNIPEG
          (Copyright The Toronto Star)
          ---             New crime busters tote calculators               ---
           WINNIPEG (CP) - Forensic accountant.
          The phrase crops up with increasing frequency in stories about
          corporate crime or business bungling and you can forget the
          bean-counter stereotype about a life of bottom-line boredom.
          The exploits of forensic accountants read like a hit television
          show, as they nail fraud artists, conduct autopsy-like audits to
          unravel money-laundering schemes and act as star witnesses in
          cases that get headlines.
          Take, for instance, Michael Mumford, manager of the Lindquist
          forensic and investigative accounting practice for Peat Marwick
          Thorne in Winnipeg.
          Late one evening he gets the call that his help is needed in a raid
          on a Great Lakes commercial fishing operation.
          The next morning, there he is, armed with his calculator alongside
          real gun-toting crime busters about to storm the fishing lodge.
          "I think I've got the sexiest side of it," Mumford says of his
          niche in the accounting world.
          "This is definitely not a scenario of what an accountant normally
          Applying accounting knowledge to legal problems is not new but the
          term forensic accountant is still far from a household phrase.
          Even Mumford says he had to ask what it was when he first heard the
          term in 1985 and he still has to explain the nature of his work to
          his colleagues at the firm.
          "Forensics has been around as long as accounting," says Alan
          Martyszenko of Price Waterhouse's financial services group.
          "But the term is relatively new. It used to be you were an
          investigative accountant."
          No matter what you call them, essentially what you get when you
          call on a forensic accountant is a combination of detective and
          auditor, who will come up with the story behind the numbers.
          Peat Marwick Thorne hypes its forensic team with a catchy case
          study entitled Bloodhounds of the Bottomline.
          "We try and shed some light and find out what really occurred,"
          Mumford says.
          Insurance claims, regulatory matters, conflicts of interest,
          shareholder disputes or the smell of kickbacks all draw the
          forensic accountant.
          "Every case is different," says Walter Dubowec, managing partner of
          Deloitte & Touche.
          "If you have a nose for that kind of work you can zero in and look
          past the forest for what needs to be done."
          For forensic accountants, what needs to be done is to provide the
          kind of information and analysis that will stand up in court.
          That's where the word forensic - meaning of or used in courts of
          law - comes in.
          Inspector Hank Moorlag of the RCMP commercial crime section in
          Winnipeg suggests their importance cannot be overemphasized in
          some cases, such as the recent charges of illegal trading that
          rocked the Winnipeg Commodity Exchange, where explaining the
          numbers is what really counts.
          Mumford says he sometimes feels like Sherlock Holmes.

Angry Former Employee Probed In Computer Virus Case
Credit:   Associated Press
Edition:  2 STAR
Section:  A
Page:     28
Origin:   DALLAS
          (Copyright 1990)
             DALLAS - A man suspected of creating a computer virus that
          infected personal computers at NASA and other government agencies is
          being investigated by the Dallas police, officials said.
              The unidentified suspect, who has not been arrested, is a
          disgruntled former employee of Electronic Data Systems Corp., police
          Sgt. Gary White told the Dallas Times Herald. EDS is based in
              White said the suspect, who resigned from EDS shortly before the
          virus broke out, could be charged with a third-degree felony under
          the Texas computer crime law.
              Police are investigating the suspect and will decide in late
          January or February whether to file charges using evidence turned
          over by NASA investigators, White said.
              ``At this point we're just gathering as much information as we
          can on who has been infected, looking over case reports, seeing if it
          can be prosecuted under state law,'' White said.
              Federal authorities decided the case could be better prosecuted
          at the local level because of difficulty in proving the suspect's
          intent to contaminate government computers.
              The virus, known as Scores, was among the first in the late 1980s
          to draw attention to the susceptibility of government computer
          networks to remote tampering.
              The program, which affects only MacIntosh computers, lies dormant
          before gradually destroying files, systems and hard disks.
              The virus attacked NASA computers in Washington, Maryland and
          Florida for five months in 1988. It also attacked computers at the
          Environmental Protection Agency, the National Oceanic and Atmospheric
          Administration and the U.S. Sentencing Commission.
              NASA and FBI investigators traced the virus to EDS because it was
          designed to attack two programs used exclusively by the company.
              ``It was by no means one of the more destructive viruses. It was
          widespread,'' said John McAfee, chairman of the Computer Virus
          Industry Association.
              White said the virus has been purged from government computers
          but continues to infect private systems.
              ``You can go in and erase them out of your system, but somebody
          always has a disk in a desk drawer or somewhere they haven't used for
          a while,'' White said. ``They don't think and stick it back in.''

Prosecution of Computer Virus Creator Urged
Credit:   Dallas Morning News
The San Diego Union and Tribune (SDU)
Pub:      UNION
Edition:  1,2,3,4,5,6
Section:  BUSINESS
Page:     D-1
Origin:   DALLAS
          (Copyright 1990)
          DALLAS -- The National Aeronautics and Space Administration has asked
          Dallas authorities to investigate and try to prosecute a former
          Electronic Data Systems Corp. employee suspected of creating a
          computer virus that attacked hundreds of government, university,
          business and even congressional computers, police said yesterday.
          Since 1988, the widespread electronic bug called Scores has infected
          and wiped out information in Apple Macintosh personal computers used
          by NASA, the Environmental Protection Agency, the National Oceanic
          and Atmospheric Administration and the U.S. Sentencing Commission.
          Mainly by way of publicly accessible electronic bulletin boards, the
          infection spread to computers in universities and U.S. and European
          companies. The virus destroyed files, made systems shut down or
          "crash" or ruined hard disks that store valuable data and a variety
          of programs such as word processing, spreadsheets or graphics.
          "It's even gotten into some of the congressional computers used in
          Washington, D.C., and in the home (district) states," said Dallas
          police Sgt. Gary White.
          White is one of two officers who will investigate the case if the
          Dallas Police Department gives the OK.
          The suspect, whose identity has not been released, could be charged
          with a third-degree felony under the state's 5-year-old computer
          crime law.
          NASA investigators believe a disgruntled employee of EDS, a suburban,
          Plano, Texas-based computer services and data processing firm,
          created the Scores virus, planted it in his employer's computers and
          then resigned before the infection broke out.

Suspect Targeted in Computer Virus Case
Credit:   AP
Edition:  FINAL
Section:  CITY/STATE
Page:     C3
Origin:   DALLAS
          (Copyright 1990)
              DALLAS (AP) - A man suspected of creating a computer virus that
          infected personal computers at NASA and other government agencies is
          being investigated by the Dallas police, officials said.
              The unidentified suspect, who has not been arrested, is a former
          employee of Electronic Data Systems Corp., police Sgt. Gary White
          told the Dallas Times Herald. EDS is based in Dallas.
              White said the suspect, who resigned from EDS shortly before the
          virus broke out, could be charged with a third-degree felony under
          Texas computer crime law.
              Police are investigating and will decide in late January or
          February whether to file charges using evidence turned over by NASA
          investigators, White said.
              Federal authorities decided the case could be better prosecuted
          at the local level because of difficulty in proving the suspect's
          intent to contaminate government computers.
              The virus, known as Scores, was among the first in the late 1980s
          to draw attention to the susceptibility of government computer
          networks to remote tampering.
              The program, which affects only Macintosh computers, lies dormant
          before gradually destroying files, systems and hard disks.
              The virus attacked NASA computers in Washington, Maryland and
          Florida for five months in 1988. It also attacked computers at the
          Environmental Protection Agency, the National Oceanic and Atmospheric
          Administration and the U.S. Sentencing Commission.
              NASA and FBI investigators traced the virus to EDS because it was
          designed to attack two programs used exclusively by the company.
              "It was by no means one of the more destructive viruses. It was
          widespread," said John McAfee, chairman of the Computer Virus
          Industry Association.
              White said the virus has been purged from government computers,
          but continues to infect private systems.

Former EDS Employee Suspected of Planting Federal Computer Virus
Credit:   AP
Edition:  CENTEX
Section:  CENTEX
Page:     C3
Origin:   DALLAS
          (Copyright 1990)
              DALLAS (AP) - A man suspected of creating a computer virus that
          infected personal computers at NASA and other government agencies is
          being investigated by the Dallas police, officials said.
              The unidentified suspect, who has not been arrested, is a former
          employee of Electronic Data Systems Corp., police Sgt. Gary White
          told the Dallas Times Herald. EDS is based in Dallas.
              White said the suspect, who resigned from EDS shortly before the
          virus broke out, could be charged with a third-degree felony under
          Texas computer crime law.
              Police are investigating and will decide in late January or
          February whether to file charges using evidence turned over by NASA
          investigators, White said.
              Federal authorities decided the case could be better prosecuted
          at the local level because of difficulty in proving the suspect's
          intent to contaminate government computers.
              The virus, known as Scores, was among the first in the late 1980s
          to draw attention to the susceptibility of government computer
          networks to remote tampering.
              The program, which affects only Macintosh computers, lies dormant
          before gradually destroying files, systems and hard disks.
              The virus attacked NASA computers in Washington, Maryland and
          Florida for five months in 1988. It also attacked computers at the
          Environmental Protection Agency, the National Oceanic and Atmospheric
          Administration and the U.S. Sentencing Commission.
              NASA and FBI investigators traced the virus to EDS because it was
          designed to attack two programs used exclusively by the company.
              "It was by no means one of the more destructive viruses. It was
          widespread," said John McAfee, chairman of the Computer Virus
          Industry Association.
              White said the virus has been purged from government computers,
          but continues to infect private systems.

Bulgarians Adept at Breeding Lethal Computer Bugs // U.S. Military
 Network Among Those Attacked by Virus
Byline:   Chuck Sudetic
Credit:   New York Times
Edition:  METRO
Section:  NEWS
Page:     18B
Origin:   Sofia, Bulgaria
          (Copyright 1990)
          Bulgaria has become the breeding ground of some of the world's most
          lethal computer viruses, programs that are maliciously designed to
          spread through computer memories and networks and at times destroy
          valuable stored information such as bank and medical records.
              "We've counted about 300 viruses written for the IBM personal
          computer; of these, 80 or 90 originated in Bulgaria," said Morton
          Swimmer of Hamburg University's Virus Test Center, which specializes
          in diagnosing and curing Eastern European computer viruses.
              "Not only do the Bulgarians produce the most computer viruses,
          they produce the best."
              One Bulgarian virus, Dark Avenger, has infected U.S. military
          computers, said John McAfee, who runs the Computer Virus Industry
          Association, which is based in Santa Clara, Calif., and tracks
          viruses for computer hardware and software companies.
              "I'm not saying that any super-secure computers have been
          infected," he said. "But the U.S. Defense Department has about
          400,000 personal computers and anyone who has that many machines has
          a 100 percent probability of being hit."
              "It is causing some people in sensitive places a lot of
          problems," a Western diplomat said, "and they are very reluctant to
          admit they have them."
              "I would say that 10 percent of the 60 calls we receive each
          week are for Bulgarian viruses and 99 percent of these are for Dark
          Avenger," McAfee said, adding that the virus has attacked computers
          belonging to banks, insurance and accounting companies,
          telecommunications companies and medical offices.
              "I've had a lot of calls from Frankfurt," Swimmer said. "One
          bank was very nervous about it, but I can't reveal its name for
          obvious reasons."
              Several experts say the spread of the Bulgarian viruses is less
          the result of activities by the secret police than it is the
          consequence of having developed a generation of young Bulgarians
          whose programming skills found few outlets beyond hacking
              A decade ago, the country's Communist leaders decided to make
          Bulgaria an Eastern-bloc Silicon Valley, said Vesselin Bontchev, a
          Bulgarian computer specialist.
              Bulgarian factories began producing computers and the government
          placed them in workshops, schools and institutes. Many computers,
          however, stood idle because people did not know how to apply them or
          lacked an economic interest in doing so.
              "People took office computers home and their children began
          playing on them," he said, adding that buying a private computer was
          almost impossible.
              These children quickly acquired software-writing skills, but had
          little or no chance to apply them constructively, he said.
              They began bootlegging copyrighted Western software, especially
          computer games, by overriding devices written into the software to
          prevent it from being copied. Then they started altering the
          operating systems that drive the computer itself.
              "From there it was one small step to creating viruses that
          attack files when they are acted on by the operating system," he
              Bontchev estimated there are only about a dozen young Bulgarian
          computer programmers who have written the viruses that have caused
          all the trouble.
              "Computer hackers here write viruses to show who is who in
          computer science in Bulgaria, to find a place in the sun," said Slav
          Ivanov, editor of a Bulgarian computer magazine. "The young computer
          people just don't rank in our society. They don't receive enough
              The average wage of a software writer in Bulgaria is about $30 a
          month, Bontchev said.
              One virus designer, however, acknowledged that revenge was also
          a factor.
              "I designed my first computer virus for revenge against people
          at work," said Lubomir Mateev, who helped write a nondestructive
          virus known as Murphy, which shares many of Dark Avenger's tricks.
          "Our first virus made all the computers at work send out a noise
          when they were switched on."
              Mateev, 23, said he collaborated with Dark Avenger's designer
          last spring on a new virus that is harder to diagnose and cure
          because it is self-mutating.
              "Dark Avenger's designer told me he would take a job as a
          janitor in a Western software firm just to get out of Bulgaria," he
          said. Attempts during several months to get in touch with Dark
          Avenger's creator proved fruitless.
              For now, Bulgaria's computer-virus designers can act with
          complete legal immunity.
              "We have no law on computer crime," said Ivanov, whose magazine
          offers free programs that cure known Bulgarian viruses. "The police
          are only superficially interested in this matter."
              Bulgaria's secret-police computers have also been infected, said
          a well-placed Bulgarian computer expert.
              Dark Avenger has also spread to the Soviet Union, Britain,
          Czechoslovakia, Poland and Hungary, Bontchev said, adding, "I've
          even had one report that it has popped up in Mongolia."
              "The Dark Avenger is the work of a Sofia-based programmer who is
          known to have devised 13 different viruses with a host of different
          versions," Bontchev said. "He is a maniac."
              Bontchev said he was almost certain Bulgaria's government was
          not involved with Dark Avenger.
              "A computer virus cannot be used as a weapon because it cannot
          be aimed accurately and can return like a boomerang to damage
          programs belonging to the creator himself," he said. "It can be used
          only to cause random damage, like a terrorist bomb."
              Unlike less-infectious viruses, Dark Avenger attacks computer
          data and programs when they are copied, printed or acted on in other
          ways by a computer's operating system, Bontchev said. The virus
          destroys information every 16th time an infected program is run.
              A virus can spread from one computer to another either on floppy
          disks or through computer modems or computer networks, he said. Many
          viruses are spread at computer fairs and through computer
          bulletin-board systems where enthusiasts exchange information over
          the telephone.
              Legislation on computer crime will be introduced in parliament
          once a criminal code is adopted, said Ilko Eskanazi, a parliamentary
          representative who has an interest in the virus issue.
              "We are now seeing viruses emerging on entirely new ground in
          Eastern Europe," Bontchev said.
              "Things may get much worse before they improve," he warned. "The
          first law of computer viruses is that if a virus can be made, it
          will be. The second law is that if a computer virus cannot be made,
          it will be anyway."

Edition:  FINAL
Section:  NEWS
Page:     10A
Category: Across the USA
          (Copyright 1990)
           SAN FRANCISCO - Auto insurance rate cuts for good drivers, rate
          hikes up to 40% for others were OK'd by Insurance Commissioner Roxani
          Gillespie. Insurers may use new rates in '91 - ending freeze in
          place since '89 passage of Proposition 103 insurance rules. ...
          BERKELEY - 386 absentee ballots in city's mayoral race cannot be
          counted because they arrived day after Dec. 4 election, judge ruled.
          Loni Hancock beat challenger Fred Weekes by 77 votes. ... HAYWARD -
          Peace activist Susan Rodriguez, 36, was convicted of felony
          vandalism, burglary for using sledge hammer to smash computers at
          Physics Intl. Firm does defense work, officials said.

Edition:  FINAL
Section:  NEWS
Page:     10A
Category: Across the USA
          (Copyright 1990)
           BOISE - Salmon protection on Columbus, Snake rivers is main goal of
          new 30,000-member coalition of business, environmental, sport groups,
          coordinator said. Group will push for changes at federal dams to
          stop salmon deaths. ... NAMPA - Zilog Inc. - computer chip maker -
          will pay $3,959 fine for violating labeling laws on hazardous waste
          containers, Dept. of Health and Welfare spokesman said.

Bulgaria Has One World-Class Export
Byline:   Chuck Sudetic
Ottawa Citizen   (OTT)
Edition:  Final
Section:  NEWS
Page:     A2
Category: NEWS
          Origin:   SOFIA, Bulgaria
          (Copyright The Ottawa Citizen)
          ---            Bulgaria has one world-class export               ---
           Not only do the Bulgarians produce the most computer viruses,"
          says a Hamburg University expert on the matter, "they produce the
           Morton Swimmer and his Virus Test Centre have counted about 300
          programs that attack IBM personal computers -- spread through
          their computer memories and, at times, destroy valuable
          information stored there, like bank or medical records.  Eighty or
          90 of them originated in Bulgaria.
           The most notable, called Dark Avenger, has attacked banks,
          insurance and accounting companies, telecommunications firms and
          medical offices.
           It has even infected American military computers, according to
          John McAfee, who runs the Computer Virus Industry Association in
          Santa Clara, Calif.
           "I'm not saying that any super-secure computers have been
          infected, but the U.S.  Defence Department has about 400,000
          personal computers, and anyone who has that many machines has a
          100-per-cent probability of being hit."
           Perhaps it wasn't the most ingratiating way of doing it, but
          Bulgaria has at last shown Western countries it can compete with
          them on their own terms.
          Hackers without a cause
           Experts say Bulgarian viruses don't spring from some secret-police
          plot but are the consequence of the country's former Communist
          leaders having developed a generation of young people with great
          programming skills but few outlets beyond hacking.
           A decade ago, Bulgaria decided to make itself into the East bloc's
          Silicon Valley, says Vesselin Bontchev, a Bulgarian computer
           Factories began churning out computers, and the government
          introduced them into workshops, schools and institutes.  Many of
          them, however, stood idle because people did not know how to apply
          them or lacked an economic interest in doing it.
           So, "people took office computers home, and their children began
          playing on them," Bontchev says.  These children quickly acquired
          software-writing skills, but had little or no chance to apply them
           They began bootlegging copyrighted Western software, especially
          computer games, by overriding devices written into the software to
          prevent it from being copied.  Soon they were altering the
          operating systems that drive the computer itself.
           "From there it was one small step to creating viruses that attack
          files when they are acted on by the operating system," Bontchev
           He estimates no more than a dozen young Bulgarian computer
          programmers are responsible for the viruses that have caused all
          the trouble.
           "Computer hackers here write viruses to show who is who in
          computer science in Bulgaria, to find a place in the sun," says
          Slav Ivanov, editor of a Bulgarian computer magazine.  "The young
          computer people just don't rank in our society.  They don't
          receive enough money."
           The average wage of a software writer in Bulgaria is about $30 a
          month, Bontchev says.
           One virus designer, however, says that revenge plays a large part
          in Bulgaria's viral productivity.
           "I designed my first computer virus for revenge against people at
          work," says Lubomir Mateev, who helped write a non-destructive
          virus known as Murphy, which shares many of Dark Avenger's tricks.
           "Our first virus made all the computers at work send out a noise
          when they were switched on."
           Mateev, 23, says he collaborated with Dark Avenger's designer last
          spring on a new virus that is harder to diagnose and cure because
          it is self-mutating.
           "Dark Avenger's designer told me he would take a job as a janitor
          in a Western software firm just to get out of Bulgaria," he says.
          Attempts during several months to get in touch with Dark Avenger's
          creator proved fruitless.
           Bulgaria's secret-police computers have also been infected, says a
          well-placed Bulgarian computer expert, who spoke on condition of
          anonymity and refused to elaborate.
           Dark Avenger has spread to the Soviet Union, Britain,
          Czechoslovakia, Poland and Hungary, Bontchev says.  "I've even had
          one report that it has popped up in Mongolia."
           He is almost certain Bulgaria's government had nothing to do with
          Dark Avenger's success.
           "A computer virus cannot be used as a weapon because it cannot be
          aimed accurately and can return like a boomerang to damage
          programs belonging to the creator himself," he says.  "It can be
          used only to cause random damage, like a terrorist bomb."
           Unlike less infectious viruses, Dark Avenger attacks computer data
          and programs when they are copied, printed or acted on in other
          ways by a computer's operating system, Bontchev says.  The virus
          destroys information every 16th time an infected program is run.
          There's no law against it
           For now, Bulgaria's computer virus designers can act with complete
          legal immunity.
           "We have no law on computer crime," says Ivanov, whose magazine
          offers free programs that cure known Bulgarian viruses.  "The
          police are only superficially interested in this matter."
           Legislation on computer crime will be introduced in parliament
          once a criminal code is adopted, says Ilko Eskanazi, a
          parliamentary representative who has taken an interest in the
          virus issue.
           "We are now seeing viruses emerging on entirely new ground in
          Eastern Europe," Bontchev says.
           "Things may get much worse before they improve," he warns.  "The
          first law of computer viruses is that if a virus can be made, it
          will be.  The second law is that if a computer virus cannot be
          made, it will be anyway."

County's FBI Staff Keeps Up With Crime // Work Now Revolves Around
 Fraud and Computer Cases
Byline:   Steve Eddy:The Orange County Register
Edition:  EVENING
Section:  METRO
Page:     b01
Origin:   SANTA ANA, CA
TX        The walls of the Orange County office of the FBI feature the usual
          mug shots of wanted fugitives -- kidnappers, terrorists, bank
             But there are other photographs too, annual "team photo" shots of
          the office staff taken over the past dozen years.
             Each picture has more smiling faces than the year before.
             As crime has evolved into high technology, massive investment
          swindles and international terrorism, the bureau has evolved with it.
          What was once a one-man cubbyhole in the 1950s is now the largest FBI
          satellite office in the nation, with more than 60 full-time special
          agents and 25 support personnel.
             Gone, too, are the "do everything" special agents of the '50s and
          '60s, who have been replaced by specialists.
             "We tended to do a little bit of everything," said Jim Conway, 63,
          who went to work for the FBI in 1952 and moved to the Santa Ana
          office in 1967. "There were eight or nine agents assigned to the
          office and no clerical help at all.  We all sat in one room and got
          to know each other very well. I have been to (the current
          headquarters) a couple of times and it boggles my mind."
             While FBI agents in Orange County still do their share of chasing
          down bank robbers, drug dealers and other criminals, more than half
          of the workload involves fraud and computer crime.
             The expansion reflects a greater focus on white-collar crime, said
          Jim Annes, recently retired supervisor of the Santa Ana office, who
          now works for a private security firm.
             Annes said that emphasis started with the Carter administration,
          as the demographics of Orange County were changing.
              "There were lots of financial centers going up," Annes said.
          "Orange County began attracting a lot of flashy con men."
             The mid-1980s brought agents the largest bank fraud case in US
          history. Bank of America alone lost an estimated $95 million in a
          scheme involving sale of fraudulent mortgage loans. It took six
          years to investigate and prosecute the case.
             "There are agents who devoted 25 percent of their careers to that
          one," Annes said.
             New investigations of fraud, including the continuing Lincoln
          Savings & Loan investigation, have taxed local FBI agents. Help is
          on the way.
             Bucky Cox, current senior supervisory resident FBI agent, said a
          "significant increase" in white-collar-crime staffing is expected
          within the next few months, although the exact number of new
          personnel is not known.
             The local office continues to devote resources to bank robbery,
          drugs, organized crime, counterterrorism and other matters.
              Cox said terrorism may be foreign or domestic.
             "In domestic terrorism, we look at organizations who have espoused
          violence as a group, or are involved in racial incidents," he said.
             Foreign terrorism hit home in 1985, when a bomb killed
          Arab-American activist Alex Odeh in his Santa Ana office. The FBI
          investigated and identified a former Jewish Defense League member as
          a suspect. The man, residing in Israel, has not been formally
             Counterintelligence comes into play because of Orange County's
          huge defense industry -- with plenty of technical secrets to be
          stolen by foreign agents.
             The basic job of FBI agents is to conduct interviews and present
          criminal cases to the US Attorney's Office for prosecution.
             Often, agents are in contact with their counterparts in other
          parts of the nation. Cox said that was the situation last month when
          three teen-age girls were kidnapped from a Michigan township by two
              One of the suspects, David Alan House, 33, was a former Orange
          County resident.
             "It started with a late-night call from a supervisor in Michigan
          to my house," Cox said. "He said it (looked) like Orange County was
          going to play an important part in the case."
             On his way to work the next morning, Cox got a call on his car
          phone and learned that, as of midnight, the pair was in Las Vegas.
          By this time, all three victims had been located.
             One of the three kidnapped teen-agers was found bound, but
          unharmed, in a Las Vegas hotel room. The other two were released in
             "It was obvious that (the kidnappers) were coming here," Cox said.
          "We had agents out on the streets all that day checking places where
          he had lived and worked, talking with close associates, looking in
          bars he used to frequent. That's the kind of thing you do -- talk to
          people who will tell you that the guy is likely to go to
          such-and-such a place or see such-and-such a person."
              That same evening, Nov. 27, House was arrested outside a Santa
          Ana towing company where he once worked. He apparently had come
          there to see his former boss. The second suspect still is being
             Phil Hanlon, now 66, joined the FBI in 1951, serving in various
          locations before being assigned to the Santa Ana office in 1963. He
          retired in 1978.
              In earlier days, Hanlon and other retired agents said, the thrust
          of work included bank robbery and rounding up military deserters.
             "It was a different world then," Hanlon said. "People wanted to
          come here because of the rural atmosphere. It was a much less
          complicated existence. You didn't have the narcotics element, the
          computer crime."
             "Nowadays, crooks are slick -- they're smart in the brain," said
          retired Special Agent Bill Carroll, who worked in the Santa Ana
          office from 1963 to 1978. More agents than ever spend their days
          poring over records of a failed bank.
             That wasn't always so, Carroll recalled.
             "One time we were investigating an unlawful flight case and had
          been looking for this guy for about a month," Carroll said. "He was
          labeled armed and dangerous and said he would never be taken alive.
          We got a tip he was going to go see his girlfriend in Laguna Beach.
             "Sure enough, his car drove up in front of her house and she got
          in," Carroll said. "We followed, and he drove into this empty
          parking lot. We sort of snuck up on them, and he was, well ... they
          were having sex in there. He had a gun on the floor, but no chance
          to get to it."
             In his day, Carroll said, "Everybody basically had to know
          everybody else's work. You had to be able to handle a real broad
          spectrum of cases. Things weren't as complex as they are now."
             Today, the heavy concentration on white-collar crime has attracted
          a new breed of agents -- young attorneys and certified public
          accountants who possess skills that are essential to untangling the
          intricate web of fraud, Cox said.
             Unfortunately, he said, many don't stay long, principally for
          financial reasons.
             An FBI agent right out of the training facility at Quantico, Va.,
          has a starting pay of about $28,000 a year, moving to $44,000 within
          about three years. Current top base pay for a journeyman agent is
          $57,650. Cox said that scale puts FBI agents in the bottom 5 percent
          of police agencies in Southern California.
             "You don't come in expecting to be well-paid," Annes said.
          "You'll have enough money for a steak and a beer, but you're always
          going to be counting the pennies. If money were the object, nobody
          would be in the FBI."
              Some of the appeal, Cox said, comes from actual working
             "Special agents begin work in a suit and tie," Cox said. "They
          aren't going to go out in a patrol car. They probably won't get spat
          on or have to roll around in the street with a drunk. They don't
          have to work in a jail. There are opportunities to travel."

1st Computer Pirate Convicted In Quebec Under Criminal Code
Credit:   GAZETTE
Montreal Gazette   (GAZ)
Edition:  FINAL
Section:  BUSINESS
Page:     C1
          (Copyright The Gazette)
          ---   1st computer pirate convicted in Quebec under Criminal
                                          Code                              ---
           The first criminal conviction for software piracy in the province
          was registered in Quebec Court this week - more than five years
          after the offence was added to the federal Criminal Code.
          Marc Alarie was convicted Wednesday.
          His fate sends a strong signal to the many users of illegally
          copied software - across the province and in the rest of Canada -
          that they are guilty of a criminal act, Michel King, president of
          St. Laurent software producer SBI Technologies Inc., said
          yesterday. Alarie is a former employee of SBI.
          A software pirate is someone who copies, uses and/or sells computer
          software illegally. Industry leaders recently estimated that such
          piracy costs the Canadian software business some $200 million a
          year in foregone revenue.
          "We often have the impression that this type of crime is more
          common in Quebec," said King. Several hundred mostly small Quebec-
          based software producers currently generate annual revenue of
          about $100 million, estimated Jacques Saint-Pierre. He's a
          consultant to the Conseil de l'Industrie Electronique du Quebec,
          whose representatives attended a news conference called by SBI to
          publicize the conviction.
          Fined $5,000, criminal record
          "It is the first time that someone in Quebec is convicted under
          section 342.1 (which covers software piracy) of the Criminal
          Code," Crown prosecutor Christian Cyr said when contacted late
          yesterday. Cyr said he believes it is also the first such
          conviction anywhere in Canada - but added that he wasn't entirely
          certain. Federal Department of Justice officials could not be
          reached for confirmation.
          Alarie was fined $5,000 by Quebec Court judge Andre Chaloux and now
          carries a criminal record. He could have received a maximum
          sentence of 10 years in prison, and an unlimited fine.
          Alarie and Normand Pigeon, another former SBI employee, currently
          face civil lawsuits filed on SBI's behalf claiming a total of
          During a preliminary hearing Dec. 10 and 11, Cyr said, the Crown
          presented evidence gathered in three raids by the police fraud
          squad. Alarie subsequently switched his plea on the piracy charge
          to guilty.
          Annual sales of $2.5 million
          Alarie operated through a company called Services Cite Informatique
          Enr. King estimated that the activities of that firm cost SBI
          $200,000 in revenue.
          SBI employs about 25 people, has annual sales of more than $2.5
          million and is embarking on a sales campaign in the United States,
          through as many as 800 software resellers. Its sophisticated
          software is used by manufacturers and distributors, mostly
          businesses with between 50 and 150 employees, and was conceived
          and developed entirely in Quebec. Over the past eight years, King
          said, the research-and-development effort has cost SBI about $1.4
          Richard Pelletier, a director of the industry council, said his
          organization is continuing to encourage businesses, school boards
          and individuals to cease using pirated software. So far, about 160
          Quebec businesses have formally adopted the council's guidelines
          on software use.

In brief
Column:   In brief
Edition:  2 STAR
Section:  ZEST
Page:     31
Category: Book Review
          (Copyright 1990)
              By Michael Bond.
              Fawcett Columbine, $16.95.
              RTURNING from ``Monsieur Pamplemousse Aloft,'' the eccentric
          flatfoot/gourmand and Pommes Frites, his clever dog, team up to sniff
          out clues when a not-so-merry prankster sabotages Le Guide,
          ``France's oldest and most respected food guide.''
              The fictional food bible's staff finds itself in a stew when a
          false obituary of the director appears in the local paper on the very
          day the final manuscript - the first edition produced by computer,
          with influential new restaurant ratings - is to be unveiled at a
          company celebration.
              There the director faints dead away when he finds the manuscript
          completely botched, riddled with missratings and erroneous reviews.
            Jovial food maven Aristide Pamplemousse, an Inspector
          Clousseau-meets-Hercule Poirot type, smells something foul when the
          company's accountant - the sole employee other than the director with
          access to the computer password - cannot be found.
              British writer Bond, also the creator of the Paddington Bear
          children's series, smartly sidesteps cliches about computer crime,
          instead devising an old-fashioned puzzle with immensely pleasurable
          characters and pervasive comic zest.

Computer Miscreants Could be Facing a Major Crackdown
Montreal Gazette   (GAZ)
Edition:  FINAL
Page:     M2
Category: COLUMN
          (Copyright The Gazette)
          ---   Computer miscreants could be facing a major crackdown      ---
            Virus-builders are the scum of the earth. They are also poor,
          sick puppies, who need to locked away for their own good as well
          as ours. On the other hand, a cracker who goes sniffing around
          within some government computer is often only an adolescent
          prankster, play-acting like some sort of modern James Bond. Even
          if he joyrides along some long-distance telephone lines to get
          into a remote computer, he is not a major criminal, despite all
          the indignant protestations of Bell.
          There is a major difficulty in prosecuting technological crime - it
          is technological, hard for the lay person to understand. The
          police and the courts sway and bend in the winds of public and
          political pressure, with their justice sometimes harsh, sometimes
          mild, but usually inappropriate.
          I remember some years ago when Montreal had its first, big
          "computer crime." The RCMP conducted raids, arrested people,
          confiscated computers, boasted of using technological means to
          catch technological criminals, and hinted they had secret,
          science- fiction, digital equipment for catching these high-tech
          criminals who threatened the security of the nation. The media
          were abuzz about a secret computerized organization known as the
          "Top 40" crackers of Montreal. At that time, you could count
          Montreal's microcomputer assembly-language programmers on the
          fingers of both hands, but those programmers were scratching their
          heads and agreeing that this Top 40 must be a pretty secret
          organization because no one had ever heard of it, or anyone who
          belonged to it.
          Our high-tech threats to society turned out to be a group of four
          or five kids, led by "the Prisoner" (Richard Brandow), who were
          using their Apple II computers as "blue boxes" - telephone tone
          generators that would allow them to make uncharged long-distance
          telephone calls. Plans for doing this were available on many
          electronic bulletin-board services (BBSs). These kids ran their
          own BBSs, and used their blue-box Apples to call, free of charge,
          BBSs in the U.S., and swap boastful stories of their antics with
          other young would-be crackers.
          What high-tech device was used to track down these digital terrors?
          An inside informant. One kid had a spat with another and barred
          him from his BBS. The banned kid went to the RCMP and turned in
          the others. And the Top 40? - a pimple-faced miscreant telephoned
          reporters and told them a made-up story, because he "wanted to
          tell them something they wanted to hear".
          A few years after this vigorous RCMP investigation and prosecution,
          a virus with Richard Brandow's name on it infected thousands,
          possibly millions, of Mac computers, yet the RCMP did nothing.
          U.S. courts and law-enforcement organizations swing between almost
          ignoring computer crime and vicious witchhunts. Right now, they
          are in a witchhunt. Secret-service officers have been crashing
          through doors all over the U.S. In New York City a woman was
          startled by about 20 heavily armed state troopers and
          secret-service men pounding on her door. One carried a sledge
          hammer. She let them in, and they found her 14-year-old, terrified
          son wrapped in a towel, standing in the bathtub.
          "Zod" (the handle the boy uses on BBSs) said that despite his
          repeated requests for an attorney, the agents interrogated him for
          the next six hours, threatening to confiscate his father's
          computer if he did not co-operate and tell them about computer
          They arrested Zod on felony charges of computer trespassing and
          tampering, accusing him of setting up BBSs on a toll-free
          Washington state computer and a Pentagon computer that contained
          "sensitive but unclassified" material. I'm not sure how it is
          possible to set up a BBS on someone else's computer - I would love
          to hear the arguments in this trial.
          U.S. Secret Service agents are conducting Operation Sun Devil, a
          crackdown on computer crime, and have, so far, confiscated
          computer equipment in more than 40 cases. They raided Steve
          Jackson Games, refusing to say what they were looking for, but
          confiscating three computer systems, two laser printers, and
          miscellaneous other equipment. They also raided the home of an
          employee, Loyd Blankenship, and confiscated his personal computer
          equipment. For months, the company could not ship new products,
          and had to lay off eight of its 17 employees. Most of the company
          equipment has been returned, some of it damaged beyond repair.
          Blankenship has not been charged, but his equipment has not been
          returned. He had been using his computer as a word-processor,
          writing a role-playing game called "Gurps Cyberpunk". Characters
          in the game can break into a fictitious computer system.
          Operation Sun Devil has alarmed a number of people in the U.S.
          computer industry, including Apple inventor Steve Wozniak, and
          they are forming legal foundations to protect the rights of
          computer users. In matters of computer crime, Canada tends to
          mimic the U.S., after the mandatory Canadian-identity time lag of
          about a year. So - ya all take care, ya hear?
          Personal Computing appears Wednesdays in the Business section and
          Saturdays in Comics and Hobbies. Columns are also available online
          in the Leisure section of Gazetel, The Gazette's electronic
          financial-information and news source. Please address letters to
          Cairn MacGregor, The Gazette, 250 St. Antoine W., Montreal H2Y
          3R7. Online messages from Gazetel members will be forwarded, as
          will fax messages. To send fax messages, dial (514) 987-2399.
                     /                                 /
                     /        File 07 / NIA069         /
                     /    Comments From The Editors    /
                     /             JD & GOT            /
                     /                                 /

The previous NIA Mailing (NIA068), was mailed out on 17DEC90 we recieved
several returns.  Please, when subscribing to NIA, include the _correct address_
so that we deliver the latest issue without delay.  Also make sure that
your system can handle files in excessive size.  If you mailer can NOT handle
it, please tell us and we will make special arrangements for your system.

We would like to thank So76 & Lord Kalkin for ya'lls help in this mailing. Also
thanks go out to Montresor for his help and contributions in this issue.

Back issues can be found off of Face 2 Face (Refer:713.242.NUKE), and off of
Unholy Temple (Refer:408.PRI.VATE).  They can also be found off of the CuD
Archives (Refer:CuD 2.15).

Submissions, questions, comments, and requests to be added to the mailing list
should be mailed to

Out Of Step magazine.  For those of you that love your country but fear
your government.  If you wish to get the latest issue of Out Of Step, or
want to submit an aritcle of your own, then contact them at:
malrj or mawilli @indsvax1               Bitnet

Based on popular demand, we have decided to adhere to this format.  Well, all
I can say is, if you don't like us, I bet your *sister* will.

NIA Ingnorance, There's No Excuse.