Trailing-Edge
-
PDP-10 Archives
-
AP-4178E-RM
-
swskit-documentation/tops-20-trouble-shooting-handbook.mem
There are no other files named tops-20-trouble-shooting-handbook.mem in the archive.
TABLE OF CONTENTS
1.O CHECKD INFORMATION
1.1 MAPPING DIRECTORIES UNDER RELEASE 3
1.2 MORE ABOUT DIRECTORY PROBLEMS
1.3 DISK INFORMATION
1.4 ANALYSING DSK FILES WITH I/O ERRORS
2.0 RECOVERING FROM A BAD EXEC
2.1 EXEC DEBUGGING
3.0 CRASH DUMPS
3.1 CRASH ANALYSIS
3.2 MAPPING THE JSB OR PSB OF ANOTHER JOB
3.3 SETTING BREAKPOINTS IN A RUNNING MONITOR
4.0 A LIST OF THE BUGHLTS
4.1 A LIST OF THE BUGCHKS
4.2 A LIST OF THE BUGINFS
5.0 A PRIVATE GALAXY SYSTEM FOR DEBUGGING
6.0 PATCHING MONITOR AND COMPATIBILITY PACKAGE WITH NEWRUN
6.1 BUILDING A NEW MONITOR
7.0 COPYING FLOPPIES
8.0 AIDS TO DEBUGGING ON THE SWSKIT
1.0 CHECKD INFORMATION
___________________________
1.0 INTRODUCTION
With the shipment of Release 2 of the TOPS-20 monitor, a new version of
CHECKD will become standard. There are changes in both the use and
implementation of CHECKD. This document describes the use of this new
version of CHECKD. Its intended audience is TOPS-20 developers and
software specialists who have some, but not extensive, knowledge of the
file system. Section 8 is intended for developers with knowledge at the
implementation level of Release 1 CHECKD.
2.0 BACKGROUND
2.1 File system
For each file on the disk, there is an entry in a directory that
describes the file. This entry (called an FDB) contains the disk
address of the page table (also known as the index block) of the file.
The page table contains disk addresses for the pages in the file. If a
file is a long file (that is, it contains a page numbered 1000 octal or
greater), the FDB contains the address of the page table table (also
known as the super index block). It in turn contains an address for
each page table, and each page table contains addresses of file pages.
Note that a directory is a file in <ROOT-DIRECTORY> and is pointed to in
the same manner as any other file. Therefore for purposes of this
discussion a file page is either a data page or a page in a directory
file.
2.2 Disk allocation
A structure consists of one or more units, each of the same disk type,
which are numbered sequentially from 0. A disk address is specified as
a sector number relative to the start of a structure. Thus for a
multi-pack structure with units of m sectors each, unit 0 contains
sectors 0 through m-1, unit 1 contains sectors m through 2m-1, etc.
When an assignment is made on the disk, a sector number is provided, but
a whole page (4 sectors) is always assigned. Thus, as discussed below,
the system knows what pages (not sectors) are available or assigned.
2.3 Bit table
The bit table indicates which pages are assigned and which are
available. It consists of 2 parts:
1. The "top half" contains one word for each cylinder on the
structure. Each word contains the number of free (unassigned) pages in
that cylinder
2. The "bottom half" contains one bit per page arranged as
follows: for each cylinder there are as many full words as are needed
for all its pages. Thus with the disks that we presently support (RP04,
RP05, RP06) there are 95 pages per cylinder, so 3 full words (108 bits)
are reserved per cylinder. Starting with the leftmost bit in the first
word for the first page, the first 95 bits initially contain 1's (the
unused bits in the third word are 0); when a page is assigned, its bit
To: Page 3
Subj:
is turned off and the count of free pages for its cylinder is
decremented.
2.4 Relationship between File System and Bit Table
When all goes well, each page in use on the disk is either
1. one of the "special system blocks", including the home blocks
2. part of the swapping space
3. recorded in the BAT block as a bad spot on the disk (and
therefore assigned in the bit table) but not necessarily
owned by a file
or 4. part of a file
Ignoring the first three for the moment, there should be, for each page
assigned to a file, an FDB or page table that points to the page, a
decremented count in the top half of the bit table, and a bit turned off
in the bottom half of the bit table. When the file system and bit table
disagree, or the top and bottom halves of the bit table disagree, an
error has occurred and must be corrected.
3.0 CHECKING THE BIT TABLE WITH CHECKD
The function of CHECKD is to look for such inconsistencies and correct
them if possible. Although CHECKD has many commands, its CHECK BITTABLE
function is the most commonly used (It is the default when CHECKD is run
at system startup). When this function is specified, CHECKD creates its
own private copy of the disk bit table and initializes it as though
there were no pages assigned. It then assigns the special blocks and
swapping space exactly as the system did it when the structure was
created. CHECKD then proceeds through all the directories in the
system, reading the disk addresses from FDB's, page table tables, and
page tables, and assigning those disk addresses in its local bit table.
If the disk is consistent, the local bit table will match the system bit
table when this is complete.
3.1 Error Reports for Individual Disk Addresses
As CHECKD proceeds through a directory, assigning each page in each
file, it checks for certain conditions. When one of these conditions
occurs, it prints a message of the form
<error> <address>:<page type>
where "error" is the type of error found, "address" is the disk address
(sector number) that CHECKD was assigning when the error was detected,
and "page type" indicates how the page that caused the error is used.
An example of this type of message is
Illegal disk address 140: page table
The following sections describe these fields
3.1.1 Error field
MESSAGE: Disk address n not in bit table
MEANING: A page on the disk is pointed to by the file system (or is
part of the swapping space or special blocks) and therefore should be
assigned in the system bit table but is not. CHECKD (using the DSKAS
To: Page 4
Subj:
JSYS) assigns this page in the system bit table was well as in its local
copy, thus correcting the problem.
MESSAGE: Illegal disk address n
MEANING: CHECKD attempted to assign in its local bit table a sector
number that was not within the limits of the structure. Since it
obtains the addresses from FDB's and page tables, this indicates an
error in an FDB, page table table, or page table.
MESSAGE: Multiply assigned disk address n
MEANING: CHECKD attempted to assign in its local bit table a page that
was already assigned. This means that two or more files are pointing to
the same disk address or a file is pointing to a page previously
assigned to a special block or the swapping space. This message
reflects only the second (or later) attempt to assign the page.
However, by using the SCAN command (see section 6.2), you can determine
all the uses of the page.
MESSAGE: Disk address n marked in BAT blocks
MEANING: A page on the disk is pointed to by the file system (or is in
the special blocks or swapping space) and is also marked in the BAT
blocks. This means that a hard disk error was previously detected in
this page. CHECKD takes no special action in this case; it assigns the
page in its local bit table as usual. This "error" is actually a
warning that the data in this page may have errors.
3.1.2 Address field
As noted earlier, this field contains the sector number relative to the
start of the structure.
3.1.3 Page type field
MESSAGE: Special system blocks
Meaning: The error occurred when assigning a page contained in the
special system blocks that are reserved at the beginning of each pack in
a structure. Commonly called the 'home blocks', they actually include
the boot strap block, primary and secondary home block, primary and
secondary bat block, and some unused but reserved blocks.
MESSAGE: Swapping space
MEANING: The error occurred when assigning a page in the swapping
space. Since CHECKD reads the home blocks to determine the size and
location of the swapping space, this may indicate a clobbered home
block.
MESSAGE: Long file page table
MEANING: The error occurred when assigning the page used by the page
table table. Thus there is probably an error in the FDB that points to
this file's page table table.
MESSAGE: Page table
MEANING: The error occurred when assigning the page used by the page
table. Thus, if the file is short, there is probably an error in the
To: Page 5
Subj:
FDB that points to this file's page table. If it is long, there is
probably an error in the page table table that points to this page
table.
MESSAGE: File page n
MEANING: The error occurred when assigning the page used by page n of
the file. There is probably an error in the page table for the file.
3.2 Summaries for Individual Files
When CHECKD finishes with a file, it checks to see if any errors have
been detected for that file. If so, it prints a message of the form
Summary for file filespec
followed by error counts of the form
n error type
It is possible to receive 2 summary lines for one error. If illegal or
multiply assigned addresses have been reported, one or more of the
following messages are printed.
n Illegal addresses
n Multiply assigned addresses
In addition, if these errors occurred when assigning file system pages
(file pages, page table tables or page tables) one or more of the
following messages are printed:
n Faulty page table addresses in FDB
n Faulty long file page table addresses in FDB
n Faulty addresses in page table
n Faulty addresses in long file page table
If a disk error has occurred while reading a page table table or page
table, the following message will be printed:
n Disk read errors
Also, one or more of the following will be printed
n Page tables unreadable
n Long file page tables unreadable
If pages that should have been assigned were found to be free, the
following message is printed
n File addresses not in bit table
If pages that were assigned were found to be marked in the BAT blocks,
the following message is printed
n Assigned pages marked in BAT blocks
The last summary message for a file is followed by a dashed line. Note
that error messages for a file precede the file name and summary
messages follow it.
3.3 Final Count of Used Pages
When CHECKD has finished all the files, it prints a final summary of the
To: Page 6
Subj:
page counts as follows:
Local count of file pages: i
Local count of overhead pages: j
Local count of used pages: l
System count before CHECKD: m
System count after CHECKD: n
AS CHECKD processes each file, it counts the number of pages it uses for
data, and adds this count to a total for the structure. The first
message reports this total. The total overhead for the structure
includes all page table tables, page tables, special system blocks, and
swapping pages. In addition, it includes any pages that are marked in
the bat blocks and thus not available for use. The second message
reports this total.
The counts of total pages used are obtained by adding the counts of used
pages per cylinder in the top half of the bit table and subtracting them
from the total pages on the structure. The third message represents the
number of pages assigned in the local copy of the bit table. The fourth
is the number of used pages that the system bit table indicated before
this run of CHECKD. The fifth is the number that the system bit table
indicated after this run of CHECKD. If the fifth is larger than the
fourth, CHECKD has found one or more pages that should have been
assigned in the system bit table but were not and it has assigned them.
3.4 Comparison of Bit Tables
Next CHECKD compares the top halves of the system bit table and the
local copy. If a pair of words disagrees, it compares the corresponding
words in the bottom halves of the two tables. There are three possible
results:
1. If a bit is off in the system bit table and on in the local
copy, the page represented by that bit is not pointed to by a file (and
is not in the special blocks or swapping space) but is assigned in the
system bit table. This is a "lost page".
2. If a bit is on in the system bit table and off in the local
copy, the page is pointed to by a file (or is in the special blocks or
swapping space) and is not assigned in the system bit table. This
condition should have been detected and corrected by CHECKD earlier. If
this error occurs, CHECKD prints
?Bit tables inconsistent at cylinder n
3. If the bit words agree even though the page counts disagree,
CHECKD prints the same message as in the second case.
When the bit tables have been compared, if there are any lost pages,
CHECKD creates a file, "str-name"-LOST-PAGES.BIN, in the connected
directory (PS:<OPERATOR> if running under job 0) and writes the disk
addresses into it. (If a disk address is marked in the BAT blocks, it
is not written into the file). It prints a message of the form
There are n lost pages
Addresses are in file <filespec>
To: Page 7
Subj:
If there are no lost pages, it prints
There are no lost pages.
If there are any errors in the form of "Illegal disk address" or
"Multiple allocation", then the writting of the lost pages file is
suppressed with the message:
% Suppressed writing of lost pages file - too many errors.
4.0 CHECKING THE FILE SYSTEM WITH CHECKD
4.1 Checking Directory Consistency
When the CHECK DIRECTORY command is specified to CHECKD, it performs,
for each directory on the structure, the DELDF JSYS with DD%CHK set in
AC1. This JSYS checks the consistency of the specified directory. It
checks the validity of certain fields in the FDB's, traces string
pointers to confirm that they point to the expected block types, and
checks the directory's count of file pages against the sum of the
individual files' page counts.
If the monitor encounters a serious error, it generates a BUGCHK. If
errors are encountered, the JSYS fails, and CHECKD performs the JSYS
again, with DD%RST set. This causes the monitor to rebuild the
directory file's symbol table and perform the checks again. Thus, if
the problem is not fixed, the BUGCHKS will be repeated. When this
action is done, CHECKD issues the message:
% Rebuilding symbol table for <directory name>
After performing the rebuild function CHECKD will either print [OK] if
no errors were encountered or [FAILED] if the damage was not repaired by
this procedure.
The CHECK BITTABLE command causes this same function to be performed.
In addition, CHECKD performs its own check of each directory that is
similar to the monitor's check. If a directory fails CHECKD's test, its
files are ignored during the assigning of pages in the local bit table.
Thus the pages used by this directory and its files will erroneously
appear in the lost pages file. The following messages may occur:
MESSAGE: RCDIR failed on directory <directory name> - Skipped
MEANING: While converting the directory name to a number, the monitor
found a serious error in the directory.
MESSAGE: OPENF failed on directory <directory name> - Skipped
MEANING: CHECKD was unable to open the directory file.
MESSAGE: DR0CHK: Illegal format for page 0 in directory <directory
name>
MEANING: The header for the directory file is bad.
MESSAGE: FDBBAD: Illegal format FDB
MEANING: An FDB for a file in the directory is bad.
MESSAGE: NAMBAD:Illegal format for name block
To: Page 8
Subj:
MEANING: There is an error in a name block, which may contain the name
of the directory, the password (if any), or the name of a file in the
directory.
MESSAGE: EXTBAD:Illegal format for extension block
MEANING: There is an error in a block containing the extension for a
file in the directory.
MESSAGE: ACTBAD:Illegal format for account block
MEANING: There is an error in a block containing the account string.
4.2 Correcting File Page Counts
For each file on the structure there is a count (in its FDB) of its data
pages. This is the count that is reported by the EXEC as the page count
of the file. Normally this count is the number of pages pointed by the
file's page table. However, after a system crash, the page table may
point to more pages than this count indicates. When CHECKD is
processing a file, it checks the file's page count in the FDB against
the total number of data pages pointed to by the page table. If the two
disagree, CHECKD changes the count in the FDB.
5.0 WHEN TO RUN CHECKD
As discussed earlier, there are two potential problems with the bit
table.
1. It may have internal inconsistencies. That is, the count of
free pages for a cylinder may disagree with the number of '1' bits in
the bottom half.
2. It may not reflect the same assignments as the file system.
When the monitor crashes and files are open, there is potential for
either error.
5.1 Automatic Running of CHECKD
When the monitor is booted, it checks for the first type of error and
corrects it by changing the count to correspond to the number of '1'
bits. If it finds any inconsistency it automatically runs CHECKD before
users are allowed to login. The most likely situation for CHECKD to
detect is lost pages. If this is the only error detected, you can allow
other users on the system and run CHECKD, giving the RELEASE command
(See section 6.1). However, if other errors are detected, system
startup will be deferred until the reported errors are corrected. It is
important to rerun CHECKD until it reports no errors since detection of
an error in a page table for a file causes checking of that file to be
terminated.
5.2 Manual Running of CHECKD
Since the monitor does not detect the second type of error, CHECKD
should be run periodically and after any disastrous hardware failure.
The best time to do this is at system startup when the monitor (if no
internal inconsistencies were detected) asks
Run CHECKD?
To: Page 9
Subj:
At this point users cannot login. This is important because if files
are being created while CHECKD is running, it may give unnecessary and
inaccurate messages.
To run CHECKD at any time, you must have WHEEL or OPERATOR capabilities
ENABLE'd and you must have <CTRL>C capability enabled. If either of
these capabilities are not enabled, you will recieve an appropriate
message the that effect and CHECKD will terminate. Ex:
@ENABLE
$RUN <SYSTEM>CHECKD
and CHECKD will prompt with
CHECKD>
At this point all the commands (See section 6) are available to you. To
perform the checks discussed above, type
CHECK BITTABLE
This is the same function as is performed when the monitor runs CHECKD.
6.0 OTHER COMMANDS
6.1 Release
RELEASE (LOST PAGES FROM) filespec (FOR) str:
When CHECKD finds lost pages, it writes their disk addresses in a new
version of "str-name"-LOST-PAGES.BIN in the connected directory. If you
type ESCAPE instead of a file spec, CHECKD defaults to
"str-name"-LOST-PAGES.BIN in your connected directory. ("str-name" will
be your connected structure). Using the DSKAS JSYS, it deassigns these
pages, marking them free in the system bit table.
6.2 Scan
SCAN (FOR DISK ADDRESSES IN) filespec (FOR) str:
The file specified is created by the user and contains disk addresses in
7-bit ASCII. Normally this is used when CHECKD has indicated multiply
assigned pages, and it is necessary to know what files have them
assigned. You can give "TTY:" for the filespec and type the numbers,
one per line, terminating with <CTRL>Z. Alternatively, you can type to
the Command Processor,
COPY (FROM) TTY: (TO) filespec
and type the disk addresses, ending with <CTRL>Z.
When CHECKD detects an address being searched for, it prints a message
of the form discussed in section 3.1. The "error" field contains
Found disk address
For each file in which it found an address it prints a summary line of
the form
n Search addresses found
6.3 Rebuild
To: Page 10
Subj:
REBUILD (BIT TABLE OF) str:
This command causes the local copy of the bit table to be written to the
disk and thus become the system bit table. This forces the bit table to
correspond to the file system and should be done only if there appear to
be no problems in the directories. When CHECKD prints its count of used
pages it does not print the system count before this run of CHECKD. The
two counts that are printed do not include the pages used by the new bit
table file because it is not yet written. When CHECKD is run the next
time with the BITTABLE command, 5 lost pages will be reported. This is
because the old bit table file is deleted with the 'forget' bit of DELF.
These pages can be released. Note that if this command is given for a
structure that was created by a Release 1 monitor, the home blocks will
be rewritten to indicate that the bit table is of Release 2 format, and
Release 1 cannot be run on that structure again.
6.4 Reconstruct
RECONSTRUCT (ROOT DIRECTORY OF) str:
This command is used to copy the backup copy of the ROOT-DIRECTORY onto
the primary copy of the <ROOT-DIRECTORY> and then automatically do a
"rebuild" function (See section 6.3). This procedure is only done is
extreme cases when the file system has been clobbered and you cannot
access or mount the named structure. For a further discussion of
ROOT-DIRECTORY reconstruction see the ???? manual.
6.5 CONTROL/A
Typing CTRL/A to CHECKD causes it to print the name of the directory
that it is checking. The directories are processed in alphabetical
order.
7.0 WHAT TO DO WHEN CHECKD REPORTS ERRORS
If CHECKD reports only lost pages, run the program again giving the
RELEASE command. Be certain to specify the file that was written most
recently.
The errors discussed in Section 4 indicate problems within a particular
directory. The errors discussed in Section 3 may indicate directory
errors (a bad FDB, for example) or a damaged bit table. It is often
unclear what problems should be corrected first when several of these
errors occur.
The first problem to be solved is that of multiply assigned disk
addresses. Use the SCAN command, typing each address that is multiply
assigned. Since each of these pages contains data for one of the files
pointing to it, you may choose one file and assume the page contains its
data if you are reasonably certain that only that file was being written
when the system last crashed. In that case, delete (with the FORGET
subcommand) all other files that point to the page. It will be
necessary later to verify that the page really contains data for the
remaining file. In general, it is easier (and safer) to delete all
To: Page 11
Subj:
files that point to a multiply assigned page.
Next, delete and forget all files for which illegal disk addresses or
unreadable page tables are reported.
If CHECKD reports bit table inconsistencies, perform the REBUILD
function.
If directory errors are reported, it is sometimes possible to repair the
directory manually. Further information about bad directories can be
obtained by running DIRPNT and DIRTST, which are included in the support
kit. If you are unable to repair the directory by hand, follow the
procedures in the Operator's Guide for dumping, killing, recreating, and
restoring the directory.
After each of the steps discussed above, perform the bit table
consistency check again. Do this until no errors are reported.
When the only remaining errors are lost pages, perform the RELEASE
function. Do not do this while there are other errors since CHECKD
aborts a particular directory or file when it detects errors in it.
Thus there will be erroneously reported lost pages.
Note that even if no errors are reported, if there are bad spots on the
disk that do not belong to a file (and are not in the special blocks or
swapping space), the local counts of file pages and overhead pages will
exceed the local count of all used pages by the number of such bad
pages.
8.0 CHANGES FOR RELEASE 2
NOTE: This section assumes familiarity at the implementation level with
the old CHECKD.
Like the monitor, CHECKD has been changed to assume that the bit table
is only as long as it needs to be for a particular structure.
Previously all bit tables were the maximum size (i.e., that of 4
RP04's). It reads the size of the bit table from the home blocks. Any
structure created by a Release 2 monitor will have this number. Old
structures have 0 in the field; CHECKD interprets this to mean that the
bit table has the old 4-RP04 format. Like the Release 2 monitor, it
will handle these structures correctly.
Like the monitor, CHECKD has been changed to handle any kind of disk,
provided that all disks in a structure are of the same type. A JSYS
provides a description of the hardware, which CHECKD uses to compute
offsets into the bit table.
The method of rebuilding the bit table has been changed to correspond to
changes in the monitor. By using new functions of the DSKAS JSYS,
CHECKD creates a private copy of the bit table, assigns the pages
pointed to by the existing files, and writes the updated bit table to
the disk. During this period, no other processes can access the bit
table. A new entry point (offset 3 in the entry vector) allows job 0 to
To: Page 12
Subj:
request this rebuilding. Thus the in-house procedure for expanding a
structure without refreshing has been preserved. Answering 'YES' to the
new startup question, 'Rebuild bit table?' causes CHECKD to be run at
the usual time, but instead of a bit table consistency check, it
rebuilds the bit table for the larger structure. Note that this is
unsupported and should not be used at customer sites.
If a structure has been built with Release 1B, do not perform the
REBUILD command with the Release 2 CHECKD. This will cause the size of
the bit table to correspond to Release 2 while the home blocks indicate
the old style.
The SCAN command has been changed to do just the scanning for specified
addresses. It no longer performs the bit table consistency check (It
did it incompletely before). Thus it can be run while files are being
created without producing meaningless error messages.
The text (but not the meaning) of the messages has changed. See the
preceding sections for details.
To: Page 13
Subj:
Work to be done:
1. Remove summary or 'faulty address' summary
2. Remove CHKFLF
3. More directory checks
4. Get disk size from monitor
1.1 MAPPING DIRECTORIES UNDER RELEASE 3
___________________________________________
J
MAPPING DIRECTORIES IN MDDT UNDER RELEASE 3
-------------------------------------------
Release 3 of TOPS-20 can take advantage of the extended
addressing features of the model B processor. Some of its data has
been reorganized and moved into non-zero sections of the addressing
space. One of the things moved was directories. Directories are now
mapped into section 2, starting at the beginning of the section. Thus
the old procedure of reading a user's directory in MDDT is no longer
valid. This will describe how to map a directory correctly, for
release 2 and for release 3.
The procedure for release 2 was the following. You first have to
find out the structure number and directory number for the directory
to be mapped. You can use the TRANSL program to get the directory
number, or use the ^EPRINT command to list the directory information.
As an example, suppose you want to find the directory and structure
information for the directory SNARK:<DBELL>. You run TRANSL and
obtain the results:
@TRANSL SNARK:<DBELL>
SNARK:<DBELL> (IS) SNARK:[4,116]
The "programmer number" obtained is the directory number, in octal.
In this example, the directory number is 116. If the directory is in
bad shape, and you can't run TRANSL or use ^EPRINT, you will have to
find out the directory number by looking at the output from a DLUSER
or ULIST run.
To find the structure number, you have to work harder. If the
structure is mounted as PS:, its structure number is always 0. For
structures mounted other than PS:, you do the following. You get into
MDDT, and look at the table STRTAB. This table contains all of the
addresses of the structure data blocks in the system. The first word
of each structure data block is the structure name in sixbit. So you
search the tables looking for the desired structure. The offset into
the table STRTAB is then the structure number. For our example:
@ENABLE
$SDDT
DDT
JSYS 777$X
MDDT
$$6T
STRTAB/ ,8[ / PS
STRTAB+1/ M^I / REL3
STRTAB+2/ M_% / SNARK
In the example above, you see that PS: is the first structure,
followed by the structures REL3: and SNARK:. Since the offset into
STRTAB was 2 for SNARK:, the structure number you want is 2.
Page 2
Knowing the structure number and the directory number, you can
now map the directory and look at it. When the directory is mapped,
location DIRORA will point to the area in the monitor you can find it
at. This is currently the address 740000. To save typing, you can
use the symbol DA, which has the value 740000 (none of the examples
here uses this symbol however). To map the directory, you call the
routine MAPDIR which is in the module DIRECT. It takes two arguments.
The directory number goes in AC1, and the structure number goes in
AC2. For our example, the output looks like:
DIRORA[ 740000
740000/ ?
1! 116
2! 2
CALL MAPDIR$X
$$
740000[ 400300,,100
The skip return from MAPDIR means you have successfully mapped the
directory. You can now look at the whole directory by examining the
proper locations. The number of pages that are mapped by MAPDIR is
30, which is the length of a directory, so the whole thing is
available to look at. By examining or changing location 740000+N in
core, you are examining or changing location N of the directory. When
you are finished, you can just leave MDDT by jumping to MRETN or by
typing ^C.
In release 3, however, when you examine location DIRORA after
calling MAPDIR, it doesn't have to contain 740000. If it does, then
your machine cannot support extended addressing and the monitor is
running the same as release 2 did. In this case you can ignore the
rest of this document. If your machine does have extended addressing,
when you examine location DIRORA you will see the number 2,,0. This
address is now in section 2 of the monitor, and MDDT cannot read the
data there directly. If you look at the location 740000 after calling
MAPDIR, it will still be unreadable, since the directory is no longer
read in there. Those pages are now unused.
To be able to read the directory now, you have to tell the
monitor to map in the pages where you can see them with MDDT. The
first step is to examine the location DRMAP. This location is the
section pointer for section 2, where the directories are mapped. This
is a share-type pointer, which contains the OFN for the desired
directory in the right half. This number is one of the arguments for
the MSETMP routine. MSETMP takes the following arguments. AC1
contains the OFN in the left half, and the first page number to be
mapped in the right half. AC2 contains flag bits in the left half,
and the address where you want to map the pages in the right half.
AC3 contains the number of pages to be mapped. For mapping
directories, you can use 740000 as the address, and you want to map 30
Page 3
pages. You also want to set flag bits so that the directory can be
changed. For the example, you do the following:
DRMAP[ 224000,,147
1! 147,,0
2! 140000,,740000
3! 30
CALL MSETMP$X
$
After the call to MSETMP, the directory is now mapped in 740000, and
you can proceed as you used to in release 2. When you are finished
with the directory, you should call MSETMP again to unmap the
directory. This is done by supplying the same arguments as before,
except that ac 1 contains zero. As an example:
1! 0
2! 140000,,740000
3! 30
CALL MSETMP$X
$
Now you can simply ^C out of MDDT, or jump to MRETN.
1.2 MORE ABOUT DIRECTORY PROBLEMS
=====================================
SOME HINTS FOR TRACING DIRECTORY PROBLEMS RELEASE2 OR MODA
=================================================
NOTE-- USE THE METHODS DOCUMENTED IN THE OPERATORS
GUIDE BEFORE RESORTING TO THE METHODS BELOW.
1. THERE IS A FILE ON THE SWSKIT CALLED DIRTST.EXE
WHICH WILL TEST FOR INCONSISTENCIES IN THE
DIRECTORY POINTERS.
@ENABLE
$RU DIRTST
DIRTST - SNARK DIRECTORY CHECKER V0
OUTPUT FILE: TTY:
DIRECTORY FILE: <TYPE USER.DIRECTORY>
THIS WILL TELL YOU JUST ABOUT EVERYTHING EXCEPT
IF THE HEADER IS BAD.
2. ANOTHER PROGRAM ON SWSKIT IS DIRPNT WHICH PRINTS
OUT THE CONTENTS ON THE CHAINED FDB'S, ENTIRE
DIRECTORY, FDB, OR SYMBOL TABLE.
TO RUN IT:
$RU DIRPNT
AND ANSWER THE QUESTIONS. THIS ALSO DOESN'T
WORK IF THE HEADERS ARE BAD.
3. IF YOU GET A BUGCHECK:
GO INTO THE MONITOR WITH MDDT AND SET A BREAKPOINT
AT THE BUGCHECK ADDRESS, SAY, FDBBAD. DO THE
FUNCTIONS THAT CAUSE THE BUGCHECK, DIR, SAY.
TRACE DOWN THE BUG. THE RELEVENT LISTINGS ARE
PROLOG AND DIRECT (EXEC3.MAC CONTAINS DIRECT).
THESE GIVE THE DIRECTORY FORMAT AND USEFUL SYMBOLS.
4. IF THE POINTERS ARE DESTROYED OR CONFUSED:
YOU CAN MAP IN THE DIRECTORY AS FOLLOWS:
@ENA
$^EQUIT ;GET INTO MINIEXEC
MX>/ ;GET INTO MDDT
;MAP IN DIRECTORY, PUT DIR NUMBER IN 1. GET
;DIR NUMBER FROM DLUSER OR TRANSL FORMAT IS
;[4,DIRECTORY#]
;PUT THE STRUCTURE NUMBER IN AC2.
;TO FIND THE STRUCTURE NUMBER LOOK AT THE TABLE STRTAB. STRTAB
;CONTAINS A LIST OF POINTERS TO THE SDBS OF STRUCTURES THAT ARE
;MOUNTED. THE STRUCTURE NUMBERS ARE EQUAL TO THE OFFSET INTO THE
;STRTAB. TO FIND OUT WHICH STRUCTURE IHAS STRUCTURE NUMBER 3,SAY,
;LOOK AT STRTAB+3 ADDRESS CONTENTS WHICH ARE THE SIXBIT STRUCTURE
;NAME.
STRTAB/ 54321 ;STR NUMBER 0
STRTAB+1/ 56776 :STR NO 1
STRTAB+2/ 12345 ;STR NO 2
12345$6T/ FOO ;STR NO 2 IS FOO:
1/ DIRECTORY NUMBER
2/STRNUMBER
CALL MAPDIR$X
;NOW YOU CAN LOOK AT THE HEADER
;POINTERS ETC., AND FIX THINGS UP
;IF YOU'RE LUCKY. GO BACK TO THE
;MINI-EXEC.
^P
MX>START
$
5. IF YOU CAN'T (OR DON'T WANT TO)
RECOVER THE EXISTING DSK FILES YOU CAN
DELETE THE DIRECTORY AND RESTORE THE FILES
USING A DUMPER TAPE. THIS WORKS FOR
<SYSTEM> AND ALL OTHER DIRECTORIES.
IN ORDER TO DELETE A DIRECTORY YOU MUST
REMOVE IT FROM <ROOT-DIRECTORY>. THIS
MEANS YOU MUST TURN OFF THE FB%DIR BIT
(WHICH INDICATES THAT THIS IS A DIRECTORY)
IN THE FDB WORD .FBCTL.
IN RELEASE 1B AND LATER YOU CAN DO THIS WITH
THE FOLLOWING SET OF COMMANDS:
(FIRST BE SURE NOTHING IS MAPPED FROM THIS
DIRECTORY)
@ENA
$DELETE<ROOT-DIRECTORY>DIRECTORYNAME.*.,
$$DIRECTORY
$$
;THAT SHOULD DO IT. IN THE CASE YOU GET INTO
;SERIOUS TROUBLE AND HAVE TO DO ALL THIS BY
;HAND SEE THE STEPS BELOW A., B., C., &E..
;IN ALL CASES CONTINUE WITH STEP F..
A. MAP IN <ROOT-DIRECTORY>
@ENABLE
$^EQUIT
MX>/ ;GO TO MDDT
1/ 1 ;1 IS ROOT DIRECTORY
2/ 0 ;0 IS PS:
CALL MAPDIR$X ;MAP IN DIRECTORY
B. FIND FDB ADDRESS OF BAD DIRECTORY
IDXTAB+<DIR #>*2/ ;GETS FDB ADDR
;THIS LOCATION AND THIS
;LOCATION+1 MUST BE CLEARED
;AT SOME TIME BEFORE YOU FINISH.
;IF DXTAB+<DIR#>*2 IS ZERO, FIND THE SYMBOL TABLE OF
;<ROOT-DIRECTORY> AS FOLLOWS:
DA/ 400300,,100 <LF>;HEADER
740001/ 1 <LF> ;DIR NUMBER
740002/ 760 <LF>
740003/ 5520 ;ROOT DIRECTORY RELATIVE
;SYMBOL TABLE ADDRESS
DA+5520/ 400400,,1<LF> ;SYMBOL TABLE HEADER
LOOK THROUGH THE SYMBOL TABLE FOR THE ASCII
DIRECTORY NAME. AT THE ASCII NAME LOCATION -1
WILL BE THE FDB ADDRESS. FOR EXAMPLE, TO FIND
COHEN:
.
.
.
746516/ ^Y <LF>
746517/ CROSS <LF>
746520/ T = 5324 <LF>
746521/ COHEN <LF>
;COHEN'S FDB IN <ROOT-DIRECTORY> IS
;5324
C. CLEAR THE FB%DIR BIT THAT SAYS THIS IS A DIRECTORY.
DA+FDBADR/ 400100,,30 <LF>
744137/ 43000,,0 ;.FBCTL WORD
;NOTE -- FB%DIR = 2000,,0
744137/ 43000,,0 41000,,0
./ 41000,,0 ;BIT CLEARED
D. GET BACK TO EXEC
^P
MX>START
$
E. DELETE AND FORGET THE NAME FROM <ROOT-DIRECTORY>
$DELETE <ROOT-DIRECTORY>COHEN.DIRECTORY,
$$FORGET
$$
$EXPUNGE <ROOT-DIRECTORY>
F. CREATE NEW DIRECTORY WITH THE SAME DIRECTORY NUMBER.
THE SAME DIRECTORY NUMBER IS IMPORTANT.
$^ECREATE <COHEN>
.
.
.
G. DUMPER THE FILES BACK.
1.3 DISK INFORMATION
________________________
A LOOK AT SOME OF THE DISK STUFF
================================
MUCH OF THE SYSTEM DEBUGGING YOU WILL HAVE TO DEAL WITH WILL INVOLVE
THE DEC-20 HARDWARE. THERE ALWAYS SEEMS TO BE A LARGE GAP BETWEEN WHAT THE
DIAGNOSTICS CAN TOLERATE AND WHAT THE MONITOR CAN TOLERATE IN THE WAY OF MAL-
FUNCTIONING HARDWARE. THE MONITOR WILL NOT ALWAYS POINT YOU TO THE REAL DISK
OR MAGTAPE PROBLEM, SAY, BUT WILL CRASH AFTER SOMETHING HAS GONE WRONG A FEW
MINUTES AGO SOMEWHERE. MOST OF THE HARDWARE PROBLEMS THAT WE HAVE HAD TO DEAL
WITH THAT WERE REALLY DIFFICULT TO TRACK DOWN AND POINT THE FIELD SERVICE REP.
TO WERE PROBLEMS WITH DISK HARDWARE. THE FOLLOWING IS INFORMATION WHICH YOU CAN
USE TO HELP FIELD SERVICE TRACE DOWN PROBLEMS WHICH ARE NOT REPORTED IN THE DIAG-
NOSTICS. IN MOST CASES THE FIELD SERVICE REP KNOWS WHAT ALL THE STATUS BITS ETC.
MEAN BUT HAVE NOT BEEN ABLE TO FIND THEM IN THE MONITOR CRASHES OR RUNNING
MONITOR.
CHANTAB:
CHANTAB IS AN ORDERED LIST OF CHANNEL DATA BLOCK ADDRESSES STARTING WITH
CHANNEL 0. RH20-0 DATA BLOCK ADDRESS IS IN THE FIRST WORD ETC.
CDB:
CDB IS THE CHANNEL DATA BLOCK. THERE IS ONE CDB PER CHANNNEL. THE CDB
CONTAINS CHANNEL DEPENDANT INSTRUCTIONS AND DATA, POINTERS TO THE UNIT
DATA BLOCK (UDB) IN THE CASE OF RPO4, RP05, AND RP06'S. IN THE CASE OF
TU45'S THE POINTER IS TO THE KONTROLLER DATA BLOCK (TM02'S) WHICH POINT
IN TURN TO THE UDBS. THE CDB ALSO CONTAINS INFORMATION ABOUT THE CUR-
RENTLY ACTIVE UNIT. WHEN THE CHANNEL INTERRUPTS, CONTROL PASSES (VIA
A JSP) TO CDBINT. THE CDB ADDRESS IS STORED IN AC1, P1 AND THE PRIN-
CIPAL ANALYSIS ROUTINE, PHYINT, IS CALLED.
NOTE: THE CDBS ARE REFERENCED IN MODULES PHYSIO, PHYH2 (RH20 CODE),
PHYM2 (TMO2 CODE) AND PHYP4 (RP04, 05, 06 CODE). THE CHANNEL DATA
BLOCK IS DEFINED IN THE MODULE PHYPAR. THE ADDRESS THAT YOU
GET IN CHNTAB IS REALLY A POINTER TO WORD0 WHICH CONTAINS THE STATUS
BITS FOR THIS CONTROLLER (CDBSTS). LOOK IN PHYPAR FOR THE TABLE
DEFINITION. SOME WORDS OF INTEREST ARE:
CDBADDRESS + CDBSTS: STATUS AND CONFIGURATION INFORMATION
CDBADDRESS + CDBUDB: 8 WORD TABLE OF UDB (OR KDB) ADDRESSES.
THE STATUS BITS WHICH ARE ALSO DEFINED IN PHYPAR ARE LISTED HERE FOR
YOUR CONVENIENCE:
CS.OFL==1B0 ;OFFLINE
CS.AC1==1B1 ;PRIMARY COMMAND ACTIVE
CS.AC2==1B2 ;SECONDARY COMMAND ACTIVE
CS.ACT==CS.AC1!CS.AC2 ;ANY ACTIVE
CS.MAI==1B3 ;CHANNEL IS IN MAINT MODE
CS.MRQ==1B4 ;MAINT MODE REQUESTED FOR SOME UNIT
CS.ERC==1B5 ;ERROR RECOVERY IN PROGRESS
BITS 30-32 ;PIA FIELD
BITS 33-35 ;CHANNEL TYPE FIELD
KDB:
KONTROLLER DATA BLOCK (TM02 ONLY) DEFINED IN PHYPAR ALSO.
REFERENCED IN PHYM2, PHYPAR, PHYSIO. WORDS OF INTEREST ARE:
KDBADDR+KDBSTS: ;FLAGS UNIT TYPE
KDBADDR+KDBUDB: ;UDB TABLE FIRST WORD (8 WORDS LONG)
UDB:
UNIT DATA BLOCK. THERE IS ONE UDB PER UNIT ASSOCIATED WITH A CDB
OR KDB. THE UDB CONTAINS INFORMATION ABOUT THE CURRENT ACTIVITY ON
THE UNIT IN QUESTION. THE UDB IS DEFINED IN PHYPAR AS WELL. SOME
WORDS OF INTEREST ARE NOTED BELOW. LOOK IN THE LISTINGS FOR OTHER
INFORMATION.
UDBADDR + UDBSTS: ;STATUS AND CONFIGURATION INFO (SEE BELOW)
UDBADDR + UDBERR: ;ERROR RECOVERY STATUS WORD
UDBADDR + UDBERP: ;ERROR REPORTING WORK AREA IF NON 0
UDBADDR + UDBRED: ;READS - SECTORS IF DISK, FRAMES IF TAPE
UDBADDR + UDBWRT: ;WRITES - SECTORS IF DISK, FRAMES IF MTA
UDBADDR + UDBSRE: ;SOFT READ ERRORS
UDBADDR + UDBSWE: ;SOFT WRITE ERRORS
UDBADDR + UDBHRE: ;HARD READ ERRORS
UDBADDR + UDBHWE: ;HARD WRITE ERRORS
UDBADDR + UDBPS1: ;CURRENT CYLINDER IF DISK, CUR FILE IF MTA
UDBADDR + UDBPS2: ;CURRENT SECTOR WITHIN CYL IF DISK, RECORD
; IN FILE IF TAPE
UDBADDR + UDBSPE: ;SOFT POSITIONING ERROR
UDBADDR + UDBHPE: HARD POSITIONING ERROR
STATUS BITS IN UDBSTS OR FIRST WORD OF UDB:
US.OFS==1B0 ;OFF LINE OR UNSAFE
US.CHB==1B1 ;CHECK HOME BLOCKS BEFORE ANY NORMAL I/O
US.POS==1B2 ;POSITIONING IN PROGRESS
US.ACT==1B3 ;ACTIVE
US.BAT==1B4 ;ON IF BAD BAT BLOCKS ON THEIS UNIT
US.BLK==1B5 ;LOCK BIT FOR THIS UNITS BATBLOCKS
US.PGM==1B6 ;DUAL PORT SWITCH IN (A OR B)
US.MAI==1B7 ;UNOT IS IN MAINT MODE
US.MRQ==1B8 ;MAINT MODE REQUESTED ON THIS UNIT
US.BOT==1B9 ;UNIT IS AT BOT
US.REW==1B10 ;UNIT IS REWINDING
US.WLK==1B11 ;UNIT IS WRITE LOCKED
US.MAL==1B12 ;MAINT MODE ALLOWED ON THEIS UNIT
US.OIR==1B13 ;OPERATOR INTERVENTION REQUIRED, SET AT
; INTERRUPT LEVEL, CHECKED AT SCHED.
US.OMS==1B14 ;ONCE A MINUTE MESSAGE TO OPERATOR. USED IN
; CONJUNCTION WITH US.OIR.
US.PRQ==1B15 ;POSITIONING REQUIRED ON THIS UNIT
US.TAP==1B16 ;DEVICE TYPE TAPE
US.IDB==1B17 ;TAPE - IDB SEEN ON PREVIOUS OPERATION.
BITS 32-35 CONTAIN UNIT TYPE CODE NAME IS USTYP
.UTRP4 = 1 ;RP04
.UTRS4 = 2 ;RS04 (DRUM)
.UTT16 = 3 ;TU16 (TU45)
.UTTM2 = 4 ;TM02 AS A UNIT
.UTRP5 = 5 ;RP05
.UTRP6 = 6 ;RP06
THE PLACES WHERE THINGS ARE ON THE DISK ARE AS FOLLOWS:
BLOCK 0: 11 BOOTSTRAP
BLOCK 1: PRIMARY HOME BLOCK
BLOCK 2: PRIMARY BAT BLOCK
BLOCKS 3-11: RESERVED
BLOCK 12 SECONDARY HOME BLOCK
BLOCK 13 SECONDARY BAT BLOCK
THE PLACES WHERE THE DISK PAGES FOR THE ABOVE ARE STORED IS IN THE TABLE HOME.
HOME IS DEFINED IN STG. THE BAT BLOCKS ARE DEFINED IN PROLOG AND THE HOME
BLOCKS ARE DEFINED IN DSKALC.
2040 AND 2050 PROC TABLE -- EXECUTIVE PROCESS TABLE
----------------------------------------------------
THE FIELD SERVICE REP. WILL HAVE INFORMATION ABOUT THE EPT IN THE
KL10 MAINTENANCE HANDBOOK. THE EPT IS IN PAGE TWO OF CORE. THE LOCATION
OF THE FIRST WORD IS DEFINED AS KIEPT==2000. THE FIRST TWO WORDS ARE DES-
CRIBED IN THE HANDBOOK. ALL YOU SHOULD CARE ABOUT IS HELPING THE F-S REP BY
MAPPING IN THE EPT. MOD B OR REL 3 KIEPT==76000.
1.4 ANALYSING DISK FILES WITH I/O ERRORS USEING THE PROGRAM READ.
________________________________________________________________
READ is a program that reads each page of a file and reports
any exception conditions that are detected. A file page can be
located on a section of the disk surface that is imperfect and
therefore some exceptional procedures are required to properly
read the data. Examples of these procedures are: ECC
correction and head-offset correction. The monitor will invoke
either or both of these techniques in an effort to read the
data. However, BOOT will use neither, and this presents a
serious problem. It is possible to write a new monitor file
and to read it with no reported errors by using the TOPS20 file
system and disk drivers. However, the same file may not be
readable by BOOT since one or more of the pages may be located
in a "correctable" location on the disk. READ was developed
specifically to test the viability of new monitor files so that
BOOT would not fail due to any of the standard correctable
exceptions. However it has proven to be useful for analyzing
files that are difficult to read reliably. For a host of known
and unknown reasons, the error correction circuitry does not
always succeed in detecting or analyzing the cause of a disk
read failure. Therefore, a file page that is located on a
"correctable" portion of a disk's surface may occasionally be
unreadable. An even more bizarre condition may arise when some
portion of the disk I/O logic (the DCL, the RH20, the Massbus
driver and cables,etc.) fails intermittently resulting in
trasient errors that may be recoverable or unrecoverable. READ
has evolved to test for all of the conditions so far described
and to provide as much information as possible about the state
of individual disk file pages and the disk I/O subsystem.
Clearly, hardware failures may produce unpredicatble results,
and no program can adequately protect itself from these
failures ( nor, alas, can it analyze the failures sufficiently
so that it will produce a reliable profile of the failure).
READ, however, has proven to be both a reliable analyzer of
"soft" disk failures, as well as a portent of impending channel
and/or device failures. Following is a description of each of
the messages produced by READ and a first-level interpretation
of the provocation: "?Hard error reading ... This error
indicates that a PT (page table), a page (file page within the
PT), or the PTT (page table table for long files) is
unreadable. None of the known error recovery techniques
sufficed and the data contents are probably lost. There is a
possibility that the page can be read on another drive or
another massbus controller (if the failure is pattern-
sensitive). ?Recoverable error reading ... This error
indicates that a PT, a page, or the PTT is located on a
"correctable" portion of the disk's surface. Again, it is
Page 2
possible that moving the pack to another drive or another
massbus controller will eliminate or change the condition.
However, the file in question will most likely not be readable
by BOOT. %Transient error reading ... This error indicates
that a PT, a page, or the PTT was readable without employing
extraordinary recovery techniques, but not on the first read
attempt. READ will attempt to read each page ten times before
resorting to error recovery. At least the first such attempt
resulted in an error, but one of the subsequent attempts
succeeded in reading the data. Such conditions are the most
difficult to analyze. There is a good chance BOOT will fail to
read the data; however, the cause of the problem is not
readily determined. If this error is reported for a number of
pages on the disk, then it is likely that some hardware failure
is imminent and that the disk surface is fine. If the error is
isolated to a very small number of pages, and is reported
consistently for these same pages, then the problem is likely
on the disk surface. If this error occurs randomly on the
disk, and repeated attempts to run READ result in different
collections of failures, then an intermittent hardware problem
is indicated. ?Check sum error reading ... This error
indicates that a PT or the PTT contains bad data. READ cannot
proceed with the file if it is a short file, or if the file is
long and the problem is in the PTT. In the case of a long
file, and one of its PT's has a check sum error, none of the
pages belonging to that PT can be read. Finally, a word on
using READ: READ prompts with: "File name(s) to verify: ".
The user may type a single file specification with or without
wild card characters ("*" or "%"). READ will process all files
indicated reporting any failures it finds. The user must be an
enabled wheel or operator in order to use READ.
2.0
RECOVERING FROM A BAD EXEC
--------------------------
This procedure is simply a rehash of the procedure for recovering
from the case in which the EXEC refuses to log in. for more
information see the article "Looking at the EXEC with DDT" which was
in the Large Buffer, issue 369 AND FOLLOWS AS THE NEXT CHAPTER.
If your system version of the EXEC blows up completely, you can
recover rather easily. You type a ^C on the CTY, and when the EXEC
blows up you will be dumped into the MINI-EXEC. Then you can use the
GET and START commands to read in a good version of the EXEC, either
from a copy on disk, or from the distribution magtapes.
If the problem with the EXEC is that it does not blow up, but it
still fails to let you log in, then you have a harder time. In this
case you have to bring up the system with the switches, and bring up
the system stand-alone. An example of what to do from the point where
the BOOT program is loaded follows:
BOOT>/L
BOOT>/G141
EDDT
DBUGSW[ 0 2
EDDTF[ 0 1
GOTSWM$B
147$G
GOTSWM$1B>> STEX+1/ HRROI T2,BOOTER+51 HRROI T2,FFF
FFF[ ""PS:<SYSTEM>OLD-EXEC.EXE"
FFF:
$B $P
^C
If you had no old version of the EXEC around, then change the name to
some garbage, so that the monitor can't find any such program. This
will then dump you into the MINI-EXEC, and then you can read a good
EXEC in from magtape.
In release 3 of the monitor, there is a new JSYS which is very
useful for debugging new versions of the EXEC. The CRJOB JSYS can
allow you to start up a new job with any program at all as it's top
level fork. You can also start the job not logged in. So you can
debug your new versions of the EXEC easily, with no possibility of
ripping yourself off.
2.1 EXEC DEBUGGING
______________________
NOW THAT MANY SWS HAVE MICRO FICHE OF THE RELEASE 3 EXEC AND MONITOR
I ANTICIPATE QUESTIONS ON LOOKING AT THE EXEC AND MONITOR. HERE IS A CURSORY
TUTORIAL ON INVESTIGATING THE INTERNALS OF THE EXEC (OR COMMAND PROCESSOR, IF
YOU PREFER.) THE EXAMPLES ARE INTENDED TO BE A GUIDE AND ALTHOUGH THE TYPEIN
IS CORRECT, THE RESPONSE MAY NOT BE CHARACTER PERFECT. YOU ARE ADVISED TO READ
THE CHAPTERS IN SECTION 3 OF THIS DOCUMENT FOR MORE INFORMATION ON DDT AND
MONITOR SNOOPING AND DEBUGGING.
LOOKING AT THE EXEC WITH DDT
============================
YOU CAN EITHER LOOK AT THE RUNNING SYSTEM EXEC OR YOUR OWN COPY
OF THE EXEC WITH DDT THAT IS LOADED WITH EXEC.
I. TO LOOK AT THE RUNNING EXEC:
FIRST YOU MUST HAVE WHEEL PRIVILEGES IN ORDER TO USE THE ^EEDDT COMMAND.
THE ^EEDDT COMMAND TRANSFERS CONTROL TO THE DDT NOW LOADED WITH EXEC,
WITH SYMBOLS. NOW YOU CAN DO ALL THE NORMAL DDT FUNCTIONS. TO EXIT
FROM DDT ALL YOU DO IS <ALT>G , ECHOED AS $G. THIS STARTS
YOUR PROGRAM WHICH IS THE EXEC AND SO NOW YOU ARE AT EXEC COMMAND LEVEL.
@ENA
$^EEDDT
DDT
.
.
.
$G
$DIS
@
II. TO LOOK AT YOUR COPY OF AN EXEC(RUNNING UNDER SYSTEM EXEC):
GET YOUR COPY OF THE EXEC IN YOUR ADDRESS SPACE, TRANSFER CONTROL TO IT
AND START DDT AS ABOVE. THERE ARE 3 WAYS TO EXIT FROM THIS DEPENDING
ON THE STATE YOU ARE IN. IF YOU ARE IN DDT YOU CAN ^Z OUT TO GET BACK
TO SYSTEM EXEC. IF YOU ARE RUNNING YOUR EXEC AND WANT TO EXIT TO THE
SYSTEM EXEC YOU CAN ^EQUIT(IF YOU ARE ENABLED) OR "POP" (IF YOU ARE NOT
ENABLED). POP IS PREFERABLE. NOTE IF YOU PREFER TO GET YOUR EXEC AND
NOT START IT IN ORDER TO SET BREAKPOINTS OR PUT IN PATCHES BEFORE RUNNING,
SEE SECTION "VI PATCHING" BELOW.
EXAMPLE EXITING FROM DDT:
@GET MYEXEC.EXE !
@SET NO CONTROL-C-CAPABILITY
@ST
@MONNAM.TXT, TOPS-20 MONITOR (VERSION#)
@ENA
$^EEDDT
DDT
.
.
.
CINITF/ -1 0 !RESET INITIALIZATION FLAG SO YOU CAN
!RUN THIS EXEC AGAIN AFTER IT IS SAVED.
.
^Z !TO EXIT AND SAVE, FOR EXAMPLE
@ !NOW YOU ARE IN THE MONITORS EXEC WITH YOUR EXEC IN
!YOUR ADDRESS SPACE. YOU CAN SAVE IT, SAY.
@SAV MYEXEC.EXE.2
EXAMPLE, EXITING FROM YOUR RUNNING EXEC:
@GET MYEXEC.EXE
@ST
@MONNAM.TXT,,TOPS-20 MONITOR(VERSION #)
@ENA
^EEDDT
DDT
.
.
$G !RUNNING YOUR EXEC
.
.
CINITF/ -1 0 !CLEAR INITIALIZATION FLAG
$^EQUIT !RETURN TO HIGHER (SYSTEM) EXEC
@ !YOU AREIN SYSTEM EXEC
@SAV NEWEXEC !ETC
EXAMPLE, EXITING FROM YOUR RUNNING EXEC WITH POP:
@GET MYEXEC.EXE
@ST
@MONNAM.TXT,,TOPS-20 MONITOR(VERSION#)
@.
.
.
@POP !RETURN TO HIGHER(SYSTEM)EXEC.
@ !NOW YOU ARE IN SYSTEM EXEC.
!NOTE: YOU SHOULD SET CINITF TO 0
!IF YOU WANT TO SAVE AND RUN THIS
!EXEC LATER. YOU CAN DO IT BY
!DDT AFTER THE POP OR ^EEDDT BEFORE
!THE POP.
III. GETTING OUT OF TROUBLE:
SINCE IT IS TRUE THAT YOU COULD GET INTO TROUBLE WITH YOUR EXEC
AND NOT BE ABLE TO GET OUT OF IT, CTRL C TRAPS OR YOU CAN'T POP OR
WHATEVER, THERE IS A WAY TO EXIT TO THE MINIEXEC ALWAYS. FIRST YOU
MUST ISSUE ^EQUIT TO GET INTO THE MINIEXEC. THEN "S" (START) TO GET
BACK TO THE SYSTEM EXEC. THEN GET INTO YOUR EXEC. IF YOU NOW GET INTO
TROUBLE YOU CAN ISSUE ^P WHICH WILL GET YOU BACK INTO THE MINIEXEC.
NOW YOU HAVE THE CHANCE TO GET BACK TO THE SYSTEM EXEC WITH "S" (START).
EXAMPLE:
@ENA
$^EQUIT
INTERRUPT AT 15657
MX>S
$ !YOU ARE NOW BACK IN SYSTEM EXEC.
$GET MYEXEC
$
$ST
@MONNAM.TXT, TOPS-20 MONITOR (VERSION)
. !LETS SAY YOU CANT DO ANYTHING REASONABLE
. !YOU ARE IN YOUR EXEC
. !GET OUT, GET INTO MINIEXEC
^P
INTERRUPT AT 12345
MX>S !MINIEXEC PROMPT FOLLOWED BY START.
$ !YOU ARE NOW IN THE SYSTEM EXEC.
REAL TROUBLE:
SUPPOSE YOU HAVE YOUR EXEC RUNNING AS THE TOP LEVEL FORK AND IT IS INSTALLED ON
SYS: AS <SYSTEM>EXEC.EXE AND SOMETHING REALLY AWFUL HAPPENS SUCH THAT YOU CANNOT
LOGIN OR GET TO THE MX> OR ANYTHING AND YOU HAVE CRASHED THE MONITOR AND YOUR
HOUSE BURNED DOWN AND THE CAT FELL IN THE WELL AND IT STARTED TO RAIN WHILE YOUR
CONVERTABLE TOP IS DOWN AND... SIGH. THE THING THAT WILL HAPPEN WHEN YOU TRY
TO BRING UP THE MONITOR IS THAT IT WILL ALWAYS FIND THE BAD PS:<SYSTEM>EXEC.EXE,
AND YOU CANNOT GET THE SYSTEM UP FAR ENOUGH TO RENAME A GOOD VERSION OR EVEN
GET INTO MX> TO GET ANOTHER EXEC. WELL, BRING THE SYSTEM UP WITH THE SWITCH
REGISTER RATHER THAN <ENA> <DSK>. SEE DEC-20 OPERATORS GUIDE FOR A DISCUSSION
OF THE SWITCH REGISTER SETTINGS PAGE 3-12 TABLE 3-1. AT THE BOOT PROMPT:
** NOTE RELEASE 3 PROTECTS YOU AGAINST THIS PRETTY WELL**
BOOT>/L ;LOADS <SYSTEM>MONITR.EXE
BOOT>/G141 ;STARTS MONITOR DDT (ALSO CALLED EDDT)
DDT
DBUGSW/0 2 ;DEBUG SWITCH
EDDTF/0 1 ;KEEP EDDT UPON STARTUP
GOTSWM$B ;BREAKPOINT WHEN YOU GET TO SWAPPABLE MONITOR
147$G ;START THE MONITOR
GOTSWM$1B>> ;SWAPPABLE MONITOR IN CORE
;NOW CHANGE THE STRING POINTER THAT POINTS TO
;PS:<SYSTEM>EXEC.EXE TO POINT TO FFF WHERE YOU PUT A
;GOOD EXEC NAME.
STEX+1/HRROI T2,BOOTER+51 HRROI T2,FFF
FFF/0 "/PS:<SYSTEM>OLDEXEC.EXE/
FFF: ;REDEFINE FFF
0$1B ;REMOVE THE BREAKPOINT
$P ;CONTINUE
;NOTE YOU COULD HAVE DONE WHATEVER WAS NECESSARY HERE
;TO SIMULATE THE ERROR RETURN FROM GTJFN SO YOU GO INTO
;THE MX> AND THEN YOU CAN DO ALL THE STUFF YOU WANT AS
;DESCRIBED IN THIS DOCUMENT. LOOK AT YOUR FICHE TO SEE
;HOW TO DO THIS.
IV. RUNNING YOUR EXEC AS A TOP LEVEL FORK:
SUPPOSE THAT YOU WANT TO RUN YOUR EXEC AS THE TOP LEVEL
EXEC, THAT IS, NOT RUNNING UNDER THE SYSTEM EXEC. GET INTO THE MINIEXEC
AND GET YOUR COPY OF THE EXEC AND RUN IT AS THE TOP LEVEL EXEC.
EXAMPLE:
@ENA
$^EQUIT
INTERRUPT AT 23456
MX>R !RESET ELSE YOU WILL MERGE RATHER THAN JUST GET
MX>G <MYAREA>MYEXEC.EXE.2
MX>S
@ !NOW YOU ARE IN YOUR EXEC
.
.
. !LETS SAY YOU WANT TO GET OUT
@^P
ABORT
MX>R !"RESET" RESETS YOUR ADDR SPACE
MX>E !YOU ARE REQUESTING THE SYSTEM EXEC
@ !YOU ARE IN SYSTEM EXEC
!NOTE! IF YOU HAD TYPED "S" RATHER THAN "E"
!ABOVE YOU WOULD HAVE RESTARTED YOUR EXEC.
V. OTHER INFORMATION:
THERE IS ONE ERROR MESSAGE WHEN TRYING TO START DDT "?" IMPLIES THAT
YOU DONOT HAVE SUFFICIENT PRIVILIGES ENABLED.
WHEN SEARCHING FOR SYMBOLS YOU MAY NOTICE THAT THE MODULE NAME
EDDT GIVES YOU IS DIFFERENT FROM THE MODULE NAMES THAT ARE ASSEMBLED
FOR THE EXEC. FOR EXAMPLE TO OPEN THE SYMBOL TABLE FOR EXECED YOU
SAY CANDE$: TO DDT.
THE FOLLOWING IS A CORRESPONDENCE LIST:
FILENAME.MAC INTERNAL REFERENCE
==================================
EXECDE.MAC XDEF
EXECGL.MAC XGLOBS
EXECPR.MAC PRIV
EXEC0.MAC EXEC0
EXEC1.MAC EXEC1
EXEC2.MAC EXEC2
EXEC3.MAC EXEC3
EXEC4.MAC EXEC4
EXECED.MAC CANDE
EXECCS.MAC CSCAN
EXECSU.MAC SUBRS
THE SOURCES AND .CTL FILE FOR ASSEMBLING THE EXEC ARE ON THE SWSKIT.
IF IT IS TRUE THAT UPON TRYING TO EXAMINE A LOCATION SYMBOLICALLY YOU
GET "U" IMPLYING THE SYMBOL IS UNDEFINED YOU MAY HAVE TO RESET THE SYMBOL TABLE
POINTERS. LOOK IN LOCATION 770001 FOR THE ADDRESS THAT CONTAINS THE SYMBOL TABLE
POINTER THEN LOOK AT LOCATION 116 TO FIND THE REAL SYMBOL TABLE POINTER. PUT THE
CONTENTS OF 116 IN THE LOCATION POINTED TO BY 770001.
116/ 762600,54463 !REAL SYMBOL TABLE POINTER
770001/ 776456 !LOC OF SYMB TAB POINTER.
776456/ 743200,,23540 762600,,54463
VI. PATCHING
THERE IS A PATCH COMMAND IN DDT. THE FORM IS AS FOLLOWS:
$< !PATCH BEFORE THIS INSTRUCTION
$$< !PATCH AFTER THIS INSTRUCTION
$> !END THIS PATCH FOLLOWING THIS INSTRUCTION
DDT WILL PUT THE PATCH IN THE EXEC PATCH AREA. THE SYMBOL IS PAT..
DDT WILL INSERT JUMPA 1,LOC+1 AND JUMPA 2,LOC+2 FOLLOWING THE PATCH YOU TYPED
IN. WHERE LOC IS THE LOCATION OF THE INSTRUCTION YOURE PATCHING. DDT THEN
REPLACES LOC, THE ORIGINAL INST., WITH A JUMPA XXXXX, WHERE XXXXX IS THE PATCH
AREA WHERE YOUR PATCH IS NOW. THEN THE PATCH AREA (PAT..) IS REDEFINED TO
FOLLOW YOUR LAST PATCH.
EXAMPLE:
GET A COPY OF <SYSTEM>EXEC, INSERT CALLS TO SUBROUTINE MUMBLE AND
SUBROUTINE FRATZ BEFORE LOCATION DING+1. DING+1 CONTAINS PRINT Q3 ORININALLY
AND CONTAINS A JUMPA TO THE PATCH AREA AFTER THE PATCH. THE PATCH AREA WILL
CONTAIN:
CALL MUMBLE
CALL FRATZ
PRINT Q3
JUMPA 1,DING+2
JUMPA 2,DING+3
USER TYPESCRIPT FOR THE ABOVE:
@ENA
$GET<SYSTEM>EXEC
$SAVE NUEXEC !YOU MUST SAVE AND GET IN ORDER TO WRITE
$GET NUEXEC !ENABLE THE EXEC TO USE DDT NOT ^EEDDT.
$DDT
DDT
EXEC0$: !OPEN SYMBOLS FOR MODULE WHERE DING IS
DING/ PUSH P,A !FIRST LOCATION IN ROUTINE "DING"
DING+1/ PRINT Q3 $< !BEGIN PATCHING BEFORE LOCATION DING+1
PAT../ 0 CALL MUMBLE !DDT OPENS UP PAT.. AREA, YOU ADD CODE
PAT..+1/CALL FRATZ !CONTINUE TO INSERT YOUR PATCH
$> !CLOSE THE PATCH
PAT..+2/ PRINT Q3 !THE ORIGINAL INSTRUCTION BEING REPLACED.
PAT..+3/ JUMPA 1,DING+2 !DDT INSERTS THIS RETURN.
PAT..+4/ JUMPA 2,DING+3 !INCASE A SKIP INST.
DING+1/ JUMPA 12345 !JUMPA TO PAT.. REPLACES ORIGINAL LOC.
$G !START YOUR COPY OF EXEC ETC.
3.0 CRASH DUMPS
===================
EACH TIME THERE IS A BUGHLT THERE IS AN AUTOMATIC DUMPING OF THE SYSTEM
CORE IMAGE INTO PS:<SYSTEM>DUMP.EXE. IF THERE IS SUFFICIENT ROOM ON THE DSK
THE DATA THAT WAS PREVIOUSLY IN DUMP.EXE WILL FIRST BE COPIED INTO DUMP.CPY.
DUMP.CPY DOES NOT GET DELETED AND YOU MAY FIND SEVERAL GENERATIONS OF DUMP.CPY.
IN THE CASE YOU HAVE SET NO AUTO RELOAD YOU CAN DUMP THE CRASH BY HAND BY
TYPING /D TO THE SYSTEM BOOT> PROMPT. YOU CAN GET INTO BOOT IF YOU ARE
RELOADING THE SYSTEM BY BRINGING THE SYSTEM UP FROM THE SWITCH REGISTERS
RATHER THAN HITTING <ENA> <DSK> IN THE CONSOLE. SEE THE OPERATORS GUIDE
PAGE 3-12 FOR A DISCUSSION OF THE MEANING OF THE VARIOUS SWITCHES ON THE
DEC-20.
3.1 CRASH ANALYSIS
_____________________
FIRST WHEN ANALYSING SOFTWARE OR SOFTWARE/HARDWARE PROBLEMS BE SURE YOU
HAVE THE PROPER TOOLS:
1. A SWSKIT ON MAGTAPE
2. A FULL COPY OF THE CURRENT RELEASE MICROFICHE MONITOR AND EXEC.
3. A MONITOR CALLS REFERENCE MANUAL.
4. A SYSERR MANUAL.
5. A LISTING OF THE SYSERR LOG, ESPECIALLY IF HDW IS SUSPECTED.
6. A CTY OUTPUT FOR BUGHLTS AND BUGINFS OR OTHER PROBLEM INDICATIONS, OR AN
ACCURATE REPRODUCTION OF THIS INFORMATION.
7. ANY OTHER MANUALS YOU MAY NEED FOR REFERENCE SUCH AS THE PROPER VERSION
INSTALLATION GUIDE, OPERATORS GUIDE, SYSTEM MGRS GUIDE ETC.
8. A TOPS-20.BWR FILE.
YOU WILLL NEED THE SWSKIT FOR IDDT AND PERHAPS LISTINGS OF THE
LATEST VERSIONS OF MONITOR MODULES IN CASE THE MICROFICHE ARE NOT UP
TO DATE. FILDDT IS ON THE CUSTOMERS DISTRIBUTION TAPE.
BE SURE YOU HAVE ANALYSED THE SYSERR LOG. BE SURE, ALSO, THAT YOU HAVE
LOOKED UP THE BUGHLT AND/OR BUGCHKS IN QUESTION IN THE LISTINGS (MICROFICHE) AND
HAVE AT LEAST READ THE COMMENTS AROUND THEM. PROBABLY TRACING DOWN HOW IT GOT
CALLED IS A GOOD IDEA. IF YOU HAPPEN TO BE WITHOUT A GLOB (PROVIDED ON MICROFICHE)
YOU CAN FIND THE BUGHLT TAG OF INTEREST IN THE MONITOR AS FOLLOWS:
GET<SYSTEM>MONITR.EXE
ST 140
DDT
ILPP3? ;BUGHLT OF INTEREST FOLLOWED BY "?"
PAGEM G ;IT IS DEFINED IN PAGEM AND IS GLOBAL
SOME OTHER USEFUL BITS OF INFORMATION. THERE IS A GLOB LISTING PROVIDED
IN THE MICROFICHE WHICH CONTAINS A LIST OF ALL THE GLOBAL SYMBOLS IN THE MONITOR.
MOST OF THE SYMBOLS ARE DEFINED IN THE MODULE STG.MAC. IF YOU DON'T KNOW A
TAG NAME BUT WANT TO LOOK AT THE STORAGE FOR DTES, SAY, LOOK THROUGH STG. STG
ALSO CONTAINS SOME SMALL PORTION OF CODE MOSTLY TO DO WITH RESTART, START, AUTO
RELOAD, DISPATCHES FOR PI CHANNELS AND A BIT OF SCHEDULER TESTS. STG STANDS
FOR STORAGE. NOTE THAT SOME STUFF MAY BE DEFINED IN PROLOG, AND OF COURSE LOTS
OF STUFF IS DEFINED THROUGHOUT THE MONITOR. YOU MAY ALSO WANT TO GET A
LISTING OF MACSYM TO BE ABLE TO UNDERSTAND THE MACROS YOU SEE WHILE READING THE
MONITOR LISTINGS, MONSYM IS ALSO USEFUL AT TIMES. BE SURE YOU KNOW HOW PARAMS
HAS BEEN CHANGED IN CASE IT HAS. SEE BUILD.MEM ON THE DISTRIBUTION TAPES FOR
THE CURRENTLY DISTRIBUTED INFORMATION ON WHAT TO DO TO CHANGE VARIOUS SYSTEM
PARAMETERS IN PARAM0.MAC. BE SURE THAT YOU KNOW ABOUT ANY VARIABLES THAT THE
SITE MAY HAVE CHANGED IN STG AS WELL.
EXAMINING THE MONITOR
---------------------
DEBUGGING A COMPLEX, MULTI-PROCESS SOFTWARE SYSTEM IS LARGELY A
MATTER OF ABSORBING SUFFICIENT KNOWLEDGE, EXPERIENCE AND FOLKLORE ABOUT THE
PARTICULAR SYSTEM WITH A CONSIDERABLE ELEMENT OF PERSONAL PREFERENCE, OR 'TASTE'
ALSO INVOLVED. THIS DOCUMENT IS A CURSORY DESCRIPTION OF FEATURES BUILT INTO
THE SYSTEM TO AID DEBUGGING, AND SUCH FOLKLORE AS CAN BE DESCRIBED IN WRITTEN
ENGLISH.
THERE ARE FIVE DIFFERENT VERSIONS OF DDT THAT MAY BE USED TO EXAMINE
THE MONITOR. EACH IS USED FOR A DIFFERENT PURPOSE AND HAS SPECIAL CAPABILITES.
THE VERSIONS OF DDT ARE:
1. UDDT(USER DDT) USED TO EXAMINE OR MODIFY THE MONITR.EXE FILE.
2. MDDT(MONITOR DDT) USED TO EXAMINE OR MODIFY THE RUNNING MONITOR
UNDER TIMESHARING.
3. EDDT(EXEC DDT) USED TO EXAMINE OR MODIFY THE RUNNING MONITOR FROM
THE CTY IN A STAND-ALONE MODE.
4. IDDT USED TO EXAMINE DUMPS.
5. FILDDT USED TO EXAMINE DUMPS.
ALL THE DDT'S EXCEPT IDDT AND FILDDT ARE VERSIONS OF TOPS-20 DDT DOCUMENTED
IN THE TOPS-20 DDT MANUAL, AND HAVE ALL OF THE FEATURES DESCRIBED IN THE
MANUAL. IDDT IS BASED ON AN OLDER VERSION OF DDT AND DOES NOT HAVE EDITING,
THE NEW PATCHING TOOL OR ANY OF THE OTHER NEW COMMANDS.
THE USE OF ALL FIVE VERSIONS OF THE DDT'S IS THE SAME AND WILL BE
DESCRIBED LATTER, HOWEVER, EACH VERSION IS STARTED DIFFERENTLY.
UDDT:
TO USE UDDT TO MODIFY YOUR MONITR.EXE FILE ON SYSTEM,
YOU MUST GIVE THE FOLLOWING EXEC COMMANDS:
@GET <SYSTEM>MONITR.EXE
@START 140
THIS CAUSES EDDT TO START IN USER MODE.
THIS IS THE SAME DDT THAT IS USED WHEN EXAMINING ANY PROGRAM. YOU MAY
NOW LOOK AT OR CHANGE ANY PART OF THE MONITOR. IF YOU MAKE CHANGES TO THE
MONITOR AND WANT TO SAVE IT, YOU SHOULD GET BACK TO THE EXEC BY TYPING ^Z.
THEN YOU MAY SAVE THE MONITOR.
YOU WILL PROBABLY HAVE TO BE ENABLED INORDER TO SAVE THE MONITOR
BACK IN <SYSTEM>. THIS IS THE SAFEST, BEST AND RECOMENDED METHOD OF PUTTING
PATCHES INTO THE MONITOR.
MDDT:
A VERSION OF DDT WHICH RUNS IN MONITOR SPACE IS AVAILABLE. IT CAN
EXAMINE AND CHANGE THE RUNNING MONITOR, AND CAN BREAKPOINT CODE RUNNING AS A
PROCESS BUT NOT AT PI OR SCHEDULER LEVEL. WHEN PATCHING OR BREAKPOINTING THE
SWAPPABLE MONITOR, THE NORMAL WRITE PROTECTION MUST BE DEFEATED, EITHER BY
SETTING DBUGSW=2 ON STARTUP, OR CALLING SWPMWE. IF YOU INSERT BREAKPOINTS
WITH MDDT, REMEMBER MONITOR CODE IS REENTRANT AND SHARED SO THAT THE BREAKPOINT
COULD BE HIT BY ANY OTHER PROCESS IN THE SYSTEM, IN THIS EVENT, THE OTHER
PROCESS WILL MOST LIKELY CRASH SINCE IT WILL BE EXECUTING A JSR TO A PAGE FULL
OF 0S.
TO USE MDDT YOU MUST HAVE WHEEL OR OPERATOR CAPABILITIES. YOU FIRST
ISSUE THE EXEC COMMAND:
@ENABLE
AFTER THE EXEC PROMPTS WITH A $, YOU GIVE THE COMMAND:
$^EQUIT
YOU ARE NOW IN THE MINI-EXEC AND RECIEVE A PROMPT OF MX>.
NOW YOU GIVE THE "/" COMMAND:
MX>/
YOU ARE NOW PUT INTO MDDT. TO RETURN TO THE EXEC YOU CAN ISSUE A ^Z OR
A ^C WHICH PRODUCES A MESSAGE LIKE "INTERRUPT AT 17372" AND
RETURNS YOU TO THE MINI-EXEC. IF YOU TYPE A ^P IN MDDT YOU WILL GET
A MESSAGE, "ABORT", AND BE RETURNED TO THE MINI-EXEC. IF YOU ONCE
GO INTO THE MINI-EXEC THE CONTROL-P INTERRUPT IS ENABLED AND TYPING THIS
CHARACTER WILL RETURN YOU TO THE MINI-EXEC. THIS IS A GOOD THING TO
USE WHEN DEBUGGING PROGRAMS THAT DO CONTROL=C TRAPPING. FROM THE MINI-EXEC
YOU MAY GIVE EITHER:
MX>S
OR
MX>E
THE S IS FILLED OUT AS START AND THE E AS EXEC. BOTH OF THESE COMMANDS
WILL RETURN YOU TO THE EXEC. SEE THE DOCUMENT EXEC-DEBUGGING.MEM FOR MORE
ABOUT ^P AND GETTING OUT OF THE EXEC TO MX> AND RETURNING FROM MX> TO EITHER
YOUR COPY OF THE EXEC OR THE SYSTEM EXEC.
YOU MAY ALSO GIVE THE COMMAND:
MRETN$G
FROM MDDT TO RETURN DIRECTLY TO THE EXEC. WHILE IN MDDT YOU MAY EXAMINE
ANY CORE LOCATION IN THE RUNNING MONITOR. YOU MAY ALSO CHANGE ANY LOCATION
IN THE RESIDENT MONITOR. (DONE FREQUENTLY BY ACCIDENT). IF YOU WISH TO
CHANGE ANY OF THE LOCATIONS IN THE SWAPPABLE MONITOR YOU MUST GIVE THE COMMAND:
CALL SWPMWE$X
TO WRITE ENABLE THE MONITOR. AFTER YOU HAVE MADE YOUR CHANGES YOU MUST GIVE
THE COMMAND:
CALL SWPMWP$X
TO WRITE PROTECT THE MONITOR AGAIN.
EDDT:
***(NOT TO BE CONFUSED WITH ^EEDDT COM
-MAND TO GET INTO EDDT USED WITH THE
COMMAND PROCESSOR. SEE SEPARATE DOCUMENT
EXEC-DEBUGGING.MEM FOR THAT.)***
TO GET INTO EDDT YOU MUST BRING THE SYSTEM UP USING THE SWITCH-REGISTER.
SEE PAGE 3-12 OF THE DECSYSTEM-20 OPERATORS GUIDE FOR A DISCUSSION OF SWITCHES.
GO THROUGH THE KLINIT DIALOG AND WHEN YOU GET THE PROMPT BOOT>, RESPOND WITH:
BOOT>/L
BOOT>/G141
THE "/L" COMMAND CAUSES THE MONITOR TO BE LOADED, BUT NOT STARTED. THE
"/G141" START THE MONITOR AT LOCATION 141, WHICH IS A JUMP TO EDDT. YOU
CAN USE EDDT LIKE UDDT UNDER TIMESHARING ON THE MONITR.EXE BY GIVING THE
FOLLOWING COMMANDS
@GET <SYSTEM>MONITR.EXE
@START 140
EDDT IS LINKED INTO THE MONITOR AND IS ALWAYS THERE. YOU MAY ALSO GET TO
EDDT FROM MDDT BY ISSUEING THE FOLLOWING:
EDDT$G
FROM MDDT. THIS STOPS TIMESHARING. TO RESUME TIMESHARING AND /OR GET
BACK TO MDDT GIVE THE COMMAND:
MDDT$G BACK TO MDDT
MRETN$G BACK TO NORMAL TIMESHARING
BREAKPOINTS MAY BE INSERTED IN THE RESIDENT MONITOR WITH EDDT, BUT NOT
IN THE SWAPPABLE MONITOR IN GENERAL, BECAUSE ITS PAGES MAY BE SWAPPED OUT AND
BE UNAVAILABLE TO EDDT. YOU CAN BRING IT IN BY TYPING SKIP LOC$X (WHERE LOC
IS SOME ADDRESS NOT IN CORE.)
THERE ARE SOME LOCATIONS IN THE MONITOR THAT ARE VERY USEFUL WHEN USING
EDDT FOR DEBUGGING. THEY MUST BE SET BEFORE GOING ON TO START THE MONITOR.
THEY ARE:
EDDTF 1 KEEP EDDT IN CORE WHEN SYSTEM COMES UP
0 DELETE DDT WHEN SYSTEM COMES UP (DEFAULT)
DBUGSW 0 DO NOT STOP ON BUGHLTS
1 STOP ON BUGHLTS AND RELOAD (DEFAULT)
2 WRITE ENABLE SWAPPABLE MONITOR, DO NOT START UP SYSJOB
AND STOP ON BUGHLTS. ALLOWS YOU TO REWRITE THE HOME BLOCKS
WITHOUT REFRESHING THE FILE SYSTEM DURING FILE SYSTEM
INITIALIZATION. YOU GET TO ANSWER THE QUESTION
"DO YOU WANT TO REPLACE THE FILE SYSTEM ON THE PS:?"
BY SAYING "NO" AD
"DO YOU WANT TO DEFINE THE PUBLIC STRUCTURE
THIS WILL CAUSE THE HOME BLOCKS TO BE REWRITTEN..."
YOU CAN ANSWER YES TO THIS IN SPITE OF THE
WARNING TO THE CONTRARY.
ALSO IT DOSENT RUN CHECKD AUTOMATICALLY ON STARTUP.
DOES NOT TYPE OUT SYSTEM RESTARTING WAIT ETC.
DO NOT SET TIME AND DAY (SEE DTESRV TO CHECK ON THIS)
DCHKSW 0 DO NOT STOP ON BUGCHKS (DEFAULT)
1 STOP ON BUGCHKS
DINFSW 0 DO NOT STOP ON BUGINFS (DEFAULT)
1 STOP ON BUGINFS
IN ADDITION THE SYMBOL GOTSWM APPEARS IN THE CODE JUST AFTER THE SWAPPABLE
MONITOR IS LOADED; SO, IF YOU WANT TO DEBUG THE SWAPPABLE PART OF THE MONITOR
YOU MUST PUT A BREAKPOINT AT GOTSWM (TO GET SWAPPABLE PART IN CORE) BY,
GOTSWMB
THEN START THE MONITOR BY,
147G
CALL SWPMLK$X
CALL SWPMLK IS USED TO LOCK SWAPPABLE MONITOR IN CORE FOR DEBUGGING. YOU MUST
HAVE MORE THAN 96K OF CORE TO GIVE THIS COMMAND SINCE THE RESIDENT AND SWAPPABLE
MONITOR ARE LARGER THAN 96K. TO START UP THE MONITOR AFTER YOU HAVE GONE INTO
EDDT AND SET UP YOUR BREAKPOINTS (REMEMBER 7 AND 8 ARE USED FOR BUGHLT AND
BUGCHK) GIVE THE COMMAND:
147$G
OR
SYSGO1$G
IF YOU ARE IN EDDT AND DBUGSW IN NOT 2, THAT IS THE MONITOR IS WRITE PROTECTED,
YOU CAN USE THE ROUTINES SWPMWE AND SWPMWP TO WRITE ENABLE AND WRITE PROTECT
THE MONITOR. CALL SWPMWE$X IN DDT.
IDDT:
TO USE IDDT YOU MUST FIRST ISSUE THE COMMAND:
TERMINAL NO PAGE
THEN RUN A COPY OF IDDT.EXE. THIS SHOULD BE ON
YOUR SOFTWARE SUPPORT KIT TAPE. WHEN YOU GET INTO IDDT ISSUE THE COMMANDS:
$YANK FILE:<SYSTEM>MONITR.EXE
^S
STORE SYMBOLS ON FILE:MONITR.SYMBOLS
FOR THE YANK COMMAND YOU TYPE "$Y" AND IDDT RESPONDS WITH "ANK FILE:".
FOR THE STORE SYMBOLS COMMAND THE "^S" IS ALL THAT IS TYPED AND IDDT
RESPONDS WITH THE "STORE SYMBOLS ON FILE:". IF YOU HAVE YOUR TERMINAL IN
PAGED MODE THE CONTROL S WILL BE TRAPPED BY THE TERMINAL HANDLER AND WILL
NEVER GET TO IDDT. ALSO YOU SHOULD BE SURE AND GET THE SYMBOLS FROM THE
SAME VERSION OF THE MONITOR AS THE MONITOR IN THE DUMP YOU WANT TO LOOK AT.
IT IS A GOOD IDEA TO GIVE THE SYMBOLS FILE THE SAME VERSION NUMBER AS THE
MONITR.EXE FILE. THIS WAY YOU WILL KNOW WHICH VERSION OF THE MONITOR IT
GOES WITH AND THE NEXT TIME THAT YOU WANT TO LOOK AT A DUMP YOU CAN OMIT
THE ABOVE STEPS IF THE FILE CONTAINING THE SYMBOLS IS STILL AROUND. NEXT
YOU GIVE THE FOLLOWING COMMANDS:
$YANK FILE:<SYSTEM>DUMP.CPY
$$YANK SYMBOL FILE:MONITR.SYMBOLS
YOU ONLY TYPE THE $Y AND $$Y IN THE ABOVE COMMANDS. ALSO, IT MAY BE NECESSARY
TO GIVE GENERATION NUMBERS IN THE FILE NAMES TO GET THE CORRECT VERSIONS.
YOU ARE NOW READY TO LOOK AT THE MONITOR.
THE RESIDENT MONITOR MAY BE LOOKED
AT WITHOUT ANY DIFFICULTIES, BUT THE SWAPPABLE MONITOR MAY NOT BE IN CORE
AT THE TIME OF THE DUMP. IF THE VALUE OF THE SYMBOL IS IN
THE SWAPPABLE MONITOR YOU MUST GO THROUGH THE MONITOR MAP TO FIND WHERE
THE LOCATION REALLY IS. THE LOCATION MONCOR CONTAINS THE NUMBER OF PAGES
OF RESIDENT MONITOR AND THE LOCATION SWPCP0 CONTAINS THE FIRST PAGE OF REAL CORE
FOR SWAPPING. SO IF THE VALUE OF THE SYMBOL IS GREATER THAN CONTENTS OF MONCOR
TIMES 1000 THEN IT IS IN SWAPPABLE MONITOR. THE VALUES FOR RELEASE 2 ARE AS
FOLLOWS:
MONCOR SWPCP0
MONMIN 110
MONBCH 115 214
MONSML 124 223
MONMED 140 237
MONBIG 160 257
THE RELEVANT VALUES FOR THE PSECTS FOR RELEASE 3 ARE COPIED HERE FROM THE
LINK CCL FILE USED TO LOAD THE REL 3 MONITOR:
TTY:/LOG/LOGL:5
MON/SAVE,/HASHSIZE:8001, -
/SET:RSCOD:1000, -
/SET:INCOD:55300, -
/SET:RSVAR:71000, -
/SET:POSTCD:74000, -
/SET:BGSTR:276000, -
/SET:BGPTR:306000, -
/SET:PPVAR:307000, -
/SET:NRVAR:313000, -
/SET:NRCOD:344000, -
/SET:NPVAR:536000, -
/NOLOCALS, -
SYS:MONSYM.REL, -
DSK:LDINIT, -
VERSIO,STG, -
/LOCALS, -
TOPS20/S, -
/SYSLIB, -
/G
IF THE PAGE OF THE SWAPPABLE MONITOR YOU WANT TO LOOK
AT IS IN CORE IT WILL PROBABLY NOT BE IN CORE IN THE LOCATION THAT IT'S ADDRESS
REFER TO SINCE THE DUMP IS OF CORE AND RELOCATION OF PAGES DOES NOT HAPPEN.
TO FIND WHERE A SYMBOL REALLY IS IN THE DUMP, FIRST TYPE THE SYMBOL FOLLOWED BY
AN "=". IDDT WILL RESPOND WITH THE VALUE OF THIS SYMBOL. THE VALUE OF THE
SYMBOL CAN BE DIVIDE INTO TWO, THREE OCTAL DIGIT, FIELDS. THE HIGH ORDER THREE
DIGITS ARE THE PAGE NUMBER AND THE LOW ORDER THREE DIGITS ARE THE OFFSET INTO
THE PAGE.
IF THE VALUE OF THE SYMBOL IS 324621 THE HIGH ORDER THREE DIGITS,
324, ARE THE PAGE NUMBER AND THE LOW ORDER THREE DIGITS, 621, ARE THE OFFSET
INTO THE PAGE. TO FIND THE LOCATION OF THE PAGE IN QUESTION IN THE DUMP YOU
MUST LOOK AT THE MONITOR MAP INDEXED BY THE PAGE NUMBER. FOR EXAMPLE:
MMAP+324/
WOULD GIVE YOU THE MONITOR MAP WORD FOR PAGE 324. THIS WORD CONTAINS
SOME PROTECTION BITS FOR THE PAGE AND THE ADDRESS OF THE PAGE WHEN THE DUMP
WAS TAKEN.
THE PAGE MAY HAVE BEEN IN CORE, ON THE SWAPPING AREA OR ON
THE DISK AT THE TIME OF THE DUMP.
IF BITS 14-17 IF THE MONITOR MAP WORD ARE NON-ZERO
THE PAGE WAS ON THE SWAPPING AREA OR DISK AND IS NO LONGER AVAILABLE.
IF BITS 14-17
ARE ZERO THEN THE PAGE WAS IN CORE, AND THE RIGHT HALF OF THE WORD CONTAINS
THE PAGE NUMBER IN THE DUMP OF THE PAGE YOU ARE LOOKING FOR. (THE DUMP
PROGRAM OVERWRITES THE LAST NINE PAGES OF MEMORY, THE DUMP THEREFORE DOES
NOT CONTAIN THESE LAST NINE PAGES.)
IF THE PAGE WAS IN CORE THE NEW ADDRESS
OF THE SYMBOL YOU ARE LOOKING FOR CAN BE FOUND BY USING THE PAGE NUMBER FROM
THE MONITOR MAP WORD AND APPENDING THE OFFSET INTO THE PAGE TO IT. FOR
EXAMPLE IF MMAP+324 CONTAINS 104000,,256, THEN THE NEW ADDRESS OF OUR SYMBOL
WOULD BE 256621.
ALL ADDRESS IN THE SWAPPABLE MONITOR MUST BE RESOLVED IN
THIS MANNER. IN ADDITION ADDRESS OF 600000 AND ABOVE ARE IN THE JSB OR PSB
(PSB IS PAGE 777) AND MUST BE RESOLVED BY FINDING THE PAGE CONTAINING THE JSB
OR PSB OF THE PROCESS THAT WAS RUNNING WHEN THE DUMP OCCURED. THERE ARE SOME
LOCATIONS AND TABLES IN THE MONITOR THAT MAKE THIS EASY:
LOC INDEX DESCRIPTION
FORKX NONE NUMBER OF THE FORK THAT WAS RUNNING AT THE TIME OF
THE DUMP, -1 IF IN THE SCHEDULER.
JOBNO IN PSB JOB NUMBER TO WHICH CURRENT FORK BELONGS.
FKJOB FORK # JOB NUMBER,,SPT INDEX OF JSB
JOBDIR JOB # CONNECTED DIRECTORY NUMBER,,LOGGED IN DIRECTORY NUMBER
JOBPT JOB # CONTROLING TTY NUMBER,,TOP FORK NUMBER
FKSTAT FORK # TEST DATA,,ADDRESS OF FORK WAIT ROUTINE
FKPGS FORK # SPT INDEX OF PAGE TABLE,,SPT INDEX OF PSB
SPT INDEXES ARE INDEXES INTO A SHARE POINTER TABLE STARTING AT SPT.
TO FIND THE PSB OF FORK 20,
YOU FIRST LOOK AT FKPGS+20. IF THIS LOCATION CONTAINS
425,,426, THE WORD AT SPT+426 IS THE POINTER TO THE PSB. THIS POINTER CAN
POINT TO DISK, SWAP AREA, OR A PAGE IN THE DUMP. IF BITS 14-17 ARE ZERO IT
IS A POINTER TO A PAGE IN THE DUMP AND THE RIGHT HALF OF THE SPT WORD IS
THE PAGE NUMBER OF THE PSB IN THE DUMP.
WHEN YOU LOOK AT A DUMP, YOU SHOULD FIRST TRY TO FIND WHY THE DUMP
OCCURED BY LOOKING AT THE LOCATION BUGHLT. IF BUGHLT IS ZERO THEN YOU
SHOULD CHECK THE CTY LOG TO FIND OUT WHY THE DUMP WAS TAKEN AND FOR
INFORMATION LIKE THE PC AT THE TIME OF THE DUMP AND THE STATUS OF THE
PI SYSTEM. IF BUGHLT IS NON-ZERO IT IS THE ADDRESS OF WHERE THE BUGHLT WAS
ISSUED. YOU SHOULD LOOK UP THE BUGHLT IN BUGSTRINGS.TXT TO FIND ADDITIONAL
INFORMATION ABOUT THE BUGHLT. IF AT THIS POINT YOU ARE NOT SURE AS TO WHY
THE BUGHLT OCCURED, YOU WILL HAVE TO LOOK AT THE LISTINGS FOR MORE INFORMATION.
A COPY OF BUGSTRINGS.TXT IS IN APPENDIX A OF THE OPERATORS MANUAL.
YOU CAN FIND THE LOCATION OF THE CALL TO THE BUGHLT BY TYPING THE BUGHLT
TAG TO DDT FOLLOWED BY A "?". DDT WILL TELL WHICH MONITOR MODULE THE BUGHLT
IS IN AND YOU CAN GO TO YOUR MICROFICHE AND READ ALL ABOUT THE CONDITIONS
PRECIPITATING THE BUGHLT.
NEXT IF NECESSARY LOOK AT FORKX. IF IT CONTAINS A -1 THE SCHEDULER
WAS RUNNING OTHERWISE IT IS THE NUMBER OF THE FORK THAT WAS RUNNING WHEN
THE DUMP OCCURED. THE REGISTERS ARE SAVED AT BUGACS ON A BUGHLT, BUT IF
BUGACS+17 CONTAINS SOMETHING,,BUGPDL+N, THEN THE REGISTERS ARE INVALID AND YOU
MUST GO TO THE SYSERR BUFFER TO GET THE GOOD REGISTERS. THIS IS DONE BY
ADDING TO THE RIGHT HALF OF THE SYSERR BUFFER POINTER, SEBQOU, THE OFFSET
INTO THE BUFFER FOR THE HEADING AND ACS, SEBDAT+BG%ACS. THIS VALUE POINTS
TO A 16 BLOCK OF WORDS CONTAINING THE USERS ACS.
***NOTE***
DO NOT FORGET TO GET A PRINT OUT OF THE SYSERR LOG WHICH WILL GIVE
YOU AND THE FIELD SERVICE REPRESENTATIVE MUCH OF THE INFORMATION YOU CAN
GET OUT OF THE DUMP. THE SYSERR OUTPUT IS MUCH EASIER TO EXAMINE, HOWEVER,
CLEARLY YOU CANNOT GET AS MUCH INFO AS YOU CAN FROM A DUMP.
SOME OTHER LOCATIONS IN THE PSB OF INTEREST ARE:
LOCATION DESCRIPTION
UAC USER'S ACS WHEN HE DID HIS LAST JSYS.
PAC MONITORS ACS
PPC PROCESSORS PC
UPDL USERS PUSHDOWN STACK
NSKED 0 = OK TO RUN SCHEDULER
1 = CANNOT RUN SCHEDULER
INTDF = -1 , OK TO RECIEVE SOFTWARE INTERRUPTS
>= 0 , CANNOT RECIEVE SOFTWARE INTERRUPTS
IT MAY BE USEFUL TO KNOW THE STATUS OF A FORK WHEN IT IS HUNG OR
YOU ARE UNSURE OF ITS STATUS. THIS CAN BE DETERMINED BY LOOKING AT FKSTAT
INDEXED BY THE FORK NUMBER. THE RIGHT HALF OF THIS LOCATION IS THE ADDRESS
OF A TEST ROUTINE AND THE LEFT HALF IS DATA TO BE TESTED. FOR EXAMPLE
IF FKSTAT+12 CONTAINS 23,,FKWAT, THEN FORK 12 IS WAITING FOR FORK 23 TO
COMPLETE. FKWAT IS A ROUTINE THAT WAITS FOR ANOTHER FORK TO COMPLETE AND
IT'S DATA (THE LEFT HALF OF THE WORD) IS THE NUMBER OF THE FORK IT IS WAITING
FOR. THERE ARE MANY DIFFERENT WAIT ROUTINES AND YOU WILL HAVE TO LOOK AT THE
CODE TO SEE WHAT INDIVIDUAL ONES ARE WAITING FOR.
YOU CAN EASILY DETERMINE ALL OF THE FORKS ASSOCIATED WITH A JOB BY
GIVING THE COMMANDS:
$M/ -1 -1,,0
FKJOB<FKJOB+NFKS>N,,0$W
WHERE N IS THE JOB YOU ARE LOOKING FOR. A FORK STRUCTURE CAN USUALLY
BE DETERMINED BY LOOKING AT THE FKSTAT OF THE FORKS AND SEEING WHICH FORKS
ARE WAITING ON WHICH FORKS. A FKSTAT OF FKSKP INDICATES A FORK IS INACTIVE.
YOU SHOULD REFER TO STG.MAC FOR OTHER FORK AND JOB TABLES AND OTHER
LOCATIONS IN THE PSB AND JSB OF INTEREST. ALL OF THE ABOVE LOCATIONS CAN BE
EXAMINED WITH MDDT OR EDDT WHILE THE MONITOR IS RUNNING. OF COURSE AT THESE
TIMES YOU DO NOT HAVE TO GO THROUGH MMAP AND THE PSB AND JSB THAT ARE IN
CORE ARE YOUR OWN.
THERE ARE TWO SEPERATE PATCH AREAS IN THE MONITOR (FFF AND SWPF).
FFF IS THE RESIDENT PATCH AREA AND SWPF IS THE SWAPABLE PATCH AREA. THESE
TWO SYMBOLS SHOULD BE UPDATED TO POINT TO THE NEXT FREE LOCATION IN THE
PATCH AREA WHEN A PATCH IS INSERTED. PAT.. IS DEFINED TO BE EQUAL TO SWPF.
THERE ARE SEVERAL GENERAL PURPOSE ROUTINES THAT CAN BE USED TO LOOK AT
THE THE MONITOR WHILE IT IS RUNNING. THESE ROUTINES SHOULD BE USED WITH
CAUTION SINCE IT IS CERTAINLY POSSIBLE TO CRASH THE MONITOR BY USING THEM
INCORRECTLY. TWO OF THE MORE GENERAL ROUTINES ARE MAPDIR, FOR MAPPING A
DIRECTORY INTO CORE, AND SETMPG FOR MAPPING PAGES (SOMEONE ELSES PSB OR JSB)
INTO CORE. YOU WILL HAVE TO LOOK AT THE LISTING FOR THE EXACT USE OF THESE
AND OTHER GENERAL ROUTINES. BEWARE OF THE PRECAUTIONS THAT SHOULD BE TAKEN
WHEN USING THEM. YOU CAN FIND THE MODULE THEY ARE LOCATED IN BY LOOKING IN
THE GLOB LISTING WHICH IS A CROSS REFERENCE LISTING OF ALL THE GLOBAL SYMBOLS
IN THE MONITOR. YOU GET A GLOB LISTING IN YOUR MICROFICHE.
MDDT:
IF YOU WISH TO EXAMINE THE SYSTEM FROM THE EXECS INFERIOR FORK MONITOR
CONTEXT:
ENA
SDDT
JSYS 777$X
TO RETURN TO USER CONTEXT:
MRETN$G
USE SETMPG TO MAP PAGES TO THIS CONTEXT:
PAGE 677 IS TRADITIONALLY USED FOR THIS:
AC2/ ACCESS,,67700
IF PAGE HAS ITS OWN SPT SLOT:
AC1/SPT INDEX
IF PAGE DOES NOT HAVE ITS OWN SPT SLOT, IT WILL BELONG TO EITHER A FILE OR
PROCESS PAGE TABLE. IT WILL BE REPRESENTED AS AN INDEX INTO THIS PAGE TABLE:
AC1/ SPT INDEX OF PAGE TABLE,,INDEX INTO PAGE TABLE
ACCESS = READ OR/AND OR WRITE ACCESS
READ/WRITE ACCESS = 140000 IN LH
THEREFORE, TO MAP A PAGE, CALL WITH EITHER:
AC1/SPT INDEX OF PAGE OR AC1/SPT INDEX OF PAGETABLE,,INDEX INTO
PAGE TABLE
AC2/140000,,677000 AC2/140000,,677000
AND SAY: CALL SETMPG$X
THE PAGE WILL THEN BE MAPPED TO PAGE 677. IN EXAMINING LOCATIONS 677000-677777,
YOU WILL BE LOOKING AT THE CONTENTS OF THE PAGE.
IF YOU DESIRE TO MAP ANOTHER PAGE INTO THIS SLOT, MERELY CALL SETMPG
AGAIN WITH ARGUMENTS FOR THE NEW PAGE. YOU NEED NOT FIRST UN-MAP THE OLD PAGE.
HOWEVER, WHEN YOU ARE FINISHED, PAGE 677 SHOULD BE UN-MAPPED IN THE FOLLOWING
MANNER:
AC1/0
AC2/ACCESS,,677000
CALL SETMPG$X
WARNING:
CALLING SETMPG INCORRECTLY CAN CRASH THE SYSTEM. BE CAREFUL! DO NOT
USE SETMPG ON A TIME SHARING SYSTEM IF A CRASH WILL CAUSE BAD FEELINGS.
FILDDT:
FILDDT IS DISTRIBUTED ON THE CUSTOMER SOFTWARE TAPE. WE HAVE IN ADDITION
INCLUDED AN EXPERIMENTAL FILDDT ON THE SWSKIT WHICH ENABLES US TO LOOK AT
SECTIONS OTHER THAN 0/1 IN THE CASE THE CUSTOMER HAS A MOD B MACHINE. IN
SPITE OF THE FACT THAT RELEASE 3 DOES NOT "TAKE ADVANTAGE" OF MULTISECTION
MACHINES IN ORDER TO IMPROVE PERFORMANCE AS PER THE RELEASE 3 PROJECT PLAN
IT IS TRUE THAT RELEASE 3 DOES INDEED USE SECTION 0/1 AS WELL AS 2 AND 3.
THERE IS CODE WHICH IS SIMPLY REMOVED FROM SECTION 0/1 AND PLACED IN ANOTHER
SECTION WITHOUT ADDING ANYTHING TO 0/1.
THE FOLLOWING IS AN EMBELLISHED FILDDT.HLP FILE.
GET(FILE) FILE-SPEC
LOADS A FILE FOR DDT TO EXAMINE. IF YOU ARE LOOKING AT A MONITOR DUMP
YOU MUST LOAD DUMP.CPY EXPLICITLY. FILDDT LOOKS FOR MUMBLE.EXE NOT MUMBLE.CPY
THAT IS DUMP<ESC> WILL TELL YOU THAT THERE IS NO SUCH FILE OR WILL LOAD
DUMP.EXE. WHEN LOOKING AT A DUMP AND YOU WISH TO LOAD THE SYMBOLS YOU MUST
FIRST ISSUE THE LOAD COMMAND FOLLOWED BY THE GET COMMAND. BE SURE THAT THE
FILE FROM WHICH YOU GET THE SYMBOLS IS THE SAME VERSION AS THE DUMP. BE
SURE, ALSO THAT THE MONITOR THAT WAS DUMPED IS THE SAME MONITOR YOU USE FOR
SYMBOLS. THAT IS DON'T GET MONMED SYMBOLS TO USE WITH MONBCH ETC,
LOAD (SYMBOLS FROM) FILE SPEC
READS SPECIFIED FILE AND BUILDS INTERNAL SYMBOL TABLE. THIS MUST BE THE
FIRST COMMAND TO FILDDT BEFORE "GET" WHEN LOOKING AT A DUMP. YOU WILL MOST
PROBABLY USE <SYSTEM>MONITR.EXE WHICH WOULD HAVE BEEN THE MONITOR
RUNNING AT THE TIME OF THE DUMP. NOTE THAT THIS COMMAND WILL NOT READ A SYMBOL
FILE CREATED BY IDDT.
EXIT (FROM FILDDT)
RETURNS TO COMMAND LEVEL. YOU THEN MAY TYPE A SAVE COMMAND IF A LOAD
COMMAND WAS JUST DONE TO PRELOAD SYMBOLS. YOU WILL GET A VERSION OF FILDDT THAT
HAS THE SYMBOLS YOU JUST LOADED IN IT SO YOU NO LONGER NEED TO "LOAD" SYMBOLS.
YOU NOW HAVE A MONITOR SPECIFIC FILDDT.
HELP
TYPES THIS TEXT. (A SUBSET, THAT IS.)
ENABLE PATCHING
ALLOWS WRITING ON AN EXISTING FILE SPECIFIED BY A GET.
ENABLE DATA-FILE
ASSUMES FILE IS RAW BINARY (I.E. NO ACS).
DDT FEATURES:
N$U SETS SPT INDEX (N) FOR INDEX BLOCK TO BE USED FOR VIRTUAL ADDRESSES
IN EXAMINING THE FILE.
<CTRL/E> RETURNS TO FILDDT COMMAND LEVEL.
APPENDIX
BUGHLT, BUGCHK, BUGINF
THE MONITOR CONTAINS A CONSIDERABLE NUMBER OF INTERNAL REDUNDANCY CHECKS WHICH
GENERALLY SERVE TO PREVENT UNEXPECTED HARDWARE OR SOFTWARE FAILURES FROM CASCADING
INTO SEVERELY DESTRUCTIVE REACTIONS. ALSO, BY DETECTING FAILURES EARLY, THEY
TEND TO EXPEDITE THE CORRECTION OF ERRORS.
THERE ARE TWO FAILURE ROUTINES, BUGCHK AND BUGHLT FOR LESSER AND GREATER SEVERITY
OF FAILURES. CALLS TO THEM WITH JSR ARE INCLUDED IN CODE BY USE OF A MACRO WHICH
RECORDS THE LOCATIONS AND A TEXT STRING DESCRIBING THE FAILURE. THE GENERAL
FORM IS:
BUG (TYPE,NAME,<STRING>)
WHERE TYPE IS HLT OR CHK, AND STRING DESCRIBES THE CAUSE.
FOR EXAMPLE,
BUG(HLT,SKDPFL,<PAGE FAULT FROM SCHEDULER CONTEXT>)
HE STRINGS AND A TABLE OF LOCATIONS ARE CONSTRUCTED DURING LOADING AND ARE
DUMPED ON TWO FILES. THE BUGSTRINGS.TXT FILE WILL PRODUCE AN ORDERED LISTING OF
THE BUG LOCATIONS AND MESSAGES FOR OPERATOR OR PROGRAMMER USE; THE BUGTABLE.IMG
FILE IS USED BY THE SYSTEM ITSELF TO LOG BUG OCCURENCES.
BUGCHK IS USED WHERE THE INCONSISTENCY DETECTED IS PROBABLY NOT FATAL TO THE
SYSTEM OR TO THE JOB BEING RUN, OR WHICH CAN PROBABLY BE CORRECTED AUTOMATICALLY.
TYPICAL IS THE SEQUENCE IN MRETN IN THE SCHED MODULE.
AOSGE INTDF
BUG(HLT,IDFOD2,<AT MRETN - INTDF OVERLY DECREMENTED>)
THIS BUGCHK IS INCLUDED STRICTLY AS A DEBUGGING AID; DETECTION OF A FAILURE
TAKES NO CORRECTIVE ACTION. THIS SITUATION USUALLY RESULTS FROM EXECUTING ONE
OR MORE EXCESSIVE OKINT OPERATIONS (NOT BALANCED BY A PRECEDING NOINT). IT IS
CONSIDERED A PROBLEM BECAUSE A NOINT EXECUTED WHEN INTDF HAS BEEN OVERLY
DECREMENTED WILL NOT INHIBIT INTERRUPTS AND WILL NOT PROTECT CODE CHANGING
SENSITIVE DATA.
BUGHLT IS USED WHERE THE FAILURE DETECTED IS LIKELY TO PRECLUDE FURTHER PROPER
OPERATION OF THE SYSTEM OR FILE STORAGE MIGHT BE JEOPARDIZED BY ATTEMPTED FURTHER
OPERATION. FOR EXAMPLE, THE FOLLOWING APPEARS IN THE SCHED MODULE:
MOVE 1,TODCLK ;CURRENT TIME
CAML 1,CHKTIM ;TIME AT WHICH JOB0 OVERDUE
BUG(HLT,J0NRUN,<JOB 0 NOT RUN FOR TOO LONG>)
THIS CHECK ACCOMPLISHES TWO THINGS:
1. A FUNCTION OF JOB0 IS TO PERIODICALLY UPDATE THE DISK VERSION
OF BITTABLES, FILE DIRECTORIES AND OTHER FILES; ABSENCE OF THIS
FUNCTION WOULD MAKE THE SYSTEM VULNERABLE TO CONSIDERABLE LOSS
OF INFORMATION ON A CRASH WHICH LOSES CORE AND SWAPPING STORAGE.
JOB 0 PROTECTS ITSELF AGAINST VARIOUS TYPES OF MALFUNCTION, THIS
BUGHLT DETECTS ANY FAILURE RESULTING IN A HANGUP.
2. DETECTS IF THE ENTIRE SYSTEM HAS BECOME HUNG DUE TO FAILURE OF
THE SWAPPING DEVICE OR SOME SUCH EVENT, ON THE BASIS THAT IF JOB
0 ISN'T RUNNING, NOBODY'S RUNNING.
DBUGSW:
------
A MONITOR CELL, DBUGSW, CONTROLS THE BEHAVIOR OF BUGHLT AND BUGCHK WHEN THEY ARE
CALLED. DBUGSW IS SET ACCORDING TO WHETHER THE SYSTEM IS ATTENDED BY SYSTEM
PROGRAMMERS.
IF C(DBUGSW)=0, THE SYSTEM IS NOT ATTENDED BY SYSTEM PROGRAMMERS, SO ALL
AUTOMATIC CRASH HANDLING IS INVOKED. BUGCHK WILL RETURN +1 IMMEDIATELY,
APPEARING EFFECTIVELY AS NOP. BUGHLT WILL IF CALLED FROM THE SCHEDULER OR AT
PI LEVEL, INVOKE A TOTAL RELOAD FROM THE DISK AND RESTART OF THE SYSTEM.
IF THE SYSTEM CONTINUES TO RUN OR IS REATARTED PROPERLY, THE
LOCATION OF THE BUG (SAVED OVER A RELOAD) AND ITS MESSAGE WILL BE REPORTED ON
THE LOGGIN TTY.
IF C(DBUGSW)=.NOT.0, THE SYSTEM IS ATTENDED, AND ONE OF THE EDDT BREAKPOINTS
WILL BE HIT. THIS ALLOWS THE PROGRAMMER TO LOOK FOR THE BUG AND/OR POSSIBLY
CORRECT THE DIFFICULTY AND PROCEED. THERE ARE TWO DEFINED NON-0 SETTINGS OF
DBUGSW, 1 AND 2, WHICH HAVE THE FOLLOWING DISTINCTION.
C(DBUGSW) = 1, OPERATION IS THE SAME AS WITH 0 EXCEPT FOR BREAKPOINT
ACTION. IN PARTICULAR THE SWAPPABLE MONITOR IS WRITE PROTECTED AND
SYSJOB IS STARTED AT STARTUP AS DESCRIBED.
C(DBUGSW) = 2, IS USED FOR ACTUAL SYSTEM DEBUGGING. THE SWAPPABLE
MONITOR IS NOT WRITE PROTECTED SO IT MAY CONVENIENTLY BE PATCHED OR
BREAKPOINTED, AND THE SYSJOB OPERATION IS NOT STARTED TO SAVE TIME.
BUGCHK AND BUGHLT PROCEDURES ARE THE SAME AS FOR 1.
THE FOLLOWING IS A SUMMARYOF DBUGSW SETTINGS:
0 1 2
MEANING UNATTENDED ATTENDED DEBUGGING
BUGCHK ACTION NOP $7B $7B
BUGHLT ACTION CRASH JOB $8B $8B
OR SYSTEM
SWPMON WTITE PROTECT? YES YES NO
CHKDSK ON STARTUP YES YES NO
OTHER CONSOLE FUNCTIONS:
IN ADDITION TO EDDT, SEVERAL OTHER ENTRY POINTS ARE DEFINED AS ABSOLUTE
ADDRESSES. THE MACHINE MAY BE STARTED AT THESE AS APPROPRIATE.
140 JRST EDDT ;GO TO EDDT
141 JRST SYSDDT ;RESET AND GO TO EDDT
142 JRST EDDT ;COPY OF EDDT ADDRESS
143 JRST SYSLOD ;INITIALIZE FILE SYSTEM
144 0
145 JRST SYSRST ;RESTART
146 JRST SYSGOX ;RELOAD AND START
147 JRST SYSGO1 ;START
THE SOFT RESTART (ADDRESS 145, EVRST) RESTARTS ALL I/O DEVICES, BUT LEAVES THE
SYSTEM TABLES INTACT. IF IT IS SUCCESSFUL, ALL JOBS AND ALL (OR ALL BUT 1)
PROCESS WILL CONTINUE IN THEIR PREVIOUS STATE WITHOUT INTERRUPTION. THIS MAY
BE USED IF AN I/O DEVICE HAS MALFUNCTIONED AND NOT RECOVERED PROPERLY. THE
TOTAL REATART INITIALIZES CORE, SWAPPING STORAGE AND ALL MONITOR TABLES.
A VERY LIMITED SET OF CONTROL FUNCTIONS FOR DEBUGGING PURPOSES HAS BEEN BUILT
INTO THE SCHEDULER. TO INVOKE A FUNCTION, THE APPROPRIATE BIT OR BITS ARE SET
INTO LOCATION 20 VIA MDDT. THE WORD IS SCANNED FROM LEFT TO RIGHT (JFFO); THE
FIRST 1 BIT FOUND WILL SELECT THE FUNCTION.
BIT 0:
CAUSES SCHEDULER TO DISMISS CURRENT PROCESS IF ANY AND STALL (EXECUTE
A JRST .), WITH -1 IAN AC0. USEFUL TO EFFECT A CLEAN MANUAL TRANSFER TO
EDDT. SYSTEM MAY BE RESUMED AT SCHED0.
BIT 1:
CAUSES THE JOB SPECIFIED BY DATA SWITCH BITS 18-35 TO BE RUN EXCLUSIVELY
TEMPORARILY DEFEATS JOB 0 NOT RUN BUGHLT.
BIT 2:
FORCES RUNNING OF JOB 0 BACKUP FUNCTION BEFORE HALTING THE SYSTEM.
3.2
MAPPING THE JSB OR PSB OF ANOTHER JOB
-------------------------------------
It is sometimes useful to be able to read or write the JSB or PSB
of another job on the system. The most common reason to do this
occurrs when some job on the system is stuck, and cannot be logged
out. In such cases the probable error is that the job is waiting for
some interlock to free, which never happens. If you can find out what
is being waited for, you can free the lock and many times the job will
proceed ok. But in order to find out what the job is doing, and what
the state of some of the interlocks are, you must be able to look at
the job's JSB and the PSB of each fork. This document will explain
how to do this.
The monitor has various tables which contain the SPT indexes of
the various pages the monitor must reference. Once you find the
offset in the SPT for the desired table, you simply call the routine
MSETMP which will map the page where you can look at it with MDDT.
ALL of the tables mentioned in this document are defined in STG. For
JSBs, you look at the table JOBPT. This table is indexed by job
number. The right half of each word contains the system fork number
of the top fork of the job (which is usually the EXEC). (This fork
number is not the same as the relative fork handles used by users to
reference their forks.) After finding the fork number for that job,
you use that to index into the table FKJOB. The left half of this
word should contain the job number you picked. The right half is the
SPT index of the job's JSB. This index is then used as an argument to
the MSETMP routine to map the JSB. As an example, suppose you want to
find the SPT index of the JSB of job 48, which is the user DBELL.
@ENABLE
$SDDT
DDT
JSYS 777$X
MDDT
JOBPT 48.[ 67,,200
FKJOB 200[ 60,,2575
From the above, you find that the top fork of job 48 has the system
fork number of 200, and that the SPT index is 2575. This number is
put into ac 1. In ac 2 you put flags and the address where you want
to map to. A convenient address is 740000, which is where directories
are mapped on release 2. Since you are in MDDT, and are not
referencing any directories, these pages can be used. The flags you
want will write enable the pages so that the JSB can be modified. The
third argument is the number of pages to be mapped. Usually only 1
page is necessary, but if many JFNs are in use, more than one page
might be needed. Continuing with the example:
Page 2
740000[ ?
1! 2575
2! 140000,,740000
3! 1
CALL MSETMP$X
$
740000[ 224000,,3273
Now you can reference the JSB of the job, and change it if it is
necessary. There is a slight complication, however. The symbols
defined for the offsets in a JSB (such as CTRLTT, JOBMAP, JFNLCK, etc)
are absolute locations. Referencing these symbols will not look at
the desired JSB, they will look at YOUR JSB. In order to relocate the
addresses to the page you have mapped the JSB to, it is convenient to
define a symbol, which when added to a symbol, will use the proper
place in the page. In the example, the symbol is called JX.
740000-JSB<JX:
JX CTRLTT[ 67
JX JFNLCK[ 777777,,777777
JX USRNAM[ 3
JX USRNAM 1[ 422050,,546230 $T;DBELL
For mapping PSBs, you run into a problem right away. There can
be many PSBs for a single job, and so you don't easily know which PSB
corresponds to the fork you are interested in. If the job only has 2
forks (the EXEC and some program it is running), then doing this is
easier. If the fork you want the PSB of is the top fork in the job,
the table JOBPT will tell you what the system fork index is for the
fork. In the example above, this number was 200. To find the other
forks of the job, you can search the table FKJOB, looking for the job
number in the left half. The entry corresponding to the top fork is
then ignored. The other entries meeting the conditions are the
non-top-level forks. So if there was only one other fork in the job,
there will be only one other entry. An example of looking for the
other fork in a job follows:
Page 3
$$C
-1,,0$M
FKJOB<FKJOB+NFKS-1>48.,,0$W
FKJOB+150/ 60,,2575
FKJOB+200/ 60,,2575
The search in MDDT found two forks which belong to job 48. The
entries both match, because there is only one JSB for a job. The
offsets into FKJOB are what you want. The offset of 200 is already
known to be the top fork, from the table JOBPT. Thus the other offset
will be the program running under the EXEC. In this example, the
offset is 150.
If there are many forks in the job, you can either guess which
PSB is the one you want, or you can search the job's fork structure
table in the JSB. To search the fork structure, you first map in the
JSB as described above. Then you look in the table FKPTRS which is in
the JSB of the job. This table has the length NLFKS, which is
currently 14. Medium sized entries (such as 620173 for example) are
unused entries, and they are linked together, with the first free
entry pointed to by FREJFK. The other entries are the job fork
handles which are in use. A job fork handle is not the same as either
the relative fork handles, or the system fork handles. Each entry of
the FKPTRS table which is in use has information containing the
relative position of that job fork handle with respect to the other
job fork handles. Each word is broken into 3 parts, each part being
12 bits. The first third of a word is the superior fork, the second
third is the parallel fork, and the last third is the inferior fork.
The superior fork third is the job fork handle of the fork superior to
this one. Note that the top level fork (the EXEC) appears as its own
superior. The inferior fork third is used for those forks which have
inferiors, and points to the first inferior. The parallel fork third
links all of the forks which have the same fork as their superior. By
examining the fork structure in this way you can usually deduce which
of the forks you are interested in. Once you find the job fork
handle, you convert it to the system fork handle by offsetting into
the table SYSFK which is also in the JSB. Then you can use this
number for mapping the PSB. As an example of looking at the fork
structure of a job, assume that below the EXEC is a program running
which has two inferiors, thus there are 4 forks total. Assuming that
you are interested in the PSB of the main program, you do the
following:
JX FKPTRS[ 1
740164[ 3
740165[ 100,,0
740166[ 100,,20000
740167[ 620170
740170[ 620171
740171[ 620172
JX SYSFK 1[ 1,,150
Page 4
From the above you can see the 4 forks in use for the job. They
happen to be the first 4 entries in the FKPTRS table, but that is not
always necessary. You can also see the beginnings of the linked list
of unused entries. Notice that job forks 0 and 1 have inferiors 1 and
3 respectively. Forks 0 and 1 have superior 0, and forks 2 and 3 have
superior 1. Forks 2 and 3 are parallel, and fork 3 points to fork 2,
and fork 2 doesn't have a parallel pointer. Thus you can recognize
fork 0 as the top level fork, fork 1 as its only immediate inferior
fork, and forks 2 and 3 as the inferiors of fork 1. Therefore in this
example, the desired job fork handle is 1. Indexing into the SYSFK
table by this number, you find the system fork number to be 150. If
the number in the SYSFK entry is -1, then this indicates that the fork
wasn't really in use, i.e. it had just been created by a CFORK, but
that nothing had been done to it. This case should never occur for a
running fork, however.
Once you find the system fork index for the fork, the table FKPGS
indexed by that value will tell you what the SPT index for the fork's
PSB is. This can then be used in a call to MSETMP in the same was as
was used for a JSB. However, there is a difference between release 2
and release 3. For release 2:
FKPGS 150[ 3477,,2314
1! 2314
2! 140000,,740000
3! 1
CALL MSETMP$X
$
For release 3:
FKPGS 150[ 3477,,2314
1! 2314,,PSBM0-PSB+776
2! 140000,,740000
3! 2
CALL MSETMP$X
$
The difference between the two releases is the argument in ac 1, and
the fact that in release 3 the PSB is two pages long, while in release
2 it was only one page long. Again, as in the case with JSBs, the
symbols used to reference PSBs are absolute addresses. Referencing
them directly will look at the PSB of your fork which entered MDDT.
These should be offset to point to the page used for the mapping.
Again it is convenient to define a symbol for this purpose, in this
example it is called PX.
Page 5
740000-PSB<PX:
PX PRIMRY[ 777777,,777777
PX CAPMSK[ 777000,,400000
PX LSTERR[ 601405
When you are done mapping a job's JSB or PSBs, you should unmap
the pages which you had used. This is done by supplying a zero in ac
1, and having the ac's 2 and 3 be the same as they were when you
mapped the page. Thus to unmap a JSB:
1! 0
2! 140000,,740000
3! 1
CALL MSETMP$X
$
Then you can leave MDDT, either by jumping to MRETN, or by simply
typing a ^C. You don't have to unmap a PSB or JSB in order to map in
another one. Mapping in another page on top of the old one will work,
the old page will become unmapped automatically. If you want to map
in both the JSB and PSB at the same time, this can be done if you use
different pages. For example, you could try using addresses at 740000
and 741000 or 742000, etc. The examples above should then be modified
to use the new page.
Finally, there are some warnings you should be aware of. Before
using a page for mapping pages into (such as 740000), you should make
sure that it is not being used already. Reference the address and see
if MDDT types a question mark. If not, do not use the page. If you
blow any of the arguments to the MSETMP routine, the system can die.
So be very careful that you are doing the right thing. When mapping
PSBs, remember that whenever the EXEC runs a different program, it
throws away the old fork and creates a new one. Thus the system fork
number may change when you rerun a program. So you should unmap the
PSB of the fork, run the program again, search for the system fork
number again, and remap the PSB again. It is a pain, but it is
necessary. If possible, typing "START" to the program being debugged
is simpler, since you stay in the same fork. When mapping the JSB, if
the job gets logged out, the system can crash. Always unmap the JSB
before the job is logged off. Therefore it is not recommended that
you do these procedures unless the system is stand-alone, or something
is really wrong and you must fix it.
3.3
HOW TO USE BREAKPOINTS IN CODE THAT MANY USERS EXECUTE
------------------------------------------------------
When inserting a breakpoint into the running monitor, you have to
be careful that no other users will execute the code containing the
breakpoint. If some other user hits the breakpoint, they will blow up
with an illegal instruction since MDDT will not be there to handle the
breakpoint. This normally limits the places you can set breakpoints,
since most of the monitor can be gotten to by any user. Even if you
run the system stand-alone, it is possible that the routine you are
debugging will be called by job 0. However, it is still possible to
do such debugging, even on a system which is not stand-alone, and this
document will describe how this is done.
The essential element of this technique is to put in the patch in
such a way that only your own fork can ever reach the breakpoint.
First you write a simple routine which will skip if it is not being
run by your particular fork. This can be done easily if you remember
that the location FORKX contains the currently running fork number.
An example of such a routine is the following:
@ENABLE
$SDDT
DDT
JSYS 777$X
MDDT
FORKX[ 23
FFF/ 0 NOTME: PUSH P,T1
NOTME+1/ 0 MOVE T1,FORKX
NOTME+2/ 0 CAIE T1,23
NOTME+3/ 0 AOS -1(P)
NOTME+4/ 0 POP P,T1
NOTME+5/ 0 POPJ P,
NOTME+6/ 0 FFF:
The routine above simply saves ac T1, gets the currently running fork
number, compares it with your own fork number which you obtained by
looking at location FORKX, and skips if they differ.
Now assume that you want to set a breakpoint into the following
code, which is in the routine BLKSCN in the module DIRECT.
BLKSC2/ HLRZ C,BLKTAB(B)
BLKSC2+1/ CAME A,C
BLKSC2+2/ AOBJN B,BLKSC2
BLKSC2+3/ JUMPGE B,BLKSCE
BLKSC2+4/ HRRZ B,BLKTAB(B)
Assume you want the breakpoint at location BLKSC2+3. You do the
following:
Page 2
BLKSC2+3/ JUMPGE B,BLKSCE FFF$<
FFF/ 0 PUSHJ P,NOTME
FFF+1/ 0 .$B JFCL$>
FFF+2/ JUMPGE B,BLKSCE
FFF+3/ JUMPA A,BLKSC2+4
FFF+4/ JUMPA B,BLKSC2+5
BLKSC2+3/ JUMPA NOTME+6
Notice that the breakpoint has been set in the JFCL instruction
following the call to NOTME. Only your fork will execute it, so you
can now debug the section of code while other users are executing it
at the same time. Remember to remove the breakpoint when you are
done.
To run a particular program while having breakpoints set, you
must remember that the breakpoint has to be set by the same process
which you expect to hit it. So for example, typing ^EQUIT, setting a
breakpoint, returning to the EXEC and running your program will not
work. You must enter MDDT and set the breakpoints from your program
you want to debug. As an example:
@ENABLE
$GET PROGRAM
$DDT
DDT
JSYS 777$X
MDDT
(PUT IN "NOTME" ROUTINE AND SET BREAKPOINTS HERE)
MRETN$G
$
$G
3.1 CRASH ANALYSIS
_____________________
FIRST WHEN ANALYSING SOFTWARE OR SOFTWARE/HARDWARE PROBLEMS BE SURE YOU
HAVE THE PROPER TOOLS:
1. A SWSKIT ON MAGTAPE
2. A FULL COPY OF THE CURRENT RELEASE MICROFICHE MONITOR AND EXEC.
3. A MONITOR CALLS REFERENCE MANUAL.
4. A SYSERR MANUAL.
5. A LISTING OF THE SYSERR LOG, ESPECIALLY IF HDW IS SUSPECTED.
6. A CTY OUTPUT FOR BUGHLTS AND BUGINFS OR OTHER PROBLEM INDICATIONS, OR AN
ACCURATE REPRODUCTION OF THIS INFORMATION.
7. ANY OTHER MANUALS YOU MAY NEED FOR REFERENCE SUCH AS THE PROPER VERSION
INSTALLATION GUIDE, OPERATORS GUIDE, SYSTEM MGRS GUIDE ETC.
8. A TOPS-20.BWR FILE.
YOU WILLL NEED THE SWSKIT FOR IDDT AND PERHAPS LISTINGS OF THE
LATEST VERSIONS OF MONITOR MODULES IN CASE THE MICROFICHE ARE NOT UP
TO DATE. FILDDT IS ON THE CUSTOMERS DISTRIBUTION TAPE.
BE SURE YOU HAVE ANALYSED THE SYSERR LOG. BE SURE, ALSO, THAT YOU HAVE
LOOKED UP THE BUGHLT AND/OR BUGCHKS IN QUESTION IN THE LISTINGS (MICROFICHE) AND
HAVE AT LEAST READ THE COMMENTS AROUND THEM. PROBABLY TRACING DOWN HOW IT GOT
CALLED IS A GOOD IDEA. IF YOU HAPPEN TO BE WITHOUT A GLOB (PROVIDED ON MICROFICHE)
YOU CAN FIND THE BUGHLT TAG OF INTEREST IN THE MONITOR AS FOLLOWS:
GET<SYSTEM>MONITR.EXE
ST 140
DDT
ILPP3? ;BUGHLT OF INTEREST FOLLOWED BY "?"
PAGEM G ;IT IS DEFINED IN PAGEM AND IS GLOBAL
SOME OTHER USEFUL BITS OF INFORMATION. THERE IS A GLOB LISTING PROVIDED
IN THE MICROFICHE WHICH CONTAINS A LIST OF ALL THE GLOBAL SYMBOLS IN THE MONITOR.
MOST OF THE SYMBOLS ARE DEFINED IN THE MODULE STG.MAC. IF YOU DON'T KNOW A
TAG NAME BUT WANT TO LOOK AT THE STORAGE FOR DTES, SAY, LOOK THROUGH STG. STG
ALSO CONTAINS SOME SMALL PORTION OF CODE MOSTLY TO DO WITH RESTART, START, AUTO
RELOAD, DISPATCHES FOR PI CHANNELS AND A BIT OF SCHEDULER TESTS. STG STANDS
FOR STORAGE. NOTE THAT SOME STUFF MAY BE DEFINED IN PROLOG, AND OF COURSE LOTS
OF STUFF IS DEFINED THROUGHOUT THE MONITOR. YOU MAY ALSO WANT TO GET A
LISTING OF MACSYM TO BE ABLE TO UNDERSTAND THE MACROS YOU SEE WHILE READING THE
MONITOR LISTINGS, MONSYM IS ALSO USEFUL AT TIMES. BE SURE YOU KNOW HOW PARAMS
HAS BEEN CHANGED IN CASE IT HAS. SEE BUILD.MEM ON THE DISTRIBUTION TAPES FOR
THE CURRENTLY DISTRIBUTED INFORMATION ON WHAT TO DO TO CHANGE VARIOUS SYSTEM
PARAMETERS IN PARAM0.MAC. BE SURE THAT YOU KNOW ABOUT ANY VARIABLES THAT THE
SITE MAY HAVE CHANGED IN STG AS WELL.
EXAMINING THE MONITOR
---------------------
DEBUGGING A COMPLEX, MULTI-PROCESS SOFTWARE SYSTEM IS LARGELY A
MATTER OF ABSORBING SUFFICIENT KNOWLEDGE, EXPERIENCE AND FOLKLORE ABOUT THE
PARTICULAR SYSTEM WITH A CONSIDERABLE ELEMENT OF PERSONAL PREFERENCE, OR 'TASTE'
ALSO INVOLVED. THIS DOCUMENT IS A CURSORY DESCRIPTION OF FEATURES BUILT INTO
THE SYSTEM TO AID DEBUGGING, AND SUCH FOLKLORE AS CAN BE DESCRIBED IN WRITTEN
ENGLISH.
THERE ARE FIVE DIFFERENT VERSIONS OF DDT THAT MAY BE USED TO EXAMINE
THE MONITOR. EACH IS USED FOR A DIFFERENT PURPOSE AND HAS SPECIAL CAPABILITES.
THE VERSIONS OF DDT ARE:
1. UDDT(USER DDT) USED TO EXAMINE OR MODIFY THE MONITR.EXE FILE.
2. MDDT(MONITOR DDT) USED TO EXAMINE OR MODIFY THE RUNNING MONITOR
UNDER TIMESHARING.
3. EDDT(EXEC DDT) USED TO EXAMINE OR MODIFY THE RUNNING MONITOR FROM
THE CTY IN A STAND-ALONE MODE.
4. IDDT USED TO EXAMINE DUMPS.
5. FILDDT USED TO EXAMINE DUMPS.
ALL THE DDT'S EXCEPT IDDT AND FILDDT ARE VERSIONS OF TOPS-20 DDT DOCUMENTED
IN THE TOPS-20 DDT MANUAL, AND HAVE ALL OF THE FEATURES DESCRIBED IN THE
MANUAL. IDDT IS BASED ON AN OLDER VERSION OF DDT AND DOES NOT HAVE EDITING,
THE NEW PATCHING TOOL OR ANY OF THE OTHER NEW COMMANDS.
THE USE OF ALL FIVE VERSIONS OF THE DDT'S IS THE SAME AND WILL BE
DESCRIBED LATTER, HOWEVER, EACH VERSION IS STARTED DIFFERENTLY.
UDDT:
TO USE UDDT TO MODIFY YOUR MONITR.EXE FILE ON SYSTEM,
YOU MUST GIVE THE FOLLOWING EXEC COMMANDS:
@GET <SYSTEM>MONITR.EXE
@START 140
THIS CAUSES EDDT TO START IN USER MODE.
THIS IS THE SAME DDT THAT IS USED WHEN EXAMINING ANY PROGRAM. YOU MAY
NOW LOOK AT OR CHANGE ANY PART OF THE MONITOR. IF YOU MAKE CHANGES TO THE
MONITOR AND WANT TO SAVE IT, YOU SHOULD GET BACK TO THE EXEC BY TYPING ^Z.
THEN YOU MAY SAVE THE MONITOR.
YOU WILL PROBABLY HAVE TO BE ENABLED INORDER TO SAVE THE MONITOR
BACK IN <SYSTEM>. THIS IS THE SAFEST, BEST AND RECOMENDED METHOD OF PUTTING
PATCHES INTO THE MONITOR.
MDDT:
A VERSION OF DDT WHICH RUNS IN MONITOR SPACE IS AVAILABLE. IT CAN
EXAMINE AND CHANGE THE RUNNING MONITOR, AND CAN BREAKPOINT CODE RUNNING AS A
PROCESS BUT NOT AT PI OR SCHEDULER LEVEL. WHEN PATCHING OR BREAKPOINTING THE
SWAPPABLE MONITOR, THE NORMAL WRITE PROTECTION MUST BE DEFEATED, EITHER BY
SETTING DBUGSW=2 ON STARTUP, OR CALLING SWPMWE. IF YOU INSERT BREAKPOINTS
WITH MDDT, REMEMBER MONITOR CODE IS REENTRANT AND SHARED SO THAT THE BREAKPOINT
COULD BE HIT BY ANY OTHER PROCESS IN THE SYSTEM, IN THIS EVENT, THE OTHER
PROCESS WILL MOST LIKELY CRASH SINCE IT WILL BE EXECUTING A JSR TO A PAGE FULL
OF 0S.
TO USE MDDT YOU MUST HAVE WHEEL OR OPERATOR CAPABILITIES. YOU FIRST
ISSUE THE EXEC COMMAND:
@ENABLE
AFTER THE EXEC PROMPTS WITH A $, YOU GIVE THE COMMAND:
$^EQUIT
YOU ARE NOW IN THE MINI-EXEC AND RECIEVE A PROMPT OF MX>.
NOW YOU GIVE THE "/" COMMAND:
MX>/
YOU ARE NOW PUT INTO MDDT. TO RETURN TO THE EXEC YOU CAN ISSUE A ^Z OR
A ^C WHICH PRODUCES A MESSAGE LIKE "INTERRUPT AT 17372" AND
RETURNS YOU TO THE MINI-EXEC. IF YOU TYPE A ^P IN MDDT YOU WILL GET
A MESSAGE, "ABORT", AND BE RETURNED TO THE MINI-EXEC. IF YOU ONCE
GO INTO THE MINI-EXEC THE CONTROL-P INTERRUPT IS ENABLED AND TYPING THIS
CHARACTER WILL RETURN YOU TO THE MINI-EXEC. THIS IS A GOOD THING TO
USE WHEN DEBUGGING PROGRAMS THAT DO CONTROL=C TRAPPING. FROM THE MINI-EXEC
YOU MAY GIVE EITHER:
MX>S
OR
MX>E
THE S IS FILLED OUT AS START AND THE E AS EXEC. BOTH OF THESE COMMANDS
WILL RETURN YOU TO THE EXEC. SEE THE DOCUMENT EXEC-DEBUGGING.MEM FOR MORE
ABOUT ^P AND GETTING OUT OF THE EXEC TO MX> AND RETURNING FROM MX> TO EITHER
YOUR COPY OF THE EXEC OR THE SYSTEM EXEC.
YOU MAY ALSO GIVE THE COMMAND:
MRETN$G
FROM MDDT TO RETURN DIRECTLY TO THE EXEC. WHILE IN MDDT YOU MAY EXAMINE
ANY CORE LOCATION IN THE RUNNING MONITOR. YOU MAY ALSO CHANGE ANY LOCATION
IN THE RESIDENT MONITOR. (DONE FREQUENTLY BY ACCIDENT). IF YOU WISH TO
CHANGE ANY OF THE LOCATIONS IN THE SWAPPABLE MONITOR YOU MUST GIVE THE COMMAND:
CALL SWPMWE$X
TO WRITE ENABLE THE MONITOR. AFTER YOU HAVE MADE YOUR CHANGES YOU MUST GIVE
THE COMMAND:
CALL SWPMWP$X
TO WRITE PROTECT THE MONITOR AGAIN.
EDDT:
***(NOT TO BE CONFUSED WITH ^EEDDT COM
-MAND TO GET INTO EDDT USED WITH THE
COMMAND PROCESSOR. SEE SEPARATE DOCUMENT
EXEC-DEBUGGING.MEM FOR THAT.)***
TO GET INTO EDDT YOU MUST BRING THE SYSTEM UP USING THE SWITCH-REGISTER.
SEE PAGE 3-12 OF THE DECSYSTEM-20 OPERATORS GUIDE FOR A DISCUSSION OF SWITCHES.
GO THROUGH THE KLINIT DIALOG AND WHEN YOU GET THE PROMPT BOOT>, RESPOND WITH:
BOOT>/L
BOOT>/G141
THE "/L" COMMAND CAUSES THE MONITOR TO BE LOADED, BUT NOT STARTED. THE
"/G141" START THE MONITOR AT LOCATION 141, WHICH IS A JUMP TO EDDT. YOU
CAN USE EDDT LIKE UDDT UNDER TIMESHARING ON THE MONITR.EXE BY GIVING THE
FOLLOWING COMMANDS
@GET <SYSTEM>MONITR.EXE
@START 140
EDDT IS LINKED INTO THE MONITOR AND IS ALWAYS THERE. YOU MAY ALSO GET TO
EDDT FROM MDDT BY ISSUEING THE FOLLOWING:
EDDT$G
FROM MDDT. THIS STOPS TIMESHARING. TO RESUME TIMESHARING AND /OR GET
BACK TO MDDT GIVE THE COMMAND:
MDDT$G BACK TO MDDT
MRETN$G BACK TO NORMAL TIMESHARING
BREAKPOINTS MAY BE INSERTED IN THE RESIDENT MONITOR WITH EDDT, BUT NOT
IN THE SWAPPABLE MONITOR IN GENERAL, BECAUSE ITS PAGES MAY BE SWAPPED OUT AND
BE UNAVAILABLE TO EDDT. YOU CAN BRING IT IN BY TYPING SKIP LOC$X (WHERE LOC
IS SOME ADDRESS NOT IN CORE.)
THERE ARE SOME LOCATIONS IN THE MONITOR THAT ARE VERY USEFUL WHEN USING
EDDT FOR DEBUGGING. THEY MUST BE SET BEFORE GOING ON TO START THE MONITOR.
THEY ARE:
EDDTF 1 KEEP EDDT IN CORE WHEN SYSTEM COMES UP
0 DELETE DDT WHEN SYSTEM COMES UP (DEFAULT)
DBUGSW 0 DO NOT STOP ON BUGHLTS
1 STOP ON BUGHLTS AND RELOAD (DEFAULT)
2 WRITE ENABLE SWAPPABLE MONITOR, DO NOT START UP SYSJOB
AND STOP ON BUGHLTS. ALLOWS YOU TO REWRITE THE HOME BLOCKS
WITHOUT REFRESHING THE FILE SYSTEM DURING FILE SYSTEM
INITIALIZATION. YOU GET TO ANSWER THE QUESTION
"DO YOU WANT TO REPLACE THE FILE SYSTEM ON THE PS:?"
BY SAYING "NO" AD
"DO YOU WANT TO DEFINE THE PUBLIC STRUCTURE
THIS WILL CAUSE THE HOME BLOCKS TO BE REWRITTEN..."
YOU CAN ANSWER YES TO THIS IN SPITE OF THE
WARNING TO THE CONTRARY.
ALSO IT DOSENT RUN CHECKD AUTOMATICALLY ON STARTUP.
DOES NOT TYPE OUT SYSTEM RESTARTING WAIT ETC.
DO NOT SET TIME AND DAY (SEE DTESRV TO CHECK ON THIS)
DCHKSW 0 DO NOT STOP ON BUGCHKS (DEFAULT)
1 STOP ON BUGCHKS
DINFSW 0 DO NOT STOP ON BUGINFS (DEFAULT)
1 STOP ON BUGINFS
IN ADDITION THE SYMBOL GOTSWM APPEARS IN THE CODE JUST AFTER THE SWAPPABLE
MONITOR IS LOADED; SO, IF YOU WANT TO DEBUG THE SWAPPABLE PART OF THE MONITOR
YOU MUST PUT A BREAKPOINT AT GOTSWM (TO GET SWAPPABLE PART IN CORE) BY,
GOTSWMB
THEN START THE MONITOR BY,
147G
CALL SWPMLK$X
CALL SWPMLK IS USED TO LOCK SWAPPABLE MONITOR IN CORE FOR DEBUGGING. YOU MUST
HAVE MORE THAN 96K OF CORE TO GIVE THIS COMMAND SINCE THE RESIDENT AND SWAPPABLE
MONITOR ARE LARGER THAN 96K. TO START UP THE MONITOR AFTER YOU HAVE GONE INTO
EDDT AND SET UP YOUR BREAKPOINTS (REMEMBER 7 AND 8 ARE USED FOR BUGHLT AND
BUGCHK) GIVE THE COMMAND:
147$G
OR
SYSGO1$G
IF YOU ARE IN EDDT AND DBUGSW IN NOT 2, THAT IS THE MONITOR IS WRITE PROTECTED,
YOU CAN USE THE ROUTINES SWPMWE AND SWPMWP TO WRITE ENABLE AND WRITE PROTECT
THE MONITOR. CALL SWPMWE$X IN DDT.
IDDT:
TO USE IDDT YOU MUST FIRST ISSUE THE COMMAND:
TERMINAL NO PAGE
THEN RUN A COPY OF IDDT.EXE. THIS SHOULD BE ON
YOUR SOFTWARE SUPPORT KIT TAPE. WHEN YOU GET INTO IDDT ISSUE THE COMMANDS:
$YANK FILE:<SYSTEM>MONITR.EXE
^S
STORE SYMBOLS ON FILE:MONITR.SYMBOLS
FOR THE YANK COMMAND YOU TYPE "$Y" AND IDDT RESPONDS WITH "ANK FILE:".
FOR THE STORE SYMBOLS COMMAND THE "^S" IS ALL THAT IS TYPED AND IDDT
RESPONDS WITH THE "STORE SYMBOLS ON FILE:". IF YOU HAVE YOUR TERMINAL IN
PAGED MODE THE CONTROL S WILL BE TRAPPED BY THE TERMINAL HANDLER AND WILL
NEVER GET TO IDDT. ALSO YOU SHOULD BE SURE AND GET THE SYMBOLS FROM THE
SAME VERSION OF THE MONITOR AS THE MONITOR IN THE DUMP YOU WANT TO LOOK AT.
IT IS A GOOD IDEA TO GIVE THE SYMBOLS FILE THE SAME VERSION NUMBER AS THE
MONITR.EXE FILE. THIS WAY YOU WILL KNOW WHICH VERSION OF THE MONITOR IT
GOES WITH AND THE NEXT TIME THAT YOU WANT TO LOOK AT A DUMP YOU CAN OMIT
THE ABOVE STEPS IF THE FILE CONTAINING THE SYMBOLS IS STILL AROUND. NEXT
YOU GIVE THE FOLLOWING COMMANDS:
$YANK FILE:<SYSTEM>DUMP.CPY
$$YANK SYMBOL FILE:MONITR.SYMBOLS
YOU ONLY TYPE THE $Y AND $$Y IN THE ABOVE COMMANDS. ALSO, IT MAY BE NECESSARY
TO GIVE GENERATION NUMBERS IN THE FILE NAMES TO GET THE CORRECT VERSIONS.
YOU ARE NOW READY TO LOOK AT THE MONITOR.
THE RESIDENT MONITOR MAY BE LOOKED
AT WITHOUT ANY DIFFICULTIES, BUT THE SWAPPABLE MONITOR MAY NOT BE IN CORE
AT THE TIME OF THE DUMP. IF THE VALUE OF THE SYMBOL IS IN
THE SWAPPABLE MONITOR YOU MUST GO THROUGH THE MONITOR MAP TO FIND WHERE
THE LOCATION REALLY IS. THE LOCATION MONCOR CONTAINS THE NUMBER OF PAGES
OF RESIDENT MONITOR AND THE LOCATION SWPCP0 CONTAINS THE FIRST PAGE OF REAL CORE
FOR SWAPPING. SO IF THE VALUE OF THE SYMBOL IS GREATER THAN CONTENTS OF MONCOR
TIMES 1000 THEN IT IS IN SWAPPABLE MONITOR. THE VALUES FOR RELEASE 2 ARE AS
FOLLOWS:
MONCOR SWPCP0
MONMIN 110
MONBCH 115 214
MONSML 124 223
MONMED 140 237
MONBIG 160 257
THE RELEVANT VALUES FOR THE PSECTS FOR RELEASE 3 ARE COPIED HERE FROM THE
LINK CCL FILE USED TO LOAD THE REL 3 MONITOR:
TTY:/LOG/LOGL:5
MON/SAVE,/HASHSIZE:8001, -
/SET:RSCOD:1000, -
/SET:INCOD:55300, -
/SET:RSVAR:71000, -
/SET:POSTCD:74000, -
/SET:BGSTR:276000, -
/SET:BGPTR:306000, -
/SET:PPVAR:307000, -
/SET:NRVAR:313000, -
/SET:NRCOD:344000, -
/SET:NPVAR:536000, -
/NOLOCALS, -
SYS:MONSYM.REL, -
DSK:LDINIT, -
VERSIO,STG, -
/LOCALS, -
TOPS20/S, -
/SYSLIB, -
/G
IF THE PAGE OF THE SWAPPABLE MONITOR YOU WANT TO LOOK
AT IS IN CORE IT WILL PROBABLY NOT BE IN CORE IN THE LOCATION THAT IT'S ADDRESS
REFER TO SINCE THE DUMP IS OF CORE AND RELOCATION OF PAGES DOES NOT HAPPEN.
TO FIND WHERE A SYMBOL REALLY IS IN THE DUMP, FIRST TYPE THE SYMBOL FOLLOWED BY
AN "=". IDDT WILL RESPOND WITH THE VALUE OF THIS SYMBOL. THE VALUE OF THE
SYMBOL CAN BE DIVIDE INTO TWO, THREE OCTAL DIGIT, FIELDS. THE HIGH ORDER THREE
DIGITS ARE THE PAGE NUMBER AND THE LOW ORDER THREE DIGITS ARE THE OFFSET INTO
THE PAGE.
IF THE VALUE OF THE SYMBOL IS 324621 THE HIGH ORDER THREE DIGITS,
324, ARE THE PAGE NUMBER AND THE LOW ORDER THREE DIGITS, 621, ARE THE OFFSET
INTO THE PAGE. TO FIND THE LOCATION OF THE PAGE IN QUESTION IN THE DUMP YOU
MUST LOOK AT THE MONITOR MAP INDEXED BY THE PAGE NUMBER. FOR EXAMPLE:
MMAP+324/
WOULD GIVE YOU THE MONITOR MAP WORD FOR PAGE 324. THIS WORD CONTAINS
SOME PROTECTION BITS FOR THE PAGE AND THE ADDRESS OF THE PAGE WHEN THE DUMP
WAS TAKEN.
THE PAGE MAY HAVE BEEN IN CORE, ON THE SWAPPING AREA OR ON
THE DISK AT THE TIME OF THE DUMP.
IF BITS 14-17 IF THE MONITOR MAP WORD ARE NON-ZERO
THE PAGE WAS ON THE SWAPPING AREA OR DISK AND IS NO LONGER AVAILABLE.
IF BITS 14-17
ARE ZERO THEN THE PAGE WAS IN CORE, AND THE RIGHT HALF OF THE WORD CONTAINS
THE PAGE NUMBER IN THE DUMP OF THE PAGE YOU ARE LOOKING FOR. (THE DUMP
PROGRAM OVERWRITES THE LAST NINE PAGES OF MEMORY, THE DUMP THEREFORE DOES
NOT CONTAIN THESE LAST NINE PAGES.)
IF THE PAGE WAS IN CORE THE NEW ADDRESS
OF THE SYMBOL YOU ARE LOOKING FOR CAN BE FOUND BY USING THE PAGE NUMBER FROM
THE MONITOR MAP WORD AND APPENDING THE OFFSET INTO THE PAGE TO IT. FOR
EXAMPLE IF MMAP+324 CONTAINS 104000,,256, THEN THE NEW ADDRESS OF OUR SYMBOL
WOULD BE 256621.
ALL ADDRESS IN THE SWAPPABLE MONITOR MUST BE RESOLVED IN
THIS MANNER. IN ADDITION ADDRESS OF 600000 AND ABOVE ARE IN THE JSB OR PSB
(PSB IS PAGE 777) AND MUST BE RESOLVED BY FINDING THE PAGE CONTAINING THE JSB
OR PSB OF THE PROCESS THAT WAS RUNNING WHEN THE DUMP OCCURED. THERE ARE SOME
LOCATIONS AND TABLES IN THE MONITOR THAT MAKE THIS EASY:
LOC INDEX DESCRIPTION
FORKX NONE NUMBER OF THE FORK THAT WAS RUNNING AT THE TIME OF
THE DUMP, -1 IF IN THE SCHEDULER.
JOBNO IN PSB JOB NUMBER TO WHICH CURRENT FORK BELONGS.
FKJOB FORK # JOB NUMBER,,SPT INDEX OF JSB
JOBDIR JOB # CONNECTED DIRECTORY NUMBER,,LOGGED IN DIRECTORY NUMBER
JOBPT JOB # CONTROLING TTY NUMBER,,TOP FORK NUMBER
FKSTAT FORK # TEST DATA,,ADDRESS OF FORK WAIT ROUTINE
FKPGS FORK # SPT INDEX OF PAGE TABLE,,SPT INDEX OF PSB
SPT INDEXES ARE INDEXES INTO A SHARE POINTER TABLE STARTING AT SPT.
TO FIND THE PSB OF FORK 20,
YOU FIRST LOOK AT FKPGS+20. IF THIS LOCATION CONTAINS
425,,426, THE WORD AT SPT+426 IS THE POINTER TO THE PSB. THIS POINTER CAN
POINT TO DISK, SWAP AREA, OR A PAGE IN THE DUMP. IF BITS 14-17 ARE ZERO IT
IS A POINTER TO A PAGE IN THE DUMP AND THE RIGHT HALF OF THE SPT WORD IS
THE PAGE NUMBER OF THE PSB IN THE DUMP.
WHEN YOU LOOK AT A DUMP, YOU SHOULD FIRST TRY TO FIND WHY THE DUMP
OCCURED BY LOOKING AT THE LOCATION BUGHLT. IF BUGHLT IS ZERO THEN YOU
SHOULD CHECK THE CTY LOG TO FIND OUT WHY THE DUMP WAS TAKEN AND FOR
INFORMATION LIKE THE PC AT THE TIME OF THE DUMP AND THE STATUS OF THE
PI SYSTEM. IF BUGHLT IS NON-ZERO IT IS THE ADDRESS OF WHERE THE BUGHLT WAS
ISSUED. YOU SHOULD LOOK UP THE BUGHLT IN BUGSTRINGS.TXT TO FIND ADDITIONAL
INFORMATION ABOUT THE BUGHLT. IF AT THIS POINT YOU ARE NOT SURE AS TO WHY
THE BUGHLT OCCURED, YOU WILL HAVE TO LOOK AT THE LISTINGS FOR MORE INFORMATION.
A COPY OF BUGSTRINGS.TXT IS IN APPENDIX A OF THE OPERATORS MANUAL.
YOU CAN FIND THE LOCATION OF THE CALL TO THE BUGHLT BY TYPING THE BUGHLT
TAG TO DDT FOLLOWED BY A "?". DDT WILL TELL WHICH MONITOR MODULE THE BUGHLT
IS IN AND YOU CAN GO TO YOUR MICROFICHE AND READ ALL ABOUT THE CONDITIONS
PRECIPITATING THE BUGHLT.
NEXT IF NECESSARY LOOK AT FORKX. IF IT CONTAINS A -1 THE SCHEDULER
WAS RUNNING OTHERWISE IT IS THE NUMBER OF THE FORK THAT WAS RUNNING WHEN
THE DUMP OCCURED. THE REGISTERS ARE SAVED AT BUGACS ON A BUGHLT, BUT IF
BUGACS+17 CONTAINS SOMETHING,,BUGPDL+N, THEN THE REGISTERS ARE INVALID AND YOU
MUST GO TO THE SYSERR BUFFER TO GET THE GOOD REGISTERS. THIS IS DONE BY
ADDING TO THE RIGHT HALF OF THE SYSERR BUFFER POINTER, SEBQOU, THE OFFSET
INTO THE BUFFER FOR THE HEADING AND ACS, SEBDAT+BG%ACS. THIS VALUE POINTS
TO A 16 BLOCK OF WORDS CONTAINING THE USERS ACS.
***NOTE***
DO NOT FORGET TO GET A PRINT OUT OF THE SYSERR LOG WHICH WILL GIVE
YOU AND THE FIELD SERVICE REPRESENTATIVE MUCH OF THE INFORMATION YOU CAN
GET OUT OF THE DUMP. THE SYSERR OUTPUT IS MUCH EASIER TO EXAMINE, HOWEVER,
CLEARLY YOU CANNOT GET AS MUCH INFO AS YOU CAN FROM A DUMP.
SOME OTHER LOCATIONS IN THE PSB OF INTEREST ARE:
LOCATION DESCRIPTION
UAC USER'S ACS WHEN HE DID HIS LAST JSYS.
PAC MONITORS ACS
PPC PROCESSORS PC
UPDL USERS PUSHDOWN STACK
NSKED 0 = OK TO RUN SCHEDULER
1 = CANNOT RUN SCHEDULER
INTDF = -1 , OK TO RECIEVE SOFTWARE INTERRUPTS
>= 0 , CANNOT RECIEVE SOFTWARE INTERRUPTS
IT MAY BE USEFUL TO KNOW THE STATUS OF A FORK WHEN IT IS HUNG OR
YOU ARE UNSURE OF ITS STATUS. THIS CAN BE DETERMINED BY LOOKING AT FKSTAT
INDEXED BY THE FORK NUMBER. THE RIGHT HALF OF THIS LOCATION IS THE ADDRESS
OF A TEST ROUTINE AND THE LEFT HALF IS DATA TO BE TESTED. FOR EXAMPLE
IF FKSTAT+12 CONTAINS 23,,FKWAT, THEN FORK 12 IS WAITING FOR FORK 23 TO
COMPLETE. FKWAT IS A ROUTINE THAT WAITS FOR ANOTHER FORK TO COMPLETE AND
IT'S DATA (THE LEFT HALF OF THE WORD) IS THE NUMBER OF THE FORK IT IS WAITING
FOR. THERE ARE MANY DIFFERENT WAIT ROUTINES AND YOU WILL HAVE TO LOOK AT THE
CODE TO SEE WHAT INDIVIDUAL ONES ARE WAITING FOR.
YOU CAN EASILY DETERMINE ALL OF THE FORKS ASSOCIATED WITH A JOB BY
GIVING THE COMMANDS:
$M/ -1 -1,,0
FKJOB<FKJOB+NFKS>N,,0$W
WHERE N IS THE JOB YOU ARE LOOKING FOR. A FORK STRUCTURE CAN USUALLY
BE DETERMINED BY LOOKING AT THE FKSTAT OF THE FORKS AND SEEING WHICH FORKS
ARE WAITING ON WHICH FORKS. A FKSTAT OF FKSKP INDICATES A FORK IS INACTIVE.
YOU SHOULD REFER TO STG.MAC FOR OTHER FORK AND JOB TABLES AND OTHER
LOCATIONS IN THE PSB AND JSB OF INTEREST. ALL OF THE ABOVE LOCATIONS CAN BE
EXAMINED WITH MDDT OR EDDT WHILE THE MONITOR IS RUNNING. OF COURSE AT THESE
TIMES YOU DO NOT HAVE TO GO THROUGH MMAP AND THE PSB AND JSB THAT ARE IN
CORE ARE YOUR OWN.
THERE ARE TWO SEPERATE PATCH AREAS IN THE MONITOR (FFF AND SWPF).
FFF IS THE RESIDENT PATCH AREA AND SWPF IS THE SWAPABLE PATCH AREA. THESE
TWO SYMBOLS SHOULD BE UPDATED TO POINT TO THE NEXT FREE LOCATION IN THE
PATCH AREA WHEN A PATCH IS INSERTED. PAT.. IS DEFINED TO BE EQUAL TO SWPF.
THERE ARE SEVERAL GENERAL PURPOSE ROUTINES THAT CAN BE USED TO LOOK AT
THE THE MONITOR WHILE IT IS RUNNING. THESE ROUTINES SHOULD BE USED WITH
CAUTION SINCE IT IS CERTAINLY POSSIBLE TO CRASH THE MONITOR BY USING THEM
INCORRECTLY. TWO OF THE MORE GENERAL ROUTINES ARE MAPDIR, FOR MAPPING A
DIRECTORY INTO CORE, AND SETMPG FOR MAPPING PAGES (SOMEONE ELSES PSB OR JSB)
INTO CORE. YOU WILL HAVE TO LOOK AT THE LISTING FOR THE EXACT USE OF THESE
AND OTHER GENERAL ROUTINES. BEWARE OF THE PRECAUTIONS THAT SHOULD BE TAKEN
WHEN USING THEM. YOU CAN FIND THE MODULE THEY ARE LOCATED IN BY LOOKING IN
THE GLOB LISTING WHICH IS A CROSS REFERENCE LISTING OF ALL THE GLOBAL SYMBOLS
IN THE MONITOR. YOU GET A GLOB LISTING IN YOUR MICROFICHE.
MDDT:
IF YOU WISH TO EXAMINE THE SYSTEM FROM THE EXECS INFERIOR FORK MONITOR
CONTEXT:
ENA
SDDT
JSYS 777$X
TO RETURN TO USER CONTEXT:
MRETN$G
USE SETMPG TO MAP PAGES TO THIS CONTEXT:
PAGE 677 IS TRADITIONALLY USED FOR THIS:
AC2/ ACCESS,,67700
IF PAGE HAS ITS OWN SPT SLOT:
AC1/SPT INDEX
IF PAGE DOES NOT HAVE ITS OWN SPT SLOT, IT WILL BELONG TO EITHER A FILE OR
PROCESS PAGE TABLE. IT WILL BE REPRESENTED AS AN INDEX INTO THIS PAGE TABLE:
AC1/ SPT INDEX OF PAGE TABLE,,INDEX INTO PAGE TABLE
ACCESS = READ OR/AND OR WRITE ACCESS
READ/WRITE ACCESS = 140000 IN LH
THEREFORE, TO MAP A PAGE, CALL WITH EITHER:
AC1/SPT INDEX OF PAGE OR AC1/SPT INDEX OF PAGETABLE,,INDEX INTO
PAGE TABLE
AC2/140000,,677000 AC2/140000,,677000
AND SAY: CALL SETMPG$X
THE PAGE WILL THEN BE MAPPED TO PAGE 677. IN EXAMINING LOCATIONS 677000-677777,
YOU WILL BE LOOKING AT THE CONTENTS OF THE PAGE.
IF YOU DESIRE TO MAP ANOTHER PAGE INTO THIS SLOT, MERELY CALL SETMPG
AGAIN WITH ARGUMENTS FOR THE NEW PAGE. YOU NEED NOT FIRST UN-MAP THE OLD PAGE.
HOWEVER, WHEN YOU ARE FINISHED, PAGE 677 SHOULD BE UN-MAPPED IN THE FOLLOWING
MANNER:
AC1/0
AC2/ACCESS,,677000
CALL SETMPG$X
WARNING:
CALLING SETMPG INCORRECTLY CAN CRASH THE SYSTEM. BE CAREFUL! DO NOT
USE SETMPG ON A TIME SHARING SYSTEM IF A CRASH WILL CAUSE BAD FEELINGS.
FILDDT:
FILDDT IS DISTRIBUTED ON THE CUSTOMER SOFTWARE TAPE. WE HAVE IN ADDITION
INCLUDED AN EXPERIMENTAL FILDDT ON THE SWSKIT WHICH ENABLES US TO LOOK AT
SECTIONS OTHER THAN 0/1 IN THE CASE THE CUSTOMER HAS A MOD B MACHINE. IN
SPITE OF THE FACT THAT RELEASE 3 DOES NOT "TAKE ADVANTAGE" OF MULTISECTION
MACHINES IN ORDER TO IMPROVE PERFORMANCE AS PER THE RELEASE 3 PROJECT PLAN
IT IS TRUE THAT RELEASE 3 DOES INDEED USE SECTION 0/1 AS WELL AS 2 AND 3.
THERE IS CODE WHICH IS SIMPLY REMOVED FROM SECTION 0/1 AND PLACED IN ANOTHER
SECTION WITHOUT ADDING ANYTHING TO 0/1.
THE FOLLOWING IS AN EMBELLISHED FILDDT.HLP FILE.
GET(FILE) FILE-SPEC
LOADS A FILE FOR DDT TO EXAMINE. IF YOU ARE LOOKING AT A MONITOR DUMP
YOU MUST LOAD DUMP.CPY EXPLICITLY. FILDDT LOOKS FOR MUMBLE.EXE NOT MUMBLE.CPY
THAT IS DUMP<ESC> WILL TELL YOU THAT THERE IS NO SUCH FILE OR WILL LOAD
DUMP.EXE. WHEN LOOKING AT A DUMP AND YOU WISH TO LOAD THE SYMBOLS YOU MUST
FIRST ISSUE THE LOAD COMMAND FOLLOWED BY THE GET COMMAND. BE SURE THAT THE
FILE FROM WHICH YOU GET THE SYMBOLS IS THE SAME VERSION AS THE DUMP. BE
SURE, ALSO THAT THE MONITOR THAT WAS DUMPED IS THE SAME MONITOR YOU USE FOR
SYMBOLS. THAT IS DON'T GET MONMED SYMBOLS TO USE WITH MONBCH ETC,
LOAD (SYMBOLS FROM) FILE SPEC
READS SPECIFIED FILE AND BUILDS INTERNAL SYMBOL TABLE. THIS MUST BE THE
FIRST COMMAND TO FILDDT BEFORE "GET" WHEN LOOKING AT A DUMP. YOU WILL MOST
PROBABLY USE <SYSTEM>MONITR.EXE WHICH WOULD HAVE BEEN THE MONITOR
RUNNING AT THE TIME OF THE DUMP. NOTE THAT THIS COMMAND WILL NOT READ A SYMBOL
FILE CREATED BY IDDT.
EXIT (FROM FILDDT)
RETURNS TO COMMAND LEVEL. YOU THEN MAY TYPE A SAVE COMMAND IF A LOAD
COMMAND WAS JUST DONE TO PRELOAD SYMBOLS. YOU WILL GET A VERSION OF FILDDT THAT
HAS THE SYMBOLS YOU JUST LOADED IN IT SO YOU NO LONGER NEED TO "LOAD" SYMBOLS.
YOU NOW HAVE A MONITOR SPECIFIC FILDDT.
HELP
TYPES THIS TEXT. (A SUBSET, THAT IS.)
ENABLE PATCHING
ALLOWS WRITING ON AN EXISTING FILE SPECIFIED BY A GET.
ENABLE DATA-FILE
ASSUMES FILE IS RAW BINARY (I.E. NO ACS).
DDT FEATURES:
N$U SETS SPT INDEX (N) FOR INDEX BLOCK TO BE USED FOR VIRTUAL ADDRESSES
IN EXAMINING THE FILE.
<CTRL/E> RETURNS TO FILDDT COMMAND LEVEL.
APPENDIX
BUGHLT, BUGCHK, BUGINF
THE MONITOR CONTAINS A CONSIDERABLE NUMBER OF INTERNAL REDUNDANCY CHECKS WHICH
GENERALLY SERVE TO PREVENT UNEXPECTED HARDWARE OR SOFTWARE FAILURES FROM CASCADING
INTO SEVERELY DESTRUCTIVE REACTIONS. ALSO, BY DETECTING FAILURES EARLY, THEY
TEND TO EXPEDITE THE CORRECTION OF ERRORS.
THERE ARE TWO FAILURE ROUTINES, BUGCHK AND BUGHLT FOR LESSER AND GREATER SEVERITY
OF FAILURES. CALLS TO THEM WITH JSR ARE INCLUDED IN CODE BY USE OF A MACRO WHICH
RECORDS THE LOCATIONS AND A TEXT STRING DESCRIBING THE FAILURE. THE GENERAL
FORM IS:
BUG (TYPE,NAME,<STRING>)
WHERE TYPE IS HLT OR CHK, AND STRING DESCRIBES THE CAUSE.
FOR EXAMPLE,
BUG(HLT,SKDPFL,<PAGE FAULT FROM SCHEDULER CONTEXT>)
HE STRINGS AND A TABLE OF LOCATIONS ARE CONSTRUCTED DURING LOADING AND ARE
DUMPED ON TWO FILES. THE BUGSTRINGS.TXT FILE WILL PRODUCE AN ORDERED LISTING OF
THE BUG LOCATIONS AND MESSAGES FOR OPERATOR OR PROGRAMMER USE; THE BUGTABLE.IMG
FILE IS USED BY THE SYSTEM ITSELF TO LOG BUG OCCURENCES.
BUGCHK IS USED WHERE THE INCONSISTENCY DETECTED IS PROBABLY NOT FATAL TO THE
SYSTEM OR TO THE JOB BEING RUN, OR WHICH CAN PROBABLY BE CORRECTED AUTOMATICALLY.
TYPICAL IS THE SEQUENCE IN MRETN IN THE SCHED MODULE.
AOSGE INTDF
BUG(HLT,IDFOD2,<AT MRETN - INTDF OVERLY DECREMENTED>)
THIS BUGCHK IS INCLUDED STRICTLY AS A DEBUGGING AID; DETECTION OF A FAILURE
TAKES NO CORRECTIVE ACTION. THIS SITUATION USUALLY RESULTS FROM EXECUTING ONE
OR MORE EXCESSIVE OKINT OPERATIONS (NOT BALANCED BY A PRECEDING NOINT). IT IS
CONSIDERED A PROBLEM BECAUSE A NOINT EXECUTED WHEN INTDF HAS BEEN OVERLY
DECREMENTED WILL NOT INHIBIT INTERRUPTS AND WILL NOT PROTECT CODE CHANGING
SENSITIVE DATA.
BUGHLT IS USED WHERE THE FAILURE DETECTED IS LIKELY TO PRECLUDE FURTHER PROPER
OPERATION OF THE SYSTEM OR FILE STORAGE MIGHT BE JEOPARDIZED BY ATTEMPTED FURTHER
OPERATION. FOR EXAMPLE, THE FOLLOWING APPEARS IN THE SCHED MODULE:
MOVE 1,TODCLK ;CURRENT TIME
CAML 1,CHKTIM ;TIME AT WHICH JOB0 OVERDUE
BUG(HLT,J0NRUN,<JOB 0 NOT RUN FOR TOO LONG>)
THIS CHECK ACCOMPLISHES TWO THINGS:
1. A FUNCTION OF JOB0 IS TO PERIODICALLY UPDATE THE DISK VERSION
OF BITTABLES, FILE DIRECTORIES AND OTHER FILES; ABSENCE OF THIS
FUNCTION WOULD MAKE THE SYSTEM VULNERABLE TO CONSIDERABLE LOSS
OF INFORMATION ON A CRASH WHICH LOSES CORE AND SWAPPING STORAGE.
JOB 0 PROTECTS ITSELF AGAINST VARIOUS TYPES OF MALFUNCTION, THIS
BUGHLT DETECTS ANY FAILURE RESULTING IN A HANGUP.
2. DETECTS IF THE ENTIRE SYSTEM HAS BECOME HUNG DUE TO FAILURE OF
THE SWAPPING DEVICE OR SOME SUCH EVENT, ON THE BASIS THAT IF JOB
0 ISN'T RUNNING, NOBODY'S RUNNING.
DBUGSW:
------
A MONITOR CELL, DBUGSW, CONTROLS THE BEHAVIOR OF BUGHLT AND BUGCHK WHEN THEY ARE
CALLED. DBUGSW IS SET ACCORDING TO WHETHER THE SYSTEM IS ATTENDED BY SYSTEM
PROGRAMMERS.
IF C(DBUGSW)=0, THE SYSTEM IS NOT ATTENDED BY SYSTEM PROGRAMMERS, SO ALL
AUTOMATIC CRASH HANDLING IS INVOKED. BUGCHK WILL RETURN +1 IMMEDIATELY,
APPEARING EFFECTIVELY AS NOP. BUGHLT WILL IF CALLED FROM THE SCHEDULER OR AT
PI LEVEL, INVOKE A TOTAL RELOAD FROM THE DISK AND RESTART OF THE SYSTEM.
IF THE SYSTEM CONTINUES TO RUN OR IS REATARTED PROPERLY, THE
LOCATION OF THE BUG (SAVED OVER A RELOAD) AND ITS MESSAGE WILL BE REPORTED ON
THE LOGGIN TTY.
IF C(DBUGSW)=.NOT.0, THE SYSTEM IS ATTENDED, AND ONE OF THE EDDT BREAKPOINTS
WILL BE HIT. THIS ALLOWS THE PROGRAMMER TO LOOK FOR THE BUG AND/OR POSSIBLY
CORRECT THE DIFFICULTY AND PROCEED. THERE ARE TWO DEFINED NON-0 SETTINGS OF
DBUGSW, 1 AND 2, WHICH HAVE THE FOLLOWING DISTINCTION.
C(DBUGSW) = 1, OPERATION IS THE SAME AS WITH 0 EXCEPT FOR BREAKPOINT
ACTION. IN PARTICULAR THE SWAPPABLE MONITOR IS WRITE PROTECTED AND
SYSJOB IS STARTED AT STARTUP AS DESCRIBED.
C(DBUGSW) = 2, IS USED FOR ACTUAL SYSTEM DEBUGGING. THE SWAPPABLE
MONITOR IS NOT WRITE PROTECTED SO IT MAY CONVENIENTLY BE PATCHED OR
BREAKPOINTED, AND THE SYSJOB OPERATION IS NOT STARTED TO SAVE TIME.
BUGCHK AND BUGHLT PROCEDURES ARE THE SAME AS FOR 1.
THE FOLLOWING IS A SUMMARYOF DBUGSW SETTINGS:
0 1 2
MEANING UNATTENDED ATTENDED DEBUGGING
BUGCHK ACTION NOP $7B $7B
BUGHLT ACTION CRASH JOB $8B $8B
OR SYSTEM
SWPMON WTITE PROTECT? YES YES NO
CHKDSK ON STARTUP YES YES NO
OTHER CONSOLE FUNCTIONS:
IN ADDITION TO EDDT, SEVERAL OTHER ENTRY POINTS ARE DEFINED AS ABSOLUTE
ADDRESSES. THE MACHINE MAY BE STARTED AT THESE AS APPROPRIATE.
140 JRST EDDT ;GO TO EDDT
141 JRST SYSDDT ;RESET AND GO TO EDDT
142 JRST EDDT ;COPY OF EDDT ADDRESS
143 JRST SYSLOD ;INITIALIZE FILE SYSTEM
144 0
145 JRST SYSRST ;RESTART
146 JRST SYSGOX ;RELOAD AND START
147 JRST SYSGO1 ;START
THE SOFT RESTART (ADDRESS 145, EVRST) RESTARTS ALL I/O DEVICES, BUT LEAVES THE
SYSTEM TABLES INTACT. IF IT IS SUCCESSFUL, ALL JOBS AND ALL (OR ALL BUT 1)
PROCESS WILL CONTINUE IN THEIR PREVIOUS STATE WITHOUT INTERRUPTION. THIS MAY
BE USED IF AN I/O DEVICE HAS MALFUNCTIONED AND NOT RECOVERED PROPERLY. THE
TOTAL REATART INITIALIZES CORE, SWAPPING STORAGE AND ALL MONITOR TABLES.
A VERY LIMITED SET OF CONTROL FUNCTIONS FOR DEBUGGING PURPOSES HAS BEEN BUILT
INTO THE SCHEDULER. TO INVOKE A FUNCTION, THE APPROPRIATE BIT OR BITS ARE SET
INTO LOCATION 20 VIA MDDT. THE WORD IS SCANNED FROM LEFT TO RIGHT (JFFO); THE
FIRST 1 BIT FOUND WILL SELECT THE FUNCTION.
BIT 0:
CAUSES SCHEDULER TO DISMISS CURRENT PROCESS IF ANY AND STALL (EXECUTE
A JRST .), WITH -1 IAN AC0. USEFUL TO EFFECT A CLEAN MANUAL TRANSFER TO
EDDT. SYSTEM MAY BE RESUMED AT SCHED0.
BIT 1:
CAUSES THE JOB SPECIFIED BY DATA SWITCH BITS 18-35 TO BE RUN EXCLUSIVELY
TEMPORARILY DEFEATS JOB 0 NOT RUN BUGHLT.
BIT 2:
FORCES RUNNING OF JOB 0 BACKUP FUNCTION BEFORE HALTING THE SYSTEM.
3.2
MAPPING THE JSB OR PSB OF ANOTHER JOB
-------------------------------------
It is sometimes useful to be able to read or write the JSB or PSB
of another job on the system. The most common reason to do this
occurrs when some job on the system is stuck, and cannot be logged
out. In such cases the probable error is that the job is waiting for
some interlock to free, which never happens. If you can find out what
is being waited for, you can free the lock and many times the job will
proceed ok. But in order to find out what the job is doing, and what
the state of some of the interlocks are, you must be able to look at
the job's JSB and the PSB of each fork. This document will explain
how to do this.
The monitor has various tables which contain the SPT indexes of
the various pages the monitor must reference. Once you find the
offset in the SPT for the desired table, you simply call the routine
MSETMP which will map the page where you can look at it with MDDT.
ALL of the tables mentioned in this document are defined in STG. For
JSBs, you look at the table JOBPT. This table is indexed by job
number. The right half of each word contains the system fork number
of the top fork of the job (which is usually the EXEC). (This fork
number is not the same as the relative fork handles used by users to
reference their forks.) After finding the fork number for that job,
you use that to index into the table FKJOB. The left half of this
word should contain the job number you picked. The right half is the
SPT index of the job's JSB. This index is then used as an argument to
the MSETMP routine to map the JSB. As an example, suppose you want to
find the SPT index of the JSB of job 48, which is the user DBELL.
@ENABLE
$SDDT
DDT
JSYS 777$X
MDDT
JOBPT 48.[ 67,,200
FKJOB 200[ 60,,2575
From the above, you find that the top fork of job 48 has the system
fork number of 200, and that the SPT index is 2575. This number is
put into ac 1. In ac 2 you put flags and the address where you want
to map to. A convenient address is 740000, which is where directories
are mapped on release 2. Since you are in MDDT, and are not
referencing any directories, these pages can be used. The flags you
want will write enable the pages so that the JSB can be modified. The
third argument is the number of pages to be mapped. Usually only 1
page is necessary, but if many JFNs are in use, more than one page
might be needed. Continuing with the example:
Page 2
740000[ ?
1! 2575
2! 140000,,740000
3! 1
CALL MSETMP$X
$
740000[ 224000,,3273
Now you can reference the JSB of the job, and change it if it is
necessary. There is a slight complication, however. The symbols
defined for the offsets in a JSB (such as CTRLTT, JOBMAP, JFNLCK, etc)
are absolute locations. Referencing these symbols will not look at
the desired JSB, they will look at YOUR JSB. In order to relocate the
addresses to the page you have mapped the JSB to, it is convenient to
define a symbol, which when added to a symbol, will use the proper
place in the page. In the example, the symbol is called JX.
740000-JSB<JX:
JX CTRLTT[ 67
JX JFNLCK[ 777777,,777777
JX USRNAM[ 3
JX USRNAM 1[ 422050,,546230 $T;DBELL
For mapping PSBs, you run into a problem right away. There can
be many PSBs for a single job, and so you don't easily know which PSB
corresponds to the fork you are interested in. If the job only has 2
forks (the EXEC and some program it is running), then doing this is
easier. If the fork you want the PSB of is the top fork in the job,
the table JOBPT will tell you what the system fork index is for the
fork. In the example above, this number was 200. To find the other
forks of the job, you can search the table FKJOB, looking for the job
number in the left half. The entry corresponding to the top fork is
then ignored. The other entries meeting the conditions are the
non-top-level forks. So if there was only one other fork in the job,
there will be only one other entry. An example of looking for the
other fork in a job follows:
Page 3
$$C
-1,,0$M
FKJOB<FKJOB+NFKS-1>48.,,0$W
FKJOB+150/ 60,,2575
FKJOB+200/ 60,,2575
The search in MDDT found two forks which belong to job 48. The
entries both match, because there is only one JSB for a job. The
offsets into FKJOB are what you want. The offset of 200 is already
known to be the top fork, from the table JOBPT. Thus the other offset
will be the program running under the EXEC. In this example, the
offset is 150.
If there are many forks in the job, you can either guess which
PSB is the one you want, or you can search the job's fork structure
table in the JSB. To search the fork structure, you first map in the
JSB as described above. Then you look in the table FKPTRS which is in
the JSB of the job. This table has the length NLFKS, which is
currently 14. Medium sized entries (such as 620173 for example) are
unused entries, and they are linked together, with the first free
entry pointed to by FREJFK. The other entries are the job fork
handles which are in use. A job fork handle is not the same as either
the relative fork handles, or the system fork handles. Each entry of
the FKPTRS table which is in use has information containing the
relative position of that job fork handle with respect to the other
job fork handles. Each word is broken into 3 parts, each part being
12 bits. The first third of a word is the superior fork, the second
third is the parallel fork, and the last third is the inferior fork.
The superior fork third is the job fork handle of the fork superior to
this one. Note that the top level fork (the EXEC) appears as its own
superior. The inferior fork third is used for those forks which have
inferiors, and points to the first inferior. The parallel fork third
links all of the forks which have the same fork as their superior. By
examining the fork structure in this way you can usually deduce which
of the forks you are interested in. Once you find the job fork
handle, you convert it to the system fork handle by offsetting into
the table SYSFK which is also in the JSB. Then you can use this
number for mapping the PSB. As an example of looking at the fork
structure of a job, assume that below the EXEC is a program running
which has two inferiors, thus there are 4 forks total. Assuming that
you are interested in the PSB of the main program, you do the
following:
JX FKPTRS[ 1
740164[ 3
740165[ 100,,0
740166[ 100,,20000
740167[ 620170
740170[ 620171
740171[ 620172
JX SYSFK 1[ 1,,150
Page 4
From the above you can see the 4 forks in use for the job. They
happen to be the first 4 entries in the FKPTRS table, but that is not
always necessary. You can also see the beginnings of the linked list
of unused entries. Notice that job forks 0 and 1 have inferiors 1 and
3 respectively. Forks 0 and 1 have superior 0, and forks 2 and 3 have
superior 1. Forks 2 and 3 are parallel, and fork 3 points to fork 2,
and fork 2 doesn't have a parallel pointer. Thus you can recognize
fork 0 as the top level fork, fork 1 as its only immediate inferior
fork, and forks 2 and 3 as the inferiors of fork 1. Therefore in this
example, the desired job fork handle is 1. Indexing into the SYSFK
table by this number, you find the system fork number to be 150. If
the number in the SYSFK entry is -1, then this indicates that the fork
wasn't really in use, i.e. it had just been created by a CFORK, but
that nothing had been done to it. This case should never occur for a
running fork, however.
Once you find the system fork index for the fork, the table FKPGS
indexed by that value will tell you what the SPT index for the fork's
PSB is. This can then be used in a call to MSETMP in the same was as
was used for a JSB. However, there is a difference between release 2
and release 3. For release 2:
FKPGS 150[ 3477,,2314
1! 2314
2! 140000,,740000
3! 1
CALL MSETMP$X
$
For release 3:
FKPGS 150[ 3477,,2314
1! 2314,,PSBM0-PSB+776
2! 140000,,740000
3! 2
CALL MSETMP$X
$
The difference between the two releases is the argument in ac 1, and
the fact that in release 3 the PSB is two pages long, while in release
2 it was only one page long. Again, as in the case with JSBs, the
symbols used to reference PSBs are absolute addresses. Referencing
them directly will look at the PSB of your fork which entered MDDT.
These should be offset to point to the page used for the mapping.
Again it is convenient to define a symbol for this purpose, in this
example it is called PX.
Page 5
740000-PSB<PX:
PX PRIMRY[ 777777,,777777
PX CAPMSK[ 777000,,400000
PX LSTERR[ 601405
When you are done mapping a job's JSB or PSBs, you should unmap
the pages which you had used. This is done by supplying a zero in ac
1, and having the ac's 2 and 3 be the same as they were when you
mapped the page. Thus to unmap a JSB:
1! 0
2! 140000,,740000
3! 1
CALL MSETMP$X
$
Then you can leave MDDT, either by jumping to MRETN, or by simply
typing a ^C. You don't have to unmap a PSB or JSB in order to map in
another one. Mapping in another page on top of the old one will work,
the old page will become unmapped automatically. If you want to map
in both the JSB and PSB at the same time, this can be done if you use
different pages. For example, you could try using addresses at 740000
and 741000 or 742000, etc. The examples above should then be modified
to use the new page.
Finally, there are some warnings you should be aware of. Before
using a page for mapping pages into (such as 740000), you should make
sure that it is not being used already. Reference the address and see
if MDDT types a question mark. If not, do not use the page. If you
blow any of the arguments to the MSETMP routine, the system can die.
So be very careful that you are doing the right thing. When mapping
PSBs, remember that whenever the EXEC runs a different program, it
throws away the old fork and creates a new one. Thus the system fork
number may change when you rerun a program. So you should unmap the
PSB of the fork, run the program again, search for the system fork
number again, and remap the PSB again. It is a pain, but it is
necessary. If possible, typing "START" to the program being debugged
is simpler, since you stay in the same fork. When mapping the JSB, if
the job gets logged out, the system can crash. Always unmap the JSB
before the job is logged off. Therefore it is not recommended that
you do these procedures unless the system is stand-alone, or something
is really wrong and you must fix it.
3.3
HOW TO USE BREAKPOINTS IN CODE THAT MANY USERS EXECUTE
------------------------------------------------------
When inserting a breakpoint into the running monitor, you have to
be careful that no other users will execute the code containing the
breakpoint. If some other user hits the breakpoint, they will blow up
with an illegal instruction since MDDT will not be there to handle the
breakpoint. This normally limits the places you can set breakpoints,
since most of the monitor can be gotten to by any user. Even if you
run the system stand-alone, it is possible that the routine you are
debugging will be called by job 0. However, it is still possible to
do such debugging, even on a system which is not stand-alone, and this
document will describe how this is done.
The essential element of this technique is to put in the patch in
such a way that only your own fork can ever reach the breakpoint.
First you write a simple routine which will skip if it is not being
run by your particular fork. This can be done easily if you remember
that the location FORKX contains the currently running fork number.
An example of such a routine is the following:
@ENABLE
$SDDT
DDT
JSYS 777$X
MDDT
FORKX[ 23
FFF/ 0 NOTME: PUSH P,T1
NOTME+1/ 0 MOVE T1,FORKX
NOTME+2/ 0 CAIE T1,23
NOTME+3/ 0 AOS -1(P)
NOTME+4/ 0 POP P,T1
NOTME+5/ 0 POPJ P,
NOTME+6/ 0 FFF:
The routine above simply saves ac T1, gets the currently running fork
number, compares it with your own fork number which you obtained by
looking at location FORKX, and skips if they differ.
Now assume that you want to set a breakpoint into the following
code, which is in the routine BLKSCN in the module DIRECT.
BLKSC2/ HLRZ C,BLKTAB(B)
BLKSC2+1/ CAME A,C
BLKSC2+2/ AOBJN B,BLKSC2
BLKSC2+3/ JUMPGE B,BLKSCE
BLKSC2+4/ HRRZ B,BLKTAB(B)
Assume you want the breakpoint at location BLKSC2+3. You do the
following:
Page 2
BLKSC2+3/ JUMPGE B,BLKSCE FFF$<
FFF/ 0 PUSHJ P,NOTME
FFF+1/ 0 .$B JFCL$>
FFF+2/ JUMPGE B,BLKSCE
FFF+3/ JUMPA A,BLKSC2+4
FFF+4/ JUMPA B,BLKSC2+5
BLKSC2+3/ JUMPA NOTME+6
Notice that the breakpoint has been set in the JFCL instruction
following the call to NOTME. Only your fork will execute it, so you
can now debug the section of code while other users are executing it
at the same time. Remember to remove the breakpoint when you are
done.
To run a particular program while having breakpoints set, you
must remember that the breakpoint has to be set by the same process
which you expect to hit it. So for example, typing ^EQUIT, setting a
breakpoint, returning to the EXEC and running your program will not
work. You must enter MDDT and set the breakpoints from your program
you want to debug. As an example:
@ENABLE
$GET PROGRAM
$DDT
DDT
JSYS 777$X
MDDT
(PUT IN "NOTME" ROUTINE AND SET BREAKPOINTS HERE)
MRETN$G
$
$G
4.0 A LIST OF THE RELEASE 3 BUGHLTS
=======================================
THE FOLLOWING IS A LIST OF THE BUGHLTS FOUND IN THE MONITOR. THE LIST
IS ORDERED ALPHABETICALLY AND THE NAME OF THE MONITOR MODULE FOLLOWS
THE BUGHLT NAME AND STRING. THERE MAY BE A COMMENT FOLLOWING THE BUGHLT
AND/OR THE TAG IN THE MODULE WHERE THE BUGHLT IS FOUND. IF YOU HAVE ANY
ADDITIONAL COMMENTS YOU WOULD LIKE TO INCLUDE FOR THE RELEASE 3A LISTING OF
THE BUGHLTS PLEASE SEND THEM IN WRITING TO THE TOPS-20 MONITOR MARLBOROUGH
SUPPORT GROUP.
ABKSKD,<ADDRESS BREAK FROM SCHEDULER CONTEXT>)#PAGEM//
APRNX1,<NXM DETECTED BY APR>,<A>)#APRSRV//P1NXM:
IN APR INTERRUPT CODE, PIAPR: AT P1NXM:.
NOTE THIS SAYS DETECTED BY APR NOT CAUSED BY APR. A CONTAINS
THE RESULT OF A CONI APR,A. THE BUGHLT RESULTS FROM A
NONSKIP FROM CONZ APR,APNXM. IN THE SYSERROR BLOCK IN
DUMP (IF NOT IN THE SYSERR.LOG) YOU CAN READ THE PAGER
DATA, PAGER AND APR FLAGS. BG%APS/APR-FLAGS, BG%PGS/PGR-FLGS
BG%PGD/PAGER-DATA. THE NXM MAY BE CAUSED BY ANYTHING, THE
CHANNELS, SA. YOU CAN LOOK IN THE KIEPT (THIS IS THE EPT)
AT THE TOP YOU WILL FIND THE EIGHT 4-WORD CHANNEL LOGOUT
LOCATIONS. WD0:/INITIAL CHANNEL COMMAND. WD1:/CHAN STATUS
WORD. WD2:/LAST UPDATED COMMAND. WD3:/RESERVED. THIS IS
ALMOST CERTAINLY A HARDWARE PROBLEM. SET NO RELOAD IF YOU ARE
GETTING LOTS OF THESE AND DO THE CONI ETC ON WHATEVER YOU
SUSPECT IS GIVING YOU THE NXM.
APRNX2,<NXM DETECTED BY APR>) ;YES#APRSRV//
ASGSW2,<SWPOMG-CAN'T ASSIGN RESERVED DRUM ADDRESS>)#PAGEM//
ASOFNF,<DELFIL: ASOFN GAVE FAIL RETURN FOR LONG FILE XB>)#DISC//
ASTJFN,<GETFDB: CALLED FOR JFN WITH OUTPUT STARS>)#LOOKUP//
BADDAC,<INSACT - NULL ACCOUNT STRING SEEN>)#DIRECT//
ROUTINE INSACT IN DIRECT IS TRYING TO INSERT A NULL ACCOUNT
STRING IN THE FDB. THE ACCOUNT STRING IS LATER USED AS AN
INDEX, THEREFORE THE HLT. THE ADDRESS OF THE FDB IS IN INSACF.
POINTER TO THE ACCOUNT IS IN INSACA. 36 BIT DIRECTORY NUMBER
IS IN <A>.
BADREC,<FILINI - Reconstruction of ROOT-DIRECTORY failed>)#FILINI//
TRYING TO COPY THE INDEX BLOCK OF THE BACKUP COPY OF THE <ROOT-DIR
ECTORY> TO THE INDEX BLOCK OF THE <ROOT-DIRECTORY> AND FAILED TO GET
OFN FOR THE INDEX BLOCK OR FOR THE ROOT-DIRECTORY, OR FAILED TO GET
PAGE TO MAP INDEX BLOCK INTO OR THE BACKUP INDEX BLOCK IS BAD.
BADROT,<FILIN2: ROOT-DIRECTORY IS INVALID>)#FILINI//
ERROR RETURN FROM BLKSCN...
BADTTY,<TRANSFER TO NONEXISTENT TTY CODE>)#TTYSRV// TTBUGH:
BADXT1,<INDEX TABLE MISSING AND CAN NOT BE CREATED>)#FILINI//
DURING FILE SYSTEM INITIALIZATION.
BADXTB,<FILIN2: Could not initialize index table>)#FILINI// IDXBAD:
BKUPDF,<BKUPD - BAD CST1 ENTRY OR INCONSISTENT CST>)#PAGEM// BKUP7:
BOOTCR,<GETSWM - NOT ENOUGH CORE FOR SWPMON>)#MEXEC//
BOOTEP,<GSMDSK - CANNOT MAP EPT PAGE>)#MEXEC//
BOOTER,<GETSWM - ERROR LOADING SWPMON>)#MEXEC//
BOOTLK,<GSMDSK - FAILED TO LOCK NEEDED PAGES>)#MEXEC// GSMLER:
BOOTMP,<GSMDSK - CANNOT MAP BOOTSTRAP PAGES>)#MEXEC//
BTBCR1,<FILINI - NO BIT TABLE FILE AND UNABLE TO CREATE ONE>)#FILINI//
DURING SYSTEM INITIALIZATION TRYING TO INITIALIZE A PRIVATE COPY OF
THE DISK BITTABLE SINCE THE REAL ONE WAS NOT ACCESSABLE .
RESULTS FROM ERROR RETURN FROM A CALL TO CRTBTB IN DSKALC WHICH
INITIALIZES A BITTABLE IN CORE. FATAL ERRORS OCCUR WHEN UNABLE TO
ASSIGN SWAPPING (SWPALC) OR HOME BLOCKS. GET A BUGCHK UPON FAILURE
TO ASSIGN PAGES MARKED IN THE BAT BLOCKS.
BTBCRT,<FILINI - COULD NOT INITIALIZE BIT TABLE FOR PUBLIC STRUCTURE>)#FILINI//
DURING FILE SYSTEM REFRESH. ERRORS ARE SAME AS BTBCR1 BUGHLT.
CKDFRK,<JOB 0 CFORK FAILED>)#MEXEC//
CST2I1,<PAGE TABLE CORE POINTER AND CST2 FAIL TO CORRESPOND>)#PAGEM//
CST2I2,<MVPT-CST2 INCONSISTENT>)#PAGEM//
CST2I3,<PAGE TABLE CORE POINTER AND CST2 FAIL TO CORRESPOND>)#PAGEM//
DGUTPG,<DIAG - LOCKED PAGE LIST PAGE LOCKED AT DIAG UNLOCK>)#DIAG//
DGZTPA,<DIAG - LOCKED PAGE LIST PAGE WAS ZERO>)#DIAG//
DNOPT0,<DSKCLZ-JFNOFN FAILED FOR PAGE 0>)#DISC//
DRMFL1,<ASFSB-UNEXPECTED DRUM FULL>)#PAGEM//
DRMFUL,<DRUM COMPLETELY FULL>)#PAGEM//
DRMIBT,<DRMASN-BIT TABLE INCONSISTENT>)#SWPALC// DRMBUG:
DRMNFR,<DRMAM-CAN'T FIND PAGE WHEN DRMFRE NON-0>)#SWPALC//
DRUMP1,<DRMIO - DRUMP ON BUT NO DRUM CODE IN SYSTEM>)#STG//
DST2SM,<SWPINI-DST TOO SMALL>)#SWPALC//
DTECAR,<DTESRV- CARRIER FUNCTION WITH NO LINE NUMBER PRESENT>)#DTESRV//
DTEDEV,<LINEAL -ILLEGAL DEVICE>)#DTESRV// LINEA1:
DTEIDP,<DTESRV- INDIRECT POINTER WITH GARBAGE PACKET>)#DTESRV//
DTEIFR,<DTESRV-ILLEGAL FUNCTION REQUEST FROM 11>)#DTESRV//
DTETTY,<TAKLC-NON-TTY DEVICE ON FUNCTION CODE 4>)#DTESRV//
DTEUIF,<DTESRV-UNIMPLEMENTED FUNCTION FROM 11>)#DTESRV// NOOP:
FATAPE,<FATAL ADDRESS PARITY ERROR>,<A>)#APRSRV//
IN APR INTERRUPT ROUTINE PIAPR:. A CONTAINS THE RESULT OF A
CONI APR,A. THE BUGHLT RESULTS FROM NONSKIP ON CONZ APR,APAPE.
FATCDP,<FATAL CACHE DIRECTORY PARITY ERROR>,<A>)#APRSRV//
IN APR INTERUPT ROUTINE PIAPR:. A CONTAINS THE RESULTS OF A
CONI APR,A. THE BUGHLT RESULTS FROM NONSKIP ON CONZ APR,APCDPE.
FATMPE,<FATAL PARITY ERROR>)#APRSRV//MEMP8:
DETECTED DURING A CORE SCAN LOOP (NOT CHECKING CACHE) PRECEEDED
BY A BUGCHK WICH SHOULD TELL YOU MORE. THERE WILL BE DATA IN
THE SYSERR.LOG FOR THE EVENT CODE 161.
FILBTB,<UNABLE TO WRITE BIT TABLE FILE>)#FILINI//
FILIRD,<FILINW: COULD NOT INITIALIZE THE ROOT DIRECTORY>)#FILINI// INIROT:
DURING FILE SYSTEM INITIALIZATION. THE ONLY FAILURE SEEMS TO BE
FROM A CALL TO MAPDIR WHICH HAS <ROOT-DIRECTORY> DIRECTORY NUIMBER
1, IN AC1, AND PS: STRUCTURE NUMBER 0, IN AC2. THAT IS CAN'T MAP
IN ROOT DIRECTORY.
FILMAP,<FILIN2: COULD NOT MAP IN ROOT-DIRECTORY>)#FILINI//
FILRID,<FILINW: INDEX TABLE ALREADY SET UP FOR ROOT DIR>)#FILINI//
FRKNPT,<FKHPTN - FORK HAS NO PAGE TABLE>)#FORK//
FRKPTE,<BADCPG-FATAL ERROR IN FORK PT PAGE>)]#PAGEM//
FRKSLF,<SUSFK - GIVEN SELF AS ARG>)#FORK//
GLFNF,<GLREM - FORK NOT FOUND>)#SCHED// GLREM2:
GTFDB2,<NEWLFP: GETFDB FAILURE FOR OPEN FILE.>)#DISC//
GTFDB3,<DSKREN-GETFDB FAILURE FOR OPEN FILE>)#DISC//
GTFDB6,<CRDI0A: CANNOT DO GETFDB ON ROOT-DIRECTORY >)#JSYSF//
HSYFRK,<HSYS-JOB 0 CFORK FAILED>)#MEXEC//
IBCPYW,<COPY-WRITE POINTER IN INDEX BLOCK>)#PAGEM//
IBOFNF,<FILINI: ASOFN FAILURE FOR ROOT DIRECTORY IB>)#FILINI//
CAN'T ASSIGN AN OFN FOR THE INDEX BLOCK OF PS:<ROOT-DIRECTORY>
DURING NORMAL SYSTEM STARTUP.
IDXNOS,<FILINI - COULD NOT ASSIGN FREE SPACE FOR IDXTAB>)#FILINI//
TRYING TO MAKE A TEMPORARY COPY OF INDEXTABLE IN JSB FREESPACE IN
ORDER TO CREATE THE FIRST FEW DIRECTORIES ON THE SYSTEM. THE FOUR
WORD PAGE ALLOCATION BITTABLE IN JSB (JBCOR) SAYS NOTHING FREE.
ILAGE,<BAD AGE FIELD IN CST0>)#PAGEM// BADAGE:
ILBOOT,<GETSWM-ILLEGAL VALUE OF BOOTFL>)#MEXEC//
ILCHS1,<PHYSIO - ILLEGAL CHANNEL STATUS AT SIO>)#PHYSIO//
ILCHS2,<PHYSIO - ILLEGAL CHANNEL STATE AT STKIO>)#PHYSIO//
ILCNSP,<PHYSIO - ILLEGAL CALL TO CONSPW>)#PHYSIO// CNSPWE:
ILCNST,<PHYSIO - ILLEGAL CALL TO CONSTW>)#PHYSIO// CNSTWE:
ILCST1,<ILLEGAL ADDRESS IN CST1 ENTRY, CAN'T RESTART>)#PAGEM//
AT SYSTEM RELOAD FOLLOWING A CRASH. TRYING TO REINITIATE I/O
OPERATIONS IN SWAPPER WHICH WERE IN PROGRESS AT THE TIME OF CRASH.
THE BACKUP ADDRESS FOR A PAGE THAT WAS BEING READ OR WRITTEN IS
FOUND TO BE NEITHER THE FILESYSTEM NOR SWAPPING...AN IMPOSSIBLE
SITUATION. THE INTEGRITY OF THE CORE STATUS TABLES CST AND CST1
ARE IN DOUBT. AC2 CONTAINS STATUS BITS,,ADDRESS FROM CST1.
ILDEST,<ILLEGAL DESTINATION IDENTIFIER TO SETMPG OR SETPT>)#PAGEM//
ILDRA2,<DRMIAD-ILLEGAL DRUM ADDRESS>)#SWPALC//
ILFPTE,<ILLFPT: ILLEGAL SECTION NUMBER REFERENCED>)#PAGEM// ILLFPT:
ILGDA1,<GDSTX - BAD ADDRESS>)#SWPALC//
ILGDA2,<GDSTX - BAD ADDRESS>)#SWPALC//
ILIRBL,<PHYSIO - IORB LINK NOT NULL AT ONFPWQ>)#PHYSIO// IRBNNL:
ILLIND,<ILLEGAL INDIRECT>)#PAGEM//
ILMADR,<ILLEGAL ADDRESS REFERENCE IN MONITOR>)#PAGEM// MILRF1:
ILOFN1,<MSCANP-ILLEG IDENT>)#PAGEM//
ILOKSK,<OKSKED WHEN NOT NOSKED>)#SCHED//
ILPAG1,<SWPOT0-INVALID PAGE>)#PAGEM// SWPTBD:
ILPAGN,<MRKMPG-INVALID PAGE NUMBER>)#PAGEM//
ILPDAR,<PHYSIO - ILLEGAL DISK ADDRESS IN PAGEM REQUEST>)#PHYSIO//
ILPLK1,<MLKPG-ILLEGAL ARGS>)#PAGEM//
ILPPT1,<UPDOFN-BAD POINTER IN PAGE TABLE>)#PAGEM// UOFBPP:
IN ROUTINE UPDOFN WHICH IS SUPPOPSED TO WRITE OUT THE INDEX BLOCK
OF THE OFN PASSED. DURING SCAN OF THE INDEX BLOCK IT IS DISCOVERED
THAT ONE OF THE INDEX BLOCK ENTERIES FOR A CORE PAGE IS OUT OF
BOUNDS, OR THE ENTRY IS A SWAPPING ADDRESS WHOSE NEXT LEVEL OF
STORAGE IS NOT THE FILE SYSTEM WHICH IT MUST BE. THE DRUM STATUS
(SWAPPER STATUS) TABLE INTEGRETY MAY BE IN QUESTION AS WELL AS THE
INDEX BLOCK. THE INDEX BLOCK IN QUESTION IS MAPPED IN BEGINNING
AT FPG2A WHERE FPG2A(11) SHOULD BE THE BAD ENTRY IF THAT MEANS ANYTHING.
ILPPT2,<UPDPGS-BAD POINTER IN PAGE TABLE>)#PAGEM// UPGBPP:
ICODE NOT REFERENCED.
ILPPT3,<BAD POINTER IN PAGE TABLE>)#PAGEM// NPGBAD:
ILPTN1,<MRPACS-ILLEG PTN>)#PAGEM//
ILRBLT,<PHYSIO - IORB LINK NOT NULL AT ONF/STWQ>)#PHYSIO// IRBNNT:
ILRREV,<ILLEGAL TO READ REVERSE>)#PHYH11//
ILSPTH,<SETPT-SPTH INCONSISTENT WITH XB>)#PAGEM//
ILSPTI,<ILLEGAL SPT INDEX GIVEN TO SETMXB>)#PAGEM//
ILSRC,<ILLEGAL SOURCE IDENTIFIER GIVEN TO SETPT>)#PAGEM//
ILSTP3,<VERLUK: IMPOSSIBLE SKIP RETURN FROM EXTLUU>)#LOOKUP//
ILSWPA,<SWPIN - ILLEGAL SWAP ADDRESS>)#PAGEM//
ILTWQ,<PHYINT - TWQ OR PWQ INCORRECT>) ;NO.#PHYSIO//
ILTWQP,<PHYSIO - PWQ OR TWQ TAIL POINTER INCORRECT>)#PHYSIO// IRBERR:
ILULK1,<MULKPG - TRIED TO UNLOCK PAGE NOT LOCKED>)#PAGEM//
ILULK2,<TRIED TO UNLOCK PAGE NOT LOCKED>)#PAGEM//
ILULK3,<MULKMP - ILLEGAL MONITOR ADDRESS>)#PAGEM//
ILULK4,<MULKCR - ILLEGAL CORE PAGE NUMBER>)#PAGEM//
ILUST1,<PHYSIO - UNIT STATUS INCONSISTENT AT SIO>)#PHYSIO//
ILUST3,<PHYSIO - SCHSEK - IMPOSSIBLE UNIT STATUS>)#PHYSIO//
ILUST4,<PHYSIO - CONTROLLER ACTIVE AT SPS>)#PHYSIO//
ILUST5,<PHYSIO - ILLEGAL UNIT OR CHANNEL STATE AT STKIO>)#PHYSIO//
ILWRT2,<ATTEMPTED WRITE REF TO PROTECTED MONITOR>)#PAGEM// ILWR2:
ILXBP,<SETPT-BAD POINTER IN XB>)#PAGEM//
IMPAFB,<IMPCQ: ATTEMPT TO UNLOCK BUFFER ON FREELIST>)#IMPDV//
IMPALF,<IMPLKB: ATTEMPT TO LOCK BUFFER ON FREELIST>)#IMPDV//
IMPBN2,<IMPIN-BFR NOT SETUP>)#IMPBBN//
IMPBN2,<IMPIN-BFR NOT SETUP>)#IMPISI//
IMPBNS,<IMPIN-BFR NOT SETUP>)#IMPBBN//
IMPBNS,<IMPIN-BFR NOT SETUP>)#IMPISI//
IMPCCF,<CAN'T CREATE IMP FORK>)#IMPDV//
IMPNBC,<PKMSG: NEGATIVE RESIDUAL BYTE COUNT>)#IMPDV//
IMPNII,<NO IMP INPUT BUFFERS>)#IMPANX//
IMPNII,<NO IMP INPUT BUFFERS>)#IMPBBN//
IMPNII,<NO IMP INPUT BUFFERS>)#IMPDBG//
IMPNII,<NO IMP INPUT BUFFERS>)#IMPISI//
IMPRMI,<IMP - REGULAR MESSAGE ON IRREG QUEUE>)#IMPDV// IMPMTT:
IMPUBF,<IMULKB: ATTEMPT TO UNLOCK BUFFER ON FREELIST>)#IMPDV//
IMPUFB,<IMIP1: ATTEMPT TO UNLOCK BUFFER ON FREELIST>)#IMPDV//
IMPUUO,<IMPOSSIBLE MUUO>)#APRSRV//
IONXM,<I/O NXM ON UNIBUS DEVICE>)#APRSRV//
IOPGF,<IO PAGE FAIL>,<A>)#APRSRV//APRFAT:
REPEAT 0< AROUND THIS CODE IN APRSRV.
IPCOVL,<PIDINI: PIDS AND FREE POOL OVERLAP, IPCF WON'T WORK!>)#IPCF//
J0NRUN,<JOB 0 NOT RUN FOR TOO LONG, PROBABLE SWAPPING HANGUP>)#SCHED//
JSBNIC,<SETPPG-JSB NOT IN CORE>)#PAGEM//
JTENQE,<JTENQ WITH BAD NSKED>)#SCHED//
KPALVH,<KEEP ALIVE CEASED>)#APRSRV//RLDHLT::
GET HERE BY THE FRONT END (OR THE OPERATOR) DOING XCT 144 ON A
KEEP ALIVE CEASED. PC IS IN RLODPC AND RLODPC+1.
A KEEP ALIVE COUNTER IS KEPT BY BOTH THE FRONT AND REAR END.
THE FRONT END CAN READ THE REAR END KEEP ALIVE COUNTER AND THE
REAR END CAN READ THE FRONT END KEEP ALIVE COUNTER AD THEY DO
SO PERIODICALLY. WHEN THE COUNTER OF THE OTHER PROCESSOR IS
NOTICED TO BE THE SAME TWICE IN A ROW AS IT WAS UPON THE LAST
SAMPLING, IT IS ASSUMED THAT THE OTHER PROCESSOR IS NOT RUNNING.
IN THIS BUGHLT CASE THE FRONT END HAS NOTICED THE REAR END COUNT
AS UNCHANGED AND CAUSED THIS BUGHLT. IN THE CASE OF THE REAR
END NOTICING THE FRONT END COUNT AS UNCHANGED THE JOB0 RUN FLAG
IS INCREMENTED, THE LOAD11 FLAG IS INCREMENTED AND THE FRONT
END GETS RELOADED THE NEXT TIME JOB0 IS RUN (CODE IN DTESRV @
DTECHK) SEND ALL OF [DECSYSTEM-20 CONTINUED] IS ISSUED. NOTE
THE BUGHLT IS FOR REAREND KEEP ALIVE COUNT CEASED.
LUUMON,<.LBCHK: ILLEGAL LUUO FROM MONITOR CONTEXT>)#APRSRV//.LBCHK:
LUUO TRAPPED IN MONITOR CONTEXT. LOOK AT FOLLOWING TO SEE HOW
IT GOT THERE:
.LUTRP: ;FLAGS
0 ;OLD PC
0 ;EFFECTIVE ADDRESS
,,.LBCHK;NEW PC
.LBCHK: THIS BUGHLT
MAP41F,<MAPF41 FAILED TO SKIP>)#FORK//
MAPBT1,<OFN FOR BIT TABLE IS ZERO>)#DSKALC//
THS SDB SLOT FOR THE BITTABLE OFN CONTAINS A 0 FOR A PARTICULAR
STRUCTURE. THE STRUCTURE NUMBER IS IN AC1. TO SEE FOR YOURSELF:
SDBTAB+STR#/SDBADDR SDBADDR+10/OFN OF BITTABLE. THE OFN IS
EXPECTED TO BE THERE.
MDDJFN,<GETFDB: CALLED FOR NON-MDD DEVICE>)#LOOKUP//
MNTLNG,<MNTBTB - BIT TABLE IS A LONG FILE>)#DSKALC//
MNTBTB IS A ROUTINE CALLED WHEN A STRUCTURE IS BREING MOUNTED AND
ALSO BY JOB 0 AT SYSTEM STARTUP FOR ALL STRUCTURES. THE DSK FILE
<ROOT-DIRECTORY>DSKBTTBL.. HAS BEEN CREATED AS A SHORT FILE AND IS
NOW APPEARING TO BE A LONG FILE WHICH IS ILLEGAL.
MONPDL,<OVERFLOW OR PDL OVERFLOW TRAP IN MONITOR>)#APRSRV//KITRPM:
MPEUTP,<PFCDPE-UNKNOWN TRAP ON TEST REFERENCE>)#APRSRV//
MTARIN,<MTAINT: INTERRUPT RECEIVED FOR NONACTIVE IORB>)#MAGTAP// NOACTV:
NETIEF,<NETOPN: EXTDEC FAILURE AFTER PREVIOUS NON-FAILURE.>)#NETWRK//
NETWNS,<WATNOT: WAS CALLED FROM SCHEDULER LEVEL.>)#NETWRK//
NEWBAK,<FILRFS - NEWIB FAILURE FOR BACKUP ROOT-DIR>)#FILINI//
TRYING TO CREATE INDEXBLOCK FOR BACKUP COPY OF ROOT-DIRECTORY
DURING SYSTEM REFRESH. ERRORS SAME AS NEWROT BUGHLT.
NEWROT,<FILRFS - NEWIB FAILURE FOR ROOT-DIRECTORY>)#FILINI//
DURING FILESYSTEM REFRESH, TRYING TO CREATE AN INDEX BLOCK FOR THE
PRIMARY COPY OF THE ROOT-DIRECTORY. NEWIB IS ROUTINE IN FILINI WHICH
RETURNED FAILURE. FAILURES IN NEWIB ARE FROM ERROR RETURN FROM DSKASA
WHICH IS TRYING TO ASSIGN A DSK ADDRESS FOR THE INDEX BLOCK, OR FROM
ASSIGNING THE OFN FOR THE INDEX BLOCK.
NLWA,<L2INI: No lineprinter window available>)#LPKSDV//
NOACB,<MENTR - NO MORE AC BLOCKS>)#SCHED//
NOADXB,<RELOFN-NO DSK ADR FOR XB>)#PAGEM//
DURING RELEASING AND/OR DELETING AN OFN HAVE GONE OFF TO INDEX BLOCK
FROM THE SYSTEM AND DISCOVERED THERE WAS NO DISK INDEX BLOCK ADDRESS
ALTHOUGH THERE WAS INDEED A CORE AND SWAPPER ADDRESS.
NOBTBN,<FILINI - UNABLE TO GET SIZE OF BOOTSTRAP.BIN FILE>)#FILINI//
IT WAS LOOKING IN THE HOME BLOCKS. DURING FILE SYSTEM INITIALIZATION.
NOCTY,<UNABLE TO ALLOCATE DATA FOR CTY>)#TTYSRV//
NOFEFS,<FILINI - UNABLE TO GET SIZE OF FRONT END FILE SYSTEM>)#FILINI//
IT WAS LOOKING IN THE HOME BLOCKS.
NOFNDU,<FNDUNT-CAN'T FIND DEVICE FOR JFN>)#DEVICE//
SOMEBODY IS TRYING TO DO SOMETHING TO A JFN LIKE CLOSF, OPEN OR
SOME MTOPR, SAY, AND NO DEVICE IS ASSOCIATED WITH THE JFN. THAT
IS WHEN THE DISPATCH TABLE FOR JFNS IS COMPARED TO THE DISPATCH
TABLE FOR DEVICES, THERE IS AN INCONSISTENCY. MONITOR LOGIC.
NOIORB,<SETIRB - MISSING IORB>)#PHYSIO//
NOPGT0,<OPNLNG: NO PAGE TABLE 0 IN LONG FILE.>)#DISC//
NOSEB2,<PGMPE-NO SYSERR BUFFER AVAILABLE>)#APRSRV//
NOTOFN,<UPDOF0-ARG NOT OFN>)#PAGEM//
DURING UPDOFN -- A GENERAL PURPOSE ROUTINE WHICH WRITES OUT AN
INDEX BLOCK TO DISK. THE ARG IN AC1 WHICH IS SUPPOSED TO BE THE
OFN IS OUT OF BOUNDS. SOME STUFF HAS ALREADY BEEN DONE INDEXING OFF
THIS OFN, LIKE UPDATING THE SPTH AND THE BITTABLE.
NOUBWA,<RH2NCH: NO UNIBUS WINDOW FOR RH11>)#PHYH11//
NSKDIS,<DISMISS WHILE NOSKED OR WITH NON-RES TEST ADDRESS>)#SCHED//
NSPUDF,<UNSUPPORTED NETWORK FUNCTION>)#STG// NSPQ::
OPOPAC,<MRETN - TRIED TO OVER-POP AC STACK>)#SCHED//
PAGLCK,<DESPT-PAGE LOCKED>)#PAGEM// DESPX1:
SOMETHING IS TRYING TO DEASSIGN A SPT BUT IT IS LOCKED IN CORE.
PAGNIC,<GETCPP-PAGE NOT IN CORE>)#PAGEM// GETCPX:
PFCDP,<MEMORY PARITY ERROR>)#APRSRV//PGNXER:
PGNDEL,<REMFPB-PAGE NOT COMPLETELY DELETED>)#PAGEM//
PHYCH1,<PHYSIO - HOME BLOCK CHECK IORB ALREADY ON TWQ>)#PHYSIO//
PHYICA,<PHYINI - ILLEGAL ARGUMENT TO CORE ALLOC>)#PHYSIO// INIERR:
PHYICE,<PHYINI - FAILED TO ASSIGN RESIDENT STG>)#PHYSIO//
PHYLTF,<PHYSIO - SCHLTM - UNEXPECTED LATOPT FAILURE>)#PHYSIO//
PHYP0E,<PHYALZ - PAGE 0 STORAGE EXHAUSTED>)#PHYSIO//
PIITRP,<INSTRUCTION TRAP WHILE PI IN PROGRESS OR IN SCHEDULER>)#SCHED//
PISKED,<ENTERED SCHEDULER WITH PI IN PROGRESS>)#SCHED//
PITRAP,<PAGER TRAP WHILE PI IN PROGRESS>)#PAGEM// PIPTR1:
PRONX2,<NXM DETECTED BY PROCESSOR>)#APRSRV//
PSBNIC,<SETPPG-PSB NOT IN CORE>)#PAGEM//
PSISTK,<PSI STORAGE STACK OVERFLOW>)#SCHED// PIOVFW:
PTAIC,<SWPIN - PT PAGE ALREADY IN CORE>)#PAGEM//
PTDEL,<DESPT-PT NOT DELETED>)#PAGEM//
TRYING TO DEASSIGN SPT AND RELEASE STORAGE AND IT DIDN'T GET COMPLETELY
PURGED FROM THE SYSTEM. THERE IS A FILE SYSTEM ADDRESS AS A BACKUP TO
THE SWAPPER ADDRESS.
PTMPE,<PAGE TABLE PARITY ERROR>)#APRSRV//PFCD25::
PTNIC1,<SWPIN - PAGE TABLE NOT IN CORE>)#APRSRV//
PTNON0,<SETPT0 - PREVIOUS CONTENTS NON-0>)#PAGEM//
PTOVRN,<UPDPGS-COUNT TOO LARGE>)#PAGEM//
WHEN UPDATING FILE PAGES (CHANGED PAGES TO FILE SYSTEM FROM SWAPPER)
THE NUMBER OF PAGES DESIRED IS ADDED TO THE FIRST PAGETABLE ADDR AND
THE RESULT EXCEEDS THE PAGETABLE SIZE.
PVTRP,<PROPRIETARY VIOLATION TRAP>)#APRSRV//PFCD21:
PWRFL,<FATAL POWER FAILURE>) ;CRASH AND RELOAD#APRSRV//
PYILUN,<PHYSIO - ILLEGAL UNIT NUMBER>)#PHYSIO//
RH11CC,<PHYH11 - ILLEGAL CHANNEL COMMAND WORD>)#PHYH11//
RH1ICF,<PHYH11 - INVALID CHANNEL FUNCTION>)#PHYH11//
RH2ICF,<PHYRH2 - INVALID CHANNEL FUNCTION>)#PHYH2//
ROTSYM,<IDXINI: ROOT-DIRECTORY SYMBOL TABLE IS BAD>)#FILINI// ERJMP [
RP4FEX,<PHYP4 - ILLEGAL FUNCTION>)#PHYP4//
RP4IF2,<PHYP4 - ILLEGAL FUNCTION AT STKIO>)#PHYP4//
RP4IFC,<PHYP4 - ILLEGAL FUNCTION AT CNV>) ;YES TO EITHER#PHYP4//
RP4ILF,<PHYP4 - ILLEGAL FUNCTION ON INTERRUPT>)#PHYP4//
RP4LTF,<PHYP4 - FAILED TO FIND TWQ ENTRY AT RP4LTM>)#PHYP4// RP4LTE:
RPGERR,<BADCPG-FATAL ERROR IN RESIDENT PAGE>)#PAGEM//
RSMFAI,<RESSMM-FAILED TO ASSIGN SWAP MON PAGE>)#PAGEM//
SECG37,<ILSCN-SECTION NUMBER GREATER THAN 37>)#PAGEM//
SECGT1,<PGRT3 - SECTION NUMBER GREATER THAN MAXSEC>)#PAGEM//
SERFRK,<SERINI-CANNOT CREATE SYSERR FORK>)#SYSERR//
SHRNO0,<DESPT-SHARE COUNT NON-ZERO>)#PAGEM//
TRYING TO DEASSIGN AN SPT AND RELEASE THE STORAGE BUT THE SHARE COUNT
IS NOT ZERO.
SJBFRK,<JOB 0 CFORK FAILED>)#MEXEC//
SKDCL1,<CALL TO SCHEDULER WHEN ALREADY IN SCHEDULER>)#SCHED//
SKDCL2,<CALL TO SCHEDULER WHEN ALREADY IN SCHEDULER>)#SCHED//
SKDMPE,<MPE IN SCHEDULER OR PI CONTEXT>)#APRSRV//
SKDPF1,<PAGE FAIL IN SCHED CONTEXT>) ;NO#APRSRV//
SKDTRP,<INSTRUCTION TRAP WHILE IN SCHEDULER>)#SCHED//
SPTFL1,<SPT COMPLETELY FULL>)#PAGEM//
YOU GOT IT.
SPTFL2,<SPT COMPLETELY FULL>)#PAGEM//
SPTPIC,<SWPIN - SPT PAGE ALREADY IN CORE>)#PAGEM//
STKOVF,<MONITOR STACK OVERFLOW>)#APRSRV// MSTKOV::
HARD TO GUESS WHY THIS MIGHT HAPPEN. LOOK AT THE STACK IN
A DUMP.CPY. THIS ROUTINE IS CALLED FROM 10 DIFFERENT MONITOR
MODULES...
STRBAD,<ASOFN-ILLEGAL STRUCTURE NUMBER>#PAGEM//
ASOFN IS GENERAL MONITOR ROUTINE THAT TRIES TO ASSIGN OFN. STR #
PASSED IN AC2 AND THERE IS NO ENTRY IN STRTAB AT STRTAB+STR#, OR
STR NO. IS OUT OF BOUNDS (STR NO.>STRN). NOTE AC1/INDEX BLOCK ADDR
AC3/DIRECTORY NUMBER.
STZERO,<FILINI: STRTAB ENTRY FOR PS IS 0>)#FILINI// FILERR:
THE STRTAB ENTRY FOR ANY STRUCTURE SHOULD CONTAIN THE SDB ADDRESS
FOR THAT STRUCTURE. REMEMBER PS: STRUCTURE # IS 0 SO IT SHOULD BE
THE FIRST ENTRY IN STRTAB.
SWPMNE,<SWAP ERROR IN SWAPPABLE MONITOR>)#PAGEM// SWPEX3:
SWPPSB,<SWAP ERROR IN PSB PAGE>)#PAGEM// SWPEX4:
SWPPT,<SWAP ERROR IN UNKNOWN PT>)#PAGEM// SWPEX7:
SWPPTP,<SWAP ERROR IN UNKNOWN PT PAGE>)#PAGEM// SWPEX6:
SWPUPT,<SWAP ERROR IN UPT, OR PSB>)#PAGEM// SWPEX8:
TTBAD1,<BAD DEVICE DESIGNATOR FOR TERMINAL AT ATACH2>)#MEXEC//
TTDAS1,<HLTJB: UNABLE TO DEASSIGN CONTROLLING TERMINAL>)#SCHED//
TTICN0,<TCI - NO BUFFER POINTER BUT COUNT NON-0>)#TTYSRV//
TTNAC3,<CTY NOT ACTIVE AT FSIPBO>)#DSKALC//
TTNAC4,<CTY NOT ACTIVE AT FSIPBI>)#DSKALC//
TTNAC5,<CTY NOT ACTIVE AT FSIINI>)#DSKALC//
TTNAC8,<CAN'T ASSIGN TERMINAL AT DEVINI>)#DEVICE//
TTOCN0,<TTSTO - NO BUFFER BUT COUNT NON-0>)#TTYSRV//
TTONOB,<TTY OUTPUT - NO BUFFER BUT COUNT NON-0>)#TTYSRV//
TWQNUL,<PHYSIO - PWQ OR TWQ WAS NULL AT A SEEK OR TRANSFER COMPLETION>)#PHYSIO// IRBMIS:
UIONIR,<UDSKIO - NO IORB FOR NOSKED FORK>)#PHYSIO//
UNPGF1,<MEMPAR-UNKNOWN PAGE FAIL TRAP>)#APRSRV//
UNPGF2,<UNKNOWN PAGE FAILURE TYPE>)#APRSRV//PFCDX::
UNTRAP,<UNKNOWN TRAP INSTRUCTION>)#APRSRV//KITRPX:
UNXMPE,<PFCDPE-UNEXPECTED PARITY ERROR TRAP>)#APRSRV//
USECG0,<USER SECTION NUMBER GREATER THAN 0>)]#PAGEM// JXN T1,TWUSR,[
WRTLNG,<WRTBTB - BIT TABLE IS A LONG FILE>)#DSKALC//
TRYING TO WRITE OUT OT DSK THE INCORE COPY OF THE DSK BITTABLE.
THE DSK FILE WAS JUST CREATED ABOUT 20 LINES OF CODE AGO AS SHORT
... INEXPLICABLE, THE DSK FILE APPEARS TO BE A LONG FILE NOW.
XSCORE,<CST TO SMALL FOR PHYSICAL CORE PRESENT>)#PAGEM//
4.1 A LIST OF THE RELEASE 3 BUGCHKS.
=======================================
NOTE THAT BUGCHKS ARE NOT FATAL SYSTEM ERRORS, THEY ARE NOT CRASHES,
AND USUALLY ARE OF LITTLE CONSEQUENCE UNLESS THERE IS SOME SORT OF SYSTEM FAILURE
FOLLOWING A BUGCHK. THE BUGCHK IS NOTED ON THE CTY SIMPLY TO TELL YOU THAT
SOME SORT OF SYSTEM INCONSISTENCY WAS FOUND IN THE MONITORS DATA BASE THAT
WAS EASILY IGNOIRED OR CORRECTED. THE BUGCHKS BECOME SIGNIFICANT WHEN THEY
ARE FOLLOWED BY A BUGHLT OR SOME OTHER FAILURE. NOTE THAT THE BUGCHKS HERE
ARE LISTED BY MONITOR MODULE IN WHICH THEY OCCUR. WHEN REPORTING BUGHLTS
TO THE MARLBOROUGH SUPPORT GROUP BE SURE TO INCLUDE ANY INFORMATION ABOUT
BUGCHKS THAT HAVE BEEN EXPERIENCED PREVIOUSLY.
SNARK:<3-MONITOR>APRSRV.MAC.396
SCHPR2: BUG(CHK,SPWRFL,<SPURIOUS POWER FAIL INDICATION>)
BUG(CHK,PWRRES,<POWER RESTART>) ;GIVE CHANCE TO LOOK AROUND
BUG(CHK,MPEDEV,<MEMORY PARITY ERROR DETECTED BY APR OR DEVICE>)
BUG(CHK,UNBADE,<UNBCH5 - UNIBUS ADAPTER ERROR>,<T1>)
UNIBUG: BUG(CHK,ILSTV,<UNIBUG: ILLEGAL SM10 VECTORED INTERRUPT>)
KIBADU: BUG(CHK,ILLUUO,<KIBADU: ILLEGAL UUO FROM MONITOR CONTEXT>,<KIMUFL,KIMUPC,KIMUEF>)
BADDMS: BUG(CHK,ILLDMS,<BADDMS: ILLEGAL DMS JSYS FROM MONITOR CONTEXT>)
PFCD22::BUG(CHK,RFILPF,<REFILL ERROR PAGE FAIL>)
PFCD27::BUG(CHK,ILPSEC,<ILLEGAL SECTION NUMBER>,<TRAPPC,TRAPSW>)
BUG(CHK,HARDCE,<HARD CACHE ERRORS--CACHE DESELECTED>)
SNARK:<3-MONITOR>DEVICE.MAC.96
BUG(CHK,DEVUCF,<DEVAV - UNEXPECTED CHKDES FAILURE>)
SNARK:<3-MONITOR>DIRECT.MAC.335
BUG(CHK,DIRSY1,<DELDL8: DIRECTORY SYMBOL TABLE FOULED UP FOR DIRECTORY:>,<A,B>)
BUG(CHK,DIRBAD,<SETDI4: SMASHED DIRECTORY NUMBER:>,<A,SETDNM>)
BUG(CHK,DIRFKP,<SETDIR-DIR PAGE 0 BELONGS TO FORK IN DIRECTORY:>,<B,SETDNM>)
BUG(CHK,DIRULK,<ULKMD2: ATTEMPT TO UNLOCK ILLEGALLY FORMATTED DIR, DIR NUMBER:>,<T1,T2>)
BUG(CHK,DIRDNL,<ULKDIR-DIRECTORY NOT LOCKED, DIRECTORY NUMBER:>,<T1,T2>)
JRST [ BUG(CHK,LNGDIR,<LONG DIRECTORY FILE IN DIRECTORY:>,<T3>)
BUG(CHK,DIRSY2,<MDDNAM: SYMBOL TABLE FOULED UP IN DIRECTORY:>,<A,B>)
BUG(CHK,DIRSY3,<LOOKUP: SYMBOL SEARCH FOULED UP IN DIRECTORY:>,<C,B>)
BUG(CHK,DIRSY4,<NAMCM4: DIRECTORY SYMBOL TABLE FOULED UP IN DIRECTORY:>,<A,B>)
BUG(CHK,MPIDXO,<MAPIDX - No OFN for Index Table File>)
BUG(CHK,DIRPG0,<DR0CHK: ILLEGAL FORMAT FOR DIRECTORY PAGE 0 IN DIRECTORY:>,<A,B>)
BUG(CHK,DIRPG1,<DRHCHK: DIRECTORY HEADER BLOCK IS BAD IN DIRECTORY:>,<A,B>)
BUG(CHK,DIRSY5,<SYMBAD: ILLEGAL FORMAT FOR DIRECTORY SYMBOL TABLE IN DIRECTORY:>,<A,B>)
BUG(CHK,DIRFDB,<ILLEGAL FORMAT FOR FDB IN DIRECTORY:>,<A,B>)
BUG(CHK,DIRNAM,<NAMBAD: ILLEGAL FORMAT FOR DIRECTORY NAME BLOCK IN DIRECTORY:>,<A,B>)
BUG(CHK,DIREXT,<EXTBAD: ILLEGAL FORMAT FOR DIRECTORY EXTENSION BLOCK IN DIRECTORY:>,<A,B>)
BUG(CHK,DIRACT,<ACTBAD: ILLEGAL FORMAT FOR DIRECTORY ACCOUNT BLOCK IN DIRECTORY:>,<A,B>)
BUG(CHK,DIRFRE,<FREBAD: ILLEGAL FORMAT FOR DIRECTORY FREE BLOCK IN DIRECTORY:>,<A,B>)
BUG(CHK,DIRSY6,<RBLDST: PREMATURELY RAN OUT OF ROOM IN SYMBOL TABLE IN DIRECTORY:>,<A,B>)
BUG(CHK,DIRBLK,<BLKSCN: ILLEGAL BLOCK TYPE IN DIRECTORY:>,<A>)
BUG(CHK,DIRB2S,<RLDFB1: DIRECTORY FREE BLOCK TOO SMALL IN DIRECTORY:>,<A,B>)
BUG(CHK,DIRB2L,<RLDFB2: DIRECTORY FREE BLOCK TOO LARGE IN DIRECTORY:>,<A,B>)
( 90.17) {BUG(CHK}
BUG(CHK,DIRBCB,<RLDFB3: DIRECTORY FREE BLOCK CROSSES PAGE BOUNDARY IN DIRECTORY:>,<A,B>)
( 90.23) {BUG(CHK}
BUG(CHK,DIRIFB,<RLDFB4: ILLEGAL BLOCK TYPE ON DIRECTORY FREE LIST IN DIRECTORY:>,<A,B>)
( 90.29) {BUG(CHK}
BUG(CHK,DIRBAF,<RLDFB5: BLOCK ALREADY ON DIRECTORY FREE LIST IN DIRECTORY:>,<A,B>)
( 90.35) {BUG(CHK}
BUG(CHK,DIRRHB,<RLDFB6: ATTEMPTING TO RETURN A HEADER BLOCK IN DIRECTORY:>,<A,B>)
SNARK:<3-MONITOR>DISC.MAC.279
( 4.33) {BUG(CHK}
DSKINB: BUG(CHK,GTFDB1,<DSKINS: GETFDB FAILURE.>)
( 40.42) {BUG(CHK}
BUG(CHK,NOUTF1,<SPLOPN: NOUT OF DIRECTORY NUMBER FAILED>)
SNARK:<3-MONITOR>DSKALC.MAC.225
( 3.30) {BUG(CHK}
BUG(CHK,DSKBT1,<DSK BIT TABLE FOULED, CAN'T FIND FREE PAGE ON TRACK WITH NON-0 COUNT>,<T2,T3>)
( 6.24) {BUG(CHK}
BUG(CHK,ASAASG,<DSKASA - ASSIGNING ALREADY ASSIGNED DISK ADDRESS>,<T1,T2>)
( 6.90) {BUG(CHK}
BUG(CHK,ASGBAD,<DSKASA - ASSIGNING BAD DISK ADDRESS>,<T3,T2>)
( 7.51) {BUG(CHK}
BUG(CHK,DEAUNA,<DEDSK-DEASSIGNING UNASSIGNED DISK ADDRESS>,<T1,T2>)
( 8.60) {BUG(CHK}
BUG(CHK,DEABAD,<DSKDEA - DEASSIGNING BAD DISK ADDRESS>,<T3,T2>)
( 19.79) {BUG(CHK}
BUG(CHK,ASGBPG,<INIBTB-FAILED TO ASSIGN BAD PAGE(S)>,<T1,T2>)
( 22.22) {BUG(CHK}
BUG(CHK,WRTCPB,<WRTBTB - FAILED TO BACKUP ROOT-DIRECTORY>,<T1>)
( 22.54) {BUG(CHK}
BUG(CHK,WRTBT4,<ASOFN ON BIT TABLE FILE FAILED>,<T2>)
( 26.17) {BUG(CHK}
BUG(CHK,DSKBT3,<DISK BIT TABLE ALREADY LOCKED AT LCKBTB>,<T1>)
( 39.54) {BUG(CHK}
; BUG(CHK,NO2PRT,<FEFSYS-NO DUAL-PORTED DISK. USING LOGICAL 0>)
( 43.23) {BUG(CHK}
BUG(CHK,FEOCPB,<FEFSYS - FAILED TO BACKUP ROOT-DIRECTORY>,<T1>)
( 49.28) {BUG(CHK}
BUG(CHK,BADBAT,<BAT BLOCKS UNREADABLE>)
( 81.43) {BUG(CHK}
BUG(CHK,SWPASF,<CHKBAT-FAILED TO ASSIGN BAD SWAPPING ADDRESS>,<C,CKBDRA>)
( 87.21) {BUG(CHK}
BUG(CHK,NOBAT1,<FAILED TO WRITE PRIMARY BAT BLOCK>,<T1,T2>)
( 87.32) {BUG(CHK}
BUG(CHK,NOBAT2,<FAILED TO WRITE SECONDARY BAT BLOCK>,<T1,T2>)
SNARK:<3-MONITOR>DTESRV.MAC.275
( 14.35) {BUG(CHK}
BUG(CHK,DTETIP,<DTETDN-TO10 DONE RECEIVED WITH NO TRANSFER IN PROGRESS>)
( 16.6) {BUG(CHK}
JRST [ BUG(CHK,DTEP2S,<TO10DN-PACKET TOO SMALL>)
( 17.19) {BUG(CHK}
BUG(CHK,DTEODD,<TAKLC-ODD BYTE COUNT FOR LINE CHARACTERS>)
( 19.11) {BUG(CHK}
JRST [ BUG(CHK,DTEDAT,<TAKTOD- ILLEGAL FORMAT FOR TIME/DATE>)
( 23.7) {BUG(CHK}
JRST [ BUG(CHK,KLIOVF,<DTESRV-KLINIK DATA BASE TOO LARGE>,<C>)
SNARK:<3-MONITOR>ENQ.MAC.77
( 6.14) {BUG(CHK}
BUG(CHK,ENQMLF,<ENQUE: INTERNAL ENQ OF A MONITOR LOCK FAILED>)
( 11.54) {BUG(CHK}
BUG(CHK,DEQMDF,<DEQUE: INTERNAL MONITOR DEQ FAILED>)
SNARK:<3-MONITOR>FESRV.MAC.63
( 12.16) {BUG(CHK}
JRST [ BUG(CHK,FEUSTS,<FESSTS-UNKNOWN STATUS>)
( 14.19) {BUG(CHK}
JRST [ BUG(CHK,FEBAD,<FEHSD-WRONG FE>) ;NO
JRST [ BUG(CHK,FEBFOV,<FEHSD-BUFFER OVERFLOW>,<A,C>) ;NO
SNARK:<3-MONITOR>FILINI.MAC.217
( 4.103) {BUG(CHK}
JRST [ BUG(CHK,NOBTB,<FILINI - UNABLE TO OPEN BIT TABLE FILE>)
( 4.123) {BUG(CHK}
BUG(CHK,BADXT2,<INDEX TABLE MISSING AND WAS CREATED>)
( 5.66) {BUG(CHK}
BUG(CHK,FILHOM,<UNABLE TO REWRITE HOME BLOCKS IN WRTBTB>)
( 5.94) {BUG(CHK}
BUG(CHK,FILFEF,<Could not create Front End File System>)
( 5.106) {BUG(CHK}
BUG(CHK,FILBOT,<COULD NOT CREATE BOOTSTRAP.BIN FILE>)
( 6.46) {BUG(CHK}
BUG(CHK,BADBAK,<FILIN2 - BACKUP COPY OF ROOT DIRECOTRY IS NOT GOOD>)
( 6.52) {BUG(CHK}
BUG(CHK,FIXBAD,<Could not re-write Home Blocks to point to FE Filesystem>)
( 6.57) {BUG(CHK}
BUG(CHK,FIXBDB,<COULD NOT RE-WRITE HOME BLOCKS TO POINT TO BOOTSTRAP.BIN>)
( 7.20) {BUG(CHK}
JRST [ BUG(CHK,FILJB1,<FILCRD: No room to create standard system directories>)
( 7.37) {BUG(CHK}
JRST [ BUG(CHK,FILCCD,<Could not create directory>)
( 7.60) {BUG(CHK}
BUG(CHK,FILBAK,<FILCRD: COULD NOT CREATE BACKUP OF ROOT-DIR>)
( 16.60) {BUG(CHK}
BUG(CHK,BADIDX,<IDXINI: PARTIALLY UNSUCCESSFUL INDEX TABLE REBUILD>)
SNARK:<3-MONITOR>FILMSC.MAC.103
( 4.44) {BUG(CHK}
PTYOP1: BUG(CHK,TTNAC1,<LINE NOT ACTIVE AT PTYOPN>)
SNARK:<3-MONITOR>FORK.MAC.123
( 33.13) {BUG(CHK}
BUG(CHK,ILJRFN,<JFKRFH - BAD JRFN, IGNORED>)
( 42.11) {BUG(CHK}
BUG(CHK,FLKINT,<FLOCK-CALLED WHILE NOINT>)
( 42.23) {BUG(CHK}
BUG(CHK,FLKTIM,<FLOCK-TIMEOUT>)
( 42.48) {BUG(CHK}
FUNLK3: BUG(CHK,FLKNS,<FUNLK-LOCK NOT SET>)
( 46.9) {BUG(CHK}
; BUG(CHK,NOXRFH,<DASFKH - ATTEMPT TO DEASSIGN NONEXISTANT RFH, IGNORED>)
SNARK:<3-MONITOR>FREE.MAC.89
( 3.38) {BUG(CHK}
RELFRA: BUG(CHK,RELRNG,<RELFRE: BLOCK OUT OF RANGE>)
( 4.43) {BUG(CHK}
BUG(CHK,RELBAD,<RELFRE-BAD BLOCK BEING RELEASED>)
( 15.10) {BUG(CHK}
JRST [ BUG(CHK,ASGREQ,<ILLEGAL POOL NUMBER GIVEN TO ASGRES>)
( 15.18) {BUG(CHK}
JRST [ BUG(CHK,ASGREP,<ILLEGAL PRIORITY GIVEN TO ASGRES>)
( 20.13) {BUG(CHK}
JRST [ BUG(CHK,RESBAD,<RELRES: ILLEGAL ADDRESS PASSED TO RELRES>)
( 20.20) {BUG(CHK}
JRST [ BUG(CHK,RESBND,<RELRES: RELEASING SPACE BEYOND END OF RESIDENT FREE POOL>)
( 20.31) {BUG(CHK}
BUG(CHK,RESBAZ,<RELRES: FREE BLOCK RETURNED MORE THAN ONCE>)
SNARK:<3-MONITOR>FUTILI.MAC.91
( 9.43) {BUG(CHK}
JE STRLK,(T1),[BUG(CHK,ULKSTZ,<OVERLY DECREMENTED STRUCTURE LOCK>)
SNARK:<3-MONITOR>GTJFN.MAC.414
( 62.31) {BUG(CHK}
BUG(CHK,NOSPLM,<RELJFN: COULD NOT SEND SPOOL MESSAGE TO QUASAR>)
SNARK:<3-MONITOR>IMPANX.MAC.10
( 10.27) {BUG(CHK}
BUG(CHK,IMPHNW,<LHOSTN DISAGREES WITH THE IMP>)
SNARK:<3-MONITOR>IMPBBN.MAC.4
( 9.24) {BUG(CHK}
BUG(CHK,IMPHNW,<LHOSTN DISAGREES WITH THE IMP>)
SNARK:<3-MONITOR>IMPDBG.MAC.4
( 10.27) {BUG(CHK}
BUG(CHK,IMPHNW,<LHOSTN DISAGREES WITH THE IMP>)
SNARK:<3-MONITOR>IMPDV.MAC.18
( 13.25) {BUG(CHK}
IMPUXI: BUG(CHK,IMPUX0,<IMP JB0 FORK - UNEXPECTED INTERRUPT>)
( 53.44) {BUG(CHK}
BUG(CHK,IMPLTF,<IMPLT FULL>)
( 54.42) {BUG(CHK}
BUG(CHK,IMPIFH,<IMPGC-IMPOSSIBLE FAILURE OF IMPHFL>)
( 58.31) {BUG(CHK}
BUG(CHK,IMPREM,<UPBRB: RECEIVED EXCESSIVE MESSAGES>,T2)
( 62.64) {BUG(CHK}
PKMSL: BUG(CHK,IMPMSL,<PKMSG - MSG TOO LARGE>)
( 63.16) {BUG(CHK}
BUG(CHK,IMPNMA,<PKBY1: NO MSG ALLOCATION>,T2)
SNARK:<3-MONITOR>IMPISI.MAC.4
( 8.24) {BUG(CHK}
BUG(CHK,IMPHNW,<LHOSTN DISAGREES WITH THE IMP>)
SNARK:<3-MONITOR>IO.MAC.218
( 19.10) {BUG(CHK}
BUG(CHK,BLKF1,<BYTINA: BLKF SET BEFORE CALLING SERVICE ROUTINE>)
( 26.41) {BUG(CHK}
BUG(CHK,BLKF2,<BYTOUA: BLKF SET BEFORE CALL TO SERVICE ROUTINE>)
( 41.14) {BUG(CHK}
BUG(CHK,DMPRLF,<DMPREL-FAILED TO RELEASE PAGE>)
SNARK:<3-MONITOR>IPCF.MAC.133
( 10.43) {BUG(CHK}
JRST [ BUG(CHK,IPCMCN,<MESREC: MESSAGE COUNT WENT NEGATIVE>)
( 25.36) {BUG(CHK}
SOJL T4,[BUG(CHK,PIDOD1,<MUTCHO: PID COUNT OVERLY DECREMENTED>)
( 39.36) {BUG(CHK}
BUG(CHK,IPCFKH,<CHKPDD: COULD NOT FIND LOCAL FORK HANDLE>)
( 42.37) {BUG(CHK}
JRST [ BUG(CHK,PIDFLF,<CREPID: FREE PID LIST FOULED UP>)
( 43.19) {BUG(CHK}
JRST [ BUG(CHK,ILPID1,<CREPID: ATTEMPT TO CREATE ILLEGAL PID>)
( 44.14) {BUG(CHK}
SOJL T4,[BUG(CHK,PIDOD2,<DELPID: OVERLY DECREMENTED PID COUNT>)
( 44.30) {BUG(CHK}
JRST [ BUG(CHK,ILPID2,<DELPID: VALIDATED PID TURNED ILLEGAL>)
( 46.24) {BUG(CHK}
SOJL T1,[BUG(CHK,IPCSOD,<GETMES: SENDER'S COUNT OVERLY DECREMENTED>)
( 52.11) {BUG(CHK}
BUG(CHK,NOPID,<PIDKFL: PID DISAPPEARED>)
( 53.52) {BUG(CHK}
ERJMP [BUG(CHK,NODIR1,<SPLMES: DIRST FAILED ON EXISTING DIRECTORY NAME>)
( 54.17) {BUG(CHK}
BUG(CHK,NOUTF2,<SPLMES: NOUT OF GENERATION NUMBER FAILED>)
( 55.21) {BUG(CHK}
JRST [ BUG(CHK,NOALCM,<ALCMES: CANNOT SEND MESSAGE TO ALLOCATOR>)
( 57.16) {BUG(CHK}
BUG(CHK,IPCJB0,<PIDINI: NOT IN CONTEXT OF JOB 0>)
( 58.19) {BUG(CHK}
PIDINB: BUG(CHK,IPCFRK,<PIDINB: CANNOT CREATE FORKS FOR IPCF>)
SNARK:<3-MONITOR>JSYSA.MAC.525
( 17.70) {BUG(CHK}
JRST [ BUG(CHK,CPYUF1,<CACCT: IMPOSSIBLE FAILURE OF CPYFU1.>)
( 30.44) {BUG(CHK}
ERJMP [ BUG(CHK,EFACF3,<EFACT: FAILED TO WRITE INTO FACT FILE>)
( 30.48) {BUG(CHK}
BUG(CHK,EFACF1,<EFACT: CLOSF FAILED TO CLOSE FACT FILE.>)
( 74.33) {BUG(CHK}
BUG(CHK,SNPLKF,<SNPFN0: CANNOT LOCK DOWN PAGE INTO MONITOR>)
( 78.15) {BUG(CHK}
BUG(CHK,SNPIC,<SNPFN3: INSTRUCTION BEING REPLACED HAS CHANGED>)
( 78.49) {BUG(CHK}
SNPF4C: BUG(CHK,SNPODB,<SNPF4C: COUNT OF INSERTED BREAK POINTS OVERLY DECREMENTED>)
( 79.22) {BUG(CHK}
BUG(CHK,SNPUNL,<SNPF5A: CANNOT UNLOCK SNOOP PAGE>)
( 121.99) {BUG(CHK}
VERACX: BUG(CHK,CRSPAG,<VERACT - ACCOUNT DATA BLOCK CROSSES A PAGE BOUNDARY>)
( 121.102) {BUG(CHK}
VERAX1: BUG(CHK,BADTAB,<VERACT - SPURIOUS HASH TABLE ENCOUNTERED>)
SNARK:<3-MONITOR>JSYSF.MAC.333
( 16.23) {BUG(CHK}
BUG(CHK,CLZABF,<CLZFFW: SERVICE ROUTINE BLOCKED ON AN ABORT CLOSE>)
( 17.14) {BUG(CHK}
BUG(CHK,BLKF3,<CLZDO: BLKF SET BEFORE CALL TO SERVICE ROUTINE>)
( 31.19) {BUG(CHK}
JRST [ BUG(CHK,CRDSDF,<CRDIR1: SETDIR FAILED ON NEW DIRECTORY>)
( 35.45) {BUG(CHK}
BUG(CHK,CRDBAK,<CRDIR3: COULD NOT MAKE BACKUP COPY OF ROOT-DIRECTORY>)
( 41.10) {BUG(CHK}
JRST [ BUG(CHK,CRDOLD,<CRGDGB: OLD FORMAT CRDIR IS ILLEGAL>)
( 42.68) {BUG(CHK}
CRBUG1: BUG(CHK,CRDNOM,<CRDIR-FAILED TO MAKE MAIL.TXT FILE>)
( 45.90) {BUG(CHK}
JRST [ BUG(CHK,CRDBK1,<CRDIR4:COULD NOT MAKE BACKUP COPY OF ROOT-DIRECTORY>)
( 52.55) {BUG(CHK}
BUG(CHK,DVCHRX,<DVCHR1 - UNEXPECTED CHKDES FAILURE WITHIN .DVCHR>)
( 58.18) {BUG(CHK}
BUG(CHK,BLKF4,<.GDSTS: BLKF SET BEFORE CALL TO DEVICE ROUTINE>)
( 77.26) {BUG(CHK}
BUG(CHK,BLKF5,<.MTOPR: BLKF SET BEFORE CALL TO DEVICE ROUTINE>)
( 103.16) {BUG(CHK}
BUG(CHK,BLKF6,<.SDSTS: BLKF SET BEFORE CALL TO DEVICE ROUTINE>)
SNARK:<3-MONITOR>LOGNAM.MAC.66
( 1.85) {BUG(CHK}
BUG(CHK,NOSLNM,<SLNINI: CANNOT CREATE SYSTEM LOGICAL NAME>)
( 33.17) {BUG(CHK}
BUG(CHK,LNMILI,<LNMLUK: ILLEGAL VALUE OF LOGICAL NAME TABLE INDEX>)
( 39.32) {BUG(CHK}
BUG(CHK,ILLTAB,<TABLK2: TABLE NOT IN PROPER FORMAT>)
SNARK:<3-MONITOR>MAGTAP.MAC.163
( 22.24) {BUG(CHK}
BUG(CHK,MTANOI,<GETUBF: NO QUEUED IORB'S FOR INPUT>)
( 24.17) {BUG(CHK}
IRBDN1: BUG(CHK,MTANOQ,<IRBDN1: IRBDON CALLED FOR NON-QUEUED UP IORB>)
IRBDN2: BUG(CHK,MTANOA,<IRBDN2: IRBDON CALLED FOR AN ACTIVE IORB>)
( 50.28) {BUG(CHK}
BUG(CHK,MTAORN,<MTDIR0: MAGTAPE IORB OVERRUN>)
SNARK:<3-MONITOR>MEXEC.MAC.287
( 13.36) {BUG(CHK}
BUG(CHK,NOSERF,<CAN'T GTJFN ERROR REPORT FILE>)
( 13.39) {BUG(CHK}
BUG(CHK,SERFOF,<CAN'T OPENF ERROR REPORT FILE>)
( 16.27) {BUG(CHK}
JRST [BUG(CHK,SYSERF,<LOGSST-NO SYSERR STORAGE FOR RESTART ENTRY>)
SNARK:<3-MONITOR>PAGEM.MAC.631
( 13.23) {BUG(CHK}
BUG(CHK,XBWERR,<UPDOFN-DSK WRITE ERROR ON XB>)
( 30.30) {BUG(CHK}
RELBAD: BUG(CHK,ILIBPT,<BAD POINTER TYPE IN INDEX BLOCK>)
( 80.44) {BUG(CHK}
JRST [ BUG(CHK,WSPNEG,<SOSWSP-WSP NEGATIVE>)
( 93.48) {BUG(CHK}
PGRT4: BUG(CHK,NSKDT2,<PGRTRP-BAD NSKED OR INTDF>)
( 99.35) {BUG(CHK}
BUG(CHK,FRKBAL,<AGESET-FORK NOT IN BALSET>)
( 124.4) {BUG(CHK}
SWPEX1: BUG(CHK,SWPFPE,<SWAP ERROR IN SENSITIVE FILE PAGE>)
( 124.7) {BUG(CHK}
SWPEX2: BUG(CHK,SWPIBE,<SWAP ERROR IN INDEX BLOCK>)
( 124.14) {BUG(CHK}
SWPEX5: BUG(CHK,SWPJSB,<SWAP ERROR IN JSB PAGE>)
SNARK:<3-MONITOR>PHYH11.MAC.79
( 10.22) {BUG(CHK}
BUG(CHK,PH1PIE,<PHYH11 - RH11 LOST INTERRUPT ENABLE>)
( 11.45) {BUG(CHK}
BUG(CHK,P1NED1,<PHYH11 - RH11 NON EX DISK READING REGISTER>,<T1,T2>)
( 11.78) {BUG(CHK}
BUG(CHK,P11PAR,<PHYH11 -- CONTROL WRITE PARITY ERR>,<T1,T2>)
( 11.86) {BUG(CHK}
BUG(CHK,P2RAE2,<PHYH11 - REGISTER ACCESS ERR WRITING REG>,<T1,T2,T3>)
( 14.15) {BUG(CHK}
JRST [ BUG(CHK,PH1IHM,<PHYH11 - ILLEGAL HDW MODE - WORD MODE ASSUMED>)
( 17.10) {BUG(CHK}
BUG(CHK,P1NED3,<PHYH11 - NON EX DISK ON DONE OR ATN INTERRUPT>,<T1,T2>)
SNARK:<3-MONITOR>PHYH2.MAC.61
( 10.33) {BUG(CHK}
BUG(CHK,PH2PIM,<PHYH2 - RH20 LOST PI ASSIGNMENT>)
( 11.44) {BUG(CHK}
BUG(CHK,P2RAE1,<PHYH2 - RH20 REGISTER ACCESS ERROR READING REGISTER>,<T1,T2>)
( 12.23) {BUG(CHK}
BUG(CHK,P2RAE2,<PHYH2 - REGISTER ACCESS ERR WRITING REG>,<T1,T2,T3>)
( 15.17) {BUG(CHK}
JRST [ BUG(CHK,PH2IHM,<PHYH2 - ILLEGAL HDW MODE - WORD MODE ASSUMED>)
( 17.15) {BUG(CHK}
BUG(CHK,P2RAE3,<PHYH2 - REGISTER ACC ERR ON DONE OR ATN INTERRUPT>,<T1,T2,T3>)
SNARK:<3-MONITOR>PHYM2.MAC.50
( 8.30) {BUG(CHK}
BADSIO: BUG(CHK,PM2SIO,<PHYM2 - ILLEGAL FUNCTION AT START IO>)
( 10.46) {BUG(CHK}
TM2INU: BUG(CHK,TM2NUD,<PHYM2 - CHANNEL DONE INTERRUPT BUT NO UNIT ACTIVE>)
( 11.14) {BUG(CHK}
JRST [ BUG(CHK,TM2IDM,<PHYM2 - ILLEGAL DATA MODE AT DONE INT>)
( 14.15) {BUG(CHK}
JRST [ BUG(CHK,TM2IF2,<PHYM2 - ILLEGAL FUNCTION ON COMMAND DONE>)
( 17.25) {BUG(CHK}
BUG(CHK,TM2HER,<TM2ERR - IS.HER SET ON SUCCESSFUL RETRY>)
( 17.35) {BUG(CHK}
CNFERR: BUG(CHK,TM2RFU,<PHYM2 - ERROR RECOVERY CONFUSED>)
( 20.14) {BUG(CHK}
BUG(CHK,TM2CCI,<PHYM2 - TM02 SSC OR SLA WONT CLEAR>)
SNARK:<3-MONITOR>PHYP4.MAC.69
( 6.50) {BUG(CHK}
BUG(CHK,RP4SSC,<PHYP4 - STUCK SECTOR COUNTER>,<T1,T2>)
SNARK:<3-MONITOR>PHYSIO.MAC.147
( 8.36) {BUG(CHK}
DONIR2: BUG(CHK,PHYNIR,<PHYSIO - NULL INTERRUPT ROUTINE AT OPERATION DONE>)
( 11.28) {BUG(CHK}
BUG(CHK,NRFTCL,<PHYSIO - NO REQUESTS FOUND FOR CYLINDER SEEKED>)
( 11.34) {BUG(CHK}
PDN4: BUG(CHK,NPWQPD,<PHYSIO - NULL PWQ AT POSITION DONE>)
( 28.17) {BUG(CHK}
BUG(CHK,ILUST2,<PHYSIO - UNIT STATUS INCONSISTENT AT SPS>)
SNARK:<3-MONITOR>SCHED.MAC.551
( 12.20) {BUG(CHK}
BUG(CHK,NOINTR,<ITRAP AND PREVIOUS CONTEXT WAS NOINT>)
( 12.22) {BUG(CHK}
BUG(CHK,NOSKTR,<ITRAP FROM NOSKED CONTEXT>)
( 26.22) {BUG(CHK}
BUG(CHK,SRQOVF,<SCDRQ-SCHED REQUEST QUEUE OVERFLOW>)
( 38.29) {BUG(CHK}
BUG(CHK,SUMNR1,<AJBALS-SUMNR INCORRECT>)
( 41.14) {BUG(CHK}
BUG(CHK,SUMNR2,<SUMNR INCORRECT>)
( 43.39) {BUG(CHK}
BUG(CHK,FKWSP1,<LOADBS-UNREASONABLE FKWSP>,<T1,T2,T3>)
( 50.40) {BUG(CHK}
UBBAD: BUG(CHK,UNBFNF,<UNBLK1 - FORK NOT FOUND>)
( 62.33) {BUG(CHK}
BUG(CHK,FRKNDL,<FORK NOT PROPERLY DELETED>)
( 67.20) {BUG(CHK}
BUG(CHK,UNPIRX,<UNPIR-NO PSI IN PROGRESS>)
( 77.58) {BUG(CHK}
BUG(CHK,PSINSK,<PSI FROM NOSKED CONTEXT>)
( 80.49) {BUG(CHK}
BUG(CHK,TRPSIE,<NO MONITOR FOR TRAPPED FORK>)
BUG(CHK,IDFOD1,<AT MENTR - INTDF OVERLY DECREMENTED>)
( 86.19) {BUG(CHK}
BUG(CHK,IDFOD2,<AT MRETN - INTDF OVERLY DECREMENTED>)>
SNARK:<3-MONITOR>SWPALC.MAC.35
( 4.9) {BUG(CHK}
BUG(CHK,ILDRA1,<DASDRM-ILLEGAL OR UNASSIGNED DRUM ADDRESS>)
( 9.26) {BUG(CHK}
BUG(CHK,ASGSWB,<SWPINI-CAN'T ASSIGN BAD ADDRESS>)
SNARK:<3-MONITOR>SYSERR.MAC.36
( 6.22) {BUG(CHK}
BUG(CHK,SEBUDT,<SEBCPY-UNKNOWN DATA TYPE>,<T1,T4>)
( 7.27) {BUG(CHK}
SEBCP7: BUG(CHK,SEBISS,<SEBCPY-INSUFFICIENT STRING STORAGE IN BLOCK>)
( 10.36) {BUG(CHK}
SEBOF2: BUG(CHK,SERGOF,<SETOFI-CANNOT GTJFN/OPEN SYSERR FILE>)
SNARK:<3-MONITOR>TTDZDV.MAC.110
( 3.41) {BUG(CHK}
BUG(CHK,DZNENB,<DZSND1 - TRANSMIT NOT ENABLED ON INTERRUPT>)
( 6.48) {BUG(CHK}
JRST [ BUG(CHK,DZLINT,<DZ11 LOST INTERRUPT ENABLE>,<T2>)
SNARK:<3-MONITOR>TTFEDV.MAC.39
( 17.8) {BUG(CHK}
JRST [ BUG(CHK,NOFRSP,<ttspst- COULD NOT GET A FREE BLOCK>)
SNARK:<3-MONITOR>TTNTDV.MAC.31
( 16.21) {BUG(CHK}
BUG(CHK,IMPTMB,<NVTXG1: TOO MANY BREAKS OUTSTANDING>)
SNARK:<3-MONITOR>TTYSRV.MAC.550
( 20.22) {BUG(CHK}
BUG(CHK,ULKBAD,<UNLOCKING TTY WHEN COUNT IS ZERO>,T2)
( 24.38) {BUG(CHK}
BUG(CHK,TTNAC7,<DEALLOCATING INACTIVE LINE>,T2)
( 70.38) {BUG(CHK}
TTGTB3: BUG(CHK,TTYNTB,<RAN OUT OF TTY BUFFERS>)
( 118.32) {BUG(CHK}
DLSSX1: BUG(CHK,TTYBBO,<TTYSRV-BIG BUFFER OVERFLOW>)
( 122.11) {BUG(CHK}
BUG(CHK,TTILEC,<TTSND-UNRECOGNIZED ESCAPE CODE>,<2,3>)
Lines recognized = 206
String Matches Unrecognized Matches
1) "BUG(CHK" 206 0
The active equivalences were:
;
Files with no matches: SNARK:<3-MONITOR>ANNBIG.MAC.2 SNARK:<3-MONITOR>ANNLGE.MAC.2
SNARK:<3-MONITOR>ANNMED.MAC.2 SNARK:<3-MONITOR>ANNSML.MAC.2 SNARK:<3-MONITOR>ANPBIG.MAC.2
SNARK:<3-MONITOR>ANPLGE.MAC.2 SNARK:<3-MONITOR>ANPMED.MAC.3 SNARK:<3-MONITOR>ANPSML.MAC.2
SNARK:<3-MONITOR>ARPAF.MAC.3 SNARK:<3-MONITOR>BOOT.MAC.68 SNARK:<3-MONITOR>CDRSRV.MAC.96
SNARK:<3-MONITOR>COMND.MAC.164 SNARK:<3-MONITOR>DATIME.MAC.54 SNARK:<3-MONITOR>DDT.MAC.45
SNARK:<3-MONITOR>DDTBLT.MAC.3 SNARK:<3-MONITOR>DDTU.MAC.4 SNARK:<3-MONITOR>DIAG.MAC.9
SNARK:<3-MONITOR>DIAGSM.MAC.6 SNARK:<3-MONITOR>DTESM.MAC.15 SNARK:<3-MONITOR>EDDT.MAC.7
SNARK:<3-MONITOR>EXPRE.MAC.6 SNARK:<3-MONITOR>FDDT.MAC.4 SNARK:<3-MONITOR>FILDDT.MAC.6
SNARK:<3-MONITOR>GLOBS.MAC.657 SNARK:<3-MONITOR>LDINIT.MAC.73 SNARK:<3-MONITOR>LINEPR.MAC.175
SNARK:<3-MONITOR>LOOKUP.MAC.75 SNARK:<3-MONITOR>LPFEDM.MAC.6 SNARK:<3-MONITOR>LPFEDV.MAC.6
SNARK:<3-MONITOR>LPKSDV.MAC.26 SNARK:<3-MONITOR>MDDT.MAC.6 SNARK:<3-MONITOR>MFLIN.MAC.25
SNARK:<3-MONITOR>MFLOUT.MAC.26 SNARK:<3-MONITOR>MR.MAC.19 SNARK:<3-MONITOR>MSTR.MAC.49
SNARK:<3-MONITOR>NAMAM0.MAC.2 SNARK:<3-MONITOR>NAMAN.MAC.3 SNARK:<3-MONITOR>NAMBCH.MAC.4
SNARK:<3-MONITOR>NAMBIG.MAC.4 SNARK:<3-MONITOR>NAMDEV.MAC.3 SNARK:<3-MONITOR>NAMMED.MAC.4
SNARK:<3-MONITOR>NAMMIN.MAC.4 SNARK:<3-MONITOR>NAMSML.MAC.3 SNARK:<3-MONITOR>NETWRK.MAC.22
SNARK:<3-MONITOR>NSPSRV.MAC.207 SNARK:<3-MONITOR>PARAM0.MAC.2 SNARK:<3-MONITOR>PARAMS.MAC.80
SNARK:<3-MONITOR>PARAN.MAC.4 SNARK:<3-MONITOR>PARANSM.MAC.3 SNARK:<3-MONITOR>PARBCH.MAC.4
SNARK:<3-MONITOR>PARBIG.MAC.7 SNARK:<3-MONITOR>PARDEV.MAC.2 SNARK:<3-MONITOR>PARMED.MAC.5
SNARK:<3-MONITOR>PARMIN.MAC.7 SNARK:<3-MONITOR>PARSML.MAC.7 SNARK:<3-MONITOR>PHYPAR.MAC.55
SNARK:<3-MONITOR>PMT.MAC.6 SNARK:<3-MONITOR>POSTLD.MAC.147 SNARK:<3-MONITOR>PROLG0.MAC.8
SNARK:<3-MONITOR>PROLOG.MAC.561 SNARK:<3-MONITOR>PSM.MAC.3 SNARK:<3-MONITOR>SERCOD.MAC.44
SNARK:<3-MONITOR>SMDDT.MAC.3 SNARK:<3-MONITOR>SMPRE.MAC.6 SNARK:<3-MONITOR>SMPRM0.MAC.16
SNARK:<3-MONITOR>SMPRMS.MAC.14 SNARK:<3-MONITOR>STG.MAC.688 SNARK:<3-MONITOR>TAPE.MAC.80
SNARK:<3-MONITOR>TIMER.MAC.5 SNARK:<3-MONITOR>TTDCDV.MAC.17 SNARK:<3-MONITOR>TTMCDV.MAC.16
SNARK:<3-MONITOR>TTPTDV.MAC.19 SNARK:<3-MONITOR>VERSIO.MAC.18
4.2 A LIST OF THE SYSTEM BUGINFS
=================================
THE BUGINFS ARE OF EVEN LESS CONSEQUENCE THAN THE BUGHLTS AND YOU WILL SEE
THEM ONLY IN DEBUGGING MODE, NEVER THE LESS THEY ARE LISTED HERE FOR YOUR
INFORMATION BY SYSTEM MOPDULE IN WHICH THEY ARE FOUND. IN THE CASE YOU ARE
REPORTING A MYSTERIOUS BUGHLT OR SYSTEM FAILURE TO MSG PLEASE INCLUDE ANY
BUGINFS YOU MAY HAVE SEEN.
SNARK:<3-MONITOR>DTESRV.MAC.275
DINGM3: BUG(INF,DTECDM,<DTESRV- TO -10 COUNTS DON'T MATCH>,<A>)
BUG(INF,DTELPI,<DTECHK- DTE LOST PI ASSIGNMENT>)
BUG(INF,DTELDB,<DTECHK- 11 LOST DOORBELL>)
BUG(INF,DT11DN,<DTECHK- 10 LOST TO11DN INTERRUPT>)
SNARK:<3-MONITOR>IMPANX.MAC.10
BUG(INF,IMINX1,<UNUSUAL ANI INTERRUPT, CONI ANI IS>,<T1>)
BUG(INF,IMPOFL,<MESSAGE BUFFER OVERFLOW>,<T1,T2,T3,T4>)
( 11.14) {BUG(INF}
BUG(INF,IMINX2,<IMIERR CALLED, CONI ANI IS>,<T1>)
SNARK:<3-MONITOR>IMPDBG.MAC.4
( 6.32) {BUG(INF}
BUG(INF,IMINX1,<UNUSUAL ANI INTERRUPT, CONI ANI IS>,<T1,T2,T3,T4>)
( 10.39) {BUG(INF}
BUG(INF,IMPOFL,<MESSAGE BUFFER OVERFLOW>,<T1,T2,T3,T4>)
( 11.14) {BUG(INF}
BUG(INF,IMINX2,<IMIERR CALLED, CONI ANI IS>,<T1>)
( 12.3) {BUG(INF}
BUG(INF,IMINX3,<UNUSUAL ANI INTERRUPT, CONI ANI IS>,<T1,T2,T3,T4>)
( 12.9) {BUG(INF}
BUG(INF,IMINX4,<UNUSUAL ANI INTERRUPT, CONI ANI IS>,<T1,T2,T3,T4>)
( 16.4) {BUG(INF}
BUG(INF,IMOUX1,<UNUSUAL ANO INTERRUPT, CONI ANO IS>,<T1,T2,T3,T4>)
( 16.10) {BUG(INF}
BUG(INF,IMOUX2,<UNUSUAL ANO INTERRUPT, CONI ANO IS>,<T1,T2,T3,T4>)
( 16.19) {BUG(INF}
BUG(INF,IMOUX3,<UNUSUAL ANO INTERRUPT, CONI ANO IS>,<T1,T2,T3,T4>)
SNARK:<3-MONITOR>IMPDV.MAC.18
( 10.25) {BUG(INF}
BUG(INF,IMPHIF,<HSTINI FAILED TO FIND HOST NAME FILE>)
( 19.17) {BUG(INF}
BUG(INF,IMPMUL,<RECEIVED MSG FOR UNKNOWN LINK>,<T1,T2>)
( 22.36) {BUG(INF}
BUG(INF,IMPRNO,<RFNM OVERDUE>,T2)
( 22.51) {BUG(INF}
BUG(INF,IMPMSO,<MESSAGE STUCK IN OUTPUT QUEUE>,T2)
( 23.8) {BUG(INF}
BUG(INF,IMPXBO,<IRREG MSG BUFFER OVERFLOW>)
( 28.37) {BUG(INF}
BUG(INF,IMPXUT,<RECEIVED IRREG MSG WITH UNKNOWN LINK OR TYPE>,<T1,T2,T3>)
( 29.24) {BUG(INF}
BUG(INF,IMPCTH,<IMPNCL TOO HIGH>)
( 30.50) {BUG(INF}
BUG(INF,IMPIFC,<ILL FMT CTL MSG>,<T2,T3>)
( 32.36) {BUG(INF}
BUG(INF,IMPREA,<RECD EXCESS ALL>,T2)
( 35.7) {BUG(INF}
IM8ERR: BUG(INF,IMPRNE,<RECD NCP ERR>,<T1,T2>)
( 38.17) {BUG(INF}
BUG(INF,IMPCUL,<RECD CTL MSG FOR UNKNOWN LINK>,<T1,T2,T3>)
( 39.18) {BUG(INF}
BUG(INF,IMPLAE,<IMPOPL: LINK ALREADY EXISTS>,T2)
( 57.51) {BUG(INF}
BUG(INF,IMPBSC,<MESSAGE HAS BAD SIZE OR COUNT>,<T1,T2>)
( 65.63) {BUG(INF}
BUG(INF,IMPLEO,<CAN'T FIND LT ENTRY FOR OUTPUT MESSAGE>,<T1,T2>)
( 73.18) {BUG(INF}
BUG(INF,IMPABF,<ASNTBF FAILED>)
SNARK:<3-MONITOR>JSYSF.MAC.333
( 45.81) {BUG(INF}
BUG(INF,DELBDD,<DELDIR: BAD DIRECTORY DELETED. REBUILD BIT TABLE>)
SNARK:<3-MONITOR>MSTR.MAC.49
( 38.23) {BUG(INF}
BUG(INF,STRMSG,<MSTDMC - COULD NOT SEND MESSAGE TO ALLOCATOR>)
SNARK:<3-MONITOR>NETWRK.MAC.22
( 33.9) {BUG(INF}
BUG(INF,NCPFUN,<NCP FSM RECIEVED FUNNY INPUT>,<T1,T2,UNIT>)
SNARK:<3-MONITOR>PHYH11.MAC.79
( 18.13) {BUG(INF}
ATNXU: BUG(INF,PH2NXA,<PHYH11 - ATTENTION FROM NONEXISTENT UNIT>)
SNARK:<3-MONITOR>PHYH2.MAC.61
( 18.30) {BUG(INF}
ATNXU: BUG(INF,PH2NXA,<PHYH2 - ATTENTION FROM NONEXISTENT UNIT>)
( 18.40) {BUG(INF}
BADDON: BUG(INF,PH2DNA,<PHYH2 - DONE INTERRUPT AND CHANNEL NOT ACTIVE>)
SNARK:<3-MONITOR>PHYM2.MAC.50
( 7.37) {BUG(INF}
AOBJP T3, [BUG(INF,TM2N2S,<PHYM2 - MORE DRIVES THAN TABLE SPACE, EXCESS IGNORED>)
( 12.21) {BUG(INF}
BUG(INF,TM2UNA,<PHYM2 - DONE INTERRUPT AND UDB NOT ACTIVE>)
( 15.28) {BUG(INF}
JRST [ BUG(INF,TM2IDX,<PHYM2 - ILLEGAL RETRY BYTE POINTER>)
( 17.14) {BUG(INF}
JRST [ BUG(INF,TM2IRF,<PHYM2 - ILLEGAL FUNCTION DURING RETRY>)
SNARK:<3-MONITOR>PHYSIO.MAC.147
( 43.54) {BUG(INF}
BUG(INF,PHYCH2,<PHYSIO - HOME BLOCK CHECK IORB TIMED OUT>)
( 44.2) {BUG(INF}
CHK6: BUG(INF,PHYCH3,<PHYSIO - HOME BLOCK CHECK IORB TIMED OUT BUT WAS NOT ON TWQ>)
( 46.18) {BUG(INF}
BUG(INF,OVRDTA,<PHYSIO - OVERDUE TRANSFER ABORTED>)
SNARK:<3-MONITOR>TTDCDV.MAC.17
( 4.15) {BUG(INF}
BUG(INF,TTYPI2,<SCANNER LOST PI ASSIGNMENT, COULD NOT RESTORE>)
( 4.19) {BUG(INF}
TTCH8C: BUG(INF,TTYPI1,<SCANNER LOST PI ASSIGNMENT, SUCCESSFULLY RESTORED>)
SNARK:<3-MONITOR>TTNTDV.MAC.31
( 29.33) {BUG(INF}
BUG(INF,IMPNEA,<NVT RECEIVED BYTES EXCEEDING ALLOCATION>)
Lines recognized = 46
String Matches Unrecognized Matches
1) "BUG(INF" 46 0
The active equivalences were:
;
Files with no matches: SNARK:<3-MONITOR>ANNBIG.MAC.2 SNARK:<3-MONITOR>ANNLGE.MAC.2
SNARK:<3-MONITOR>ANNMED.MAC.2 SNARK:<3-MONITOR>ANNSML.MAC.2 SNARK:<3-MONITOR>ANPBIG.MAC.2
SNARK:<3-MONITOR>ANPLGE.MAC.2 SNARK:<3-MONITOR>ANPMED.MAC.3 SNARK:<3-MONITOR>ANPSML.MAC.2
SNARK:<3-MONITOR>APRSRV.MAC.396 SNARK:<3-MONITOR>ARPAF.MAC.3 SNARK:<3-MONITOR>BOOT.MAC.68
SNARK:<3-MONITOR>CDRSRV.MAC.96 SNARK:<3-MONITOR>COMND.MAC.164 SNARK:<3-MONITOR>DATIME.MAC.54
SNARK:<3-MONITOR>DDT.MAC.45 SNARK:<3-MONITOR>DDTBLT.MAC.3 SNARK:<3-MONITOR>DDTU.MAC.4
SNARK:<3-MONITOR>DEVICE.MAC.96 SNARK:<3-MONITOR>DIAG.MAC.9 SNARK:<3-MONITOR>DIAGSM.MAC.6
SNARK:<3-MONITOR>DIRECT.MAC.335 SNARK:<3-MONITOR>DISC.MAC.279 SNARK:<3-MONITOR>DSKALC.MAC.225
SNARK:<3-MONITOR>DTESM.MAC.15 SNARK:<3-MONITOR>EDDT.MAC.7 SNARK:<3-MONITOR>ENQ.MAC.77
SNARK:<3-MONITOR>EXPRE.MAC.6 SNARK:<3-MONITOR>FDDT.MAC.4 SNARK:<3-MONITOR>FESRV.MAC.63
SNARK:<3-MONITOR>FILDDT.MAC.6 SNARK:<3-MONITOR>FILINI.MAC.217 SNARK:<3-MONITOR>FILMSC.MAC.103
SNARK:<3-MONITOR>FORK.MAC.123 SNARK:<3-MONITOR>FREE.MAC.89 SNARK:<3-MONITOR>FUTILI.MAC.91
SNARK:<3-MONITOR>GLOBS.MAC.657 SNARK:<3-MONITOR>GTJFN.MAC.414 SNARK:<3-MONITOR>IMPBBN.MAC.4
SNARK:<3-MONITOR>IMPISI.MAC.4 SNARK:<3-MONITOR>IO.MAC.218 SNARK:<3-MONITOR>IPCF.MAC.133
SNARK:<3-MONITOR>JSYSA.MAC.525 SNARK:<3-MONITOR>LDINIT.MAC.73 SNARK:<3-MONITOR>LINEPR.MAC.175
SNARK:<3-MONITOR>LOGNAM.MAC.66 SNARK:<3-MONITOR>LOOKUP.MAC.75 SNARK:<3-MONITOR>LPFEDM.MAC.6
SNARK:<3-MONITOR>LPFEDV.MAC.6 SNARK:<3-MONITOR>LPKSDV.MAC.26 SNARK:<3-MONITOR>MAGTAP.MAC.163
SNARK:<3-MONITOR>MDDT.MAC.6 SNARK:<3-MONITOR>MEXEC.MAC.287 SNARK:<3-MONITOR>MFLIN.MAC.25
SNARK:<3-MONITOR>MFLOUT.MAC.26 SNARK:<3-MONITOR>MR.MAC.19 SNARK:<3-MONITOR>NAMAM0.MAC.2
SNARK:<3-MONITOR>NAMAN.MAC.3 SNARK:<3-MONITOR>NAMBCH.MAC.4 SNARK:<3-MONITOR>NAMBIG.MAC.4
SNARK:<3-MONITOR>NAMDEV.MAC.3 SNARK:<3-MONITOR>NAMMED.MAC.4 SNARK:<3-MONITOR>NAMMIN.MAC.4
SNARK:<3-MONITOR>NAMSML.MAC.3 SNARK:<3-MONITOR>NSPSRV.MAC.207 SNARK:<3-MONITOR>PAGEM.MAC.631
SNARK:<3-MONITOR>PARAM0.MAC.2 SNARK:<3-MONITOR>PARAMS.MAC.80 SNARK:<3-MONITOR>PARAN.MAC.4
SNARK:<3-MONITOR>PARANSM.MAC.3 SNARK:<3-MONITOR>PARBCH.MAC.4 SNARK:<3-MONITOR>PARBIG.MAC.7
SNARK:<3-MONITOR>PARDEV.MAC.2 SNARK:<3-MONITOR>PARMED.MAC.5 SNARK:<3-MONITOR>PARMIN.MAC.7
SNARK:<3-MONITOR>PARSML.MAC.7 SNARK:<3-MONITOR>PHYP4.MAC.69 SNARK:<3-MONITOR>PHYPAR.MAC.55
SNARK:<3-MONITOR>PMT.MAC.6 SNARK:<3-MONITOR>POSTLD.MAC.147 SNARK:<3-MONITOR>PROLG0.MAC.8
SNARK:<3-MONITOR>PROLOG.MAC.561 SNARK:<3-MONITOR>PSM.MAC.3 SNARK:<3-MONITOR>SCHED.MAC.551
SNARK:<3-MONITOR>SERCOD.MAC.44 SNARK:<3-MONITOR>SMDDT.MAC.3 SNARK:<3-MONITOR>SMPRE.MAC.6
SNARK:<3-MONITOR>SMPRM0.MAC.16 SNARK:<3-MONITOR>SMPRMS.MAC.14 SNARK:<3-MONITOR>STG.MAC.688
SNARK:<3-MONITOR>SWPALC.MAC.35 SNARK:<3-MONITOR>SYSERR.MAC.36 SNARK:<3-MONITOR>TAPE.MAC.80
SNARK:<3-MONITOR>TIMER.MAC.5 SNARK:<3-MONITOR>TTDZDV.MAC.110 SNARK:<3-MONITOR>TTFEDV.MAC.39
SNARK:<3-MONITOR>TTMCDV.MAC.16 SNARK:<3-MONITOR>TTPTDV.MAC.19 SNARK:<3-MONITOR>TTYSRV.MAC.550
SNARK:<3-MONITOR>VERSIO.MAC.18
5.0 A Private GALAXY System for Debugging
===============================================================
1.0 Introduction
QUASAR, the queue handler for GALAXY, is rather unusual among user
software in that only one copy can be running on a system at any given
time. When QUASAR is first run after system startup, it defines
itself as the system QUASAR. If QUASAR is run again while this first
copy is running, the new QUASAR fails with the message
QUASAR STOP CODE - PQI
This makes things rather awkward for people like software specialists
who need to debug QUASAR, for it implies that either your users be
extremely cooperative and not do any queuing while you are debugging,
or that you take stand-alone time, which is often hard to get.
A similar problem exists when debugging LPTSPL, BATCON, or
SPRINT. In the case of these programs, as many copies can be run as
desired, but it is difficult to keep innocent users from being
affected by your work. If you are debugging LPTSPL, and QUASAR sends
another user's request to your LPTSPL, it's easy to see that the
request might be lost or at least held up because of your debugging.
For the above reasons, the concept of a "private GALAXY" has
been invented and implemented by a number of edits to GALAXY
components. With these changes installed, a specialist may run his or
her own copy of QUASAR which is completely independent of the QUASAR
running under SYSJOB. The queues are kept separately. Any requests
sent to the specialist's "private" QUASAR will never be seen by the
system QUASAR (the one running under SYSJOB), and vice versa. The
specialist may also run copies of LPTSPL, BATCON, SPRINT, and/or
QUENCH which will communicate only with the private QUASAR. Users
running the standard system software will not be affected, and their
requests cannot be sent to your copies of these programs by mistake.
As an example, to debug a new version of LPTSPL, you might run
private copies of QUASAR, QUENCH, and LPTSPL. With QUENCH, you would
queue requests for your LPTSPL to handle. The private copy of QUASAR
A Private GALAXY System for Debugging Page 2
Introduction
would receive those requests and then send them to your private copy
of LPTSPL. Since that LPTSPL is communicating with your own copy of
QUASAR, not the system one, it would not receive any requests except
those you queued yourself.
The following modules have been changed to implement a private
GALAXY:
QSRMAC - The QUASAR universal file for GALAXY
QSRT20 - The TOPS-20 monitor interface for QUASAR
CSPQSR - The QUASAR interface for LPTSPL and BATCON
QMANGR - The QUASAR interface for QUENCH and SPRINT
No other modules are changed. In particular, none of the sources for
BATCON, LPTSPL, SPRINT, or QUENCH are changed. This means, for
example, that you can debug BATCON by loading it with the CSPQSR on
the SWS kit. When the code is tested and ready to be used by all
users, simply recompile it using the system universal files and reload
it with the CSPQSR on the standard software tape. It is not necessary
to change the source for BATCON.
A Private GALAXY System for Debugging Page 3
Building a Private GALAXY System
2.0 Building a Private GALAXY System
1. First find a System Manager's Guide and an empty directory.
2. Refer to chapter 9 of the System Manager's Guide and restore
the GALAXY files from the standard software tape (not the SWS
kit) as shown in section 9.1.
3. Delete the following MAC files:
QSRMAC.MAC
QSRT20.MAC
CSPQSR.MAC
QMANGR.MAC
4. Replace these MAC files with the files of the same name from
the SWS kit.
5. Run GALGEN and submit the GALAXY control file as shown in
sections 9.2 and 9.3 of the manual. Do not go through
section 9.4. The system's batch system should be left
running and unaltered.
3.0 Running the Private GALAXY System
When the batch job submitted in the last step above has
finished running, there will be a number of universal (UNV), REL and
EXE files in your directory. The EXE files are all private components
-- that is, if run in the proper order, they will set up a private
GALAXY system. The files that the batch job has left in this area
should not be put on SYS:. When you wish to set up a private GALAXY
system, you should always run the files from this directory. Do not
run the EXE files on SYS:. The standard released GALAXY system does
not know how to run as a private GALAXY system.
Starting and running a private GALAXY system is similar to
running GALAXY in the usual manner. First QUASAR is started, then
LPTSPL, BATCON, and/or SPRINT is started, and then QUENCH may be used
to queue requests. Since you will almost always be running more than
one program at once, it is most convenient to do everything under
PTYCON.
3.1 Starting QUASAR
You must always start QUASAR first. If you do not, LPTSPL or
whatever program you run will not set itself up as private, but will
communicate with the standard system QUASAR.
A Private GALAXY System for Debugging Page 4
Running the Private GALAXY System
First make sure that the system's QUASAR running under SYSJOB
is alive and well. You can do this easily by typing the command
@INFORMATION (ABOUT) OUTPUT-REQUESTS and making sure that you get the
usual kind of response -- either a listing of the print queue or a
statement that the queue is empty. This check is necessary because
the QUASAR.EXE in your area will set itself up as the system QUASAR if
there is not one running. Since there will usually be a QUASAR
running under SYSJOB, this will not happen often, but it is wise to
check first. If the INFORMATION command doesn't give you a reasonable
response, wait until it does before you try to set up a private
system.
Then run PTYCON and define a subjob with a mnemonic such as
QUA. Connect to it, log it in, and then ENABLE. You must have WHEEL
or OPERATOR priviledges for QUASAR to run successfully. Then simply
type the command @RUN QUASAR. You should immediately get the message
%Becoming private QUASAR
Then type ^X to get back to PTYCON command level. QUASAR will not
type any more messages unless it crashes (hopefully a rare occurence).
Therefore, you can pretty much ignore this subjob from now on, unless,
of course, it is QUASAR that you are debugging.
3.2 Starting QUENCH
It is almost always useful to have a subjob available for
examining your queues and printing or submitting jobs. Therefore,
define another subjob with a mnemonic (Q is a nice one), connect to
it, and log it in. It is then necessary to set up the job so that the
QUEUE, PRINT, and SUBMIT commands will always run the QUENCH.EXE in
your area. To do this, type the commands
@SET OLD-QUEUE-COMMANDS
@DEFINE SYS: DSK:,SYS:
Once you have done this, the queue manipulation commands mentioned
above will always reference your own private copy of the queues.
However, commands which are handled only by the EXEC, such as CANCEL,
MODIFY, or the INFORMATION commands which reference the queues, will
still refer to the regular system queues for all users. This is
because the EXEC has no knowledge of a private GALAXY system.
Therefore, it is important to remember that all queue-class commands
should be typed as you did under release two, when everything was
handled by QUENCH. Do not attempt to use the newer syntax created by
having these commands handled by the EXEC. You will either get an
error message from QUENCH, or you will confuse yourself by referencing
the system queues when you don't mean to.
To make sure that you have got everything set up correctly,
type the command
A Private GALAXY System for Debugging Page 5
Running the Private GALAXY System
@QUEUE
You should get the message
The queues are empty
If you then type a command such as
PRINT FOO.TXT
or
SUBMIT FOO.CTL
another QUEUE command should list these requests.
3.3 Starting Other Programs
To start up a private LPTSPL, BATCON, or SPRINT, define another
subjob with an appropriate mnemonic (L, B, or SPR), connect to it, and
log it in. Then ENABLE. You must be enabled with WHEEL or OPERATOR
priviledges to run any of these programs.
Once you have enabled, run the program you are interested in.
Be sure to use the RUN command so that you run the program from your
directory, not SYS:. If it is LPTSPL or BATCON you are running, you
should immediately get the message
%Connecting to private QUASAR
If you don't, you have either forgotten to start your own QUASAR, or
your own copy of QUASAR has crashed. In any case, if you don't get
this message from BATCON or LPTSPL, you should EXIT immediately from
these programs before typing any other commands, because the lack of
the message means that the program is not running as a private
component. If you are running SPRINT, it will not give a message of
this kind, whether or not it is running private.
Now that you have got the program you want running, you may use
any of the commands mentioned in the BATCH Operator's Guide for that
program. You may start SPRINT to read from the card reader, or start
LPTSPL on any available line printer, or start BATCON to begin
processing any batch jobs you have submitted using your QUENCH subjob.
If you are using SPRINT to submit jobs from the card reader, they will
be put into your private input queue. If you then run a private copy
of BATCON, BATCON will process those batch jobs. When those jobs are
finished, their log files will be queued and put into your private
output queue. If you then run a private copy of LPTSPL, it will print
those log files.
A Private GALAXY System for Debugging Page 6
Stopping a Private GALAXY System
4.0 Stopping a Private GALAXY System
When you are all done with your debugging session, simply type
^X to get back to PTYCON command level, and then type "KILL ALL" to
kill all the subjobs. Then EXIT to get to the EXEC.
If you wish to kill off the subjobs one at a time, you should
kill the QUASAR subjob last. You must have a QUASAR running at all
times, until you are through with everything.
5.0 A Collection of Random Hints
1. All your subjobs must be logged in under the same directory.
Therefore, any jobs you PRINT or SUBMIT will be submitted for
the same user. If you want jobs from more than one user in
your private queue, ENABLE your QUENCH subjob and use the
/USER switch. For more information on this switch, refer to
the article Release 2 Changes to QUENCH in volume 367 of the
Large Buffer. If you are running a private copy of SPRINT,
the jobs submitted will be for the users whose names are on
the $JOB cards.
2. The queues for the private GALAXY system are kept on a file
in your connected directory called
PRIMARY-MASTER-QUEUE-FILE.QUASAR. This file will be about 10
pages long -- longer if your private queues have a lot of
requests in them. If you want to bring up a private GALAXY
system and have the queues empty, just delete and expunge
this file before starting QUASAR. QUASAR will build a new
file for you. Be sure to delete the file in your directory!
There is a file of the same name on directory PS:<SPOOL>
which contains the system queues, and which should not be
deleted.
3. To run a program like BATCON as a private component after
installing a patch, simply replace the field-image source in
your directory, which you restored from the software tape
when first building a private system, with the edited source.
Then rebuild the private batch system as described in step
five of section 2.0, above.
4. There are several choices on how to start LPTSPL, as far as
the output is concerned. If your site has a spare
lineprinter, your private LPTSPL can be started with a
command like
LPTSPL>START PLPT1:=LPT1:
If you do not have a lineprinter available, you can put the
output on magtape for examination later. Do this with a
command of the form
A Private GALAXY System for Debugging Page 7
A Collection of Random Hints
LPTSPL>START MTA0:=LPT0:
If you are not really interested in what the output looks
like, but are more interested in debugging a particular
command, like the REQUEUE command, you can dump all the
output onto device NUL: like this:
LPTSPL>START NUL:=LPT0:
If you want to do this, make sure that you have gotten the
"connecting to private QUASAR" message. If started this way,
LPTSPL is essentially throwing away any requests it receives,
and you want to make sure that it is throwing away only
requests that you have queued for the purpose of debugging.
6.0 Restrictions
1. The queue-handling commands which have been put into the EXEC
always reference the system QUASAR, not your private one.
Therefore, you must always run QUENCH explicitly (@RUN
QUENCH) or do the setup shown above for insuring that queue
commands always go through your copy of QUENCH. No commands
handled by the EXEC will understand the existence of a
private QUASAR.
2. All programs must be run under the same directory. If QUASAR
is logged in under user LNEFF, LPTSPL must also be run under
user LNEFF or it will get its requests from the system
QUASAR, not the private one.
3. Spooled lineprinter files will always be sent to the system
QUASAR. For example,
@COPY LPT:=FOO.BAR
will create a request FOO in the regular print queue, never
in a private queue. This is because the queuing is handled
by the monitor, which, like the EXEC, does not recognize
private GALAXY systems.
Please note that the $language cards in SPRINT
generate listings that are spooled files, and therefore these
listings will appear in the system queues, not the private
ones. This is true even if the card deck was submitted
through a private copy of SPRINT.
4. Don't attempt to build a program as a private component,
using the modified sources on the SWS kit, and then put it on
SYS: to be used with standard software. While it is
believed that this will work, it has not been tested. After
debugging, always recompile the source and reload using the
A Private GALAXY System for Debugging Page 8
Restrictions
standard software from the distribution tape.
7.0 An Example of a Private GALAXY Session
Below you will find the PTYCON log file of a sample debugging
session, using a private GALAXY system.
************************************************************************
PTYCON LOG FILE 3-Jan-78 11:11:35
PTYCON> !FIRST DEFINE A SUBJOB FOR QUASAR
PTYCON> DEFINE (SUBJOB #) 0 (AS) QUA
PTYCON> CONNECT (TO SUBJOB) QUA
[CONNECTED TO SUBJOB QUA(0)]
TOPS-20 BIG SYSTEM, TOPS-20 MONITOR 3(1371)
@LOG LNEFF.3DEBUG
JOB 45 ON TTY226 3-JAN-78 11:12:19
@!FIRST LOOK AT ALL THE EXE FILES IN THIS DIRECTORY
@!THESE ARE ALL PRIVATE COMPONENTS
@DIR *.EXE
PS:<LNEFF.3DEBUG>
BATCON.EXE.1
LPTSPL.EXE.2
QUASAR.EXE.1
QUENCH.EXE.2
SPRINT.EXE.1
TOTAL OF 5 FILES
@!NOW ENABLE AND RUN QUASAR
@ENABLE
$RU QUASAR
%BECOMING PRIVATE QUASAR
^X
PTYCON> !NOW DEFINE A JOB FOR QUEUING THINGS
PTYCON> DEFINE (SUBJOB #) 1 (AS) Q
PTYCON> CONNECT (TO SUBJOB) Q
[CONNECTED TO SUBJOB Q(1)]
TOPS-20 BIG SYSTEM, TOPS-20 MONITOR 3(1371)
@LOG LNEFF.3DEBUG
JOB 46 ON TTY227 3-JAN-78 11:15:25
@!NOW TO DO SOME SETUP SO WE ALWAYS RUN OUR OWN
@!COPY OF QUENCH ON QUEUE-TYPE COMMANDS
@SET OLD-QUEUE-COMMANDS
@DEFINE (LOGICAL NAME) SYS: DSK:,SYS:
@!NOW TRY A COMMAND
@QUEUE
A Private GALAXY System for Debugging Page 9
An Example of a Private GALAXY Session
THE QUEUES ARE EMPTY
@!THOSE ARE OUR PRIVATE QUEUES IT'S TALKING ABOUT
@!TO PROVE IT, LOOK AT THE SYSTEM QUEUES.
@INFORMATION (ABOUT) OUTPUT-REQUESTS
QUEUE JOB SEQ LIMIT USER
----- --- --- ----- ----
LPT REL3AD 5719 256 MEIDELL BEING OUTPUT ON PLPT0:
CDP D60SPD 5759 2400 ORAN
@!SYSTEM QUEUES ARE NOT EMPTY, BUT OUR PRIVATE ONES ARE!
@!NOW QUEUE SOMETHING
@PRINT LOGIN.CMD
[LPT:LOGIN=/SEQ:5410/LIMIT:52, 1 FILE]
@!NOW LIST THE QUEUES, IT SHOULD BE THERE
@PRINT
OUTPUT QUEUES:
DEV JOB SEQ PRIO LIMIT USER
------ ------ ----- ---- ----- ---------------
LPT LOGIN 5410 10 52 LNEFF.3DEBUG
TOTAL: LPT: 1 JOB; 52 PAGES
@^X
PTYCON> !NOW DEFINE A SUBJOB FOR LPTSPL
PTYCON> DEFINE (SUBJOB #) 2 (AS) L
PTYCON> CONNECT (TO SUBJOB) L
[CONNECTED TO SUBJOB L(2)]
TOPS-20 BIG SYSTEM, TOPS-20 MONITOR 3(1371)
@LOG LNEFF.3DEBUG
JOB 43 ON TTY230 3-JAN-78 11:19:49
@!NOW ENABLE AND RUN LPTSPL
@ENABLE
$!MAKE SURE AT THIS POINT THAT YOU "RUN LPTSPL". DON'T
$!JUST SAY "LPTSPL" OR YOU WILL GET THE ONE FROM SYS:,
$!WHICH WON'T RECOGNIZE YOUR PRIVATE QUEUES
$RUN LPTSPL
%CONNECTING TO PRIVATE QUASAR
LPTSPL>MESSAGE ALL
LPTSPL>START NUL:=LPT0:
LPTSPL>[LPTLVF LOADING VFU 'NORMAL' IN NUL]
STARTING NUL:LOGIN/SEQ:5410/USER:LNEFF.3DEBUG PRINTED:0/52 PAGES
[LPTSTF STARTING FILE PS:<LNEFF.3DEBUG>LOGIN.CMD.1]
FINISHED NUL:LOGIN/SEQ:5410/USER:LNEFF.3DEBUG PRINTED:1/52 PAGES
EXIT
$!WE SEE THAT IT FOUND OUR REQUEST IN THE PRIVATE QUEUES
$!AND PRINTED IT. SINCE THIS WAS AN EXAMPLE, AND WE WEREN'T
$!INTERESTED IN SEEING THE OUTPUT, WE STARTED LPTSPL ON DEVICE
$!NUL:.
$!IF WE GET BACK TO OUR QUENCH JOB WE SHOULD SEE THAT THE
$!REQUEST WE PRINTED IS GONE AND THE QUEUES ARE NOW EMPTY AGAIN.
$^X
PTYCON> CONNECT (TO SUBJOB) Q
A Private GALAXY System for Debugging Page 10
An Example of a Private GALAXY Session
[CONNECTED TO SUBJOB Q(1)]
QUEUE
THE QUEUES ARE EMPTY
@^X
PTYCON> !FOR DEBUGGING, YOU CAN SET BREAKPOINTS IN LPTSPL,
PTYCON> !QUENCH, OR QUASAR AND THEN START UP THE PROGRAMS
PTYCON> !WHEN THE BREAKPOINTS ARE HIT, CONNECT TO THE
PTYCON> !SUBJOB AND DDT TO YOUR HEART'S CONTENT.
PTYCON> !
PTYCON> !FOR RUNNING BATCON AND SPRINT, THE PROCEDURE
PTYCON> !IS ESSENTIALLY THE SAME. START QUASAR FIRST
PTYCON> !AND THEN START BATCON AND/OR SPRINT.
PTYCON> !
PTYCON> !YOU CAN START UP THE QUENCH JOB ANY TIME YOU
PTYCON> !LIKE. THE ONLY IMPORTANT POINT IS THAT QUASAR
PTYCON> !MUST BE STARTED FIRST.
PTYCON>
PTYCON> !WE ARE ALL DONE NOW, SO JUST KILL EVERYTHING.
PTYCON> WHAT ALL
QUA(0) 45 LNEFF.3DEBUG QUASAR RN 0:0:1
Q(1) 46 LNEFF.3DEBUG EXEC TI 0:0:3
L(2) 43 LNEFF.3DEBUG EXEC TI 0:0:2
PTYCON> KILL ALL
PTYCON> EXIT
6.0 AUTOMATIC PATCH INSERTION
================================================
PATCHES FOR THE MONITOR AND MONITOR RELATED PROGRAMS THAT MUST BE
ASSEMBLED WITH MACRO 51 MAY BE DISTRIBUTED IN A BINARY FORMAT. THE
PATCHES WILL REQUIRE THE USE OF A PROGRAM CALLED NEWRUN THAT IS ON THE
SOFTWARE SUPPORT KIT TAPE. FOR EACH PATCH THERE WILL BE A FILE ON THE
SOFTWARE SUPPORT KIT TAPE OR ON A SPECIAL PATCH DISTRIBUTION TAPE. THE
FILE WILL HAVE A NAME FORMED OF THE MODULE NAME-TCO-TCO NUMBER.PATCH.
FOR EXAMPLE A PATCH FOR THE MONITOR MIGHT BE CALLED
MONITR-TCO-1045.PATCH. A .LOG FILE WILL ALSO BE DISTRIBUTED FOR EACH
PATCH SO THAT YOU CAN CONFIRM THAT THE PATCH WAS INSERTED CORRECTLY.
TO PUT A PATCH ON THE SYSTEM YOU MUST FIRST GET A COPY OF NEWRUN
AND THE .PATCH FILES. THEN ISSUE THE FOLLOWING COMMANDS:
RUN NEWRUN
INPUT FILE: MONITR-TCO-1100.PATCH,
OUTPUT TO FILE: MONITR-TCO-1100.LOG
WHEN THE PATCH HAS BEEN COMPLETED THE PROGRAM WILL TYPE:
FINISHED.
AT THIS POINT YOU SHOULD COMPARE YOUR .LOG FILE WITH THE ONE SUPPLIED
TO MAKE SURE THE PATCH WAS INSERTED PROPERLY. THE NEWRUN PROGRAM
LOGS A JOB IN ON A PTY: THAT ACTUALLY PREFORMS THE PATCH SO YOUR JOB
WILL LOOK AS IF IT IS DOING NOTHING WHILE THE PATCH IS BEING PERFORMED.
THE FILE PA1050.EXE CAN NOT BE PATCHED DIRECTLY. YOU MUST PATCH
THE PAT.EXE FILE AND MAKE A NEW VERION OF PA1050.EXE. A COPY OF
PAT.EXE IS ON <SUBSYS>. AFTER APPLYING THE PATCH TO THE PA1050 AN UPDATED
PAT.EXE WILL BE IN <SUBSYS>. YOU SHOULD KEEP THIS FILE, OTHERWISE THE NEXT TIME
YOU PATCH THE PA1050 YOU WILL LOSE ALL OF YOUR OLD PATCHES.
6.1 TOPS20 Monitor Building Procedures and Information
=======================================================
Third Printing, January
1978
COPYRIGHT (C) 1976, 1977, 1978 BY DIGITAL EQUIPMENT
CORPORATION, MAYNARD, MASS.
THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND
COPIED ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND
WITH THE INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS
SOFTWARE OR ANY OTHER COPIES THEREOF MAY NOT BE PROVIDED OR
OTHERWISE MADE AVAILABLE TO ANY OTHER PERSON. NO TITLE TO AND
OWNERSHIP OF THE SOFTWARE IS HEREBY TRANSFERRED.
THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT
NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL
EQUIPMENT CORPORATION.
DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF
ITS SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.
To: TOPS20 List A Page 2
Subj: TOPS20 Monitor Building Procedures and Info.
1.0 INTRODUCTION
This document provides complete information on configuring and
building the TOPS20 monitor. Multiple configurations are
provided so as to minimize the amount of resident storage used
while supporting all of the available peripheral devices. The
"build" procedure produces a core-image file of the monitor
from the various relocatable files and the one
parameter-dependent source file.
Generally, an installation will be able to run one of the
standard monitor configurations supplied. Section 2 of this
document tells how to select the appropriate monitor
configuration and how to run the build procedure.
Some installations may wish to use a set of configuration
parameters different from those of the standard set. Section 3
describes the function of each parameter and its effect on the
resultant configuration.
Section 4 describes how to add installation-specific terminal
definitions.
2.0 BASIC MONITOR SELECTION AND BUILDING PROCEDURES
Note: This section is intended for anyone who needs to build a
monitor, and it requires a minimum level of familiarity with
the structure or operation of the system. The knowledge which
is required is:
1. How to login and use basic EXEC commands.
2. How to use the magtape file restore program (DUMPER).
3. How to bring up the system with an existing monitor.
To: TOPS20 List A Page 3
BASIC MONITOR SELECTION AND BUILDING PROCEDURES
2.1 How to Select a Monitor Configuration
There are five standard monitor configurations. The first four
are intended for general timesharing and batch operation and
differ only in overall size. The fifth is intended for
batch-only operation. A sixth configuration is an ARPA-only
monitor. The configuration names and general descriptions are:
"Minimum" The smallest supported configuration for
general timesharing (non-ARPA).
"Small" A typical small configuration for general
timesharing.
"Medium" A typical medium-size configuration for general
timesharing.
"Batch" A configuration for batch-only operation on a
medium to large non-ARPA hardware
configuration.
"Big" The largest standard monitor supported by
Digital.
"Large" The largest monitor supported by Digital (ARPA
only).
1. If you intend to do batch-only operation and your
machine has at least 128K core, select the "Batch"
monitor. If you have less than 128K core, the "Batch"
monitor does not provide any advantage over the
appropriate general purpose monitor. The "Batch"
monitor supports 14 jobs, 12 pseudo-terminals (PTY's),
8 terminal lines, 256K core memory, 8 magtape units,
and 2 line printers.
2. If you are not using the "Batch" monitor, select one of
the general purpose monitors based on your hardware
configuration. You will want the smallest monitor
which supports all of the hardware you have and which
handles the number of users you wish to allow. All
monitors support up to 8 disk drives.
To: TOPS20 List A Page 4
BASIC MONITOR SELECTION AND BUILDING PROCEDURES
a. The "Minimum" monitor will support the following:
20 Users (interactive and batch)
64 Terminal Lines, 20 active
96K Core memory (max)
2 Magtape units (max)
1 Line Printer
2350 Pages of swapping space
no ARPANET interface
b. The "Small" monitor will support the following:
40 Users (interactive and batch)
64 Terminal Lines, 40 active
256K Core memory
8 Magtape units (max)
2 Line Printers (max)
2350 Pages of swapping space
20 Network Virtual Terminals (ARPA only)
c. The "Medium" Monitor will support the following:
60 Users (interactive and batch)
64 Terminal Lines, 60 active
256K Core memory
8 Magtape Units (max)
2 Line Printers (max)
3070 Pages of swapping space
30 Network Virtual Terminals (ARPA only)
d. The "Big" monitor will support the following:
100 Users (interactive and batch)
128 Terminal lines, 100 active
512K Core memory
8 Magtape units (max)
2 Line printers (max)
5000 Pages of swapping space
40 Network Virtual Terminals (ARPA only)
e. The "large" monitor will support the following:
100 Users (interactive and batch)
128 Terminal lines, 100 active
1024K Core memory
8 Magtape units (max)
2 Line printers (max)
5000 Pages of swapping space
40 Network Virtual Terminals
This monitor is only supported on ARPA
installations with the AN20 ARPANET Interface.
To: TOPS20 List A Page 5
BASIC MONITOR SELECTION AND BUILDING PROCEDURES
It does not matter if the monitor you select supports more of
some devices than you have. The resident core requirements of
each device are quite small, and monitors configured between
the ones above would not show significant performance
improvement.
2.2 How to Build a Standard Monitor Configuration
At this point, you will have selected one of the standard
monitor configurations described above (or have constructed
your own parameter file as described in Section 3). The
following step-by-step procedure produces a monitor configured
according to the parameters in the corresponding parameter
file.
( ) 1. Login and connect to a directory containing a
complete set of monitor files. If the monitor
files have not been loaded onto the disk, load them
from your distribution tape using DUMPER (document
TOPS20.DOC ).
( ) 2. If you are building a standard monitor, copy the
appropriate parameter file to "PARAM0.MAC". If you
are building an ARPA monitor, copy the appropriate
parameter file to "PARAN.MAC". The parameter files
for the various monitors are:
Standard Monitor ARPA Monitor
-------- ------- ---- -------
"Minimum" = PARMIN.MAC N/A
"Small" = PARSML.MAC "Small" = ANPSML.MAC
"Medium" = PARMED.MAC "Medium" = ANPMED.MAC
"Batch" = PARBCH.MAC N/A
"Big" = PARBIG.MAC "Big" = ANPBIG.MAC
N/A "Large" = ANPLGE.MAC
For example, if you are building a standard small
monitor,
@COPY PARSML.MAC (TO) PARAM0.MAC.1 !new file!
If you are building a medium ARPA monitor,
@COPY ANPMED.MAC (TO) PARAN.MAC.1 !new file!
( ) 3. If you are building a standard monitor, copy the
appropriate name file to "NAMAM0.MAC". If you are
building an ARPA monitor, copy the appropriate name
file to "NAMAN.MAC". The name files for the
various monitors are:
To: TOPS20 List A Page 6
BASIC MONITOR SELECTION AND BUILDING PROCEDURES
Standard Monitor ARPA Monitor
-------- ------- ---- -------
"Minimum" = NAMMIN.MAC N/A
"Small" = NAMSML.MAC "Small" = ANNSML.MAC
"Medium" = NAMMED.MAC "Medium" = ANNMED.MAC
"Batch" = NAMBCH.MAC N/A
"Big" = NAMBIG.MAC "Big" = ANNBIG.MAC
N/A "Large" = ANNLGE.MAC
For example, if you are building a standard small
monitor,
@COPY NAMSML.MAC (TO) NAMAM0.MAC.1 !new file!
If you are building a medium ARPA monitor,
@COPY ANNMED.MAC (TO) NAMAN.MAC.0 !new file!
( ) 4. Submit the appropriate batch file for the type of
monitor you are building: TOPS20.CTL for a
standard monitor, T20-AN.CTL for an ARPA monitor.
For example, to build a standard small monitor,
@SUBMIT TOPS20/TAG:SINGLE/TIME:2:0:0
To build a medium ARPA monitor,
@SUBMIT T20-AN/TAG:SINGLE/TIME:2:0:0
This will leave the monitor in your directory. The
file name of the monitor file is MONITR.EXE.
If it is desirable to build all of the standard
monitors, then submit the control file with a
/TAG:ALL switch, e.g.,
@SUBMIT TOPS20/TAG:ALL/TIME:2:0:0
( ) 5. If this monitor is to be loaded from magtape, copy
the file to magtape.
COPY MONITR.EXE (TO) MTA0:
The tape density must be 1600 BPI for MTBOOT to
work.
The build procedure is now complete and the new monitor is
ready to be brought up using the normal bootstrap procedures.
To: TOPS20 List A Page 7
THE MONITOR CONFIGURATION PARAMETERS
3.0 THE MONITOR CONFIGURATION PARAMETERS
Note: This section is intended for anyone needing to build a
monitor configuration different from the standard
configurations. It requires some familiarity with the
operation of the system and utility programs, and some
knowledge of the structure of the monitor. Specifically:
1. Everything required in Section 2.
2. How to use the text editor.
3. How to read assembly language.
4. The meaning of common monitor terms, e.g., "jobs",
"forks", "PTY", etc.
The monitor configuration is determined by a single parameter
file PARAM0.MAC (or PARAN.MAC if building an ARPANET monitor).
This file is the only configuration-dependent file required for
a monitor build. To configure a monitor, you will use the text
editor to produce this parameter file. PARAM0.MAC (or
PARAN.MAC) should contain only those parameters that are
different from the standard values listed in PARAMS.MAC. This
section describes the meaning of each parameter and its effect
on the monitor configuration.
You should read each description, determine the proper value
for your configuration, and note this value on a listing of the
parameter file. You can then edit the parameter file to
include these values.
Your edited parameter file should be given the name PARAM0.MAC,
(or PARAN.MAC if building an ARPA monitor).
When the new parameter file has been produced, you may follow
the normal monitor build procedure (Section 2).
The Parameter File
--- --------- ----
3.1 NJOBS
The number of jobs. This parameter determines the size
of the job tables and hence the maximum number of jobs
which can exist at any one time. This includes
interactive and batch jobs and the automatic jobs which
perform background functions (e.g., LPTSPL). There are
5 resident tables which are directly dependent on this
parameter; in addition, the number of forks (described
below) is usually determined by the number of jobs, and
To: TOPS20 List A Page 8
THE MONITOR CONFIGURATION PARAMETERS
the normal ratio is 3 forks/job. Hence (unless you
change the fork/job ratio), the number of resident
words required is:
N=NJOBS*(5+3*13) = NJOBS*44