informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/magazines/NIA/nia-69.phk

7051 lines
336 KiB
Plaintext
Raw Permalink Normal View History

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