Directory of image this file is from
This file as a plain text file
FIELD SERVICE SOFTWARE ASSISTANCE BROCHURE O S - 8 Prepared by: Rick Moore
INTRODUCTION This is a reference document for Field Service use in diagnosing system problems. The information presented in this chapter is extracted from various OS-8 reference manuals and literature which are listed in the appendix. It is not intended to be a course on OS-8 or a substitute for standard DEC software manuals. However, the topics presented here are some of the more commonly used features and some of the commands that should help you to better serve your customer through an enhanced knowledge of his OS-8 operating system. It is strongly recommended that you be extremely careful using your customer's software as a little knowledge is a dangerous thing. If you do work on a customer's files, be sure to use copies of his system only. Tell him what you feel the problem is and let him take any corrective action.
OS-8 consists of an executive and library of system programs which reside on a mass storage device called a "system device". This could be a disk, dectape or floppy unit. The executive supervises the overall program processing and consists of the following four major components: - Keyboard monitor ( KMON ) - Command Decoder ( CD ) - Device Handlers - User Service Routine ( USR ) The Keyboard Monitor provides communications between the user and the OS-8 Executive. The root segment of the monitor resides perminently in memory and occupies 256 words. Commands from the console terminal are interperted and whenever needed, the Command Decoder, USR, KMON, and ODT are brought into memory in a series of overlays while the contents of the memory used is swapped out to the system scratch area. In this manner it is possible to run a baseline system in only 8K words of memory. The commands that are executed directly from the KMON are: ASsign - assigns a new, user defined device name to a perminant device. DEASsign - restores perminant device names GET - loads core image files into memory from a device START - starts execution of a program already in memory RUn - loads core image (.SV) files into memory from a device and starts execution R - loads core image (.SV) files into memory from the SYStem device and starts execution SAve - creates core image programs on a device ODt - invokes the Octal Debugging Technique DAte - sets / prints the system date
The Command Decoder is called when a system program needs additional information from the operator concerning files to be acted upon or devices to be used. You are in the Command Decoder whenever the prompt character "*" is issued. Understanding the Command Decoder line format is probably the most important step to successful usage of the OS-8 Operating System. It is as follows: *OUTDEV:OUTFIL.EX<INDEV:INFILE.EX,INFILE.EX/SW1/SW2=N ... to translate ... OUTDEV: - the output device (SYS:,RKB0:,DTA0:,LPT:) OUTFIL.EX - the name of the output file and it's extension INDEV: - the input device INFILE.EX - the name of the input file and the extension SW? - an optional switch ... differint for each program =N - numerical value (ie: in direct =N# of columns) There may be 0-3 input files, 0-9 output files, 0-3 option switches, depending on the requirements of the individual program. In several programs, it is not necessary to specify every detail ... certain programs have default values for devices, switches, etc. The only way to be sure of this is to know the program you are working with. Again, the value of learning the command decoder format cannot be overstressed ... the same basic format is used thoughout DEC software. (ie: RT-11, RSTS, etc.) Device Handlers are subroutines which handle data transfer to and from peripheral devices. Device handlers for the particular hardware system you are using are activated by the program "BUILD". These subroutines are then available to all OS-8 programs. It is through the use of device handlers that a sort of "device independence" is acheived. The USR is a collection of subroutines that perform operations of opening and closing files, loading device handlers, program chaining, and calling the CD. The USR provides these functions not only for the system itself, but for any programs running under OS-8.
INITIALIZING OS-8 Mount the OS-8 System on the appropriate hardware and execute the bootstrap. This may be as simple as pressing a "BOOT" button or require a toggle-in program from the operator's console. Various bootstraps are listed in the appendix. After the bootstrap is executed, the monitor will print a dot "." on the console. At this point, KMON is active and the system is ready to accept one of the monitor level commands listed on page 1. CCL The Concise Command Language ia a means of providing an easy to understand "English-like" command interface between the operator and the monitor. It translates the commands, chains to the appropriate system programs, passes arguments and filespecs, and starts execution. Any CCL command can be simulated by typing the necessary monitor and CD responses manually. For example: .DIR is equivalent to .R DIRECT *TTY:<SYS:/E=2 .COPY RXA1:<RKA0: is equivalent to .R FOTP *RXA1:*.*<RKA0:*.* The use of CCL is optional in OS-8; manditory in OS-78. This is because you cannot normally access monitor level commands in OS-78. There is a way around this; by typing ".SET SYS OS8" it is possible to turn on this attribute. GETTING DIRECTORIES .DIR - types directory of system device on the console .DIR-L - prints directory of system device on line printer .DIR RKB0:-L - prints directory of device RKB0 on line printer
SET The program "SET.SV" is called by the ".SET" CCL command and can be used to modify some of the attributes of the various device handlers. Some useful ones are: .SET SYS OS8 - allows monitor level commands in OS-78. .SET SYS OS78 - normal OS-78 mode; CCL commands only .SET SYS INIT - causes the command file "INIT.CM" to be executed upon boot-up. .SET SYS INIT [cmd] - causes the command [cmd] to be executed upon boot-up. .SET SYS NO INIT - negates the above .SET LPT LA78 - allows PDP-8A (M8316) parrallel port as controller for LA-180 (device code=0570) .SET LPT LA8A - restores LPT to normal 0660 device code .SET TTY SCOPE - causes a rubout to actually erase the character from the screen. .SET TTY NO SCOPE - causes the rubout to echo the character/slash combination for hardcopy terminals. .SET TTY PAUSE - causes the terminal to pause every "height" lines for ease of reading. .SET TTY HEIGHT 24 - tells the handler the screen has 24 lines .SET TTY WIDTH 80 - allows 80 character width to VT52 screen *** WARNING *** The command ".SET SYS NO INIT" must be given before attempting to use the "BUILD" program, since execution of the "INIT.CM" file or any CCL command will cause the previous contents of memory and the system scratch area to be altered. Also, since the process of executing this file may entail several overlays, the usefullness of it on any media except disks or diskettes is questionable.
OS-8 FILES There are three standard types of OS-8 file formats used by OS-8 and associated system programs; ASCII, Binary and Core Image (.SV). ASCII and Binary files are packed three characters to every two 12 bit words as follows: ----------------------------------------------- | | | Word 1 | Char. 3 | Character 1 | | (bits 0-3) | (bits 0-7) | | | | ----------------------------------------------- | | | Word 2 | Char. 3 | Character 2 | | (bits (4-7) | (bits 0-7) | | | | ----------------------------------------------- 0 - 3 4 - 11 In Binary files, the binary data must be preceded by one or more frames of leader/trailer code (ASCII 200 code). The first character must be either 100-177 octal (origin setting for absolute binary files), 240-257 octal (a COMMON declaration frame for relocatable binary files), or 300 octal which is an origin setting. The end of binary data is one or more frames of leader trailer code. ASCII and Binary files are terminated by a CTRL/Z code (ACSII 232). A Core Image file consists of a header followed by the actual core image. The header is called the Core Control Block (CCB). It consists of first 128 words of the first block (256 words) of the file. The CCB is a table of information that contains the length of the file, the program's starting address, and the Job Status Word (JSW). The CCB for a program at the time it is loaded into core is always saved in words 200-377 (octal) of block 37 on the system's scratch area. It is placed there by the GET or RUN operations or by the ABSLDR program. This information is then used when performing a SAVE without arguments.
FILE NAMES and EXTENSIONS Files are referenced symbolically by a name of up to six characters followed, optionally, by a period and a two character extension. The extension to a file name is generally used to type the files according to their formats or defaults to particular system programs. In most cases, the user will want to conform to the standard file name extensions established for OS-8. If the extension is not specified for a files, some system programs will append an assumed extension by default. This default extension can be overidden by stating the extension in the CD line explicedly. The most common OS-8 standard default extensions are: SV - core image programs BN - binary programs PA - PAL8 assembly language sources BA - BASIC source files BI - BATCH control files SY - system heads DG - diagnostic program ** BX - DECX8 exercisor modules ** X8 - customised DECX8 system exercisor ** ** refers to psuedo standards imposed by the New England District PDP-8 Diagnostic System.
FILE MANIPULATIONS Files can be transfered between OS-8 devices by using either "FOTP.SV" (File Oriented Transfer Program) or "PIP.SV" (Peripheral Interchange Program) or the CCL commands that call them. These commands and their uses are: COPy - copies files from one device to another DELete - deletes files from a device LIst - lists an ASCII files on the LPT REName - changes the name of a file in the directory SQuish - eliminates all empty and deleted files on a device TYpe - types an ASCII file on the console terminal ZERO - zeroes the directory of a device, deleting all existing files on that device For example, to copy file FOO.PA from RXA1: to RKB0: .COPY RKB0:<RXA1:FOO.PA ( note the similiarity between this and the format of the Command Decoder Line on page 2.) To copy an entire device using PIP and FOTP type: .R PIP first transfer the system heads *RKA1:<RKA0:/Y/Z *RKB1:<RKB0:/Y/Z .R FOTP now all the files *RKA1:<RKA0:*.* using wildcard transfers *RKB1:<RKB0:*.* For floppies, it is easier since the program "RXCOPY.SV" or the CCL command ".DUPLicate" will copy the entire device.
SYSTEM HEADS The "/Y" option of PIP.SV can be used for system head manipulation. A system head is 50 blocks long and is located at the beginning of the system device. It contains the system bootstrap, the monitor, and all it's overlays. System heads are sometimes stored as files on a device for ease of use with the extension ".SY". To move a system head: .R PIP *RKA1:<RKA0:/Y if "RKA1" is a virgin device, a skeleton directory must be created, so type: *RKA1:<RKA0:/Y/Z USING WILDCARDS Certain commands allow wildcards in the file name specifications. These commands are COPY, DELETE, DIRECT, LIST, RENAME, and TYPE. Wildcards allow a filename or extension to be totally replaced with an asterisk (*) or partially repalced with a question mark (?). Wildcards are particularly useful when doing multiple file transfers. This is illustrated in the following examples: TEST1.* - all files with the name TEST1 and any extension *.BN - all files with a BN extension and any name *.* - all files with any name and any extension TEST2.B? - all files with the name TEST2 and any extension starting with a B TES??.PA - all files with a PA extension and any name from 3 to 5 characters beginning with TES the asterisk amd question mark can be used together ???.* - all files with any extension and with file names of three characters or less
BUILD The program "BUILD.SV" is the system generation program for OS-8 which allows the user to: 1. Maintain and update device handlers in an existing OS-8 system. 2. Add device handlers to a new or existing system. 3. Change the system characteristics to reflect hardware modifications. Device handlers are supplied with the OS-8 system and are in the format of Binary (.BN) files. To run the Build program, type: .RUN SYS BUILD NOTE: It is important that the user specify the "RUN" command, rather than the "R" command when loading BUILD into core. This will allow the CCB to be stored on the system scratch area for use with the SAVE command! Also, since the system scratch area is used at times when the "INIT.CM" file is executed, it is imperative that the command ".SET SYS NO INIT" be given prior to beginning the BUILD process. After the program is SAVEd, ".SET SYS INIT" can be reinstituted. This matter cannot be overemphisized ... SAving "BUILD" without these precautions will appear to work and the system will boot without failure, however, the next time BUILD is run, it will not work! This is because the proper CCB parameters will have been lost.
RUNNING BUILD Changing a system's parameters can be a complicated procedure with too many variables to be explained in this document. For complete instructions on BUILD, see the appropriated OS-8 Manual. - DEVICES Some of the devices that are available in the OS-8 system are: SYS: - the system device DSK: - the default device (usually SYS:) RKA0: - "A" side of RK05 drive #0 RKB0: - "B" side of RK05 drive #0 TTY: - console teletype LPT: - line printer LQP: - letter quality printer (Diablo) PTR: - paper tape reader PTP: - paper tape punch DTA0: - dectape drive #0 DTA1: - dectape drive #1 RXA0: - RX01 floppy drive #0 RXA1: - RX01 floppy drive #1 RL0A: - RL01 area "A" drive 0 RL0B: - RL01 area "B" drive 0 RL0C: - RL01 area "C" drive 0
FUTIL The OS-8 File UTILity program was orginally developed by Jim Crapuchettes of Menlo Computer Associate,Inc., Menlo Park, CA. It is now included within the OS-8 Extension Kit after release V3D, and is also contained on the New England District PDP-8 Diagnostic System after release V8.04. FUTIL enables a user to examine and modify the contents of mass storage devices, including the SYStem device, and is therefore as dangerous as it is useful! It can be used to recover damaged files, repair destroyed directories, patch programs on the mass storage device, and check for bad blocks on the device. It is this last feature that is particularly useful to us in Field Service as we often have questions concerning the validity of a customer's disk or diskette. The following procedure can verify this: .R FUTIL SET DEVICE RXA0 floppy drive 0 is the target device SCAN 0-755 scans the 756 (octal) blocks on the device EXIT returns to OS-8 If any bad blocks were encountered, the program would report BAD BLOCK nnn where "nnn" was faulty The cause of this could be due to either a bad CRC character due to blown data (can be recopied) or blown format (device must be reformatted). In the case of floppies, the later condition is fatal as they cannot be reformatted.
FUTIL can be used to scan devices regardless of their program contents, for example, OS-8, COS 300, or any customer written file structure can be scanned, as long as standard sector format is used. to SCAN an RK05 Disk: .R FUTIL SET DEVICE RKA0 or RKA1, etc. SCAN 0-6257 there are 6260 blocks SET DEVICE RKB0 now the other side SCAN 0-6257 EXIT . NOTE: At this time, a note on the "sides" of a disk is in order. The RK05 is broken up into two (2) logical devices called "RKA0" and "RKB0" as the RL01 is broken into three (3) devices called "RL0A", RL0B", and "RL0C" by OS-8. This is because of the system's inability to address the entire disk and the limited number of entries the directories can hold. These "sides" are actually not physical sides (who ever heard of a three sided RL01), but refer (on the RK05) to the first 6260 sectors as "RKA0" and the remaining 6260 sectors as "RKB0". A look at the hardware shows that after the sector counter overflows (at 16 sectors) the heads switch to the other surface. After the sector counter overflows again, the heads switch back and then the cylinder address increments. Thus RKA0 is on the outer tracks of the disk and RKB0 is on the inner tracks.