The Hacker's Encyclopedia 1998

home *** CD-ROM | disk | FTP | other *** search

/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / n_z / nia_69.txt < prev next >

Wrap

Text File | 2003-06-11 | 343.2 KB | 7,051 lines

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