Google
 

Trailing-Edge - PDP-10 Archives - BB-H311C-RM - swskit-documentation/handbook.mem
There are 5 other files named handbook.mem in the archive. Click here to see a list.





















                  TOPS-20 TROUBLE-SHOOTING HANDBOOK
                  =================================



                     Releases 4.1 and 5.0 Edition



                              April 1982














                     TOPS-20 Monitor Support Group
                        Marlboro Support Group
                          Software Services
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 2
INTRODUCTION






                             INTRODUCTION
                             ------------





     This document is the TOPS-20 Trouble-Shooting Handbook.  It is  a
collection  of materials designed to increase the effectiveness of the
Software Specialist in the field  in  coping  with  TOPS-20  problems.
Some  of the common "disasters" to befall TOPS-20 sites are discussed,
along with debugging  methods  in  general.   Though  the  information
contained  herein is probably not sufficient to make a Specialist into
a TOPS-20 "wizard", it  should  help  ease  the  communication  burden
between  the  Specialist  in the field and his counterpart in Marlboro
and lead to quicker resolution of problems.

     This document contains materials from many sources, and  presents
some information not available anywhere else.  Certain sections may be
a bit dated, but an effort has been made to remove at  least  some  of
the old/wrong stuff along with including new articles.

     There is a continuing need to update this document as part of the
SWSKIT  materials, and Specialists are encouraged to give the Marlboro
Support Group feedback on these materials.  This communication can  be
via the Hotline, or by writing to the following address:

                TOPS-20 Monitor Support Group
                Digital Equipment Corporation
                200 Forest Street, MR1-2/S43
                Marlboro, Massachusetts  01752
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 3
TABLE OF CONTENTS


                          TABLE OF CONTENTS
                          -----------------




     1.  INTRODUCTION                                             2

     2.  TABLE OF CONTENTS                                        3

     3.  POLICY STATEMENT                                         5

     4.  PRODUCING A GOOD SPR                                     6

     5.  USING SIRUS                                              9

     6.  DDT PATCHING THE TOPS-20 MONITOR                        16

     7.  MAPPING DIRECTORIES IN MDDT                             20

     8.  RECOVERING FROM DIRECTORY ERRORS                        22

     9.  MORE ABOUT DIRECTORY PROBLEMS                           25

    10.  JSB AND PSB MAPPING                                     27

    11.  BREAKPOINTING MULTI-USER CODE                           31

    12.  USING ADDRESS BREAK TO DEBUG THE MONITOR                33

    13.  RECOVERING FROM SYSTEM DISASTERS                        36

    14.  LOOKING AT HUNG TAPES                                   42

    15.  A LOOK AT SOME OF THE DISK STUFF                        46

    16.  NEW DISK FEATURES FOR FILDDT                            50

    17.  TOPS-20 SCHEDULER TEST ROUTINES                         53

    18.  TOPS-20 PAGE ZERO LOCATIONS                             60

    19.  KNOWN HARDWARE DEFICIENCIES LIST                        64

    20.  KS10 CONSOLE INFORMATION                                67

    21.  BOOT COMMAND STRING FUNCTIONALITY                       76

    22.  CRASH ANALYSIS                                          78

    23.  MORE CRASH ANALYSIS                                     97
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 4
TABLE OF CONTENTS


    24.  BUG'TYP MACRO CHANGES FOR VERSION 4 OF TOPS-20         114

    25.  MONITOR BUILDING HINTS                                 116

    26.  EXEC DEBUGGING                                         119

    27.  RECOVERING FROM A BAD EXEC                             125

    28.  DEBUGGING THE GALAXY SYSTEM                            126

    29.  DEBUGGING MOUNTR                                       142

    30.  DEBUGGING PA1050                                       145

    31.  COPYING FLOPPY DISKS                                   146

    32.  THE SWSKIT TOOLS PROGRAMS                              148
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 5
POLICY STATEMENT


              LEGAL POLICY CONCERNING THE TOPS-20 SWSKIT
              ------------------------------------------




     There is a great confusion concerning the materials that make  up
the SWSKIT tape, and their legal standing.  This memo is an attempt to
clear up some of those problems.

     The SWSKITs are made up of an assortment of materials intended to
increase   the   effectiveness  of  the  software  specialist.   These
materials include program sources not normally distributed or sold for
a premium;  internal and company confidential documentation, which may
be in part incomplete or actually  incorrect,  but  supplied  for  the
information value on subsystems which may be insufficiently documented
through the usual channels;  documentation for  specialists  specially
produced  by  the  corporate  support  people;   and  utility programs
produced and maintained to  some  extent  by  corporate  support.   In
addition,  the  SWSKIT  may contain special or pre-release versions of
supported software provided for the incremental value a specialist may
obtain  from  the  software  under controlled circumstances.  In time,
utilities from the SWSKIT may evolve into supported products.

     All of the SWSKIT materials are proprietary to DIGITAL, and  were
never  intended  to  be  just  given  to the customer.  Obviously, the
materials which are otherwise sold cannot  be  given  away;   and  the
company  confidential  materials  should not be.  While it is expected
that the tools programs may wind up  being  used  at  customer  sites,
neither  are  they  gifts  to the customer.  An effort must be made to
protect  DIGITAL's  rights  to  these  proprietary   materials.    For
instance,  a PL90 contract retains rights to all materials provided to
the customer.  Deleting a tool program after use at  a  customer  site
indicates  intent.   There  should  be an awareness that if a customer
incurs damages due to  use  of  some  program  given  to  him  by  the
specialist,  even  though improperly used, then DIGITAL may be seen to
be at least in part responsible.  This should be avoided.

     In summary, the  SWSKIT  is  a  tool  provided  to  increase  the
effectiveness  of  the  specialist, especially with regard to PL90 and
debugging activity, but  the  rights  to  all  materials  remain  with
DIGITAL and the specialist should act accordingly.

     THIS IS NOT A LEGAL DEPARTMENT DOCUMENT.  CONSULT  LEGAL  IF  YOU
HAVE ANY DEFINITE PROBLEMS REQUIRING RESOLUTION.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                 Page 6
PRODUCING A GOOD SPR


                          PRODUCING A GOOD SPR
                          --------------------




           A software specialist is  often  asked  to  assist  with  the
      submission  of  SPRs for a customer.  It is always discouraging to
      have  problems  getting  an  answer  to  an   SPR   for   entirely
      non-technical  reasons.  For that reason, below are some hints for
      producing a "good" SPR which will  help  in  getting  the  problem
      solved more quickly.



      1.0  THE SPR FORM

      Much of the data on the SPR  form  is  unimportant,  until  it  is
      omitted.   The  line  of  product data is one.  Try to isolate the
      problem to the correct component, since that  will  determine  who
      first  receives  the SPR.  This will remove the time it takes for,
      say the COBOL maintainer, to determine that  the  problem  is  not
      really  in  COBOL,  but  in PA1050 or the monitor, and the time it
      takes for the next maintainer to become familiar with the problem.
      Something  which  crashes  the system is ALWAYS a monitor problem,
      even if it is an EXEC command which causes the problem, or a short
      BASIC program.

           If you really have a problem, be sure to mark  the  "problem"
      box,  and  don't  use  words  like  "we  suggest  you  correct the
      following situation...".  If the people who  handle  the  incoming
      paperwork  think  they  have  a  suggestion,  it  may  get  routed
      elsewhere, and never seen by the appropriate maintainers.   A  few
      problems have been greatly delayed this way.

           The priority boxes are not super-critical, but if you have  a
      problem  which  is  holding  up production, or crashing the system
      several times a day, try to make a note of that somewhere  in  the
      description  of  the problem and mark the high-priority box.  That
      should let the maintainer know that  a  work-around  may  also  be
      appropriate in the short term.  Customer-marked high priority SPRs
      are generally our first priority for answering.

           The phone number of the submitter could be important  if  the
      problem  is  of  such a nature that it proves not-reproducible, or
      the  complexity  is  such  that  futher  clarification   just   to
      understand  the  problem  might  be needed.  Your number here as a
      software specialist provides a more informal contact  than  direct
      maintainer-to-customer  confrontation,  although the customer will
      be contacted directly if that is most expedient.

           The attachments--be sure to mark some of these boxes  if  you
      send  along  supporting  materials.  Since these can get separated
      from the form, this will help keep them from  getting  permanently
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                 Page 7
THE SPR FORM


      lost.

           The "DO NOT PUBLISH" box is for security problems and ways to
      crash   the   system.    We   double-check  this  during  incoming
      processing, but if the box is checked you can be sure that the SPR
      will not be published unanswered.

           Describe the problem as clearly  as  possible  in  the  space
      provided.   Try  to  provide enough detail to easily reproduce the
      problem.  Concentrate on the description of the problem,  and  any
      diagnosis  you  may  have made.  Attempting to declare a "cure" is
      not always good idea because the actual correction may  be  of  an
      entirely  different  nature  for a number of reasons.  However, if
      you have something that works, the information could  be  of  use.
      Just  don't  count  on that exact change being the actual fix.  If
      the problem  is  not  reproducible  from  the  description  given,
      chances  are  that  something  you  left  out  is  relevant to the
      problem.  Unless the problem directly concerns them,  things  like
      logical  names,  mounted  structures,  and  other  features  often
      obscure the problem.  For the purpose of the problem  description,
      a terminal listing of an occurrance is often highly desirable, and
      it is sometimes a  good  idea  to  create  a  brand-new  directory
      without  any  fancy  LOGIN.CMD  setups or user groups and so on to
      demonstrate the problem.



      2.0  THE SUPPORTING MATERIALS

           As above, the listing from a terminal session is often a very
      good  attachment.   Try  to  include all the relevant information.
      Again, sometimes things like logical  names,  file  and  directory
      protections,  user  groups,  and  other  job-state  variables  are
      important and should be  included.   Inclusion  of  data  such  as
      program  version  numbers  and  edit  levels  can be essential for
      products with large numbers of edits.  If you are  complaining  of
      monitor problems, which patches you have installed could be useful
      information.  Terminal sessions should be as  clear  as  possible.
      It  should be made obvious just what is going on or the maintainer
      may just see a series of commands and think "So?".  Concurrent  or
      after the fact commenting is one way to accomplish this.

           Many times there  is  a  program  which  exercises  the  bug.
      Sometimes  these  programs are alright as they are, but often they
      are giant COBOL monsters working on a multi-RP06  data  base,  and
      very  unwieldy  for  a  maintainer  to  try  to work with.  If the
      program can be reduced to a small subset,  do  so.   Many  monitor
      problems often turn out to be reproducible from a set of arguments
      to a single JSYS.  If it is a question of  incorrect  output  from
      some  program, it is helpful to send along all the files needed to
      reproduce the problem, and the files of incorrect output.  In  the
      case  of  programs with multiple edits to field-image, this speeds
      up the maintainer, since he does not have to manually apply  those
      edits  to attempt to recreate your versions, and he can also check
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                 Page 8
THE SUPPORTING MATERIALS


      the installation of the edits, if that  is  appropriate.   And  in
      case  the  problem  proves  to  be not easily reproducible the bad
      output can at least be examined for clues.

           In the case of a monitor crash, the  problem  may  have  been
      reduced  to  a  program  of less than one page.  It is tempting to
      type this on the front of the SPR and send it in that way.   While
      the  maintainer can type in the program easily enough (if the copy
      is  both  legible  and  correct),  the  submitter  has  been  lax.
      Sometimes,  that short program will not cause a crash, even though
      run thousands of times under varying conditions by the maintainer.
      And  even  when  it  does  cause  the  crash  the  first time, the
      submitter has lengthened the turn-around by not sending  the  dump
      from  the  crash along with the SPR.  Sending the dump solves both
      problems.  If the problem is not reproducible with ease, the  dump
      is  vital  to further understanding.  And having the dump to start
      with speeds up the work of the maintainer who now does not need to
      schedule  stand alone to try to exercise the bug and cause a crash
      so he has a dump to look at.

           When sending a dump, always send the unrun monitor along with
      it.   If  you  don't, you are just causing a delay in handling the
      problem while the maintainer tries it against the  standard  ones,
      which  involves  finding tapes with the standard ones, and loading
      them...  If you are running an unpatched standard monitor, and you
      refuse  to send it, at least tell which one it is somewhere on the
      form.  The unrun monitor is also useful for checking the existence
      and correct installation of patches when that becomes an issue.

           The current preferred tape format is 9-track, 1600bpi, and in
      standard  DUMPER  format,  not  in  INTERCHANGE format, since file
      information can be lost that way.  Take the time to get a  listing
      of  a directory of the tape and include it with the tape.  It will
      help to speed things up, as if it is obvious  from  the  directory
      that something is missing, faster feedback is generated.  There is
      also the indication that the tape will  indeed  be  readable  when
      received,  and  will  partly eliminate the usual first step of the
      maintainer in getting a directory of the tape.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                 Page 9
USING SIRUS


                              USING SIRUS
                              -----------

     Did you know that you can dial into a Marlboro development system
and type out almost any patch that the Marlboro Support Group has made
to -10 or -20 software in the last three to four years?   The  program
which does this is called SIRUS, and with it you can:

     1.  Search through all the patches to a  particular  product,  if
         you know a problem exists but don't know what the patch is or
         don't know if we've heard of the problem.  If  you  find  the
         patch you want, you can then type it out.

     2.  Type out a particular patch to a particular product,  if  you
         know what the edit number is.

     3.  Obtain the status of any SPR, including the entire answer  if
         it has been answered.


     By using SIRUS, you can get patches whenever the  system  is  up,
even  if  it's  two  A.  M.  and the Hotline is closed.  You can print
patches in your local office without having to wait for  a  specialist
in  Marlboro  to  mail you a copy.  You can be sure that the patch you
have is correct.  (Dictating patches over the Hotline is very prone to
errors.)  Even  if the problem you are experiencing cannot be found in
SIRUS, you can help us when you call by so  stating.   We  immediately
know that the problem you are having is a new one.

     There have been several articles about SIRUS  in  previous  Large
Buffers, but none have been oriented towards specialists in the field.
This one is!

     To use SIRUS, dial into system 1026 in Marlboro, log in, and then
run it.  In more detail:

     1.  Dial into system 1026.  Any of  the  following  numbers  will
         reach system 1026 in Marlboro.  They are all 300 baud lines.
         
                            231-1171  (DTN)
                            231-1172  (DTN)
                       (617)481-5606
                       (617)481-5632
                       (617)481-5635
                       (617)481-5636
                       (617)481-5637
                       (617)481-5638
         
         Once the machine notices you, type "SET HOST  26"  to  insure
         that  you  are  connected  to  system  1026.   If you get the
         message "?Undefined Network Node", the machine is  down  (try
         again later).
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 10
USING SIRUS


     2.  To login, type "LOGIN 10,#".  When  the  machine  requests  a
         name, type one in.  You will not need a password.

     3.  To run SIRUS, just  type  "R  SIRUS".   SIRUS  takes  several
         seconds  to  initialize  itself  and  then  prompts  you with
         "PRODUCT [H]*".  At this point,  type  either  "10<CRLF>"  or
         "20<CRLF>"  depending  on  whether the customer of concern is
         running TOPS10  or  TOPS20.   SIRUS  then  prompts  you  with
         "[H] *".  You are now at SIRUS command level.


     SIRUS has many commands, but only a few are of  interest  to  the
field specialist.  They are:

     1.  H -- for Help.  This may be typed anytime SIRUS precedes  its
         prompt with "[H]".

     2.  EX -- for Exit.  Use this to exit SIRUS.  Then  type  K/N  to
         logout, and hang up.

     3.  PP -- for Peruse PCOs.  PCO stands for Product  Change  Order
         and  essentially means a patch.  This command is used to look
         through patches for a particular product if you  aren't  sure
         which patch you want.

     4.  GP -- for Get PCO.  This is used to  type  out  a  particular
         patch once you know which one you want.

     5.  GS -- for Get SPR.  Use this to  retrieve  information  on  a
         particular SPR.

     6.  NP -- for New Product.  Use this  command  if  you  type  the
         wrong  answer to "PRODUCT [H]*" as mentioned above, or use it
         in association with the PP command as described below.  SIRUS
         will prompt you for a product again.


     The three most useful of these commands are PP, GP, and GS.



3.0  PP Command

     Use this command to peruse the patches for a  particular  product
--  e.g.   LINK  or  603  (monitor) or BATCON -- if you want to find a
particular patch you know exists, or  if  you  want  to  know  if  the
support group has heard of and fixed some problem you are experiencing
with a product.  After you type "PP<CRLF>" SIRUS  will  prompt  for  a
component.  Here type the program you're interested in -- LINK, BATCON
or whatever.  A response of LIST will type the  programs  SIRUS  knows
about and then prompt you for a component again.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 11
PP Command


     Once you type in the component, SIRUS prompts with  "[H] PCO #:".
There  are two reasonable responses to this.  The first is ALL.  (Type
NO to the subsequent question about a file.)  This  will  give  you  a
short  summary of all the patches available for this product, one line
per patch.  This includes a PCO number, the SPR for which  this  patch
was  written,  the  edit  number  corresponding  to the patch (for the
TOPS10 monitor this is the MCO number), a keyword describing the  bug,
the  maintainer  who  wrote  the patch, and the date it was made.  The
other response you might type here is simply  <CRLF>.   In  this  case
SIRUS will type out the symptom of the newest PCO, and then prompt you
with "NEXT?".  By continuing to type carriage returns,  you  can  type
all  the symptoms of all the patches for this product, from the newest
to the oldest.  When you have found the patch you want  (remember  the
PCO number), type RETURN to get back to SIRUS command level.

     If you did not find your symptom while perusing, and your product
exists  on both TOPS10 and TOPS20, you should also search the PCOs for
the alternate operating system.  To do this, type NP to SIRUS  command
level,  and  then type in the other product number when SIRUS asks for
it.  Then peruse PCOs for your product as you did before.



4.0  GP Command

     This is used to print out a patch once you know the  PCO  number.
The  PCO  number  is printed while you are perusing PCOs and is of the
form 10-product-nnn or  20-product-nnn.   After  typing  GP  to  SIRUS
command  level,  SIRUS prompts for a PCO number.  The leading "10-" or
"20-" is supplied by SIRUS, so your response should  be  of  the  form
"product-nnn".

     In response, SIRUS types out information about  the  patch.   The
two most useful data are labeled VLD and SAE.  VLD stands for validity
and is the version of the software to which the patch applies.  SAE is
Source  After Edit and is the edit or MCO number of the patch.  To get
the actual text of the patch, respond YES to  SIRUS's  question  "Show
Write-up File?".



5.0  GS Command

     This is used to get the status of an SPR.  SIRUS will prompt  for
an  SPR  number, and then will provide you with info about the SPR you
specified.  This  includes  the  site  that  submitted  the  SPR,  the
specialist  responsible  for  the  SPR, and date received and the date
closed, if the SPR has been answered.  If answered, it will  also  say
whether or not an auxiliary file was written for the SPR and what PCOs
(if any) were included.  The aux file  is  an  introductory  paragraph
which  is written for most SPR answers.  For SPRs which do not require
patches, the aux file constitutes the entire answer.  The aux file can
be typed by responding YES to "SHOW AUXILIARY FILE?".  The PCOs can be
typed out with the GP command.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 12
GS Command


     Finally, if SIRUS begins to give you error messages such as "File
not  found",  EX  from  SIRUS  and  mount a special disk pack with the
monitor command "MOUNT SIRS:".  Then try again.  This gives you access
to more PCOs and aux files than are normally available.

     For more information, see the example  run  of  SIRUS  below,  in
which  user  input  is  shown  underlined,  or  the  article  on SIRUS
published in volume 409 of the Large Buffer.  Finally,  SIRUS  is  for
use  by  DIGITAL personnel only.  DO NOT give out instructions for its
use or the system 1026 phone numbers to customers.

.R SIRUS
 - -----


SIRUS...3(3)
 
[WHEN '[H]' APPEARS YOU MAY TYPE 'HELP' FOR ASSISTANCE]
 
 
PRODUCT [H]* 20
             --
[H] *PP
     --
 
[H] COMPONENT TO PERUSE: D60SPL
                         ------
[PCO LIMIT FOR 'D60SPL' IS 15]
[H] PCO #:<CR>
          ----
[20-D60SPL-015]
 
DATE: 09-JUL-79 BY: BENCE
VLD: 
 
[SYMPTOM]




Jobs sent to the LPT queue from D60SPL are  given  a  random
file name and are billed to OPERATOR.


 
NEXT?<CR> 
     ----
[20-D60SPL-014]
 
DATE: 09-JUL-79 BY: WEISBACH
VLD: 
 
[SYMPTOM]
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 13
GS Command





If the spooler is pausing, typing a  GO  can  result  in  an
illegal instruction.


 
NEXT? ALL
      ---
DO YOU WANT A FILE? NO
                    --
PCO 015 SPR 12355             (6,022) KEY= LNAME      BENCE      09-JUL-79
PCO 014 SPR 12225  OUTOUT     (6,020) KEY= PAUSE      WEISBACH   09-JUL-79
PCO 013 SPR 11660  LODVFU 6013(6,014) KEY= VFU        WEISBACH   09-JUL-79
PCO 012 SPR 13244  D60CRE 103 (6,032) KEY= CARD       L.NEFF     06-JUL-79
PCO 011 SPR        D60CR4 103 (6,015) KEY= CARDS      L.NEFF     03-JUL-79
PCO 010 SPR        REQUEU 103 (6,030) KEY= CTQMFQ     L.NEFF     14-JUN-79
PCO 009 SPR 12588  INTCTC 1   (6,026) KEY= CONTROL C  TEEGARDEN  17-MAY-79
PCO 008 SPR 12881  OUTE.6 103 (6,025) KEY= REQUEUE    NEFF       17-APR-79
PCO 007 SPR 12139         103 (6,019) KEY= ILLEGAL    WEISBACH   27-OCT-78
PCO 006 SPR 12005             (0) KEY= SIMULTANEO BENCE      22-SEP-78
PCO 005 SPR 11672  ENDJOB 103 (6,018) KEY= QUASAR     BENCE      18-SEP-78
PCO 004 SPR 11841  D60STK 103 (6,016) KEY= BAD        WEISBACH   23-AUG-78
PCO 003 SPR 11476  TTYOUT 103 (6,010) KEY= OVERWRITE  WEISBACH   12-MAY-78
PCO 002 SPR 11431  OUTE.6     (6,007) KEY= INTERRUPTS WEISBACH   12-APR-78
PCO 001 SPR 11456  D60SPL     (6,006) KEY= BLANK      WEISBACH   03-APR-78
[H] PCO #: RETURN
           ------
 
 
[H] *GP
     --
 
 
[H] PCO #: 20-D60SPL-8
[20-D60SPL-008 RETRIEVED]
 
PROG:   NEFF
COMPONENT: D60SPL
SER/SPR:20-12881
KEYS: REQUEUE    /  
ROUTNS: OUTE.6 /  
VLD:    103(2304)
SBE     %103 (6,024)
SAE     %103 (6,025)
CRIT:   N
DOC:    N 
F/D:    F
TEST FILE:     :          [        ]
P-IND:  10
 
SHOW WRITE-UP FILE? YES
                    ---
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 14
GS Command


 
 
[WRITE-UP FILE]
008             NEFF
[SYMPTOM]




     If a job is requeued because of a  communications  failure,  with
D60SPL  reporting  that  the  station  has  signed off, then, when the
station signs on again, the print file  will  be  restarted  from  its
beginning, not from the last checkpoint.


[DIAGNOSIS]

     When the  error  is  detected,  routine  OUTE.6  calls  IBACK  to
backspace  the  file  five  pages.   IBACK  zeroes  the  page counter,
J$RNPP(J), and rewinds the  file,  in  the  belief  that  the  forward
spacing  code  will  update  the page count as it skips to the correct
page.  However, D60SPL discovers the error is not recoverable  and  it
requeues  the job immediately.  Since the page count is never updated,
DOREQ requeues the job to start at the beginning of the file.


[CURE]

     Preserve the page at which to resume printing over  the  call  to
IBACK.  if the job is to be requeued immediately, restore J$RNPP(J) so
that the job will be requeued and checkpointed five  pages  back  from
its current position.
[FILCOM]
File 1) DSK:D60SPL.MAC[4,1022]  created: 1724 09-Apr-1979
File 2) DSK:D60SPL.MAC[4,417]   created: 1625 10-Apr-1979

1)1             LPTEDT==6024                    ;EDIT LEVEL
1)              LPTWHO==1                       ;WHO LAST PATCHED
****
2)1             LPTEDT==6025                    ;EDIT LEVEL
2)              LPTWHO==1                       ;WHO LAST PATCHED
**************
1)4     ;*****End of Revision History*****
****
2)4     ;6025   If a job printing on a remote printer is interruped by
2)      ;       a communications failure, requeue to start five pages ba
        ck
2)      ;       instead of at beginning of file.  LLN, SPR # 20-12881,
2)      ;       10-APR-79
2)      ;*****End of Revision History*****
**************
1)179           PUSHJ   P,IBACK                 ;BACKSPACE THE FILE
1)              PUSHJ   P,INTON                 ;[6007]TURN INTERRUPTS B
        ACK ON
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 15
GS Command


1)              PUSHJ   P,D60NRY                ;PERFORM "NOT READY" DIA
        LOG
1)               JRST   OUTE.7                  ;ERROR IS UNRECOVERABLE
1)              TELL    OPR,[ASCIZ /![LPT...  continueing!]
****
2)179   ;**;[6025] ADD SEVERAL LINES AT OUTE.6 + 13L.  LLN, 10-APR-79
2)              MOVE    T1,J$RNPP(J)            ;[6025] CALCULATE THE NE
        W
2)              SUB     T1,N                    ;[6025]  DESTINATION PAG
        E
2)              PUSH    P,T1                    ;[6025]  AND SAVE IT
2)              PUSHJ   P,IBACK                 ;BACKSPACE THE FILE
2)              PUSHJ   P,INTON                 ;[6007]TURN INTERRUPTS B
        ACK ON
2)              PUSHJ   P,D60NRY                ;PERFORM "NOT READY" DIA
        LOG
2)               JRST   [POP    P,J$RNPP(J)     ;[6025] RESTORE PAGE NO.
         FOR REQUEUE
2)                       JRST   OUTE.7]         ;[6025] ERROR IS UNRECOV
        ERABLE
2)              POP     P,(P)                   ;[6025] THROW AWAY DESTI
        NATION
2)                                              ;[6025] PAGE - FORWARD S
        PACING
2)                                              ;[6025] CODE WILL HANDLE
         IT
2)              TELL    OPR,[ASCIZ /![LPT...  continueing!]
**************
[END OF WRITE-UP FILE]
 
 
[H] *EX
     --

EXIT

.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 16
DDT PATCHING THE TOPS-20 MONITOR





                    DDT PATCHING THE TOPS-20 MONITOR
                    --------------------------------




     This article discusses how DDT patches are made to TOPS-20.

     From time to time the Marlboro Support Group has  to  describe  and
explain  the DDT patching of TOPS-20 to Specialists from the field.  The
following is an explanation, if not a justification,  of  the  way  some
things are done.

     A DDT patch to TOPS-20 as published is, in essence, a terminal  log
of a session applying the patch by hand.  This differs from the sometime
practice of a control file containing only the typein to DDT.   The  raw
typein  has  a few disadvantages with respect to the log:  It is hard to
display in a publication format like  the  Software  Dispatch  the  bare
control  characters like linefeeds and tabs that might be used, and even
harder to edit around them with the  only  currently  supported  editor,
EDIT.   In addition, the full typescript allows some confidence building
(or cause for concern) if the DDT typeout from application of the  patch
is  (is  not)  the  same  as  the typescript.  The published patch IS an
actual typescript, and is  "proof"  that  the  patch  CAN  be  correctly
installed.

     In applying  the  patch,  the  basic  methodology,  lacking  innate
knowledge,  is  to  just  start  typing from the typescript whenever the
computer goes into input wait.  Any "$" appearing in a DDT session which
is  not  the prompt from the enabled EXEC should be the result of typing
an ESCAPE.  (ESCAPE is sometimes referred to  as  ALTMODE  or  ALT.)  In
order  to  avoid confusion, we try never to use any dollar sign symbols,
and hopefully should make special note of any that might occur.

     Starting at the top of a session, there are usually a few  comments
about  the  patch.   If  we  are currently patching multiple releases of
TOPS-20, the specific release for the patch should be noted here.   Also
noted  should  be any hardware or monitor dependencies:  KS- or KL-only,
or 2040, 2060, or ARPA only, etc.

     The first monitor command is an ENABLE, followed by a  GET  of  the
monitor  file  to be patched.  Unless we are patching an existing patch,
our published patches always show us patching a "virgin"  monitor  file,
one  without  any previous patches installed.  You should always be able
to duplicate the patch typescript yourself on an unpatched monitor.

     At this point we do a START 140 command to get into DDT.  There  is
a  fine distinction at this step between typing START 140 and typing DDT
to get into DDT.  START 140 starts up EDDT (Exec-mode  DDT)  running  in
user  mode,  which is the required action.  Typing DDT to the EXEC would
merge  SYS:UDDT.EXE  with  the  monitor  EXE  file  and  start  up  UDDT
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 17
DDT PATCHING THE TOPS-20 MONITOR


(User-mode  DDT), which is not what we want.  In fact, with Release 4 of
TOPS-20 the EXEC is clever enough to start up EDDT for  us  on  the  DDT
command  also,  but  even  so, for the sake of consistency, and to avoid
confusion, published patches should still use START 140.

     After entering DDT, it is common to select the local  symbol  table
for  the  module  to  be  patched  in  case  there might be local symbol
conflicts, etc.  This is done using the  MODULE-NAME$:   (ESCAPE  colon)
construct.

     Next follows the body of the patch.  We purposely avoid the fancier
DDT  commands when applying patches in order to avoid confusion.  We try
to limit ourselves to a few DDT commands:

        ADDRESS/ (slash)to open the location at ADDRESS
        ADDRESS[ (open-square-bracket)
                        similar to / but typeout numeric not symbolic
        RETURN          to close the current location, storing any new
                        value specified
        LINE-FEED       to close the current location, storing any new
                        value specified, and open the next location
        TAB             a convenience command used to close the current
                        location and open the location specified by the
                        last reference; commonly used to get to and
                        open location FFF immediately after inserting a
                        JRST FFF instruction in the code
        SYMBOL: (colon) to define a symbol at the current location;
                        usually to redefine FFF: further down in the
                        patch space
        FFF$< (ESCAPE open-angle-bracket) or
        FFF$$< (ESCAPE ESCAPE open-angle-bracket)
                        to start a patch in the patch area named FFF
        $> (ESCAPE close-angle-bracket)
                        to terminate a patch, which installs the jumps
                        back to the inline code, redefines the FFF
                        symbol value past the used patch space, and then
                        inserts the initial jump to the patch into the
                        inline code

Those who apply patches are of course free to use the more sophisticated
DDT commands to achieve the same effect.

     A few TOPS-20 peculiarities  should  be  explained  here.   TOPS-20
patches  are  applied  using  the FFF patch area.  The default DDT patch
area symbol, PAT.., (used if no argument  is  given  to  an  $<  or  $$<
command) should NOT be used.  You are apt to wind up with system crashes
since the PAT..  area is not locked down.  FFF is defined in the  module
STG.MAC  (which  goes to the customers), and the area is 100 octal words
long.  FFF is part of the resident monitor code PSECT, and is always  in
memory.   Special  care  must  be  taken  when installing patches not to
overrun the patch area, which could also result in system crashes.   The
first symbol past the FFF area is DTSCNW.  If that symbol shows up while
attempting to install a patch, you may be in trouble.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 18
DDT PATCHING THE TOPS-20 MONITOR




                                  NOTE

               For Release 5 of TOPS-20, the  patch  area
               has  been  moved and is no longer found in
               STG, but in POSTLD,  at  the  end  of  the
               RSDAT  PSECT,  and  so requires changes to
               the LINK CCL  file  to  expand  the  area.
               Care  should  be  taken  so  that the next
               PSECT is not overlapped with patches.  The
               space   reserved   is   now   400  (octal)
               locations.



     There is another patch space defined in TOPS-20,  called  SWPF,  in
the  swappable  portion of the monitor.  We always use FFF in preference
to SWPF since first, SWPF can only be  used  for  patches  to  swappable
code,  but  FFF will work for either.  Second, two patch areas in common
use might be confusing to the customers, specialists, and us.  Third, if
we  get  a  dump to examine from a customer, we can always check the FFF
area for possible (bad) patch installation.  SWPF might be swapped  out,
and not in the dump.

     Unconventionally enough, the symbols FFF, FFF1, and  FFF2  are  all
defined together in STG.MAC with the same value.  When DDT decides which
to type out when printing the symbolic form of an address, it finds FFF2
first,  which accounts for the common appearance of FFF2 in patches.  In
addition, just the symbol FFF is  redefined  on  patch  installation  to
always  point  to the first free word of the remaining patch area.  FFF1
and FFF2 are  never  redefined,  and  so  should  always  point  to  the
beginning of the initial patch area built into the monitor.  FFF2 should
never have been explicitly referenced as typeIN to DDT;   any  occurance
in  a  patch should be known to be from DDT typeOUT, probably from a DDT
LINE-FEED command.  This  is  a  common  source  of  error  in  applying
patches;   writing  over  earlier patch area by typing in the FFF2-based
symbols.

     Normally,  in  a  DDT  patch,  lines  which  follow   one   another
immediately in the published patch are the result of typing LINE-FEED at
the end of the line, and not RETURN and the next address  symbol.   When
the  $<  and  $$<  commands  are  used, all lines from that point to the
terminating $> command should have  been  ended  with  LINE-FEED,  using
successive locations in the patch space.  The patches should show breaks
in this form by inserting extra blank lines in the  published  patch  to
indicate a new "sub-section" of the patch.

     The patching session is ended by the ^Z (Control-Z) command to exit
DDT properly.  The Control-Z command is the correct way to exit from DDT
when applying patches.  It allows DDT to do any  final  cleanup  it  may
need  to  do.   Exiting  via  Control-C  is NOT recommended when you are
installing patches, and is NOT guaranteed to work.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 19
DDT PATCHING THE TOPS-20 MONITOR


     Finally, the patched monitor is saved away on  a  disk  file.   The
published  typescript  shows  creating  a  new  generation of the system
MONITR.EXE file, but a more conservative approach is to save the patched
monitor  as  some  other  name, and try running it experimentally during
system time before installing it as the default monitor.



     And now for an annotated example:

@
@! PATCH TO RELEASE 3 AND 3A MONITORS TO CORRECT ENQ FROM
@! APPENDING A REQUEST TO THE WRONG LOCK BLOCK WHEN A STRING
@! AND USER CODE HAPPEN TO HASH TO THE SAME ADDRESS.
@! THE MAGIC NUMBER AT XXX: IS POINT 3,T2,2
@
@ENABLE (CAPABILITIES)          !Appropriate releases noted above.
$GET SYSTEM:MONITR              !Get the monitor
$START 140                      !Enter user mode EDDT
DDT

ENQ$:                           !Open the symbol table for the module

FFF/   0   XXX:   410300,,T2    !Store into the patch area and define
FFF2+1/   0   FFF:              ! label XXX: to point to it; redefine
                                ! FFF to be the new first unused word
STRCMP+5/   MOVE T3,T2   FFF$<  !Begin an $< patch at FFF
FFF/   0   LDB T3,XXX           !This line and the next are ended by
FFF+1/   0   CAIN T3,5          ! LINE-FEEDs
FFF+2/   0   RET$>              !Terminate the patch
FFF+3/   MOVE T3,T2             !These 4 lines are typed out by DDT on
FFF+4/   JUMPA T1,STRCMP+6      ! terminating the patch
FFF+5/   JUMPA T2,STRCMP+7
STRCMP+5/   JUMPA FFF2+1        !And another blank line indicating end
                                ! of this sub-patch region
^Z                              !Control-Z to exit DDT properly
$SAVE SYSTEM:MONITR             !Save away the patched monitor
 <SYSTEM>MONITR.EXE.2 Saved
$
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 20
MAPPING DIRECTORIES IN MDDT




                  MAPPING DIRECTORIES IN MDDT
                  ---------------------------




     Release 3 and later of TOPS-20 can take advantage of  the  extended
addressing features of the model B processor.  Some of the 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  3  and
later.

     You first have to find  out  the  structure  number  and  directory
number  for  the directory to be mapped.  You can use the TRANSL command
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:<CURDS>.
You use TRANSL and obtain the results:  

        @TRANSLATE (DIRECTORY) SNARK:<CURDS>
        SNARK:<CURDS> (IS) SNARK:[4,117]

The "programmer number" obtained is the directory number, in octal.   In
this  example,  the directory number is 117.  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, or from BUGCHK output.

     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
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 21
MAPPING DIRECTORIES IN MDDT


for SNARK:, the structure number you want is 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.   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!   117
        2!   2
        CALL MAPDIR$X
        <SKIP>

        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 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 and after, however, when you examine  location  DIRORA
after calling MAPDIR, it doesn't have to contain a section zero address.
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.


     For Release 4 of TOPS-20, the various  flavors  of  DDT  have  been
trained  to  understand  extended  addresses, so the mapping contortions
used for 3 and  3A  are  unnecessary.   On  extended  machines  one  can
reference section two directly as below:

        DIRORA[   2,,0

        2,,0[   400300,,100

When done, you can still just ^C out or jump to MRETN.

     NOTE:  if you have the Release 5  version  of  MDDT/EDDT  that  has
sticky  current  address  section  (see DDTxx.MEM) then be careful about
doing an MRETN$G after examining section 2, as a crash will result  from
transferring to MRETN in section 2.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 22
RECOVERING FROM DIRECTORY ERRORS


                    RECOVERING FROM DIRECTORY ERRORS
                    --------------------------------




     Sometimes after a monitor crash due to disk problems, some of the
directories  on  the  system  will contain errors.  These errors cause
BUGCHKs such as DIRFDB, NAMBAD, DIRPG0, and DIRPG1.  It  is  sometimes
possible  to  find  the  error  in the directory by getting into MDDT,
mapping the directory, finding what is wrong,  and  fixing  it.   This
procedure  is  described  in  the SWSKIT.  However, this is not always
easy, and may take a lot of time.  It  is  therefore  better  in  many
cases  to  simply  delete  the bad directory and recreate it.  This is
easy to do for most directories.  But special procedures are necessary
for the directories <SYSTEM> and <SUBSYS>.  The rest of this memo will
describe the methods of recovering from bad directories,  handling  in
particular the difficult case of the <SYSTEM> directory.

     You can first try to give the EXPUNGE command  with  the  REBUILD
and  PURGE  subcommands.   If  the  problem with the directory is very
simple, it may fix your problem.  As an example, suppose the directory
PS:<SICK-DIRECTORY> is incorrect.  You would type:


        $EXPUNGE (DIRECTORY) PS:<SICK-DIRECTORY>,
        $$REBUILD (SYMBOL TABLE)
        $$PURGE (NOT COMPLETELY CREATED FILES)
        $$
         PS:<SICK-DIRECTORY> [NO PAGES FREED]
        $



     If this does not help the problem, you will have  to  delete  the
directory  and  then  recreate it.  Before proceeding, you should make
sure that any files you can reference are copied to another directory,
or  else  are  saved  on  tape.  Now first try to delete the directory
normally, as follows:


        $BUILD (USER) PS:<SICK-DIRECTORY>
        [OLD]
        $$KILL
        [CONFIRM]
        $$
        $



     If this is successful, then simply recreate the directory  again,
and  restore the user's files.  You should recreate the directory with
the same directory number as it had before, so that DLUSER's data will
still be correct.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 23
RECOVERING FROM DIRECTORY ERRORS


     The procedure above will fail if either the directory  is  mapped
by  another  job,  or if it is totally unusable.  If it is mapped, and
the directory is a random user, you can wait until the directory is no
longer  in use, or you can take the system stand-alone so that no user
can reference it.

     If the directory is totally unusable, you will then have  to  try
to  delete  it  the  hard  way.   Before proceeding, you should try to
delete and expunge all files in the directory.  This will minimize the
amount  of  lost  pages  that will result.  Now there are two cases to
consider.  If the directory is  not  a  sub-directory,  you  type  the
following:  


        $DELETE (FILE) PS:<ROOT-DIRECTORY>SICK-DIRECTORY.DIRECTORY,
        $$DIRECTORY (AND "FORGET" FILE SPACE)
        $$
         <ROOT-DIRECTORY>SICK-DIRECTORY.DIRECTORY.1 [OK]
        $



     If the directory is a subdirectory, you modify the above  command
by   replacing  "ROOT-DIRECTORY"  by  the  name  of  the  next  higher
directory.  Thus if the directory was PS:<ANOTHER.BAD-ONE>, you  type:


        $DELETE (FILE) PS:<ANOTHER>BAD-ONE.DIRECTORY,
        $$DIRECTORY (AND "FORGET" FILE SPACE)
        $$
         <ANOTHER>BAD-ONE.DIRECTORY.1 [OK]
        $



     The above procedure tells the monitor to treat the directory file
like  a  normal  file,  and to delete it as such.  This means that any
files in the directory will become "lost".   The  disk  pages  can  be
recovered  later  with  CHECKD.   If  the  above works, you simply can
recreate the directory and restore the files.

     The only reason the above command should fail is if the directory
is  still  mapped.   For  PS:<SUBSYS>,  you  can  bring  up the system
stand-alone so that no programs are run from it, and then  delete  it.
For PS:<SYSTEM>, even taking the system stand-alone will not help, for
it is always mapped by job 0.  But there are two  procedures  you  can
use which do work.

     The safest method can be used if the user's system has  mountable
structures.   If  you  have built another PS: structure, you can mount
the pack with the bad directory as an alias, and  then  the  directory
will not be mapped and can be deleted.  As an example:
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 24
RECOVERING FROM DIRECTORY ERRORS


        $MOUNT STRUCTURE SICK:/STRUCTURE-ID:PS:
        STRUCTURE SICK: MOUNTED
        $
        $DELETE (FILES) SICK:<ROOT-DIRECTORY>SYSTEM.DIRECTORY,
        $$DIRECTORY (AND "FORGET" FILE SPACE)
        $$
         SICK:<ROOT-DIRECTORY>SYSTEM.DIRECTORY.1 [OK]
        $



     Then you can build the new directory, restore the  files  to  it,
and  then use it again for your normal PS: pack.  Be sure to build the
new directory with the same number.  This is especially important  for
the special system directories.

     If you do not have another disk drive or another PS: disk, or  if
you  don't  want to bother MOUNTing the disk, you can fix the <SYSTEM>
area by using MDDT.  The basic idea is to patch the monitor so that it
no  longer  thinks  that  the  directory  is  in use.  This is done as
follows:


        $^EQUIT

        INTERRUPT AT 17117
        MX>/MDDT
        CHKOFN/   JSP CX,.SAVE   JRST RSKP
        MRETN$G
        $



     Then  you  should  have  no  problems  deleting  the   directory.
Immediately  after  doing  the  delete,  you should reload the system.
When the system restarts, you can read the monitor and the EXEC either
from  the distribution magtape or from another directory where you had
kept copies.  Then recreate the <SYSTEM> area, making sure to give  it
the  same directory number as it had before.  Then you can restore the
files and let the users back on.  Finally, you should  run  CHECKD  to
recover the lost pages.

     NOTE:  The special system directory numbers are:
                1 - <ROOT-DIRECTORY>
                2 - <SYSTEM>
                3 - <SUBSYS>
                4 - <ACCOUNTS>
                5 - <OPERATOR>
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 25
MORE ABOUT DIRECTORY PROBLEMS


                     MORE ABOUT DIRECTORY PROBLEMS
                     -----------------------------

SOME HINTS FOR TRACING DIRECTORY PROBLEMS


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
         
         This will tell you just about everything.

     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:
         
                @ENABLE
                $RU DIRPNT
         
         And answer the questions.  This also  may  not  work  if  the
         headers are bad.

     3.  If you get a BUGCHK:

         Go into the monitor with MDDT and set  a  breakpoint  at  the
         BUGCHK address, say, FDBBAD.  Do the functions that cause the
         BUGCHK;   DIR,  say.   Trace  down  the  bug.   The  relevent
         listings  are  PROLOG  and  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 MINI-EXEC
                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
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 26
MORE ABOUT DIRECTORY PROBLEMS


                ; find  out  which  structure   has  structure  number
                ; 3 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/ STR NUMBER
                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  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> (or next higher-level directory).
                
                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
                $$
         
         Create new directory with the same directory number.  The same number
         is important for the special system directories.
         
                $^ECREATE <DIRECTORYNAME>
                [New]
                $$NUMBER nn
                .
                .
                .
         
         Now DUMPER the files back.
         
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 27
JSB AND PSB MAPPING


        An Easy Way to Examine the PSB and JSB of Another Job
        -----------------------------------------------------




     There is an occasional need to look at the  state  in  detail  of
another  job on the system.  A common reason for doing this is to find
the cause and cure of a "hung job" which cannot  be  logged  out.   To
find  out  what  the  job is doing you usually start by looking at the
JSYS stack in the PSB.   But  you  cannot  examine  such  data  easily
because  the  fork data in the PSB and the job data in the JSB are not
in the monitor's address space until the fork is run.  If you  try  to
look  at  the PSB or JSB using MDDT you will see the data for your own
fork.  To look at the data for another  fork  you  must  do  what  the
monitor does, and that is to map it.

     A procedure for doing the mapping of a PSB or JSB  was  given  in
the release 3 and 3A SWSKITs.  You first find the SPT index of the PSB
or JSB you want to map, then you call  SETMPG  or  MSETMP  to  set  up
pointers  to  the  data,  and  then you can examine it.  But there are
several problems in using that method, which are:

     1.  You have to find an empty  set  of  pages  in  the  monitor's
         address space which can be used for mapping.

     2.  There is not enough room to map all of the PSB and  JSB.   So
         if  you  want to examine many different things you have to do
         the mapping many times.

     3.  The routines SETMPG and MSETMP do  no  validity  checking  of
         their  arguments.   Thus if you feed them bad data the system
         will probably crash.  So if you need to map things many times
         your chances are you will make a mistake once too often.

     4.  The addresses of the data are not correct.  To  look  at  PPC
         for example, you can't just examine location PPC (which would
         be for your own fork).  You have to look in the page you  are
         using  for  mapping.   So every reference has to be offset by
         some constant.

     5.  When you are done looking at the fork, you can't simply leave
         MDDT.   You  have to call SETMPG or MSETMP again to unmap the
         data.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 28
JSB AND PSB MAPPING


     Since that documentation was written I  have  found  a  procedure
which is much easier.  It eliminates almost all of the above problems.
The procedure is this:

     1.  Do a "GET" of the file the monitor was loaded  from,  usually
         SYSTEM:MONITR.EXE.

     2.  Enter user mode DDT in the file you got, and then do  a  JSYS
         777 to get into MDDT.

     3.  Find out the SPT indexes as before, and call  MSETMP  to  map
         the  PSB  or  JSB  to  the USER address space, in the correct
         place!!

     4.  Return from MDDT, and examine PSB and JSB locations directly,
         and see the correct data in the right place.

     5.  When you are done, just ^C and do a RESET.




     The rest of this document will document  step  by  step  how  the
procedure  above is done, by using an example.  Assume that we wish to
examine the state of fork 105, which  belongs  to  job  21.   We  then
begin:
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 29
JSB AND PSB MAPPING


@ENABLE                                 !Get a copy of the monitor
$GET PS:<SYSTEM>MONITR.EXE
$START 140                              !Get into user DDT
DDT

JSYS 777$X                              !Enter MDDT
MDDT



!Following is an example of the procedure to map the JSB of a job:


FKJOB+105[   25,,2035                   !Get the SPT index of the JSB
                                        !of fork 105

T1!      2035,,0                        !Put SPT index in left half
T2!      540000,,JSBPGA                 !* Flags and where to map to
T3!      JSLSTA'1000-JSBPGA'1000        !Number of pages to map

CALL MSETMP$X                           !Do the mapping
$


!Following is an example of the procedure to map the PSB of a fork:


FKPGS+105[   2657,,2332                 !Get the SPT index of the PSB
                                        !of fork 105

T1!      2332,,PSBMAP-PSBPGA            !Put SPT index in left half,
                                        !and offset in right half
T2!      540000,,PSSPSA                 !* Flags and where to map to
T3!      PSBMSZ                         !Number of pages to map

CALL MSETMP$X                           !Do the mapping
$
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 30
JSB AND PSB MAPPING


!Example of returning to user mode and looking at data from both
!the PSB and the JSB of the fork:


MRETN$G                                 !Return to user mode
$

USRNAM[   3                             !Examine job's user name
USRNAM+1[   422050,,546230   $T;DBELL   

CTRLTT[   777777,,777777                !Controlling terminal

FILBYT+MLJFN[   4400,,334010            !Start of data block for JFN 1

PPC/   T1,,DISXE#+2                     !Current PC of the fork

PAC+17/   -215,,UPDL+62                 !Current stack pointer

UPDL/   CHKHO5#                         !First few stack locations
UPDL+1/   CAM CHKAE0#+12   
UPDL+2/   CHKHO5#   
UPDL+3/   CAM CHKAE0#+12   
UPDL+4/   T1,,.COMND+1   


!Example of terminating the mapping we have done:


^C
$RESET                                  !To finish, just quit and reset
$


     The procedure as given above maps the JSB and PSB  write-enabled.
So  if  you  find something you want to change, you can simply deposit
the new value  into  the  location.   If  you  want  the  data  to  be
write-protected,  then  change  the  540000 to 500000 in the two steps
marked with an asterisk.


     WARNING:  The procedure of mapping things into your user  address
space  has its limitations.  Mapping the JSB and PSB works because the
user core used for mapping was previously empty.  In general, you  can
only  map  things  into  your  user core if your core pages are either
nonexistant or are private.  If you call  MSETMP  or  SETMPG  and  map
something  over  a  shared page, the old file page is unmapped without
the share counts being updated, which prevents your job  from  logging
out  later.  To get around this problem you can BLT your core image to
force all of the pages to be private.

     The SWSKIT tools program MONRD is able to examine the JSB and PSB
of  any  job/fork  on  the  system,  and  is  the  preferred method of
obtaining this sort of information, unless the ability to  modify  the
data or advanced features of DDT are required.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 31
BREAKPOINTING MULTI-USER CODE


        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                     ; check our fork number

FFF/   0   NOTME:   PUSH P,T1   ; save an AC
NOTME+1/   0   MOVE T1,FORKX    ; get currently running fork number
NOTME+2/   0   CAIE T1,23       ; is it us=23?
NOTME+3/   0   AOS -1(P)        ; no, setup skip return
NOTME+4/   0   POP P,T1         ; restore the saved AC
NOTME+5/   0   POPJ P,          ; and return to caller
NOTME+6/   0   FFF:             ; reset the position of 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.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 32
BREAKPOINTING MULTI-USER CODE


     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:  


BLKSC2+3/   JUMPGE B,BLKSCE   FFF$<     ; patch this location
FFF/   0   PUSHJ P,NOTME                ; call the NOTME routine
FFF+1/   0   .$B   JFCL$>               ; me if it gets here, set breakpoint
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    ; get the program to be used
$DDT            ; enter DDT
DDT
JSYS 777$X      ; and enter MDDT from there
MDDT

(PUT IN "NOTME" ROUTINE AND SET BREAKPOINTS HERE)

MRETN$G         ; return to the context of the test program
$
$G              ; start the test program
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 33
USING ADDRESS BREAK TO DEBUG THE MONITOR


                Using Address Break to Debug the Monitor
                ----------------------------------------


Sometimes when examining a set of dumps, you will notice  the  crashes
are  caused  by  some  location  being destroyed.  If you have no idea
where the destruction is done from, finding the problem could be  very
difficult.   One  useful procedure in such cases is to use the address
break feature of the hardware to track down the  problem  (except  for
2020's!).   The  only  problem is that the use of address break is not
obvious.  This is a manual describing how to use address break in  the
TOPS-20 monitor.

     In order to use address break, four things must be done.   First,
the  current routines the monitor uses to set address breaks for users
must be disabled.  Secondly, your own address break must be  set  from
MDDT  or  EDDT.   Thirdly,  instructions  which  you  want  to execute
properly have to be modified so that they will not cause  an  unwanted
address  break.  Finally, breakpoints must be placed in the monitor so
that the state of the monitor can be examined when the  address  break
occurs.  The following is a step by step example of doing this.


1.      Load the monitor for debugging, and enter EDDT.  The procedure
        starting from BOOT is the following:

        BOOT>/L                         ;Load monitor but don't start it
        BOOT>/G140                      ;Start EDDT
        EDDT
        DBUGSW/   0   2                 ;Set debugging mode
        EDDTF/   0   1                  ;Keep EDDT once system starts
        GOTSWM$B                        ;Install useful breakpoint
        SYSGO1$G                        ;Start the monitor


        [PS MOUNTED]
        $1B>>GOTSWM   0$1B              ;Remove breakpoint now



2.      Disable the monitor's normal changing of  the  address  break.
        This is currently done at two places:
 
        KISSAV+4/   DATAO UNPFG1+26   JFCL      ;Disable instruction
        SETBRK+12/   DATAO A   JFCL             ;Here too
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 34
USING ADDRESS BREAK TO DEBUG THE MONITOR


3.      Set your own address break at the desired location.  Refer  to
        the Hardware Reference Manual for details.  The instruction to
        set an address break is:
 
        DATAO APR,ADDR          ;Note:  APR = 0
 
        where ADDR contains the following fields:
 
        Bits            Description
        ----            -----------
          9             Break at given address on instruction fetches
         10             Break at given address on reads
         11             Break at given address on writes
         12             0=exec address space, 1=user address space
        13-35           Address to break on.
 
 
        So now assume you want  to  catch  a  bug  which  is  blasting
        location  CURDS.   You want to break only for writes, and want
        to use exec virtual space.  Therefore you type the following:
 
        FFF/   0   100000000+CURDS      ;Put data in convenient place
        DATAO APR,FFF$X                 ;Set the address break
 
 
 
4.      Now you want to disable address  break  for  all  instructions
        which you expect to change the given location.  Assume in this
        example that  only  location  DIDDLE  should  change  location
        CURDS.  Then you do the following for a model B CPU:
 
        FFF!   IT:                      ;Define location to get old flags
        IT+1!                           ;Old PC
        IT+2!                           ;New flags
        IT+3!   IT+4                    ;New PC
        IT+4!   EXCH IT                 ;Save AC and get old flags
        IT+5!   TLO 1000                ;Set address break inhibit bit
        IT+6!   EXCH IT                 ;Restore flags and AC
        IT+7!   JRST 5,IT               ;Return to caller
        IT+10!   FFF:                   ;Redefine FFF
 
        DIDDLE/   MOVEM A,CURDS   FFF$< ;Insert patch
        FFF/   0   JRST 7,IT$>          ;Call above routine
        FFF+1/   0   MOVEM A,CURDS      ;Typed by DDT when finishing patch
        FFF+2/   0   JUMPA A,DIDDLE+1
        FFF+3/   0   JUMPA B,DIDDLE+2
        DIDDLE/   MOVEM A,CURDS   JUMPA IT+10
 
        The JRST 7,IT instruction is used to save the old PC at IT and
        IT+1,  and take a new PC from IT+2 and IT+3.  There the old PC
        is changed to include the address break inhibit bit.   Then  a
        JRST 5,IT  is  done  which  returns  to  the caller.  The next
        instruction then executes without causing  an  address  break.
        You   have  to  insert  the  JRST 7,IT  instruction  at  every
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 35
USING ADDRESS BREAK TO DEBUG THE MONITOR


        instruction you want to succeed.
 
        For model A CPUs the procedure is similar, but a little easier:
 
        FFF!   IT:                      ;Define location to hold PC
        IT+1!   EXCH IT                 ;Get old PC and save AC
        IT+2!   TLO 1000                ;Set address break inhibit flag
        IT+3!   EXCH IT                 ;Restore PC and AC
        IT+4!   JRSTF @IT               ;Return to caller
        IT+5!   FFF:                    ;Redefine FFF
 
        DIDDLE/   MOVEM A,CURDS   FFF$< ;Insert patch
        FFF/   0   JSR IT$>             ;Call above routine
        FFF+1/   0   MOVEM A,CURDS      ;Typed by DDT when finishing patch
        FFF+2/   0   JUMPA A,DIDDLE+1
        FFF+3/   0   JUMPA B,DIDDLE+2
        DIDDLE/   MOVEM A,CURDS   JUMPA IT+5
 
 
 
5.      Now put the breakpoints into  the  monitor  so  that  when  an
        address  break  occurs, you will get into EDDT.  There are two
        locations to patch, one for PI level and one for non-PI level.
        You  also  have  to patch a monitor bug in release 3 and 3A so
        that the page fail dispatch code works properly.

        ADRCMP$B                        ;Set breakpoint at non-PI routine
        PFCD23$B                        ;Set breakpoint at PI routine
        PIPTRP+1/   MOVE A,TRAPSW   MOVE A,TRAPS0       ;And fix a bug
        $P                              ;Now let the monitor proceed



6.      When either of the above breakpoints is hit, the flags and  PC
        of  the  instruction which caused the address break will be in
        locations TRAPFL and TRAPPC.    If the address break was  from
        JSYS  level  (breakpoint  was to ADRCMP and location INSKED is
        zero) then an $P will proceed properly.  If the address  break
        was  from  the  scheduler  or  from PI level, doing $P will be
        useless since the monitor will then BUGHLT because it  doesn't
        want to see an address break under these conditions.  However,
        this is ok if all you want  to  do  is  find  the  instruction
        causing the trashing.


      If the location still gets trashed after trying to catch it this
 way,  either  your  procedure is wrong; you are trying this on a 2020
 (which has no address break feature); the location is  being  changed
 by  some  IO  being  done  (RH20s, DTEs, etc); or else the machine is
 having some hardware problems.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 36
RECOVERING FROM SYSTEM DISASTERS


                    RECOVERING FROM SYSTEM DISASTERS
                    --------------------------------


There are some common system disasters which  in  many  cases  can  be
recovered from quickly and with a minimum of effort.  The four we will
discuss in this article are:


     1.  Hung Terminals

     2.  Hung SETSPD

     3.  Trashed Disks

     4.  Hung Jobs




     1.0  HUNG TERMINALS

     Hung terminals are usually the result of  two  problems.   Either
the speed has been set incorrectly for that terminal type or a problem
exists between the KL and the front end.  If the problem is  a  result
of  an improper speed setting, then simply resetting the speed will be
sufficient.  On the other hand, if the problem is  due  to  some  sync
problem between the KL and the 11 then the easiest way to recover from
this is to reload the front end.  This can be done by  depressing  the
halt  switch  on  the operator's console of the 11 and then placing it
back in the enable state.  After about fifteen seconds, the message

                        [DECsystem-20 continued]

to be printed on the CTY.  If this fails to free the terminal, perhaps
the problem is a hung job.  See the discussion under that heading.



     2.0  HUNG SETSPD

     This is a fairly common  problem  brought  on  by  some  hardware
problem.  It is possible to bring the system up without running SETSPD
under JOB 0, logging in, and then trying  to  run  SETSPD  under  some
other operator job.  If SETSPD then hangs, it is possible to CONTROL/C
out of the program, edit 4-CONFIG.CMD to remove the commands suspected
of  hanging  SETSPD, and retrying.  In this way, while waiting for the
problem to be resolved, it is possible to continue timesharing.

     To bring the system up without running SETSPD automatically,  one
need  only  install  the  following patch to the MONITOR using EDDT on
system start up.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 37
HUNG SETSPD


          BOOT>/l
          BOOT>/g141
          EDDT
          EDDTF[   0   -1
          DBUGSW[   0   2
          GOTSWM$B
          SYSGO1$G
          [PS MOUNTED]
          1B>>GOTSWM
          RUNDD3+7/   PUSHJ P,RUNDII   JFCL
          0$1B
          $P
          %%No SETSPD


     The system will then come up as usual except that SYSJOB will not
run.   After successfully deciding the problem with SETSPD, SYSJOB can
be run by typing

      COPY (FROM) <SYSTEM>SYSJOB.RUN (TO) <SYSTEM>SYSJOB.COMMANDS


     This will cause all the commands in the  SYSJOB.RUN  file  to  be
executed by SYSJOB.

     There is a project under way to allow SETSPD to time  out  itself
and continue with the next comand in 4-CONFIG.CMD.  Look for it in the
Large Buffer or the 20 Dispatch.



     3.0  TRASHED DISKS

     This is surely one of the biggest headaches facing a  specialist.
Trashed  disks come in many forms and recovering from these requires a
good knowledge of the structure of the TOPS-20 file system.

     If the structure cannot be mounted, it is because of one  of  the
following reasons:

     1.  Inconsistency in either of the HOM blocks

         1.  Word HOMNAM (1) of either HOM block not SIXBIT/HOM/

         2.  Word HOMCOD (176) of either HOM block not 707070

         3.  Word HOMHOM (5) of first HOM block not 1,,12

         4.  Word HOMHOM (5) of second HOM block not 12,,1

         5.  Word HOMFSN (173) of either HOM block not 20040,,47524
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 38
TRASHED DISKS


         6.  Word HOMFSN+1 (174) of either HOM block not 51520,,31055

         7.  Word HOMFSN+2 (175) of either HOM block not 20060,,20040

         8.  Right half of word HOMLUN (4) of either home block either
             refers  to  a  unit  greater  than  the left half of word
             HOMLUN or it refers to a UNIT already verified

         9.  Word HOMSNM (3) of either home block does not agree  with
             SIXBIT/STRUCTURE-NAME/

        10.  No disk address for index block in word  HOMRXB  (10)  of
             either HOM blocks


     2.  Inconsistencies in Root-Directory page 0

         1.  Directory number in Directory page  0  of  Root-Directory
             not 1

         2.  Directory block type (DRTYP) of Root-Directory page 0 not
             400300

         3.  Relative Page number (DRRPN) of Root-Directory page 0 not
             0

         4.  Top of symbol table (DRSTP) of Root-Directory page 0  out
             of Directory bounds

         5.  Pointer to first free  block  (DRFFB)  of  Root-Directory
             page 0 not in page 0 of the directory

         6.  Pointer to Directory Name String (DRNAM) not under  start
             of symbol table

         7.  Directory name pointer (DRNAM)  not  0  and  Name  string
             block length (NMLEN) not at least 2 words long

         8.  Directory name pointer (DRNAM) not 0 and  directory  name
             block header (NMTYP) not 400001

         9.  Password block pointer not 0 and  password  string  block
             length (NMLEN) not at least 2 words long

        10.  Password block pointer not 0 and  password  string  block
             header (NMTYP) not 400001

        11.  Account string block pointer not  0  and  Account  string
             block length (NMLEN) not at least 2 words long

        12.  Account string block pointer not  0  and  Account  string
             block header (NMTYP) not 400001
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 39
TRASHED DISKS


     3.  Inconsistencies in Block types or free  space  in  subsequent
         pages of the directory.

              All blocks in the directory (including free space) begin
         with   a  block  header  which  specifies  type  and  length.
         Immediatly following one block should be a header for  a  new
         block.  If this scheme is corrupted, the mount will fail.

         1.  Header of a block not

             1.  (NAMTYP)  400001

             2.  (EXTTYP)  400002

             3.  (ACCTYP)  400003

             4.  (USRTYP)  400004

             5.  (FDBTYP)  400100

             6.  (DIRTYP)  400300

             7.  (FRETYP)  400500

             8.  (FBTTYP)  400600

             9.  (GRPTYP)  400700


         2.  Header of a block is NAMTYP and Block length not at least
             2 words

         3.  Header of a block is EXTTYP and block length not at least
             2 words

         4.  Header of a block is ACCTYP and block length not at least
             3 words

         5.  Header of a block is USRTYP and block length not at least
             3 words

         6.  Header of a block is FDBTYP and

             1.  Block length not at least 30 (.FBLN0) words long

             2.  Pointer to Author String (.FBAUT) not 0 and points to
                 a block outside of the directory or points to a block
                 that does not meet the tests for a user  name  string
                 as described above.

             3.  Pointer to Last Writer  String  (.FBLWR)  not  0  and
                 points  to a block outside of the directory or points
                 to a block that does not meet the tests  for  a  user
                 name string block as described above.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 40
TRASHED DISKS


             4.  Pointer to Account String (.FBACT) is not  less  than
                 or  equal to zero and it points to a block outside of
                 the directory or it points to a block that  does  not
                 meet  the  tests  for  an  account  string  block  as
                 described above.

             5.  Pointer to Name String  (.FBNAM)  is  not  0  and  it
                 points  to  a  block  outside  of the directory or it
                 points to a block that does not meet the tests for  a
                 Name String Block as described above.

             6.  Pointer to Extension String (.FBEXT) is not 0 and  it
                 points  to  a  block  outside  of the directory or it
                 points to a block that does not meet the tests for an
                 Extension String Block as described above.


         7.  Header of a block is DIRTYP and

             1.  Header is not on a page boundary

             2.  Relative page number (DRRPN) not the calculated  page
                 number

             3.  Pointer to first free block (DRFFB) does not point to
                 a location within the current directory page

             4.  Directory number (DRNUM) not 1.


         8.  Header of a block is FRETYP and block is not at least two
             words  or  Pointer to next free block (FRNFB) is not zero
             and points to a location not on the same page as current

         9.  Last block did not end at  DRFTP  (address  specified  on
             first page of directory)


     4.  BAT blocks inconsistent.

         1.  Either block  does  not  contain  SIXBIT/BAT/  in  BATNAM
             (offset 0 in block)

         2.  Either block does not contain 606060  in  BATCOD  (offset
             176 in block)

         3.  Sector number of the BAT  block  (BATBLK)  not  the  true
             sector of block

         4.  The BAT blocks to not compare  exactly  with  each  other
             through word 176 of the blocks
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 41
TRASHED DISKS


     5.  Checksum of the Root-directory Index  Block  does  not  agree
         with the checksum calculated.

              Checksums are calculated as follows:

         CHKSUM = 0 ;
         For I = 0 to 777
             If XB(I) = 0 then 
                 CHKSUM = CHKSUM + I
             Else 
                 CHKSUM = CHKSUM + XB(I) ;

         where XB is the first word of the index block.



     As you can see, there are many things that could be wrong with  a
structure that inhibits it from being mounted.  The consistency of the
structure can be checked quite easily using the new FILDDT commands of
STRUCTURE  and  DISK  (see 'NEW DISK FEATURES FOR FILDDT' also in this
SWSKIT).

For  structures  which  are  badly  trashed,  the  only  sane  way  of
recovering  is to rebuild the structure using a catastrophe tape.  For
simple inconsistencies such as a bad BAT block, CHECKD  does  the  job
well.   For  more  involved  trashes which can not be recovered from a
back up tape  (because  of  a  forgetful  system  manager)  the  above
information can be of great help.



     4.0  HUNG JOBS

     There are a number of circumstances which arise which cause a job
to  become  hung,  usually  waiting for some resource to free up, some
share count to become zero etc.  Some times, these  tests  will  never
become  satisfied,  the  Job  has  its PSI system turned off, and as a
result the job becomes Hung.  Freeing it up can be very  tricky.   The
first thing to try is to log the job out from some other terminal.  If
this doesn't succeed in freeing the job up, then the next  best  thing
is to detatch the job from the terminal and allow it to sit there.  It
may be using negligible amounts of  CPU  time  and  cause  no  adverse
affects  to the system.  To zap the job may crash the system which, in
most cases, is not the desirable approach.

The next time the system is reloaded, be sure to get  a  dump  of  the
system  with  the  hung  job  and  submit it as an SPR (see the SWSKIT
article about getting informative Dumps).
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 42
LOOKING AT HUNG TAPES


                         LOOKING AT HUNG TAPES
                         ---------------------




     A number of problems of the general  classification  "tape  hang"
have  been  reported, and will probably always exist as long as we use
magtapes.  Although there  are  apparently  several  variants  of  the
problem,  there  are  some  things  which  can  be  done by a suitably
cautious specialist when presented with a  hung  tape  drive.   Listed
below  are  some  techniques  which  can  be  used  in  an  attempt to
investigate and perhaps alleviate the problem.  These  things  should,
in general, be harmless to the system, barring mis-typing in MDDT.  As
a result, perhaps they will not clear the problem.

     For release 4, there are several tables that are used in relation
to  tape  drives.  Some of these tables are indexed by MT unit number,
some by MTA unit number.  In general, it can be said that if  a  table
name  begins  with  the  characters  MT,  it will be indexed by MTA or
physical unit number, and if the table name begins with TL or  TP,  it
will  be  indexed  by MT or logical unit number.  The TL and TP tables
will usually have something to do with the tape labeling system.  This
article concerns itself mainly with the more important tables relating
to MTAs (physical tape units).

     When playing with the tape  subsystem,  certain  care  should  be
taken.  For instance, it always helps if no one else is actively using
the tape  drives  while  you  attempt  something  like  reloading  the
microcode for a DX20.

1.  Finding the Tape Drive

     There are several tables parallel to each other which concern the
ownership  of a tape drive.  Those of interest are DEVNAM, DEVCHR, and
DEVUNT.  At DEVNAM+n is the device name in SIXBIT.  At DEVUNT+n  is  a
word  with the left half set to the assigner's job number, -1 if free,
or -2 if being controlled by the allocator.  The right  half  contains
the  unit number.  Note that in release 4, with tape allocation turned
on, MTAs will always indicate that job 0 has the  drive  assigned  and
that the offset to the MT unit number will contain the job number of a
user.  At DEVCHR+n is the device characteristics  word.   Knowing  the
devicename  or  the  owning  job,  one  can  use DDT to find the table
offset.  See example below.

2.  Grabbing the Drive

     Knowing the offsets into DEVUNT, the  device  assignment  can  be
freed  by  putting  -1  into  the  left half of the appropriate DEVUNT
entry.  The drive can then be assigned by the normal ASSIGN command to
the  EXEC.   In dealing with the allocator for Release 4, your own job
number can be placed here if  necessary.   The  drive,  however,  will
still  be  in no state to use.  Note that the appropriate DEVUNT entry
would be the one referring to the MT not the MTA.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 43
LOOKING AT HUNG TAPES


3.  Clearing External Errors

     Make sure that there is a tape of  some  sort  mounted,  and  the
drive  is  placed on-line.  Having a write-enable ring in the tape may
help in being sure the unit is functional if  the  hung  condition  is
cleared.

4.  Checking the UDB

     Next, the Unit Data Block status should be reset.  This word  can
be  found  using  the MTCUTB table.  This table is indexed by MTA unit
number, the left half is the address of the channel data block  (CDB),
and  the  right half contains the address of the UDB.  The status word
of the UDB should then be reset to the base  state.   The  right  half
should be left alone--it basically contains drive type.  The left half
should have only bit 16  set,  which  indicates  a  tape  type  device
(US.TAP).  The old contents should be remembered for purposes of later
analysis.

5.  Checking the Status

     Now, table MTASTS is examined, indexed by MTA unit number  again.
Remember the old contents.  Then clear the word to zero.

6.  Example

    @enaBLE (CAPABILITIES) 
    $sddt
    DDT
    mddt%$x
    MDDT
    
    dvxstn=21   !THIS WILL PROVIDE A HANDY INDEX
                !INTO THE MTA OFFSETS IN THE
                !DEVxxx TABLES.
    
    
                !DEVNAM IS A SIXBIT DEVICE NAME
    
    devnam+21/   HLRZM P2,FKBSPW+217(T1)   $6t;MTA0     
    DEVNAM+22/   MTA1     
    DEVNAM+23/   MTA2     
    DEVNAM+24/   MTA3     
    DEVNAM+25/   MTA4     
    DEVNAM+26/   MTA5
        ...
        ...
        ...
    
    DEVNAM+40/   MTA17     
    
    mtan=20     !ROOM FOR 20 (OCTAL) TAPE DRIVES HAS BEEN ALLOCATED
    
    mtindx[   777765,,5   !BUT ONLY 5 ACTUAL TAPE DRIVES ARE ON THIS SYSTEM
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 44
LOOKING AT HUNG TAPES


    
                !THE MTs WILL APPEAR AFTER MTAs IN THE DEVxxx
                !TABLES SO DVXSTN+MTAN WILL PROVIDE THE OFFSET
                !TO THE MT ENTRIES
    
    devnam+41/   HLRZM P1,@0   $6t;MT0      
    DEVNAM+42/   MT1      
    DEVNAM+43/   MT2      
    DEVNAM+44/   MT3      
    DEVNAM+45/   MT4      
    DEVNAM+46/   MT5      
        ...
        ...
        ...
    
    DEVNAM+60/   MT17
    
                !DEVUNT IS PARALLEL TO DEVNAM AND PROVIDES
                !THE OFFSETS INTO THE MTxxxx TABLES FOR MTAs
                !AND OFFSETS INTO THE TLxxxx/TPxxxx TABLES
                !FOR MTs
    
    devunt+21[   0   !MTA UNIT ZERO (MTA0: FROM DEVNAM ABOVE) ASSIGNED TO JOB 0
    DEVUNT+22[   1   !JOB 0,,MTA1:
    DEVUNT+23[   2   !JOB 0,,MTA2:
    DEVUNT+24[   3   !JOB 0,,MTA3:
    DEVUNT+25[   4   !JOB 0,,MTA4:
    DEVUNT+26[   5   !JOB 0,,MTA5:
    DEVUNT+27[   777777,,6   !UNASSIGNED,,MTA6:
        ...
        ...
        ...
    
    DEVUNT+40[   777777,,17   !UNASSIGNED,,MTA17:
    
                !DV%PSD=400000 INDICATES A PSEUDO DEVICE
                !THE FOLLOWING ENTRIES FOR MTs WILL INDICATE
                !THE AVAILABILITY OF LOGICAL TAPE UNITS
    
    devunt+41[   32,,400000   !PSEUDO DEVICE MT0: IS ASSIGNED TO
                              !JOB 32 OCTAL (JOB 26 IN DECIMAL)
    DEVUNT+42[   777776,,400001   !CONTROLLED BY ALLOCATOR,,MT1:
    DEVUNT+43[   777776,,400002   !     "     "       "   ,,MT2:
    DEVUNT+44[   777776,,400003   !     "     "       "   ,,MT3:
        ...
        ...
        ...
    
    DEVUNT+60[   777776,,400017   !     "     "       "   ,,MT17:
    
                !TLABR0 (INDEXED BY MT NUMBER) WILL INDICATE
                !WHICH PHYSICAL TAPE UNIT WILL BE USED WHEN
                !REFERENCING AN MT. THIS IS INDICATED  BY THE
                !PHYSICAL MTA NUMBER IN BITS 2-8.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 45
LOOKING AT HUNG TAPES


    
    tlabr0[   405000,,0   !BIT 0 INDICATES A VALID VOLUME IS MOUNTED ON MTA5
    
    mtcutb+5[   730437,,730625   !CDB,,UDB FOR MTA5 BEING USED BY JOB 26
                                 !WHO KNOWS IT AS MT0 (SEE ABOVE)
    
    
    730625[   102,,157  !FIRST WORD OF UDB FOR MTA5
                        !US.WLK=1B11 >> WRITE LOCKED
                        !US.TAP=1B16 >> TAPE TYPE DEVICE
                        !.UTT70=17B35 >> TU70
    
    mtasts+5[   0   !THIS EXAMPLE INDICATES A TAPE DRIVE THAT PROBABLY
                    !HASN'T BEEN REFERENCED BY THE USER YET
    
    
    mretn$g             !TO RETURN TO SDDT FROM MDDT
    <>
    
    ^Z                  !TO RETURN TO THE EXEC FROM SDDT
    $
    

     If clearing MTASTS and UDBSTS for the drive doesn't seem to clear
the  problem, you will probably have to do more digging around to find
some other, more obscure, inconsistency in the  MTA/MT  tables.   This
can  be  accomplished  by  referring  to  the  monitor  tables (which,
hopefully, have been included with the SWSKIT) under MTA-STORAGE-AREA.
As always, extreme caution should be exercised while fooling around in
MDDT as you can accidentally trash some random location in the monitor
just by hitting a carriage return at the wrong time.

     One last note should be made about the monitor tables here.   The
description  of  the  DEVUNT  table would lead one to believe that the
right half will contain a -2 if the device is  under  control  of  the
allocator.   If  the  device is under control of the allocator, the -2
will appear in the left half.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 46
A LOOK AT SOME OF THE DISK STUFF



                   A LOOK AT SOME OF THE DISK STUFF
                   --------------------------------



     This article is a front for the PHYPAR module, which is where the
information may be reliably obtained, and should serve as the ultimate
reference for these problems.

        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 malfunctioning 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 diagnostics.   In most  cases the  Field Service  rep
knows what all the status  bits etc.  mean but  has  not been able  to
find them in the monitor crashes or running monitor.

CHNTAB:
        CHNTAB 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   dependent
        instructions and data, pointers to the unit data block
        (UDB) in the case of  RPO4, RP05, and RP06's.  In  the
        case of tapes  the pointer  is to the Kontroller  Data
        Block (TM02/3) which points in turn to the UDBs.   The
        CDB also  contains  information  about  the  currently
        active unit.   When  the channel  interrupts,  control
        passes (via  a JSP)  to CDBINT.   The CDB  address  is
        stored in AC1, P1 and the principal 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.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 47
A LOOK AT SOME OF THE DISK STUFF


        
        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 maintenance mode
        CS.MRQ==1B4             ; maintenance mode requested for unit
        CS.ERC==1B5             ; error recovery in progress
        CS.STK==1B6             ; channel supports command stacking
        CS.ACL==1B7             ; alternate command list is current

        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 (1 word/UDB)


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        

                                ; NOTE - there are several other UDB words
                                ; including a device dependent portion
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 48
A LOOK AT SOME OF THE DISK STUFF


        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 this unit
        US.BLK==1B5     ; lock bit for this units BAT blocks
        US.PGM==1B6     ; dual port switch in (A or B)
        US.MAI==1B7     ; unit is in maintenance mode
        US.MRQ==1B8     ; maintenance 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    ; maintenance mode allowed on this unit
        US.OIR==1B13    ; operator intervention required, set at
                        ;  interrupt level, checked periodically.
        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.PSI==1B17    ; tape - online/offline/rewind done transition

        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
        .UTRP7 = 7      ; RP07
        .UTRP8 = 10     ; RP08
        .UTRM3 = 11     ; RM03
        .UTTM3 = 12     ; TM03 AS A UNIT
        .UTT77 = 13     ; TU77
        .UTTM7 = 14     ; TM78
        .UTT78 = 15     ; TU78
        .UTDXA = 16     ; DX20-A FOR TAPES
        .UTT70 = 17     ; TU70
        .UTT71 = 20     ; TU71
        .UTT72 = 21     ; TU72
        .UTT73 = 22     ; TU7x
        .UTDXB = 23     ; DX20-B FOR DISKS
        .UTP20 = 24     ; RP20
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 49
A LOOK AT SOME OF THE DISK STUFF



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.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 50
NEW DISK FEATURES FOR FILDDT



                         NEW DISK FEATURES FOR FILDDT
                         ----------------------------


    The FILDDT to be shipped with release  4 of TOPS-20 will have two  new
    commands in relation to disk file structure maintenance.

    They are:

        STRUCTURE (FOR PHYSICAL I/O IS) disk-structure
                Examines the specified disk structure.

        DRIVE (FOR PHYSICAL I/O IS ON CHANNEL) c (UNIT) u
                Examines the specified disk unit.

    These are privileged functions and one must have privileges enabled to
    use these.

    These two commands are nearly  identical.  Their difference is in  the
    way the structure  is identified.   To use the  STRUCTURE command  the
    structure must  be  mounted.   The STRUCTURE  command  is  useful  for
    examining a multi-pack  structure.  The  DRIVE command  is useful  for
    examining the  file system  of a  structure which  cannot be  mounted.
    Channel and unit  numbers can be  found from the  programs UNITS,  DS,
    SYSDPY, or OPR.
        
    Addressing is in the same format as in other forms of DDT.
        
    It is easier  to understand exactly  what the disk  will look like  in
    FILDDT if you keep in mind that all sectors will be packed in the  DDT
    address space, without regard for sector size, starting at DDT address
    0.  For instance, on an RP06 there are four sectors per memory page or
    200 (octal) words per sector.  Therefore, sector zero of the structure
    will begin at FILDDT address 0 and end at memory address 177  (octal).
    Sector 1 will begin at address 200 and end at 377.  For release 4, all
    DEC supported  disks  contain  200  (octal) words  per  sector,  so  a
    consistent mapping  exists between  sector  number and  FILDDT  memory
    location.  Soon, TOPS-20 will support  RP20's.  For RP20's, there  are
    1000 (octal)  words per  sector (one  page per  sector).  Index  block
    addresses and most monitor disk addresses are in sectors.  That is why
    it is important to be able  to translate between sector addresses  and
    FILDDT memory addresses.
        
    The FILDDT option of  ENABLE PATCHING is also  available for use  with
    the DRIVE and  STRUCTURE command.  With  this option on,  the user  is
    able  to  modify  specific  words  on  the  structure.   Another  very
    convenient FILDDT command  one may  use in conjunction  with the  disk
    commands is LOAD (symbols from) input file spec.  One may specify  any
    file here but a useful one is SYSTEM:MONITR.  The symbol table to  the
    MONITOR has  home block  sector addresses,  FDB offsets  etc.  When  a
    file's  symbols  are  loaded,  one may  also define  his own  symbols.
    This is useful to remember addresses of data structures on the  units.
    For example, after finding the index block to a file, one could define
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 51
NEW DISK FEATURES FOR FILDDT


    a symbol, FILIDX at that address for easy referencing later on.

    When examining  a multi-pack  structure using  the STRUCTURE  command,
    addressing the first unit is exactly as if there were only one unit in
    the structure.  FILDDT addresses of  sectors on the other units  begin
    immediately  after  the  last  address  for  the  first  unit  of  the
    structure.  For example, consider  that we would  like to examine  the
    BAT blocks for the second unit of a two pack STR: on RP06 drives.
        
    An RP06 contains 304000. sectors per unit and 128.  words per sector.
    The first FILDDT address for the second unit of a RP06 two  pack  STR:
    is  304000.*128.=38912000. or 224340000 (octal)
        
    FILDDT>STRUCTURE (FOR PHYSICAL I/O IS) PS:
    [Looking at file structure PS:]

                        ; starting address of second unit in structure
                        ; plus sector address of BAT blocks (2)
                        ; times number of words per sector gives
                        ; FILDDT address of start of BAT blocks for
                        ; that unit

    224340000+2*200=224,,340400

    224,,340400[   424164,,0   $6T;   BAT
        
    For another example, let's say we would like to find the start of  the
    ROOT-DIRECTORY symbol table.

    @ENABLE (CAPABILITIES) 
    $FILDDT
    FILDDT>LOAD (SYMBOLS FROM) SYSTEM:MONITR
    [22722 symbols loaded from file]
    FILDDT>STRUCTURE (FOR PHYSICAL I/O IS) PS:
    [Looking at file structure PS:]
        
    NWSEC=200                   ; number of words per sector
    HM1BLK=1                    ; sector number of HOM block
    HOMRXB=10                   ; offset in HOM block for index
                                ; block to root-directory
    
                                ; sector number of HOM block
                                ; times words per sector equals
                                ; FILDDT address of start of HOM block
    HM1BLK*NWSEC[   505755,,0   $6T;HOM  
    HM1BLK*NWSEC+HOMRXB[   10,,5740 ; plus offset to address of index block
                                ; sector number of index block times
                                ; number of words per sector gives
    5740*NWSEC[   10,,5744      ; FILDDT adr of root-dir index block
                                ; NOTE:  Bit 14 (DSKAB) specifies this
                                ; address as a disk sector address.
                                ; sector addresses are bits 15-35
    RTDIDX:                     ; define symbol for index block
                                ; sector number of first page of
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 52
NEW DISK FEATURES FOR FILDDT


                                ; root-directory times number of words
                                ; per sector gives the
    5744*NWSEC[   400300,,100   ; FILDDT adr of first page of ROOT-DIR
    RTDIR0:                     ; define start of page 0 of ROOT-DIR
    RTDIR0+3[   30610           ; plus 3 for start of symbol table
                                ; NOTE: adr is a 'directory address'
                                ;       offset 610 of directory page 30
    RTDIDX+30[   10,,6250       ; get sector adr of page 30 of ROOT-DIR
                                ; sector adr of page 30 times words per
                                ; sector gives FILDDT address of page
                                ; 30 of ROOT-DIR.
    6250*NWSEC+610[   400400,,1 ; Add offset for symbol table start
    RTDSYM:
    ^E
    FILDDT>EXIT

        
    Here are some magic numbers for all DEC supported drives.
        
        DRIVE TYPE      SECTORS/UNIT    STARTING ADR    STARTING ADR
                                        OF 2nd UNIT     OF 3rd UNIT
                        (in decimal)     (in octal)      (in octal)
        __________      ____________    ____________    ____________
        
        RP04-RP05         152000.       112,,160000     224,,340000
        RP06              304000.       224,,340000     450,,700000
        RP07              502200.       365,,156000     752,,334000
        RM03              121360.        73,,204000     166,,410000
        RP20              201420.       611,,314000    1422,,630000


    NOTE: RP20 will not be supported in  release 4.  It is important  to
          remember that there are  1000 (octal) words  per sector for  a
          RP20.  As a result, to look at a sector of an RP20, one  would
          multiply the sector number by 1000 (octal) to find the  FILDDT
          starting address for that sector.   For all other drive  types
          there are 200 (octal) words per sector.


    The above information is calculated  from the parameters available  in
    STG.MAC.

    REF: DDT41.MEM
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 53
TOPS-20 SCHEDULER TEST ROUTINES


                    TOPS-20 SCHEDULER TEST ROUTINES
                    -------------------------------

     The following is a tabulation of (hopefully) all of  the  scheduler
tests  used  by the TOPS-20 monitor, time-frame approximately Release 5.
This includes ARPA and DECNET tests.  This is the data one finds in  the
monitor table FKSTAT indexed by fork number for forks which have blocked
and left the GOLST (i.e.  LH(FKPT) contains WTLST).  The format  of  the
FKSTAT  table  words  is TEST DATA,,TEST ROUTINE ADDRESS.  The scheduler
test routines are called periodically to determine if a process  can  be
unblocked.   This is indicated by a skip return from the scheduler test.
A nonskip return is taken if the process cannot yet be unblocked.

     When examining the monitor because of  a  hung  job  or  fork,  the
FKSTAT  table  can  often  reveal  the reason the fork is hung, and this
sometimes even allows corrective action to be taken.

     The table below gives routine name, what you should expect  to  see
in  the  FKSTAT  table,  and  the  module in which the scheduler test is
defined, followed finally by a short description of what the  particular
condition is which is being tested.



                            SCHEDULER TESTS


 TEST           CONTENTS OF T1 AT TIME OF SCHEDULER CALL        DEFINED
 ----           ----------------------------------------        -------

BALTST          [CONNECTION #,,BALTST]                          [NETWRK]
                Wait for network bit allocation.

BATTST          [UNIT #,,BATTST]                                [DSKALC]
                Wait for US.BLK, the lock bit for the BAT blocks
                on the unit, in the UDB to be zero.

BLOCKM          [TIME,,BLOCKM]                                  [SCHED]
                Wait for TIME in BLOCKM format which is the low
                order 17 bits of the desired future time to be
                compared against a suitably masked TODCLK.

BLOCKT          [TIME,,BLOCKT]                                  [SCHED]
                Wait for TIME in BLOCKT format which is a
                value that is shifted left 10 bits and compared
                against a suitably masked TODCLK, providing a
                longer delay than BLOCKM, but less precision.

BLOCKW          [TIME,,BLOCKW]                                  [SCHED]
                Wait for TIME in BLOCKW format (same as BLOCKM).

CDRBLK          [UNIT NUMBER,,CDRBLK]                           [CDRSRV]
                Wait for card-reader offline, or not waiting for
                a card.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 54
TOPS-20 SCHEDULER TEST ROUTINES


 TEST           CONTENTS OF T1 AT TIME OF SCHEDULER CALL        DEFINED
 ----           ----------------------------------------        -------

CHKLOK          [ADDRESS,,CHKLOK]                               [NSPSRV]
                Wait for NSP block lock at address to free.

COFTST          [TIME,,COFTST]                                  [MEXEC]
                Wait for job in FKJOBN to be attached or time
                in BLOCKT form to elapse.

D6BWT           [INDEX,,D6BWT]                                  [DTESRV]
                Wait for D6STS(INDEX) to be .GE. zero, indicating
                a free condition.

D6DWT           [INDEX,,D6DWT]                                  [DTESRV]
                Wait for D6%DDN to be set in D6STS(INDEX) to
                indicate read data done.

D6RWT           [INDEX,,D6RWT]                                  [DTESRV]
                Wait for D6%RDN to be set in D6STS(INDEX) to
                indicate response header.

D6WKT           [INDEX,,D6WKT]                                  [DTESRV]
                Wait for timer in D6CLK(INDEX) to expire.

DBWAIT          [DTE #,,DBWAIT]                                 [DTESRV]
                Wait for the TO-10 doorbell from the given DTE.

DGLTST          [0,,DGLTST]                                     [DIAG]
                Wait for DIAGLK lock to be free.

DGUIDL          [UDB ADDRESS,,DGUIDL]                           [DIAG]
                Wait for the unit to show as idle in the UDB.

DGUTST          [UDB ADDRESS,,DGUTST]                           [DIAG]
                Wait for the maintenance bit to set in the UDB.

DISET           [ADDRESS,,DISET]                                [SCHED]
                Wait for contents of ADDRESS to be zero.

DISGET          [ADDRESS ,,DISGET]                              [SCHED]
                Wait for contents of ADDRESS to be positive.

DISGT           [ADDRESS,,DISGT]                                [SCHED]
                Wait for contents of ADDRESS to be greater than
                zero.

DISLT           [ADDRESS,,DISLT]                                [SCHED]
                Wait for contents of address to be less than
                zero.

DISNT           [ADDRESS,,DISNT]                                [SCHED]
                Wait for contents of ADDRESS to be non-zero.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 55
TOPS-20 SCHEDULER TEST ROUTINES


 TEST           CONTENTS OF T1 AT TIME OF SCHEDULER CALL        DEFINED
 ----           ----------------------------------------        -------

DMPTST          [COUNT,,DMPTST]                                 [IO]
                Wait for COUNT to be less than DMPCNT to indicate
                dump mode buffers freed.

DSKRT           [PAGE #,,DSKRT]                                 [PAGEM]
                Wait for CSTAGE for PAGE # to not be PSRIP,
                meaning disk read completed.

DWRTST          [PAGE #,,DWRTST]                                [PAGEM]
                Wait for DRWBIT to clear in CST3(PAGE #),
                meaning write completed.

ENQTST          [FORK #,,ENQTST]                                [ENQ]
                Wait for the lock on ENFKTB+FORK #.

FEBWT           [ADDRESS OF FE UDB,,FEBWT]                      [FESRV]
                Wait for EOF or input bytes available from FE.
                Wake also on invalid assignment.

FEDOBE          [ADDRESS OF FE UDB,,FEDOBE]                     [FESRV]
                Wait for output buffer empty and all bytes are
                acknowledged by the FE.  Wake also if not a 
                valid assignment.

FEFULL          [ADDRESS OF FE UDB,,FEFULL]                     [FESRV]
                Wait for the current count of output bytes to be
                less than the count of bytes in the interrupt
                buffer.  Wake also on invalid assignment.

FORCTM          [SUPERIOR FORK INDEX,,FORCTM]                   [SCHED]
                Identifiable wait forever, forced termination.

FRZWT           [PREVIOUS TEST,,FRZWT]                          [FORK]
                Identifiable wait forever, frozen fork.

HALTT           [SUPERIOR FORK INDEX,,HALTT]                    [SCHED]
                Identifiable wait forever for halted fork.

HIBERT          [TIME,,HIBERT]                                  [SCHED]
                Wait for TIME in BLOCKT format.

HUPTST          [<0:9>TIME<10:17>HOST #,,HUPTST]                [NETWRK]
                Wait for IMPHRT bit set for host or time out in
                BLOCKW form.

IDVTST          [0,,IDVTST]                                     [IMPDV]
                Wait for the lock on IDVLCK to free, lock it.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 56
TOPS-20 SCHEDULER TEST ROUTINES


 TEST           CONTENTS OF T1 AT TIME OF SCHEDULER CALL        DEFINED
 ----           ----------------------------------------        -------

IMPBPT          [0,,IMPBPT]                                     [IMPDV]
                Wait for IMPFLG nonzero, or IBPTIM timer to run
                out, or IDVLCK lock free and output scan needed
                for the IMP.

JB0TST          [TIME,,JB0TST]                                  [MEXEC]
                Wait for JB0FLG set nonzero for explicit request
                or time in BLOCKT form to elapse.

JRET            [0,,JRET]                                       [SCHED]
                Wait forever, interruptible.

JSKP            [0,,JSKP]                                       [SCHED]
                Unconditional skip used to schedule immediately.

JTQWT           [0,,JTQWT]                                      [SCHED]
                Wait for JSYS trap queue.

LCKTSS          [ADDRESS,,LCKTSS]                               [IO]
                Wait for lock at ADDRESS to unlock, lock it.

LKDSPT          [0,,LKDSPT]                                     [STG]
                Wait for room in LDTAB table of directories
                currently locked.
LKDTST          [INDEX INTO LDTAB,,LKDTST]                      [STG]
                Wait for bit in LCKDBT to clear, indicating
                directory unlocked.

LODWAT          [ADDRESS OF STATUS WORD,,LODWAT]                [LINEPR]
                Wait for flag LP%LHC to set in the addressed
                word, indicating loading has completed of the
                VFU or RAM file.

LPTDIS          [UNIT ADDRESS,,LPTDIS]                          [LINEPR]
                Wait for an error condition on the addressed
                unit, or for all buffers cleared and no bytes
                still in the front-end, before finishing close
                operation on the device.

MTARWT          [IORB ADDRESS,,MTARWT]                          [MAGTAP]
                Wait for IRBFA in the IORB to indicate that this
                IORB is no longer active.

MTAWAT          [UNIT #,,MTAWAT]                                [MAGTAP]
                Wait for all outstanding IORBs for unit to be
                finished.

MTDWT1          [UNIT #,,MTDWT1]                                [MAGTAP]
                Wait for the count of outstanding requests on the
                unit to go to one.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 57
TOPS-20 SCHEDULER TEST ROUTINES


 TEST           CONTENTS OF T1 AT TIME OF SCHEDULER CALL        DEFINED
 ----           ----------------------------------------        -------

NCPLKT          [0,,NCPLKT]                                     [NETWRK]
                Wait for lock NCPLCK to free, lock it.

NICTST          [0,,NICTST]                                     [PAGEM]
                Wait for SUMNR less than or equal to MAXNR or
                only one fork in BALSET.

NOTTST          [<0:8>CONNECTION #<9:17>STATE,,NOTTST]          [NETWRK]
                Wait for connection to leave state.

NSPTST          [0,,NSPTST]                                     [NSPSRV]
                Wait for KDPFLG nonzero, indicating KMC11 wants
                service, or MSGQ nonzero, indicating messages to
                process.

NVTNTT          [<0:8>OPTION #,<9:17>LINE #,,NVTNTT]            [TTNTDV]
                Wait for completed NVT negotiation.

OFNLKT          [OFN,,OFNLKT]                                   [PAGEM]
                Wait for OFN unlocked--SPTLKB zero in SPTH(OFN).

PIDWAT          [FORK #,,PIDWAT]                                [IPCF]
                Wait for bit for fork in PDFKTB to set.

RLDTST          [0,,RLDTST]                                     [DTESRV]
                Wait for master DTE running.

SEBTST          [0,,SEBTST]                                     [SYSERR]
                Wait for SECHKF to go nonzero before starting
                Job 0 task to write queued SYSERR entries.

SEEALL          [0,,SEEALL]                                     [TTYSRV]
                Waits for SNDALL to go to zero, indicating the
                send-all buffer available.

SPCTST          [0,,SPCTST]                                     [DTESRV]
                Wait for a node.

SPMTST          [0,,SPMTST]                                     [PAGEM]
                Wait for page in SPMTPG to be on SPMQ or the
                time SPMTIM to expire.

SQLTST          [0,,SQLTST]                                     [IMPDV]
                Wait for the special queues lock SQLCK and lock
                it.

STRTST          [SDB ADDRESS OF STRUCTURE,,STRTST]              [MSTR]
                Wait for the structure lock to be free.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 58
TOPS-20 SCHEDULER TEST ROUTINES


 TEST           CONTENTS OF T1 AT TIME OF SCHEDULER CALL        DEFINED
 ----           ----------------------------------------        -------

STSWAT          [ADDRESS OF STATUS WORD,,STSWAT]                [CDRSRV]
                Wait for flag CD%SHA to come on in the addressed
                word, indicating that cardreader status has
                arrived.

STSWAT          [ADDRESS OF STATUS WORD,,STSWAT]                [LINEPR]
                Wait for flag LP%SHA to set in the addressed
                word, indicating that printer status has
                arrived.

SUSFKT          [FORK #,,SUSFKT]                                [FORK]
                Wait for fork to be on WTLST in either SUSWT
                OR FRZWT.

SWPRT           [PAGE #,,SWPRT]                                 [PAGEM]
                Wait for CSTAGE for PAGE # to not be PSRIP,
                meaning swap read completed.

SWPWTT          [0,,SWPWTT]                                     [PAGEM]
                Wait for NRPLQ nonzero.  Increment CGFLG each
                time test is unsuccessful.

TCIPIT          [FORK #,,TCIPIT]                                [TTYSRV]
                Waits for no interrupts pending for FORK #.

TCITST          [LINE #,,TCITST]                                [TTYSRV]
                Wait for line inactive, no fork in input wait,
                or input buffer non-empty.

TCOTST          [LINE #,,TCOTST]                                [TTYSRV]
                Wait for line inactive, or output buffer not
                too full to add a character to it.

TRMTS1          [0,,TRMTS1]                                     [FORK]
                Identifiable wait forever for inferior fork termination.

TRMTST          [FORK #,,TRMTST]                                [FORK]
                Wait for FORK # to be on WTLST for either HALTT
                or FORCTM.

TRP0CT          [MINIMUM NRPLQ,,TRP0CT]                         [PAGEM]
                Wait for NRLPQ to be above stated minimum or
                normal minimum.  Increment CGFLG each time
                test is unsuccessful.

TSACT1          [LINE #,,TSACT1]                                [TTYSRV]
                Wait until line inactive, becoming active, or
                has a full length dynamic block assigned.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 59
TOPS-20 SCHEDULER TEST ROUTINES


 TEST           CONTENTS OF T1 AT TIME OF SCHEDULER CALL        DEFINED
 ----           ----------------------------------------        -------

TSACT2          [LINE #,,TSACT2]                                [TTYSRV]
                Wait for line available--inactive or fully
                active.

TSACT3          [LINE #,,TSACT3]                                [TTYSRV]
                Wait for line inactive--dynamic data unlocked.

TSTSAL          [0,,TSTSAL]                                     [TTYSRV]
                Wait for SALCNT to go to zero, indicating the
                send-all is finished for this buffer.

TTBUFW          [NUMBER,,TTBUFW]                                [TTYSRV]
                Wait for NUMBER of buffers.

TTIBET          [LINE #,,TTIBET]                                [TTYSRV]
                Wait for line inactive or input buffer empty.

TTOAV           [LINE #,,TTOAV]                                 [TTYSRV]
                Wait for line inactive and output buffer not
                empty.

TTOBET          [LINE #,,TTOBET]                                [TTYSRV]
                Wait for line inactive or output buffer empty.

UDITST          [0,,UDITST]                                     [PHYSIO]
                Wait for at least two free IORBs on UIOLST.

UDWDON          [IORB ADDRESS,,UDWDON]                          [PHYSIO]
                Wait for IS.DON to set in IRBSTS for this IORB.

UPBGT           [CONNECTION INDEX,,UPBGT]                       [IMPDV]
                Wait for LTDF connection done flag to set, or
                output buffers to appear.

USGWAT          [0,,USGWAT]                                     [JSYSA]
                Wait for lock on queued USAGE blocks to free.

VVBWAT          [UNIT #,,VVBWAT]                                [TAPE]
                Wait for the MDA to reset TPVV handling EOV.

WATTST          [<0:8>CONNECTION #<9:17>STATE,,WATTST]          [NETWRK]
                Wait for connection to be in state.

WTFKT           [FORK #,,WTFKT]                                 [FORK]
                Wait for fork to be on WTLST.

WTSPTT          [PAGE #,,WTSPTT]                                [SCHED]
                Wait for share count on PAGE # to go to 1.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 60
TOPS-20 PAGE ZERO LOCATIONS




                      TOPS-20 PAGE ZERO LOCATIONS
                      ---------------------------




     The following text outlines the uses of memory in page zero of  the
TOPS-20 monitor as of Release 5.


ADDR   MNEMONIC USAGE
====   ======== =====

  0-17    --    Shadow ACs, not used.

 20     SCTLW   Scheduler halt request word (see SWTST in SCHED).   Word
                 of   function  bits,  current  functions  include  Halt
                 timesharing, wait for system down,  manual  pause,  and
                 reset FE protocol.

 21       --    Used by BOOT to build CCW lists (unused by monitor).

 22       --    Same as 21;  both unused for KS10 systems.

 23     CRSHTM  Initial time for  reload;   -1  =>  time  not  set  yet.
                 Contains   the  date/time  that  the  system  was  last
                 reloaded.   May  see  -1  after  forced  reload  on  KS
                 processor.   BUGSTO  (APRSRV) copies TADIDT into it for
                 each BUGHLT/CHK/INF.

 24     SEBQOU  Pointer to queued SYSERR blocks not yet written.

 25     MMAPWD  Pointer to MMAP for SETSPD.  Contains MMAP.

 26     BUGHAD  Code around SYSLD1 (STG) puts LH into  BUGCHK,  RH  into
                 BUGHLT  after  a  reload.   No  one else uses it, so it
                 should contain zero.

 27     CRSTD1  Current time is saved here on each BUGHLT/CHK/INF.  This
                 is the value that gets into the SYSERR block.  Contains
                 the   date/time   for   the   system's   most    recent
                 BUGHLT/CHK/INF.

 30     SHLTW   Scheduler  halt  word,  depositing  a  nonzero  contents
                 requests system shutdown.

 31     RLWORD  KS  only;   used  for  front-end  communication,  flags,
                 keep-alive, etc.  (see PROKS).  Unused on KL.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 61
TOPS-20 PAGE ZERO LOCATIONS


 32     CTYIWD  KS only;  used for front-end communication, used for the
                 CTY input location.  Unused on KL.

 33     CTYOWD  KS only;  used for front-end communication, used for the
                 CTY output location.  Unused by KL.

 34     KLIIWD  KS only;  used for front-end communication, used for the
                 KLINIK input location.  Unused by KL.

 35     KLIOWD  KS only;  used for front-end communication, used for the
                 KLINIK output location.  Unused by KL.

 36       --    Unused/reserved.  Holds KS RHBASE during boot.

 37       --    Unused/reserved.  Holds KS unit number during boot.

 40     .JBUUO  Monitor's location 40.  Holds KS tape info during boot.

 41     .JB41   Monitor's LUUO dispatch word.
                 Contains XPCW LUUBLK.

 42-43    --    Unused/reserved.

 44     .JBREL  Job Data Area word filled in by LINK.  Contains 777.

 45-67    --    Unused/reserved.

 70     PWRTRP  Location executed by the front-end on powerfail restart.
                 Contains JRST PWRRST.

 71     RLDADR  Executed  by  the  front-end  on  certain   (keep-alive)
                 reloads.   APRSRV  demands  this  location be PWRTRP+1.
                 Contains XPCW RLODPC which winds up  at  RLDHLT  for  a
                 KPALVH BUGHLT.

 72       --    Contains address of EDDTF word.

 73     CRSTAD  Is supposed to contain date/time of last crash.  Code in
                 STG  checks  it  to  decide  to  restore  the data from
                 BUGHAD.  During system startup for KL-10s the  word  is
                 used   to   set   the   reload  date/time  if  nonzero.
                 Apparently it gets no real  use  on  KS-10s.   Contains
                 zero while system is in normal operation.

 74     .JBDDT  JOBDDT location.
                 Contains DDT (EDDT entry point).

 75     .JBHSO  Unused/reserved.

 76       --    Contains address of DBUGSW word.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 62
TOPS-20 PAGE ZERO LOCATIONS


 77       --    Contains address of DCHKSW word.

100-107   --    Reserved for use by the front-end command language.

110     STSBLK  KL-Status block pointer, virtual address.  Contains zero
                 if status reporting is not enabled.

111       --    Physical address (MAP) of above virtual address.

112     .JBEDV  Pointer to Exec Data Vector
                 Contains MONEDV.

113-114   --    Unused/reserved.

115-117   --    Unused/reserved.

120     .JOBSA  TOPS-10 style start address.
                 Contains NPVARZ+1,,EVGO.

121     .JBFF   Contains first free address not loaded by LINK.
                 Contains NPVARZ+1.

122-132   --    Unused/reserved.

133     .JBCOR  Job Data Area location set by LINK.  LH contains highest
                 low  segment  address loaded with data.  RH refers to a
                 SAVE argument for highest page.

134-136   --    Unused/reserved.

137     .JBVER  Job Data Area version number word.
                 Contains current monitor version number.

140     EVDDT   Monitor startup transfer vector;  enter EDDT.
                 Contains JRST DDTX.

141       --    Reset and go to EDDT location.
                 Contains JRST SYSDDT.

142     EVDDT2  Copy of 140.
                 Contains JRST DDTX.

143     EVSLOD  Entry to initialize file system, used for installation.
                 Contains JRST SYSLOD.

144     EVVSM   Entry to verify swappable monitor on startup.
                 Contains JRST SYSVSM.

145     EVRST   Restart the system location.
                 Contains JRST SYSRST.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 63
TOPS-20 PAGE ZERO LOCATIONS


146     EVLDGO  Reload and start the system location.
                 Contains JRST SYSGO.

147     EVGO    Start the monitor location.
                 Contains JRST SYSGO1.

150     DDTPRS  DDT present flag;  EDDT is present if nonzero.
                 Contains -1 initially, cleared later for EDDTF not set.

151     BUTRXB  Defined in BOOT and STG but not  used  (BOOT  reads  the
                 disk   address  of  the  Root-directory  from  the  HOM
                 blocks).  Contains zero.

152     BUTMUN  Defined in BOOT and STG but not  used  (BOOT  reads  the
                 values  from  the  HOM blocks, and uses variable MAXUNI
                 instead).  Contains zero.

153-162 BUTDRT  Defined in BOOT and STG but not used (BOOT uses internal
                 variable  DSKTAB  for  logical  to  physical  structure
                 mapping).  Contains zeros.

163-201 BUTCMD  ASCIZ file  name  of  monitor;   used  for  booting  the
                 swappable monitor with calls to VBOOT for segments.

202     BUTPGS  Start,,End virtual addresses of VBOOT  pages.   Used  to
                 reference and finally unlock/destroy VBOOT pages.

203     BUTEPT  Contains in LH:  Address of the VBOOT EPT page.
                 RH:  Address of the VBOOT page table page.

204     BUTPHY  Contains in LH:  Minus number of pages to map.
                 RH:  Address of first page to map  (for  the  monitor).
                 Typically contains -6,,NPVARZ for four pages of code, a
                 file data page and an index block page.  Used with  the
                 value in BUTVIR.

205     BUTVIR  Virtual address of first page of BOOT to map.  Typically
                 will contain 772000.  Used in conjunction with BUTPHY.

206     BOOTFL  BOOT flags word, 0 => normal, nonzero =>  special  boot.
                 The  contents  is supposed to be the index into a table
                 (BOOTD) designating how to boot the swappable  monitor.
                 An ILBOOT BUGHLT results if the index is too large.  In
                 the SYSGO routine the value IRBOOT is put into  BOOTFL;
                 the table BOOTD contains entries of JRST GSMDSK for all
                 entries but the IRBOOT offset, which has JRST GSMIRB.

207-236 PHYPZS  Formerly  used  for  page  zero  I/O  use   by   PHYSIO.
                 Currently unused, contain zero.

237-777   --    Not used, contain zero.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 64
KNOWN HARDWARE DEFICIENCIES LIST


                    Known Hardware Deficiencies List
                    --------------------------------



This is a collected list of known hardware characteristics which show up
from  time  to  time  as  part  of certain reported problems.  This says
nothing about whether these characteristics are  bugs  or  features,  or
whether  they will ever be fixed or changed, but merely attempts to make
them known internally.




     1.  DZ11 - Cannot set the speed to zero in the hardware,  can  only
         turn off the receiver.

     2.  TM02 - Can generate bad parity which it  passes  to  memory  to
         cause  the  system  memory  parity  errors  when  the  data  is
         referenced.  This is still seen with Rev 12 to the RH20.

     3.  TM03 - A chip race condition has been known to  occur  where  a
         function  register  has wrong value because it has not settled.
         This generates a device error which  appears  transient;   i.e.
         CRLFing DUMPER tries the read again and succeeds.

     4.  TM03 - ANSI ASCII was  not  included  in  the  hardware  format
         modes.   The  TM03  does  not set format error if ANSI ASCII is
         selected.  It will usually get a frame error;  if the  transfer
         is  a  multiple  of  7/8  bit bytes, the frame error is not set
         either.

     5.  TM03 - When using industry-compatible  mode,  reads  not  of  a
         multiple of four bytes will produce strange results.  The bytes
         are counted, but the extra bytes are  not  written  to  memory,
         leaving garbage.

     6.  TM03 - if an error ocurs while rewinding, the  monitor  may  be
         left in a state of waiting for the rewind to complete, the tape
         being unusable.  The easiest way to clear this condition is  to
         reset the TM03, most easily done by the customer by powering it
         down and back up.

     7.  TM03 - if the TM03 loses synch during the  PE  preamble  bytes,
         and  it  reaches  9,  it  will  raise  the postamble instead of
         generating the proper error.  This can result in lost  records.
         The  usual  symptom  is  a  frame  count  error.   This case is
         recognizable by the residual frame count being the same as  the
         initial frame count.

     8.  VT100 - on a VT100 without the extended memory, one can confuse
         the  internal  microprogram enough to have it clear sections of
         the screen on Control-U, Control-R, "clear to end of screen" in
         132 column mode, etc.  
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 65
KNOWN HARDWARE DEFICIENCIES LIST


     9.  RH20 - perfectly willing to store bad parity data  into  memory
         until Rev 12.  May still do so.

    10.  DX20 - is unwilling to allow registers to be examined after  it
         has  started  I/O.   Can  cause  register  access errors if not
         programmed in correct sequence.

    11.  DX20 - there is a race type condition where the DX20  generates
         an  an  interrupt  request on channel 5 for some condition, but
         the code is playing with the DX20 and handles the condition, so
         it lowers its request, however the KL has latched the interrupt
         and tries to process it, but no one will respond.  So it  tries
         the 40+2n type, which gives a PI5ERR occasionally.

    12.  DX20/TU71 - the DX20 microcode does not set the 556 bpi density
         correctly   for   TU71  (7-track)  drives.   This  can  be  set
         successfully from the maintenance panel.

    13.  DX20/TX03 - With dual-porting between systems,  if  the  system
         issues a drive clear to the DX20 during serious error recovery,
         or when booting the DX, the DX  resets  the  TX03.   The  reset
         traps  the  TX03  to  zero,  leaving any operation on the other
         channel in a hung state.

    14.  DX20/TX03- when dual-porting between  systems,  DX2FGS  BUGCHKs
         occur.  The DX2FGS timer in TOPS-20 has been made larger.  This
         should lessen the occurence  of  these  BUGCHKs,  but  may  not
         eliminate them entirely.

    15.  LP20 - at least one of the printers fails to go  off-line  when
         there  is  anything  in the print line buffer, even if the drum
         gate is opened.

    16.  LP26 - fails to go offline when there is something left in  the
         print  line buffer.  When it runs out of paper, it goes offline
         several lines from the actual bottom of the page.

    17.  RP20 - when using the dual-port option, RP20s regularly lose  a
         full  rotation  when  trying  to do read/write next operations.
         This happens about once every ten seconds and  will  result  in
         slightly degraded performance.

    18.  RP20 - may evidence RMR (register modification refused)  errors
         due  to  a limp servo mechanism on one of the drives.  Multiple
         queued  operations  complete  before  the   drive   disconnects
         properly and sets GO correctly for the controller to handle the
         write.  

    19.  KL10 Microcode - the ADJBP instruction does  not  work  on  the
         last location of a page.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 66
KNOWN HARDWARE DEFICIENCIES LIST


    20.  KS-10 Front End - Rev.  3.  exhibits problems with  the  KLINIK
         line.   If  the  link is in use, it is possible to lock out the
         CTY.  There are problems with the password check on  subsequent
         tries, and problems with line hang-up.  A software fix has been
         implemented which clears the KLINIK output word after  queueing
         the KLINIK request.  This appears to solve the problems.

    21.  KS-10 Front  End  -  Rev.   3.   exhibits  some  problems  with
         powerfail  restart.   If  the  power  returns  in less that 3.5
         seconds or so the restart will hang.  In addition  if  Rev.   3
         and  Rev.  2 boards are mixed, there is no powerfail restart or
         reload capability.

    22.  KS10 - during a forced reload, the halt status block is written
         twice,  first when halting and second when rebooting;  thus the
         second time wipes any valuable data from the first time.   It's
         once again the 8080 that's responsible.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 67
KS10 PROCESSOR CONSOLE INFORMATION


                   KS10 PROCESSOR CONSOLE INFORMATION
                   ----------------------------------



CSL-COMMANDS CURRENTLY IMPLEMENTED (CSL V0.161)


^Z      ;enter USER mode
^\      ;enter CONSOLE mode
MK XX   ;Marks microcode word at CRAM address XX (sets bit 95)
UM XX   ;Unmarks Microcode at CRAM address XX
MB      ;load only bootstrap of currently selected magtape
LA XX   ;Load/set KS10 Memory Address
LI XX   ;Load/set I/O address
LK XX   ;Load/set 8080 address
LC XX   ;Load/set CRAM address to be written/read
EM      ;Examine KS10 Memory (last Memory location specified)
EM XX   ;Examine KS10 Memory location XX
EN      ;Examine Next (either from last EK, EM or EI)
EB      ;Examine BUS and 8080 control registers
EI      ;Examine I/O (last I/O address specified)
EI XX   ;Exmaine I/O address XX
EK      ;Examine 8080 location
EK XX   ;Examine 8080 address XX
DM XX   ;Deposit KS10 Memory last addressed, XX data (36 bits)
DN XX   ;Deposit next (depending on last DK, DM or DI) XX data
DB XX   ;Deposit BUS, XX data (36 bits)
DI XX   ;Deposit I/O, XX data (16,18 or 36 bits)
DK XX   ;Deposit XX (8 bits) into 8080 (Data can only be deposited
        ;in RAM addresses)
MR      ;MASTER RESET
CS      ;CPU clock start
CH      ;CPU clock halt
CP XX   ;CPU clock pulse (XX=NR of pulses -- default 1 pulse)
SI      ;Single Instruction
LF XX   ;Load diagnostic write function (0-7) specifying 12 bits of
        ;microcode (see note at end ****)
DF XX   ;Deposit Field, write microcode bits according to last LF-command
EC      ;Examine CRAM ..curr. Control reg, no clocks .. current loc as addr.
EC XX   ;Examine CRAM at address XX
DC XX   ;Deposit CRAM, XX is at least 32 octal characters. Address 
        ;previously loaded by LC command
EX XX   ;EXecute KS10 instruction XX
ST XX   ;STart KS10 at address XX. Console enters user mode
SM XX   ;Start microcode at XX (SM 1 causes dump of HALT-status block !!) 
        ;Default is 0 -- Start microcode
HA      ;HALT KS10 (execute HALT-instruction -- causes microcode to
        ; write HSB and then to enter HALT-loop)
SH      ;SHUTDOWN (deposit non-zero data in memory location 30)
        ; causing TOPS20 to shut down
CO      ;Continue (causes microcode to leave HALT-loop)
PE X    ;Parity Enable (0=disable, 1=DRAM-par, 2=CRAM-par
        ; 4=clock-par error stop, 5=DPE/DPM, 6=CRA/CRM, 7=enable all)
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 68
KS10 PROCESSOR CONSOLE INFORMATION


CE X    ;CACHE enable (0=OFF, 1=ON, <CR>=show current state)
TE X    ;CPU timer (1 MSEC) enable (0= OFF, 1=ON, <CR>=show current state)
TP X    ;CPU TRAPS enable (0=OFF, 1=ON (enables paging),
        ;<CR>=show current state)
LT      ;Lamp Test, lights three lamps of front panel
RC      ;Read CRAM direct, functions 0-17
        ; (no resets, no load diag adr, no CPU clock) (see note at end ****)
EJ      ;Examine Jumps -- prints CRAM address signals (Current CRAM address, 
        ;next CRAM address, jump address, subroutine return address)
TR XX   ;TRACE - repeats CP and EJ commands until any character typed
        ;XX (if typed) is desired CRAM stop-address
PM      ;Pulse Microcode (issue single CP and EJ)
ZM      ;Zero KS10 MOS Memory (beware -- slow)
RP      ;Repeat - repeats last command, or line of commands which it delimits
        ; Any character (except CNTRL-O) typed will stop repeat
        ;EXAMPLE: EM 0, EK 0, EC 0, RP will repeat execution of this line
BT      ;Boot SYSTEM -- load CRAM from designated disk (see DS)
        ; via memory then load monitor boot from disk and start at 1000
BT 1    ;same as BT, but loads diagnostic monitor SMMON and starts at 20000
LB      ;Load Bootstrap from designated disk (see DS)
LB 1    ;Load Bootstrap diagnostic monitor SMMON
DS      ;Disk Select for bootstrap or microcode verification. Command prompts 
        ;to specify UNIT NUMBER (default 0), RHBASE (default 776700), 
        ;and UNIBUS ADAPTER (default 1) to load from when booting
MS      ;Magtape Select for bootstrap or microcode verification. Command 
        ;prompts to specify UNIT NUMBER (default 0), RH BASE (default 772440),
        ;UNIBUS ADAPTER (default 3), SLAVE NUMBER (default 0), and 
        ;DENSITY (default 1600 BPI) of magtape to boot from
MT      ;Magtape Boot system from selected magtape
MT 1    ;BOOT diagnostic monitor SMMAG from magtape
PW      ;clears KLINIK password, or sets it (6 char's max)
BC      ;BOOT Check. PROM code which tests the basic 2020 system
        ; load path from the UNIBUS adaptor into the CRAM via memory.


CONTROL CHARACTERS
^U      ;rub out current line
^O      ;switch: first one stops CTY-output, second one resumes CTY-output
^S      ;stop TTY-output and hangs 8080 waiting for CONTROL-Q (see below)
^Q      ;resumes TTY-output
^C      ;stops whatever the 8080 is doing
RUB-OUT ;rub out previous character typed

NOTE:    Several commands may be put on a single line, separated by commas.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 69
KS10 PROCESSOR CONSOLE INFORMATION



*****   CRAM Bit Formats

        LF-Command CRAM Bits            RC-Command CRAM Data
        --------------------            ---------------------

        LF      CRAM bits               RC      Data
        --      ---------               --      ------------------------------

        0       00-11                   0       CRAM bits 00-11
        1       12-23                   1       Next CRAM address
        2       24-35                   2       CRAM subroutine return address
        3       36-47                   3       current CRAM address
        4       48-59                   4       CRAM bits 12-23
        5       60-71                   5       CRAM bits 24-35 (Copy A)
        6       72-83                   6       CRAM bits 24-35 (Copy B)
        7       84-95                   7       0s
                                        10      Parity bits A-F
                                        11      KS10 bus bits 24-35
                                        12      CRAM bits 36-47 (Copy A)
                                        13      CRAM bits 36-47 (Copy B)
                                        14      CRAM bits 48-59
                                        15      CRAM bits 60-71
                                        16      CRAM bits 72-83
                                        17      CRAM bits 84-95
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 70
KS10 PROCESSOR CONSOLE INFORMATION


8080-CONSOLE-ERROR-CODES
------------------------


?BUS            BUS polluted on power-up
?BFO            Input Buffer Overflow
?IL             ILLEGAL Instruction
?UI             Unknown Interrupt
?A/B            A and B copies of CRAM bits did not match
?DNF            Did Not Finish instruction
?BT             device error or timeout during BOOT operation
?DNC            Did Not Complete HALT
?PAR ERR        report clock-freeze due to parity error,
                 and type out READ IO of 100,303,103
?RE             memory Refresh Error (MEM BUSY stayed set too long,
                 because it didn't release data on a write to memory)
?CHK            PROM checksum failed
?BC             BOOT Check failed
?RUNNING        CPU clock running (command typed requires clock to be stopped
                 and may fail)
?NDA            received No Data Acknowledge on memory request
?NXM            referenced NoneXistent Memory location
?NBR            Console was not granted BUS on a request
?RA             command Requires Argument
?BN             received Bad Number on input (character typed is not an 
                 octal number
?KA             KEEP ALIVE failed
?FRC            had a forced reload
?PWL            Password Length error
?IA             Illegal Argument (address out of range, etc.)


OTHER 8080 CONSOLE MESSAGES
---------------------------

BUS 0-35                message header for EB command
KS10>                   prompt message
CYC                     cycle type for DB command
SENT                    data sent to bus
RCVD                    data received on bus
HLTD                    message "HALTED/XXXXXX " where xxxxxx is data
BT SW                   message says BOOTING, using BOOT switch
OFF                     message, says current state is off
ON                      message, says current state is on
>>UBA?                  query for UNIBUS adapter
>>UNIT?                 query for unit to use
>>RHBASE?               query for RH11 base register address to use
>>DENS?                 query tape density
>>SLV?                  query tape slave number
C CYC                   typed on DB-command if COM/ADR cycle blew
D CYC                     "             "      DATA    cycle blew
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 71
KS10 PROCESSOR CONSOLE INFORMATION


8080-ERROR-Messages-during-BOOTING
----------------------------------


Disk:
        On an error-condition, detected by the 8080, the
        Fault-light will go on and a message of the form

                ?BT XXXYYY

        will be printed on the CTY.


The following error-codes are only "rough" pointers, they can be
caused by any of the following problems:

        Disk not a disk at all
        Wrong unit selected (see DS-command)
        Home blocks not readable or not there
        Home blocks not set by SMFILE for 8080
        8080 File-system garbage

XXX=001 Disk error encountered while trying to read HOME-blocks
        Can mean incorrect RHBASE specified, wrong UBA selected,
        bad disk drive, neither  home block or alternate home
        block has home block ID ("HOM" in sixbit)

XXX=002 Disk error encountered while trying to read the page of
        pointers, which make up the "8080-File-System"
        Can mean pack is not in format for 8080 loading, home blocks
        bombed, bad drive or pack

XXX=003 Disk error encountered while trying to read a page of
        microcode - can mean pack is not in 8080 format, or bad drive or 
        pack

XXX=004 Microcode did not successfully start running after a BT, MT,
        MB, or LB command.  This error will occur when an LB is done
        before the system microcode is loaded.
        
XXX=010 Disk error encountered while trying to read PRE-BOOT

YYY     are the lower 8 bits of the 8080 address of the failing
        "Channel Command List" operation. Normally it is here
        a good bet to do an "EI" to get the contents of the
        RH11 register that has the error-bits set !
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 72
KS10 PROCESSOR CONSOLE INFORMATION




Magtape:

The following ERROR-messages can point to the following problem areas:

        Magtape is no magtape at all
        Wrong unit selected (see MS-command)
        Magtape is not bootable (no microcode, no PRE-BOOT)

XXX=001 Error trying to read microcode first page
        Can mean wrong unit selected, wrong RHBASE address, wrong UBA
        selected, wrong slave number, wrong density, bad drive, bad
        controller, bad tape, tape in wrong format

XXX=003 Error trying to read additional pages of microcode

XXX=010 Error trying to read in PRE-BOOT program
        May occur while doing a skip over the microcode file, or
        while reading the PRE-BOOT itself

YYY     see above (disk-section)



Error-messages-out-of-PRE-BOOT


PRE-BOOT is loaded from Disk or Magtape (see 8080 commands DS, MS,
         BT, BT 1, MT, MT 1)

PRE-BOOT is written onto the disk using "SMFILE.EXE", it also is written on
"standard" Diagnostic-tapes  and onto the "MONITOR-INSTALLATION"-tapes.

PRE-BOOT is loaded by the 8080 into MEMORY-locations 1000 and up, and starts
at 1000.  The ERROR-halts are:

        1001    found "bad" core-transfer address
                 (page 1 is illegal - can't overload PRE-BOOT)
        1003    No RH11 Base Address
        1004    Magtape Skip failure
        1002    Disk Retry error or Magtape Read error

At ERROR-halt time the following MEMORY-Locations contain the useful INFO :


                Disk-Booting                    Magtape-Booting
                ------------                    ---------------

        100     "8080" disk-address             Not used
        101     Memory transfer address         same
        102     T3, selection pickup pointer    same
        103     RPCS1-register                  MTCS1-register
        104     RPCS2-register                  MTCS2-register
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 73
KS10 PROCESSOR CONSOLE INFORMATION


        105     RPDS - register                 MTDS - register
        106     RPER1-register                  MTER1-register
        107     RPER2-register (RP06 only)      Not used
        110     RPER3-register                  Not used
        111     UBA Page RAM loc 0              same
        112     UBA-status register             same
        113     Version Nr. of PRE-BOOT         same

        Note: The Version Nr. of PRE-BOOT will be the same as the Version Nr.
        of SMFILE. The "8080" disk-address is in the form " CYL SEC SURF "


THEREBY IT WILL BE POSSIBLE TO ASK A CUSTOMER WITH A PRE-BOOT FAILURE,
TO DO AN :

        EM 77
        EN,RP
        ...... AND TYPE SOMETHING AFTER ADDRESS 115
        ...... AND THEN TELL US WHAT HE SEES
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 74
KS10 PROCESSOR CONSOLE INFORMATION



8080-Communication-Area (KS10 Memory)
-------------------------------------


The 8080 maintains and services an in-core communication area.
Currently used are words 31 to 40.  See PROKS.MAC for more info.

Word Nr.                Meaning
---- ---                -------
  31            Keep Alive and Status word
  32            KS-10 CTY input word (from 8080)
  33            KS-10 CTY output word (to 8080)
  34            KS-10 KLINIK user input word (from 8080)
  35            KS-10 KLINIK user output word (to 8080)
  36            BOOT RH-11 Base Address
  37            BOOT Drive Number
  40            Magtape Boot Format and Slave Number


Word 31         Keep Alive and Status word
---- --
Bit 4           Reload Request
Bit 5           Keep Alive active
Bit 6           KLINIK active
Bit 7           PARITY Error detect enabled
Bit 8           CRAM Parity Error detect enabled
Bit 9           DRAM Parity Error detect enabled
Bit 10          CACHE enabled
Bit 11          1 msec enabled
Bit 12          TRAPS enabled
Bit 20-27       Keep Alive counter field
Bit 32          BOOT SWITCH BOOT
Bit 33          POWER FAIL
BIT 34          Forced RELOAD
BIT 35          Keep Alive failed to change


Word 32         KS-10 CTY input word (from 8080)
---- --
Bits 20-27      0 -- no action, 1 -- CTY character pending
Bits 28-35      CTY-character


Word 33         KS-10 CTY output word (to 8080)
---- --
Bits 20-27      0 -- no action, 1 -- CTY character pending
Bits 28-35      CTY-Character


Word 34         KS-10 KLINIK user input word (from 8080)
---- --
Bits 20-27      0 -- no action, 1 -- KLINIK character,
                2 -- KLINIK active, 3 -- KLINIK carrier loss
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 75
KS10 PROCESSOR CONSOLE INFORMATION


Bits 28-35      KLINIK-Character


Word 35         KS-10 KLINIK user output word (to 8080)
---- --
Bits 20-27      0 -- no action, 1 -- KLINIK character, 2 -- Hangup request
Bits 28-35      KLINIK-Character




OUTPUT process KS10 ==> 8080
----------------------------

 Load character and flag into  33,   set 8080-interrupt,   8080 examines
   33 and gets character, clears interrupt, sends character to hardware,
   clears 33 and sets KS-10 interrupt.

INPUT process 8080 ==> KS10
---------------------------

 8080 gets interrupted "TTY-char available",   8080 gets character and
  delivers into input-word (31) with flag(s) and sets KS-10 interrupt.




***NOTE: Additional information on KS10 console commands can be found 
         in the KS10 MAINTENANCE GUIDE
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 76
BOOT COMMAND STRING FUNCTIONALITY


                   BOOT COMMAND STRING FUNCTIONALITY
                   ---------------------------------



The BOOT program is usually invoked in one of two ways:  invisibly  as
part  of a system dump and reload on a crash condition, or by explicit
invocation and response to the BOOT> prompt,  usually  with  a  simple
carriage return.

BOOT,   however,   possesses   substantially   more    command    line
functionality,  at least some of which can be useful to the Specialist
in a debugging situation.  This document tries to explain some of that
functionality in the context of the BOOT for Release 5 of TOPS-20.

BOOT parses a command string of the form:

device:<directory>file.extension.generation/switchaddress(lower,upper)

with  the  restrictions that some switches have precedence and so some
combinations are meaningless, and that the directory  must  NOT  be  a
subdirectory, i.e.  <SYSTEM> is legal, but <SYSTEM.MONITORS> is not.

The "default" command string (in response to a simple carriage return)
is:   PS:<SYSTEM>MONITR.EXE/R  -  i.e.   load  and  start the resident
monitor.

The available switches are:

  /M    MERGE - merge specification with current memory.

  /L    LOAD  -  load  according  to  specification   (suppresses
          default startup).

  /A    ALL - load all of specified  file,  useful  for  avoiding
          bounds values;  loads up to page 377.

  /R    RUN - run specification - this is the default.  Load  and
          start  at  the  EXE  file entry vector location.  If no
          (firstpage,lastpage) specification is given, then  BOOT
          will look in .JBSYM for the last location of the symbol
          table and load up to that point (this assumes that this
          is  the  last  location  in  the resident monitor).  If
          .JBSYM is zero, or there is no page zero  in  the  .EXE
          file  to  find it in, then the old assembled-in default
          of (0,340) will be used.

  /D    DUMP - dump on given specification.  The default here  is
          PS:<SYSTEM>DUMP.EXE.1 but other existing files could be
          used, e.g.  if the normal dump file  kept  causing  the
          dump to fail with ?IO Error because of bad pages or was
          too small, etc.  one could do something like:
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 77
BOOT COMMAND STRING FUNCTIONALITY


            BOOT>JUNK:<DUMPS>DEBUG.EXE.1/D
            BOOT>

          BOOT has  special  address  space  knowledge  which  it
          applies  to  writing out the monitor dumps, such as not
          writing out pages overwritten by BOOT, etc.

  /S    SAVE - similar to /D, but no special  knowledge  applied,
          saves  according  to  specification.  Useful for things
          like saving image of BOOT for debugging.

  /Gadr GO - transfer control to location adr;  for example /G141
          to invoke EDDT.

  /E    EDDT - load and transfer to EDDT.  This  is  a  shorthand
          method  for  the  old  two command sequence of /L, then
          /G141;  e.g.

            BOOT>NEWMON/E
            EDDT

  /I    INFORMATION - displays the current version  of  BOOT  and
          the  version  numbers  of  any DX20A or DX20B microcode
          assembled into BOOT.


The monitor uses the (lowerbound,upperbound) construct in loading  the
swappable  monitor  in  multiple  passes  into  the available physical
memory by building the appropriate command string to  merge  the  next
set  of  pages  and  invoking  BOOT  at the VBOOT entry point multiple
times.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 78
CRASH ANALYSIS


                              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  be
copied into DUMP.CPY by SETSPD after the system is reloaded.  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 <ENABLE> <DISK> on the console.  See the
Operators Guide for  a  discussion  of  the  meaning  of  the  various
switches on the DEC-20.

It is possible to give a FILENAME/D to BOOT to specify where  to  dump
the  monitor, so it is possible to put up another pack, or whatever to
get a dump for those situations where there is no existing DUMP.EXE on
the  pack  to  dump into.  The filename given must exist however.  The
distributed MAKDMP program can be run during timesharing to  create  a
DUMP.EXE of the proper size for the system, or any other method may be
used to pre-create a file of the necessary size, which is one page per
page  of  memory, plus enough pages to hold the EXE file directory for
the dump  (generally  one),  minus  the  number  of  pages  that  BOOT
overwrites, and which will not be present in the dump.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 79
CRASH ANALYSIS


                             CRASH ANALYSIS
                             --------------



First when analyzing 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 (or SPEAR) manual.

     5.  A listing of  the  SYSERR  log,  especially  if  hardware  is
         suspected.

     6.  The 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
         Managers Guide, etc.

     8.  The BUGS.MAC file.

     9.  The TOPS-20.BWR file.


You will need the SWSKIT 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
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 80
CRASH ANALYSIS


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 few 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.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 81
CRASH ANALYSIS


                         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 four 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.  FILDDT used to examine dumps.


All the DDT's are versions of TOPS-20 DDT documented  in  the  TOPS-20
DDT manual, and have all of the features described in the manual.  See
also the document DDT41.MEM.

The use of all four versions of the DDT's is  the  same  and  will  be
described later, however, each version is started differently.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 82
CRASH ANALYSIS


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	or on Release 4 systems, @DDT

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 in order to save the monitor back
in <SYSTEM>.  This is the safest, best, and only recommended method of
putting patches into the monitor.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 83
CRASH ANALYSIS


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 to 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 the system since it will be executing a  JSR  to  a  page
full of zeros.

To use MDDT you must have WHEEL or OPERATOR capabilities.   You  first
issue the EXEC command:

	@ENABLE
	$^EQUIT

		; You are now in the mini-exec and receive 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
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 84
CRASH ANALYSIS


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

MDDT may also be entered from process level via JSYS:

	JSYS 777$X
	    or
	MDDT%$X	; will enter MDDT from the context of the current process

If you wish to examine the system from the EXECs inferior fork monitor
context:

	@ENA
	$SDDT
	DDT

	JSYS 777$X
	MDDT

To return to user context:

	MRETN$G

Use SETMPG to map pages to this context:

	page 677 has been traditionally used for this;
	but any unused page may be used.  To make sure that the page
	is currently unused type:

	ADDRESS/   ?	; the question mark from DDT indicates that the
			; page is nonexistent.

	when the destination page has been found, set up AC2 as:

	AC2/ ACCESS,,677000

	If the page has its own SPT slot:

	AC1/SPT INDEX

If  the  source 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:
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 85
CRASH ANALYSIS


	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
	AC2/140000,,677000

		or

	AC1/SPT INDEX OF PAGETABLE,,INDEX INTO PAGE TABLE
	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.


NOTE:  if you have the Release 5 version of MDDT/EDDT that has  sticky
current address section (see DDTxx.MEM) then be careful about doing an
MRETN$G after examining  section  2,  as  a  crash  will  result  from
transferring to MRETN in section 2.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 86
CRASH ANALYSIS


EDDT:
----



                                 NOTE

               Not to be confused with  ^EEDDT  command
               to  get  into UDDT used with the command
               processor.   See  separate  document  on
               EXEC DEBUGGING for that.



To  get  into  EDDT  you  must  bring  the   system   up   using   the
switch-register.    See   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"  starts  the  monitor at location 141, which is a jump to
EDDT.  You can use EDDT like UDDT under timesharing on the  MONITR.EXE
file 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 issuing 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 them in by typing:

	SKIP LOC$X 		; where LOC is some address not in core
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 87
CRASH ANALYSIS


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, crash and reload
		1 	 stop on BUGHLTs (hit EDDT breakpoint)
		2 	 write enable swappable monitor,
			 do not start up SYSJOB, and stop on
			 BUGHLTs.  Also it dosn't run CHECKD
			 automatically on startup.

	DCHKSW	0 	 do not stop on BUGCHKs (default)
		1 	 stop on BUGCHKs (hit EDDT breakpoint)

	DINFSW	0  	 do not stop on BUGINFs (default)
		1  	 stop on BUGINFs (hit EDDT breakpoint)

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,

	GOTSWM$B

Then start the MONITOR by,

	147$G

	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  the  last  two  are  used  for  BUGHLT and BUGCHK) give the
command:

	147$G
or
	SYSGO1$G

If  you  are in EDDT and DBUGSW is 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.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 88
CRASH ANALYSIS


FILDDT:
------

FILDDT is distributed on the customer software tape.

The following is an chewed-up 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.


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, which
was common practice  for  TOPS-10,  but  is  not  generally  done  for
TOPS-20.


HELP

Types something like this text.


ENABLE PATCHING

Allows writing on an existing file specified by a GET.


ENABLE DATA-FILE

Assumes file is raw binary (i.e.  no ACs, and not an EXE file).

DDT FEATURES:
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 89
CRASH ANALYSIS


	EP$U	Sets monitor context for FILDDT mapping.  EP is a symbol
		which is equal to the page number of the EPT.  (Rel 4)

   <CTRL/E>	Returns to FILDDT command level.

TRACKING DOWN UNMAPPED ADDRESSES:
--------------------------------

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

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 "=".  DDT will respond with the value of  this  symbol.
The  value  of  the symbol can be divided 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 in 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  some  pages  of  memory,
therefore it does not contain these 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.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 90
CRASH ANALYSIS


All address in the swappable monitor must be resolved in this  manner.
In addition the pages of the JSB and PSB must sometimes be resolved in
this manner.  There are some locations and tables in the monitor  that
make this easy:

	NAME	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 #	logged in directory number
	JOBPT	Job #	controlling 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 or
BUGS.MAC 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 crash occurred.  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 block of 16
words containing the users ACs.  You may have to chain down more  than
one queued-up SYSERR entry to get to the BUGHLT block.
                                 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		monitor's ACs
	PPC		processor's PC
	UPDL		user's pushdown stack while in a JSYS
	NSKED		0 = ok to run scheduler
			>0 = cannot run scheduler
	INTDF		-1 = ok to receive software interrupts
		 	>= 0 , cannot receive 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 its 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.   There  is a memo on scheduler tests which details most
all of the scheduler tests in the monitor.



You can easily determine all of the forks associated  with  a  job  by
giving the commands:

	-1,,0$M
	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 separate 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
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 92
CRASH ANALYSIS


the  patch  area  when  a  patch  is  inserted.   By  convention,  all
distributed patches are applied at FFF.  This serves the  purposes  of
reducing  confusion, always working until the patch area is exhausted,
and leaving patches always present in a dump for the cases where  that
is important.

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.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 93
CRASH ANALYSIS


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 three failure routines, BUGINF and  BUGCHK  and  BUGHLT  for
lesser  and  greater severity of failures.  Calls to them with JSR (or
PUSHJ P, for Release 5 BUGCHKs and BUGINFs) 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 or INF, and string describes the cause.

For example,

	BUG(HLT,SKDPFL,<PAGE FAULT FROM SCHEDULER CONTEXT>)

The strings are constructed during loading and are dumped into a file.
The BUGSTRINGS.TXT file will produce an ordered  listing  of  the  bug
messages for operator or programmer use.

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>)
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 94
CRASH ANALYSIS


This check accomplishes two things:

	1.	A function of JOB ZERO 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 ZERO
		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 ZERO isn't running, nobody's
		running.



                                 NOTE


               For Release  4,  the  program  form  the
               BUGxxx  calls  takes  has been modified,
               and  the  new  file  BUGS.MAC   contains
               hopefully  useful information on each of
               the BUGxxx calls  in  one  place.   This
               should    be   considered   a   required
               debugging file.



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 a restart of the system.  The BUGCHK/INF output will appear on the
CTY and in the SYSERR log when JOB ZERO gets around to them.

If the system continues to run or is restarted properly, the  location
of  the  bug (saved over a reload) and its message will be reported on
the CTY.

If C(DBUGSW).NEQ.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-zero settings of DBUGSW, 1 and 2, which have the following
distinction.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 95
CRASH ANALYSIS


	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 summary of DBUGSW settings:

			0		1		2
MEANING			Unattended	Attended	Debugging

BUGCHK action		NOP		Hit Breakpoint	Hit Breakpoint
BUGHLT action		Crash System 	Hit Breakpoint	Hit Breakpoint
SWPMON write protect?	Yes		Yes		No
CHECKD 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.

EVDDT	140	JRST EDDT		; go to EDDT
	141	JRST SYSDDT		; reset and go to EDDT
EVDDT2	142	JRST EDDT		; copy of EDDT address
EVSLOD	143	JRST SYSLOD		; initialize file system
EVVSM	144	JRST SYSVSM		; verify swap mon on startup
EVRST	145	JRST SYSRST		; restart
EVLDGO	146	JRST SYSGOX		; reload and start
EVGO	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   restart
initializes core, swapping storage and all monitor tables.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 96
CRASH ANALYSIS


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.  Refer to routine SWTST in SCHED for the current details.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 97
TOPS-20 Crash Dump Analysis


                    MORE TOPS-20 CRASH DUMP ANALYSIS
                    --------------------------------





     1.0  INTRODUCTION

     The purpose of this article is to provide some basic guidelines for
     those   who   have  never  analyzed  a  TOPS-20  crash  dump.   The
     information contained in this article refers exclusively to Version
     4  of  the  TOPS-20  Monitor, although most of the basic principles
     will also apply to earlier versions of the Monitor.   None  of  the
     concepts   included  in  this  article  can  be  considered  highly
     advanced, indeed it is doubtful that  there  exists  an  "advanced"
     methodology in crash dump analysis.  Such techniques are the result
     of nothing more than the continual exercise of  the  basic  skills.
     In  all  cases,  the  person who is to perform the analysis must be
     familiar  with  the  internal  structures  of  the  Monitor,  which
     requires  their  attendance  at  one of the TOPS-20 Monitor courses
     offered by Educational Services.  Obviously, one must know where to
     look  for  a potential problem before hoping to solve it.  For this
     reason, this article  assumes  that  the  reader  has  an  in-depth
     knowledge  of  the  basic  structures  of the TOPS-20 Monitor.  Any
     comments or sugestions to improve  the  content  of  this  material
     would be most welcome.



     2.0  NECESSARY PREPARATIONS

     Obviously enough, dumps do not simply  appear  as  a  result  of  a
     crash.   There are certain prerequisites to obtaining a dump, which
     will be discussed in this section.



     2.1  Creating The Dump File

     TOPS-20 will not, as a rule, create a dump of  the  Monitor  unless
     the  system  is  properly prepared to do so.  This means that there
     must first  exist  a  file  called  PS:<SYSTEM>DUMP.EXE  that  will
     accomodate  the  dump.   This file can be found on the distribution
     tape for TOPS-20, or it can be created by using the MAKDMP program,
     which  will  accept  the  memory size from the user, and create the
     proper sized file.  The file must contain a  sufficient  number  of
     pages  equal to the total number of pages of physical memory in the
     Decsystem-20.  For example,  a  system  that  has  1024K  words  of
     memory,  let's say a 2060, should have a DUMP.EXE file that is 2048
     pages long.  It is important to remember that the number  of  pages
     in  the  dump  file  must be twice the size of the machine's memory
     capacity in K words.  In addition, unless this file already  exists
     before the crash that we wish to capture, we will be unable to save
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 98
NECESSARY PREPARATIONS


     the image of the  system,  because  the  BOOT  program  hasn't  the
     ability to create such a file on it's own.



     2.2  The BOOT

     Normally, when the system has crashed for whatever reason, it  will
     reload itself using the BOOT program.  This Auto-reload feature can
     be suppressed, by giving the "SET NOT  RELOAD"  or  "CLEAR  RELOAD"
     command  to the PARSER.  The PARSER must first be set in PROGRAMMER
     mode, via the "SET CONSOLE PROGRAMMER command.  These  commands  do
     not  apply  to  2020's, of course.  There is a location in the 8080
     which, when it contains the right number,  will  prevent  automatic
     reloads  after crashes.  The location depends on the revision level
     of the ROM, which  is  typed  at  system  startup.   The  following
     commands will turn off auto-reload:

     	ROM level 0.1
     		KS10>LK 20255
     		KS10>DK 303
     
     	ROM level 4.2
     		KS10>LK 20256
     		KS10>DK 303
     
     Also, patching the BUGHLT code where the reload is  requested  will
     prevent  an  auto-reload.   Placing a JFCL in locations BUGH2+3 and
     BUGH2+4 in the  running  monitor  will  prevent  the  monitor  from
     issuing its request.

     BOOT has a limited file system capability when creating the file to
     contain the dump, and in this manner avoids complicating a possibly
     compromised file structure during  the  reload.   It  is  for  this
     reason  that  the  DUMP.EXE  file  must already exist on the public
     structure, for BOOT can find it there, but it can not create it  if
     it  does  not  already  exist.   Also, because BOOT resides in main
     memory of the host (KL10 or KS10) processor, small portions of  the
     Monitor  will  be  overwritten  when  BOOT  is  loaded into memory.
     Currently, BOOT is written into that area of the  resident  Monitor
     that  normally  contains  pure  code, and as such is not usually of
     much consequence.  When one needs to refer to this portion  of  the
     code, either the listings or fiche should be used.

     If for some reason the system fails  to  auto-reload,  then  it  is
     still possible to obtain a copy of the dump.  To do this, the front
     end must have at least loaded the BOOT  program,  and  the  console
     will display the BOOT prompt:
     
     			BOOT>
     
     BOOT  has  a  number of commands that may be used to manipulate the
     contents of the processor memory;  in this  case,  the  command  we
     will  use  will  cause  BOOT  to  copy  the contents of memory into
TOPS-20 TROUBLE-SHOOTING HANDBOOK                                Page 99
NECESSARY PREPARATIONS


     PS:<SYSTEM>DUMP.EXE:
     
     			BOOT>/D
     			BOOT>
     

     At this point the system  may  be  brought  up  normally,  and  the
     analysis of the dump may begin.

     Similarly, a KL-10 system may be set to  suppress  the  auto-reload
     facility,  and  the  CTY  will prompt with the KLI> prompt.  Simply
     typing the word "BOOT" will load  the  BOOT  program  into  memory.
     There  are cases where the system may be completely hung, and it is
     unclear how to best initiate an orderly shutdown.  Obviously, it is
     always possible to type the control-backslash (^\) character at the
     CTY to get into the front-end parser, but then what  can  be  done?
     The  front-end parser allows the operator to force the processor to
     jump to a specified location, and in the case described above, this
     feature  may  be  used  to  force a BUGHLT.  This can be done after
     typing ^\, with the following commands:
     
     		PAR>SET CONSOLE PROGRAMMER
     		 CONSOLE MODE: PROGRAMMER
     		PAR>JUMP 71
     		PAR>
     
     causing the console to return to USER mode, connected to the KL-10.
     This  will  be  followed immediately by a KPALVH BUGHLT (Keep Alive
     Halt), and the system will perform  the  usual  BUGHLT  procedures.
     The  above  command  forces  the  processor to jump to location 71,
     which in turn will cause the BUGHLT, sweeping the cache  to  ensure
     all  of the dump taken will contain valid data.  Simply forcing the
     processor to halt, and then reBOOTing and getting a dump will cause
     the  cache to be invalidated, and random locations in the dump will
     not contain valid data.

     On the 2020 the equivalent command is "KS10>ST 71".



     2.3  Getting A Front-end Dump

     The front-end will  generally  create  a  crash  dump  file  called
     PS:<SYSTEM>0DUMP11.BIN,  containing  the  core image of the PDP-11.
     If the front-end is hung, and none of the terminals are usable,  it
     is  still  possible  to  obtain  a dump of the -11.  By setting the
     HALT/ENABLE switch of the -11 to the HALT position, and  then  back
     to the ENABLE position, the KL-10 will force the -11 to reload.  In
     the process of reloading the -11, the KL will indicate to  the  -11
     that  it has reloaded, and send the necessary information to set up
     the terminals, and unit record devices connected to the  -11.   The
     -11 will, in the process of reloading, dump the old core image into
     the 0DUMP11.BIN file mentioned earlier.   In  the  event  that  the
     problem  will  be  the  subject of an SPR, the front-end crash dump
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 100
NECESSARY PREPARATIONS


     should also be included on the DUMPER tape with the SPR.



     3.0  GENERAL INFORMATION

     It would not be practical to define a method  of  approaching  each
     BUGHLT  in  the  system, but the state of the system at the time of
     the crash may be defined in terms of the data  structures  that  it
     accesses.   By  looking  at  the Monitor's stack, the status of the
     current job, and process, and the condition of the Monitor's tables
     that were in use by the code that BUGHLTed, we can define a limited
     number of "types" of crashes, e.g.,  a  scheduler  crash,  a  pager
     crash,  an  APR  or  device interrupt crash.  Each crash will occur
     while the Monitor is using a specific subset of the  internal  data
     structures  of  the system.  We will attempt to limit the number of
     "types" of crashes based upon the function being performed  by  the
     Monitor  at  the time of the crash.  In the sections following this
     general information, we will suggest some of  the  areas  to  check
     when  looking  at  each  type  of  crash.   This information is not
     complete, but  contains  some  of  the  information  that  is  more
     significant in each particular context.



     3.1  The Basic Materials

     The most important materials in looking at  dumps  are  the  source
     listings  of  the  Monitor.   Either  in  the  form of fiche, or in
     machine-readable format, it is absolutely essential to have  access
     to  listings of the Monitor to be able to analyze any dump, because
     without these listings you would simply be working in darkness.  In
     order   to   understand   the   significance  of  any  BUGHLT,  the
     circumstances of the BUGHLT must be known, as well  as  the  reason
     the  Monitor  could not continue.  To find out this information, we
     must look in the listings.  After the system has re-BOOTed,  it  is
     always  a  good  idea to take note of the console output, including
     the name of the BUGHLT, and any other  associated  console  output.
     Try  to  be  sure  that  no unusual messages, other than the BUGHLT
     itself, appeared on the console within a reasonable period of  time
     before  the  system  crashed.   BUGCHK's, BUGINF's, and "Problem on
     device..." type messages are always significant.  Similarly, a copy
     of  the output from the SYSERR program will be helpful in revealing
     any failing hardware that should be investigated first.  Always try
     to eliminate the possibilty of a hardware problem FIRST, especially
     if the site has had any recent problems in this area.   These  last
     two  points  are  significant in determining the environment at the
     time of the crash, and, in the event that the  dump  will  be  made
     part of an SPR, the information will become essential.

     Naturally, it will be necessary to have a copy  of  the  MONITR.EXE
     file that was running when the crash occurred, and a copy of FILDDT
     to look at the  dump.   With  these  materials  collected,  we  can
     hopefully make a valid analysis of the dump.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 101
GENERAL INFORMATION


     Here is a list, then, of the necessary and helpful materials needed
     to look at dumps:

     1.  The MONITR.EXE file

     2.  The DUMP.CPY file from the crash

     3.  A copy of FILDDT.EXE from the distribution tape

     4.  A copy of the SYSERR output

     5.  A complete set of Monitor and Exec Fiche or listings

     6.  The CTY output from the crash

     7.  The Monitor Calls Reference Manual

     8.  A copy of the SWSKIT tape

     9.  Any other TOPS-20 Manuals that may be appropriate, such as  the
         Operator's Guide, or the Installation Guide.

    10.  The TOPS20.BWR file




     3.2  Identifying The Type Of Crash

     The Monitor performs several basic operations, each  of  which  has
     its own set of tables and data structures.  These operations can be
     defined as:

     1.  JSYS processing

     2.  Page faults

     3.  PSI Service

     4.  Scheduling

     5.  DTE interrupt Service

     6.  Initiating I/O transfers (queueing)

     7.  Device interrupt Service

     8.  APR interrupt Service
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 102
GENERAL INFORMATION


     3.2.1  The BUGHLT Itself - 

     There are specific areas in any crash dump that can be examined  to
     determine  the  status and context of the system at the time of the
     crash.  The most obvious of these is the  location  called  BUGHLT,
     which  will  contain the address whence the BUGHLT code was called.
     It is good practice to remember when looking at this  address  that
     there are portions of the monitor that were overwritten by the BOOT
     program, when the dump was taken, and therefore,  the  contents  of
     the  address  that  called  the  BUGHLT code, that is, the location
     whose address is contained in location "BUGHLT", may not  point  to
     the  same  code  that  the  fiche or the listings indicate.  A good
     example of such a BUGHLT is a PTNIC1, one that is  a  part  of  the
     APRSRV code, which is overwritten by BOOT.

     As of Release 4, all of the BUGHLT's, as well as the  BUGCHK's  and
     BUGINF's  in the Monitor are defined and documented in a new module
     called BUGS.MAC.  This module not only contains, for  each  BUGHLT,
     etc., the name and a string describing the type of halt, but also a
     description of the circumstances that cause  the  halt,  or  check,
     etc.,  to occur.  There is a new argument to the macro that creates
     the BUGHLT's, etc.,  that  is  supposed  to  indicate  whether  the
     problem  is hardware or software related.  You will find either the
     word "HARD" or "SOFT" in this  location  of  the  Macro  call.   In
     addition,  the  additional  information  supplied  in  BUGCHK's and
     BUGINF's now has a string associated with it  that  indicates  what
     the  additional  information  actually  represents.   Finally,  one
     argument to the  BUGDEF  (bug  definition)  Macro  is  a  narrative
     documentation  of  circumstances  that  can cause the problem being
     seen.  Needless to say, this sort of information is  invaluable  to
     anyone  looking  at  a  crash  dump.  Unfortunately, not all of the
     documentation of the BUG's was completed, and as a result, many are
     indicated  as  being  "HARD"  problems, when actually they are not.
     Those BUGDEF's that include the narrative description  of  the  BUG
     have  been  completed,  but  those that do not may indicate falsely
     that the problem is hardware related.

     The BUGHLT's are performed  by  using  the  XCT  instruction  of  a
     location  that contains a JSR BUGHLT instruction.  In the locations
     following the JSR BUGHLT, is the list of additional data addresses,
     and  then  the  name  of  the  BUGHLT,  in  SIXBIT  format, such as
     "PTNIC1".  Finally in the event of multiple BUGCHK's,  BUGINF's  or
     even  nested BUGHLT's, the location "BUGNUM" contains the number of
     BUGHLT's, BUGCHK's, and BUGINF's since the  last  system  start-up.
     This  location  is  most helpful in obtaining a clearer view of the
     circumstances of the crash.  The case of  the  BUGHLT  code  itself
     causing  a  BUGHLT  is  extremely  unusual, but in certain cases of
     extreme degradation of the  system's  data  bases  or  "pure"  code
     pages, this is a possibility.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 103
GENERAL INFORMATION


     3.2.2  The Monitor's Stacks - 

     The next piece of valuable information is contained  in  the  stack
     pointer,  P.   This  location will point to one of several possible
     monitor stacks, and will give a strong indication about the context
     of  the  monitor at the time of the crash.  Identifying the type of
     BUGHLT will usually be a direct indication of which stack  will  be
     in  use, however under certain circumstances, the monitor may crash
     while changing from one stack to another, and such  a  circumstance
     could  provide  a  useful insight into the state of the system just
     before the crash.  The following are the names  of  eight  possible
     monitor stacks, and the context under which each of them is used:


     UPDL      This  is  the  user  stack,  in  that  it  is  used  when
               processing  a  a  user's JSYS in exec mode.  Whenever any
               user executes a JSYS, this area in his PSB  is  used  for
               the stack.  Those processes under job 0 which run in exec
               mode will also use this stack.

     TRAPSK    This stack is used by the paging code whenever a  process
               page  faults.   Normally a page fault will occur while in
               the midst of performing some other function,  such  as  a
               JSYS, and the stack pointer at the time of the page fault
               will be in location TRAPAP, which in turn  will  in  this
               case point to UPDL plus some offset.

     PIPDB     This is used by the software interrupt handler.

     SKDPDL    This stack is used by the scheduler.

     DTESTK    This stack is used by the DTE interrupt service routines.

     PHYPDL    This stack is used by  PHYSIO  code  in  the  process  of
               queing I/O request blocks (IORB's).  These IORB's are the
               means by which RH20/RH11 data transfers are initiated.

     PHYIPD    This stack  is  used  by  the  PHYSIO  interrupt  service
               routines, and therefore is the interrupt-level equivalent
               of PHYPDL.  It is important to remember  that  these  two
               stacks  are  independent of each other, and should not be
               confused.

     MEMPP     This stack is used when processing APR interrupts


          The stack that is being used, and the  section  of  code  that
     executed  the  BUGHLT  will  indicate  the  type of BUGHLT that has
     occurred, file  system  BUGHLT's  will  be  observed  either  while
     performing  a JSYS, servicing an interrupt, or otherwise attempting
     to access a file system that has been corrupted  to  the  point  of
     being unusable.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 104
JSYS CONTEXT (UPDL)


     4.0  JSYS CONTEXT (UPDL)

          When a process executes a JSYS, the Monitor performs the  JSYS
     by  dispatching through a table called JSTAB to the proper routine.
     These routines are named by convention as the JSYS  name,  preceded
     by  a  ".",  thus  the  routine  to perform the JSYS PMAP is called
     ".PMAP::".  This name is always a global  symbol.   The  last  JSYS
     executed  in  user  context is saved in the PSB for the process, in
     location KIMUU1, and KIMUU1+1.  The second of these locations  will
     contain  the  dispatch offset in JSTAB;  this number, when combined
     with the JSYS opcode (104000,,0), is the last JSYS performed by the
     user.  This, then, will point indirectly through the JSTAB table to
     the place where the user JSYS began processing.  By  following  the
     code,  and examining the stack, it is often possible to reconstruct
     the events leading to the crash.  The stack will contain two copies
     of  the  user's  program  counter  (PC) and flags in the first four
     locations of UPDL.  The PSB location MPP  will  contain  the  stack
     pointer  at  the  time  of  last  JSYS,  and  each time the Monitor
     performs a JSYS internally, this data is pushed onto the stack, and
     set to the current value of P.

     Initial JSYS stack set-up:
     
     	UPDL/	PC
     	UPDL+1/	flags
     	UPDL+2/	PC
     	UPDL+3/	flags
     

     JSYS in Monitor context (nested JSYS):
     
     	UPDL+n/	INTDF		;old interrupts-deferred flag
     	      / MPP		;previous PC, or level of nesting
     	      / PC of JSYS
     	      / PC flags
     

          Some other useful locations in JSYS context are:



                             JSB Locations


     USRNAM    This contains the name of the user, in ASCII.


                             PSB Locations

     JOBNO     Contains the number of the job for this process.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 105
JSYS CONTEXT (UPDL)


     FORKN     Contains the fork number for the top fork of the  job  in
               the  left  half  of  the word, and the fork number of the
               current fork in the right.

     INTDF     Contains -1 if process is OKINT, 0 or  greater  if  NOINT
               (defer all software interrupts for this job)

     NSKED     Contains 0 if process is OKSKED, 1 or greater if  NOSKED.
               (defer scheduling of other forks)


        Monitor Fork Table - indexed by the current fork number

     FKCNO     Contains the SPT offset that points to the second page of
               the PSB in the left half of this word.

     FKINT     Contains the  pseudo-interrupt  communications  register,
               with  flags  in  the  left  half  describing  the type of
               request, and the channel number of  the  request  in  the
               right half.

     FKINTB    Contains the pseudo-interrupt  channel  requests  pending
               since the fork's last PSI interrupt.

     FKJOB     Job number of the fork in the left half,  and  SPT  index
               for the JSB in the right half.

     FKJTQ     Part of a doubly linked list of forks  that  are  waiting
               program  software interrupt the Monitor.  JTLST points to
               the top fork on the list.

     FKNR      Contains in bits 0-8 the age stamp value at the last time
               local garbage collection was performed.

     FKPGS     Contains the SPT indices for the process page  table,  in
               the left half, and the PSB in the right half.

     FKPGST    Contains the address of the routine to test  for  balance
               set  wait  satisfied in the right half, with test data in
               the left.  If the fork is not in the  balance  set,  this
               contains  the  time  of  day that the fork entered a wait
               list.

     FKPT      Part of a linked list of forks on a particular  schedular
               list,  such  as GOLST, WTLST, etc.  The right half of the
               word contains the address of  the  next  element  in  the
               list,  and  the  left half contains the amount of runtime
               the fork's  job  will  have  accumulated  when  the  fork
               exceeds its Balance Set Hold time.

     FKQ1      Contain the  fork's  remaining  run  quantum.   When  the
               quantum  expires, the fork is moved to a lower run queue,
               and given the appropriate new quantum.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 106
JSYS CONTEXT (UPDL)


     FKQ2     Contains the fork's schedular queue level  number  in  the
               left  half,  and  the  list  address, i.e.  GOLST, WTLST,
               etc., in the right.

     FKSTAT    Contains the address of the schedular test routine  which
               will determine when the fork is available to be placed on
               the GOLST.

     FKTIME    Contains the time of day, in internal  format,  that  the
               fork was placed on its current run queue.

     FKWSP     Contains the number of physical  pages  assigned  by  the
               fork  in  the right half, and the working set size of the
               fork when the fork entered the balance set in the left.



     5.0  PAGER CONTEXT (TRAPSK)

          Page faults trap through the user's UPT, by  placing  the  old
     flags  and  PC  for  the  process  in  locations  UPTPFL and UPTPFO
     respectively, and taking the new PC from location  UPTPFN.   UPTPFN
     will  usually contain the address PGRTRP, which is the beginning of
     the page fault code.  The location being referenced  and  therefore
     causing  the  page  fault  is stored in UPTPFW, also called TRAPS0.
     This contains the virtual address that page faulted in bits  13-35.
     Bit  0  of  this  word indicates if the location is in user or exec
     (monitor) address space.  If this bit is set,  the  address  is  in
     user  address space.  The PGRTRP code copies TRAPS0 into TRAPSW, in
     case of recursion.  This code will determine the nature of the page
     fault,  and  attempt  to  resolve  it.   UPTPFL and UPTPFO are also
     called TRAPFL and TRAPPC respectively.  The old  stack  pointer  is
     saved  in  location TRAPAP (this is only relevant if the page fault
     occurred in exec mode).  The new stack, TRAPSK, is set up according
     to  the  context  of  the  page  fault, i.e., user context, monitor
     context, or recursive page fault.  A page fault in user mode causes
     the  stack  to be set up with the runtime, return PC, and return PC
     flags in the first three locations of the stack:
     
     		TRAPSK/		runtime
     		TRAPSK+1/	return PC
     		TRAPSK+2/	return PC flags
     

          Page faults from monitor context have  the  following  initial
     stack set-up:
     
     		TRAPSK/		AC1
     		TRAPSK+1/	AC2
     		TRAPSK+2/	AC3
     		TRAPSK+3/	AC4
     		TRAPSK+4/	AC7
     		TRAPSK+5/	AC16
     		TRAPSK+6/	TRAPSW
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 107
PAGER CONTEXT (TRAPSK)


     		TRAPSK+7/	runtime
     		TRAPSK+10/	PC
     		TRAPSK+11/	PC flags
     
     Recursive page faults will cause the following set up in TRAPSK, at
     the time of the page fault:
     
     		/ AC1
     		/ AC2
     		/ AC3
     		/ AC4
     		/ AC7
     		/ AC16
     		/ TRAPSW
     		/ PC
     		/ PC flags
     
     Recursive  page  faults  will  indicate  the  level of recursion in
     TRAPC.  This location is normally set  to  -1  and  is  incremented
     every  time  the  page fault code is called, and decremented when a
     page fault has been satisfied.

          In examining a pager crash, it is usually a good idea to begin
     by  tracing  down the Monitor's table entries for the location that
     faulted.  This location is stored in location TRAPS0.  The identity
     of  the page causing the trap is stored in location TRPID, and will
     be in either of two forms:  page table number  in  left,  and  page
     number in right, or simply the page table number in the right.  The
     page table number is an SPT index, and the page number, if any,  is
     an  offset  into the page table pointed to by that SPT slot.  There
     are four Core  Status  Tables  (CST's)  indexed  by  physical  page
     number, that are used to keep track of each page in the machine.  A
     page fault crash will usually have bad data in either the SPT  slot
     indicated  in  TRPID,  or  one  of  the CST's for the physical page
     pointed to indirectly through that SPT  slot.   If  TRPID  contains
     PTN,,PN,  then  find location SPT+PTN.  This should have a physical
     page number in the right half.  Look at this physical page,  offset
     by  PN  in  TRPID  to  find the pointer to the page that caused the
     fault.  Shared and indirect pointers in this  location  will  point
     through  another  SPT  location,  but  private  pointers will point
     directly at the physical page that we are looking  for.   If  TRPID
     contains just PTN, then SPT+PTN will point directly at the physical
     page we are looking for.  Knowing the physical page number,  it  is
     now possible to examine the CST tables for that page.


     CST0      Used principally by the  pager  hardware,  this  location
               will  contain  the Process Use Register, mentioned in the
               FKCNO table above, and the age stamp.

     CST1      Contains the system lock count, and  the  backup  address
               for  the  page.   The  lock count indicates the number of
               systen events necessary before the page will  be  swapped
               out,  and  the  backup  address for the page.  The system
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 108
PAGER CONTEXT (TRAPSK)


               should never swap out a page with a non-zero lock  count.
               The  backup  address  can be a disk or drum address for a
               page in memory.

     CST2      Contains the home map location of the  page,  and  should
               match the contents of TRPID.

     CST3      Is used by the software  to  create  lists  of  pages  in
               various  states  of  use.   Those pages available for use
               will be on the Replaceable Queue, and linked together  in
               a doubly linked list.  Those pages awaiting swapping will
               be on a swapping device  queue,  and  part  of  a  singly
               linked  list.   Pages in use will contain the fork number
               of the owner in bits 3-14, and the local disk address for
               PHYSIO for the page.

     CST5      Contains the list of short I/O  Request  Blocks  (IORB's)
               associated with the page.


          A few other significant locations for page faults are:


     RPLQ      Points to the beginning of the Replaceable Queue in CST3.

     NRPLQ     Contains the number of pages on the Replaceable Queue.

     SWPLST    Points to the beginning of the PHYSIO swap list, in CST3.

     NOF       Contains the number of OFN's in use in the SPT.



     6.0  PSI CONTEXT (PIPDB)

          Take note of the Monitor fork tables in the  JSYS  section  of
     this  document.   The  locations FKINT and FKINTB will be useful in
     determining the type and timing of PSI interrupts  pending  at  the
     time  of the crash.  When a process has a PSI interrupt pending, it
     is flagged in the FKINT entry for that fork, and the scheduler will
     take  note  of  this  event and set the PPC location in the PSB for
     that process to contain the address PIRQ.  This action takes  place
     at  location  SCHED5  in  the  scheduler.   The  next time that the
     process is ready to run, it will continue at location  PIRQ,  which
     will  set  up  the  PSI  stack,  PIPDB.   SCHED5 also moves the PSI
     request word from FKINT to PIMSK in the PSB.  Thus, it is  possible
     to check this location for the last PSI request that was scheduled.
     The old contents of PPC and PFL are stored in PIPC and PIFL by  the
     SCHED5  routine, so these will indicate the point where the process
     was interrupted.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 109
SCHEDULER CONTEXT (SKDPDL)


     7.0  SCHEDULER CONTEXT (SKDPDL)

          Take note of the Monitor Fork tables in the  JSYS  section  of
     this  document.   The  scheduler  is  usually invoked in one of two
     ways:  through a software  interrupt  initiated  by  channel  3  PI
     routine, indicating that a set period of time has elapsed since the
     last scheduler cycle, or through the ENTSKD macro, which is used by
     a  running  process  that  is  about  to  dismiss.  In this way the
     scheduler is guaranteed to run at regular  intervals,  or  whenever
     the  system  is  idle.  The primary entry point to the scheduler is
     SCHED0.  It is through this location control  passes  whenever  the
     running  process  dismisses,  or  whenever one of the two scheduler
     clock cycles elapses.  Briefly, the hardware traps on  every  clock
     tick  through  location  TIMVIL in the EPT.  This location contains
     the instruction XPCW TIMINT.  Again, as  in  the  device  interrupt
     code,  this  instruction  causes  the  flags and PC to be placed in
     locations TIMINT, and TIMINT+1, and control passes to the  location
     in  TIMINT+3,  which  in  this  case  is TIMIN0.  TIMIN0 determines
     whether or not it is time to run the scheduler, and  dismisses  the
     interrupt.   If  the  scheduler  is  to  be run, TIMIN0 initiates a
     software interrupt on channel 7, which causes a  trap  through  the
     EPT  location  KIEPT+56  to  PISC7R.   The  instruction executed in
     KIEPT+56 is an XPCW PISC7R, causing the old  PC  and  flags  to  be
     deposited  at  PISC7R,  and control to begin at PISC7+1.  The PISC7
     code sets up PPC and PFL to contain the  old  PC  and  flags,  from
     PISC7R,  and saves the process ac's at the time of the interrupt in
     a block of the  PSB  called  PAC.   Having  set  up  for  scheduler
     context,  the  PISC7  code  then  transfers  control  to the SCHED0
     routine.  Similarly, the ENTSKD macro does an XPCW ENSKR, causing a
     jump  to  the  ENSKED routine that does the context switch.  On the
     2020 the clock will interrupt through location  KIEPT+46  (standard
     level  3  interrupt).   The level 3 routine will first determine if
     this interrupt was caused by a  clock  tick,  and  if  so  JRST  to
     routine TIMIN0.

          Some other useful locations in scheduler context:

     1.  GOLST     Points to the beginning of  the  GOLST  in  the  FKPT
         table.

     2.  WTLST     Points to the Wait list in the FKPT table.

     3.  TTILST    Points to the TTY input wait list in the FKPT table.

     4.  FRZLST    Points to the list of frozen forks.

     5.  WT2LST    Points to the list of forks waiting to be  unblocked.
         (UNBLK1)

     6.  TRMLST    Points to the list of forks waiting for another  fork
         to terminate.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 110
SCHEDULER CONTEXT (SKDPDL)


     7.  SUMNR     Contains the number of reserved  pages.   (locked  in
         memory)

     8.  BALSHC    Contains the number of pages reserved due  to  shared
         access.

     9.  INSKED    Set to non-zero if in the scheduler.




     8.0  DTE INTERRUPT CONTEXT (DTESTK)

          DTE interrupts also dispatch through  locations  in  the  EPT,
     depending  upon which DTE is interrupting.  For each DTE that could
     exist on a system (4), there is an eight word block in the EPT used
     to  keep  up-to-date  information for that DTE.  Not all of the DTE
     blocks will necessarily be used, however they will all exist in the
     EPT.   These blocks begin at location DTEEBP.  The format of one of
     these blocks is described below.  The DTE  interrupt  executes  the
     third  word  in this block, which contains a XPCW DTEN0.  This will
     cause the old PC and flags to be stored  at  location  DTEN0,  and,
     since  DTEN0+3 contains ".+1", the system will begin processing the
     interrupt at location DTEN0+4.  This part of the routine  will  set
     up  the  DTE  stack, DTESTK, and save the PC, flags, and AC's.  The
     flags and PC are stored at DTETRA,  and  the  AC's  are  stored  at
     DTEACB.  DTEN0 will then use INTDTE to process the interrupt.  This
     code can be found in the DTESRV module of the monitor.

     The DTE control block:
     
     	DTEEBP/	To -11 byte pointer
     	DTETBP/	To -10 byte pointer
     	DTEINT/	"XPCW DTEN0"		;dispatch for DTE-0
     	      /	reserved
     	DTEEPW/	Examine Protection Word
     	DTEERW/	Examine Relocation Word
     	DTEDPW/	Deposit Protection Word
     	DTEDRW/	Deposit Relocation Word
     
     Note that the labels above  apply  only  to  DTE-0,  and  that  the
     remaining DTE's must be offset by DTE-number X 8.

          Some other useful locations in the EPT:
     
     	DTEFLG/	Operation Complete Flag
     	DTECFK/	Clock Interrupt Flag
     	DTECKI/	Clock Interrupt Instruction
     	DTET11/	To -11 argument
     	DTEF11/	From -11 argument
     	DTECMD/	Command Word
     	DTESEQ/	DTE20 Operation Sequence Number
     	DTEOPR/	Operation In Progress Flag
     	DTECHR/	Last Typed Character
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 111
DTE INTERRUPT CONTEXT (DTESTK)


     	DTETMD/	Monitor TTY Output Complete Flag
     	DTEMTI/	Monitor TTY Input Flag
     	DTESWR/	Console Switch Register
     
     These location are found at offsets 444 through 457 in the EPT.



          9.0  I/O QUEUEING (PHYPDL)

          All disk and tape I/O is initiated through the PHYSIO code, by
     calling  PHYSIO  with  a  pointer to an I/O Request Block (IORB) in
     AC1, and the addresses of the Channel Data  Block  (CDB)  and  Unit
     Data Block (UDB) in AC2 (CDB,,UDB).  PHYSIO validates the arguments
     passed to it, and then determines whether the IORB belongs  on  the
     Position  Wait Queue (PWQ) or the Transfer Wait Queue (TWQ).  These
     two queues are pointed to by offsets UDBPWQ and UDBTWQ in  the  UDB
     for  the  device.   Note that these are offsets into the UDB, which
     will be in resident free space,  as  well  as  the  CDB's.   During
     processing, PHYSIO will keep the following information in the ac's:
     
     	P1/	address of the CDB
     	P2/	address of the KDB (for tapes) or 0
     	P3/	address of the UDB
     	P4/	address of the IORB being processed
     
     Since PHYSIO is called via the PUSHJ P, instruction,  the  previous
     PC  is not saved.  The P and Q ac's are stored on the stack via the
     SAVEPQ macro.  PHYSIO does use a private  stack,  and  so  the  old
     stack  pointer is saved in PHYSVP.  Also, because PHYSIO does use a
     private stack, it is necessary for the process calling PHYSIO to be
     NOSKED.  Also take note of the fact that IORB's are associated with
     the physical pages of memory that are involved with the I/O through
     pointers  in  the CST5 table for those pages.  See the next section
     for more information in this area.



          10.0  DEVICE INTERRUPT CONTEXT (PHYIPD)

          Device interrupts, in this context, refer  to  disk  and  tape
     interrupts,  those devices connected through the RH20's.  Each RH20
     channel has a "Channel Logout" area at the beginning of EPT.   This
     logout  area  is  four words in length for each channel, the fourth
     word of which contains an instruction to execute on  an  interrupt.
     This  instruction causes the system to dispatch to code actually in
     the CDB for the channel.

          On  the  2020,  the  interrupts  work  differently.   The  EPT
     contains pointers to SM10 vector tables starting at address SMTEPT.
     The number of the interrupting UBA (1 or 3) is used as an offset to
     SMTEPT  to  find the proper vector table, and then the function and
     device (read done, DZ11, etc...) is used  as  an  offset  into  the
     vector  table  which  contains  the appropriate XPCW instruction to
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 112
DEVICE INTERRUPT CONTEXT (PHYIPD)


     transfer control to the correct routine.

          The previous PC and flags are saved in  the  area  immediately
     preceding  the CDB;  offset CDBINT (value -6) is the location where
     the flags and PC  are  stored.   When  the  interrupt  occurs,  the
     hardware executes the instruction in the channel logout area, which
     is "XPCW loc".  "Loc" is the address of the CDB for  this  channel,
     offset  by  CDBINT  (-6).   The XPCW instruction saves the flags at
     CDBINT(CDB), the PC at the next location, and gets  the  new  flags
     and  PC  from  the next two locations.  This area of the CDB, then,
     contains the following:
     
     	CDBINT(CDB)/	old flags
     	    -5(CDB)/	old PC
     	    -4(CDB)/	new flags (0)
     	    -3(CDB)/	new PC ( ".+1")
     	    -2(CDB)/	MOVEM P1,CDBSVQ(CDB)	; saved in CDB offset CDBSVQ
     	    -1(CDB)/	JSP P1,PHYINT		; dispatch to interrupt code
     	CDBSTS(CDB)/	status and configuration flags
     
     The  PHYINT  code, then, resolves the interrupt, and returns to the
     old PC by JRSTing through offset CDBJEN in the CDB.  This  part  of
     the CDB contains the following:
     
     	CDBJEN(CDB)/	BLT 17,17
     		   /	DATAO RH,CDBRST
     		   /	XJEN CDBINT(P1)
     
     The  last  of  these locations causes the system to resume where it
     was interrupted.  During processing of the interrupt, the following
     information may be found:
     
     	P1/	address of the CDB
     	P2/	address of the KDB or 0
     	P3/	address of the UDB
     	P4/	address of the IORB or argument code:
     
     		(P4) < 0 - schedule a channel cycle
     		(P4) = 0 - dismiss interrupt
     		(P4) > 0 - complete current request (IORB address)
     

          When the system is attempting to perform  I/O  to  or  from  a
     specific page of physical memory, that page is locked into core, by
     incrementing the lock count in the CST1 location for that page.  If
     a  device  error  occurs during the transfer of data for that page,
     then the CST5 entry for that page will  have  either  a  short  I/O
     Request  Block  (IORB) or a pointer to a long (Mag Tape) IORB.  The
     short IORB is only one word in length and is used for disk transfer
     requests,  i.e.,  swapping.   In  either case, the first word of an
     IORB, called IRBSTS, contains flags that describe  the  success  or
     failure  of  the  transfer.   It  may  be  helpful  to  check these
     locations in the event of a PHYINT crash.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 113
DEVICE INTERRUPT CONTEXT (PHYIPD)


          The following offsets contain useful  information  for  PHYSIO
     crashes:

     In the UDB:
     
     	UDBPS1/ cylinder number
     	UDBPS2/ surface,, sector number
     	UDBERC/ error retry count
     	UDBERR/ status function for error retry
     
     In the CDB:
     
     	CDBCNI/ status of channel when interrupt began.
     



     11.0  APR INTERRUPT CONTEXT (MEMPP)

          APR Interrupts, like Device interrupts, are  vectored  through
     the EPT, but in the case of the APR interrupts, the vector location
     is a part of the priority interrupt  scheme.   These  are  priority
     channel 3 interrupts, and dispatch through location KIEPT+45, which
     contains a XPCW PIAPRX.  This is the channel 3  interrupt  routine.
     This routine will attempt to resolve the interrupt, and in doing so
     will set up its own stack, MEMPP.  As in the  case  of  the  device
     interrupt, the XPCW PIAPRX will cause the PC and flags to be stored
     at locations PIAPRX and PIAPRX+1, and the processor will then  jump
     to  the  location  stored  in  PIAPRX+3,  which  is PIAPR+1.  PIAPR
     actually dismisses the APR interrupt, or BUGHLT's.  The  old  stack
     pointer,  at  the  time of the interrupt, is stored in MEMAP.  Ac's
     0-10 are saved starting at  location  MEMPA.   One  unusual  aspect
     about  handling  APR  interrupts is that the PIAPR code changes the
     page fault trap vector, mentioned earlier, from PGRTRP  to  MEMPTP,
     in  UPTPFN,  to  handle  the  special  case  of a page fault in APR
     interrupt context.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 114
BUG'TYP MACRO CHANGES FOR VERSION 4 OF TOPS-20


             BUG'TYP MACRO CHANGES FOR VERSION 4 OF TOPS-20
             ----------------------------------------------


Version 4 of TOPS-20  will  include  some  changes  in  the  BUG  code
generation.   The  purpose  of these changes is to generate a document
describing the TOPS-20 BUGCHKs, BUGHLTs, and  BUGINFs  that  are  more
descriptive than the previous BUGSTRINGS.TXT file.

The logistics of this change include moving the BUG definitions out of
the  monitor  source  listings  and  into a central source file.  This
source file will serve both as the definition file for the bugs and as
documentation  for the BUGS.  This file is called BUGS.MAC and will be
distributed to all sites on the distribution  tape.   These  BUGS  are
still  referenced  in  the  source module where the bug is invoked but
they are defined in BUGS.MAC.

This involves a modification to the old BUG  macro  and  a  new  macro
called  DEFBUG.   The  BUG macro appears in the source modules and the
DEFBUG macro appears in BUGS.MAC.

The format of the new BUG macro is as follows:

              BUG (BUGNAM,<<x1,des1>,<x2,des2>...>)

This is placed in the monitor code where the BUG called BUGNAM  is  to
occur.  This macro executes a macro with name 'BUGNAM' which generates
a XCT BUGNAM where the contents of BUGNAM is a  JSR  BGCHLT  or  PUSHJ
P,BGCCHK  or  PUSHJ  P,BGCINF for release 5, or JSR BUGHLT/CHK/INF for
release 4.  Following the location BUGNAM  are  the  locations  to  be
printed  (one  address  per  word)  followed  by  SIXBIT/BUGNAM/.  The
locations to be printed are defined with the DEFBUG  macro  while  the
locations specified in the BUG macro are for documentation only.

Accompanying this BUG macro is a DEFBUG macro which is placed  in  the
file  BUGS.MAC.   This entry completely defines the BUG, including its
type (BUGHLT, BUGCHK, or BUGINF) and documentation.

The format of the DEFBUG macro is:

                DEFBUG (TYP,TAG,MOD,WORD,STR,LOCS,HELP)


     For a description of the arguments to this macro see  the  SWSKIT
article called BUGS.MEM.  

In order to make listings (output from MACRO or CREF) more informative
than  before,  the  BUG  macro  will  cause the statement of the short
description displayed in the listing where the BUG  macro  is  called.
Also,  the  flavor of bug (INF, CHK, or HLT) and whether it's hardware
or software related will be  displayed  in  the  listing.   Hence  the
OVRDTA bug would appear in the listing as:
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 115
BUG'TYP MACRO CHANGES FOR VERSION 4 OF TOPS-20


          BUG(OVRDTA)
          ;BUG Type:              hardware-related BUGINF
          ;BUG description:       PHYSIO - OVERDUE TRANSFER ABORTED


     When fully documented, the BUGS.MAC file will be extremely useful
for  specialists.  It will describe, in one convenient place, what the
additional data printed on the console is, what caused  the  bug,  and
what the site or specialist should do if that particular bug occurs.

Here is a section of the current BUG definition/documentation for  the
BUG GIVTMR from BUGS.MAC:

DEFBUG(INF,GIVTMR,JSYSA,SOFT,<GIVOK TIMEOUT>,<<T2,FUNC>>,<

Cause:  The access control job has not responded with a  GIVOK  within
        the designated time period.

Action: If this consistently happens with the same function code,  you
        should  see  if  the  processing  of  the function can be made
        faster.

        If there is no obvious function code pattern, you may need  to
        increase  the  timeout  period  or rework the way in which the
        access control program operates.

Data:   FUNC - the GETOK function code 


        >)

INF specifies the bug is a BUGINF.  GIVTMR is the  name  of  the  bug.
JSYSA  is the module that the bug would occur in.  SOFT specifies that
it is likely the bug is caused by a software bug.  <GIVOK TIMEOUT>  is
the  bug string.  <T2,FUNC> specifies the data that will be printed on
the operator's console.  The initial spec called  for  the  descriptor
FUNC  to  be included in the operator's message but at this time, this
descriptor is just for source documentation.

The blurbs following the initial line of the BUG definition attempt to
describe  to  the  specialist,  in  a  more  detailed  manner than the
description printed on the console, what it means when this bug occurs
and  what  should be done first in order to resolve the situation.  In
this case the ACTION is to examine the GETOK routine which is executed
for  the  additional  data  FUNC.   This  routine  is getting hung up.
Sometimes, the ACTION will state to call the hot line or to submit  an
SPR.   These  descriptions  will  help the specialist be more informed
about the bugs which may occur at one of their sites and save them the
time  of  calling  the hot line or searching through the source module
for an idea of the problem.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 116
MONITOR BUILDING HINTS


                         MONITOR BUILDING HINTS
                         ----------------------


1. GENERAL

Judging from the  number of  requests for  help on  this subject,  the
chances are that you  will be required to  rebuild a monitor  sometime
during your career  as a  Software Specialist. The  reasons are  quite
simple.  There are customers, who simply want functionality other than
that provided  by  stock  monitors.  There  are  also  those  who  are
experiencing performance problems. We  cannot forget the sales  folks.
It is not  unusual to  have to  rebuild a monitor  in order  to run  a
benchmark. A very common example  is increasing the OFN area.  Another
quite common requirement is  to increase the  patch area (FFF).  Doing
either of these and simply submitting a build control file will  often
produce a bad monitor.

We will talk about PSECTS in  relation to the Monitor's address  space
but will  make  no attempt  to  define what  they  do. A good detailed
discussion on the Monitor's address space is on pages 2-62 to 2-73  in
the Release 4  Update Manual. Also  there is a  memo on the  Monitor's
address space in the SWSKIT.


2. BACKGROUND

In V3A, all of the Monitor was in the same address space. Nevertheless
there was a crunch on space. As  a result some PSECTS were allowed  to
overlap. So  critical  was the  space  requirement, that  attempts  to
increase the OFN area  or FFF usually resulted  in the overlapping  of
PSECTS other the  the ones  permitted. Therein lies  the problem.  The
Monitor produced from such a process would ordinarily be useless.
				
With  the  development  of  V4,  the  space  requirement  became  more
critical.  The Symbol Table became the object of concern. It  required
a large number of pages, and in general, it is only used  infrequently
under normal  conditions.  Hence  the Engineering  folks were  of  the
opinion that  it should  be completely  eliminated.  We  objected.  It
would be a nightmare to try  to debug the monitor without symbols.  It
thus became  our  project  to  somehow keep  the  Symbol  Table  while
conforming with  the space  restrictions.  We  decided to  remove  the
Symbol Table and place it in  an alternate  address  space. It  should
be noted  that  this  action  does  not  impact  adversely  on  system
performance. With this change, the  build procedure and the  monitor's
address space were reorganized.

3. BUILD PROCEDURE

Outlined below are some steps to guide you when rebuilding a  monitor.
Bear in mind that this  is a guide and might  not account for all  the
unusual situations.  This guide however, coupled with your  experience
and common  sense will  most likely  do the  trick. PLEASE  READ  THIS
ENTIRE MEMO BEFORE ATTEMPTING TO  REBUILD  YOUR  MONITOR. Also  please
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 117
MONITOR BUILDING HINTS


read the build BEWARE file that is on the Installation tape.
	
NOTE:	The customers Distribution Tape will have all the files needed
	to rebuild  the  monitor.  All  TOPS-20  modules  will  be  in
	TOPS-20.REL (or T2020.REL etc) The control file is  TOPS20.CTL
	(or T2020.CTL  etc).  The  link file  will be  NAME.CCL  where
	"NAME" depends upon what monitor is being used (could be 2020,
	ARPA etc.). For 2040/50, it is called LNKSCH.CCL. In any  case
	the TOPS20.CTL file  will have  the name. The  files you  will
	change will be one  of  the  PARAM's  file  and/or STG.MAC. It
	should be noted that the special LINK.EXE and MACRO.EXE needed
	to build V3A are not required under V4.
	
	If you have  the time, it  is not a  bad idea to  use all  the
	standard files and  build yourself a  "vanilla" monitor.  This
	will test  the procedure  and files  and reveal  any  problems
	peculiar to the  build itself.  Once these  are resolved,  any
	problems encountered  when you  are rebuilding  your  modified
	monitor will be related to the change itself. The time for the
	debugging phase can thus be reduced substantially.
		
STEP 1		Restore all files needed  from <5-SOURCES>. This  will
		usually contain the monitor modules (TOPS20.REL file),
		all needed source  files, all  build control,  command
		and log files.
		
STEP 2		Carefully make the source changes as needed.
		
STEP 3		Examine the TOPS20.CTL  file. This  file will  usually
		have logical name definitions and TAKE commands  along
		with other things. Also look at all referenced files.
		
STEP 4		Examine the  corresponding log  file. This  will  show
		what the result of  the original build procedure  was.
		It should therefore be a template which should be used
		to judge the validity of the new Monitor. Pay  special
		attention to the section which shows the PSECT  layout
		at the  end of  the BUILD  procedure. This  shows  the
		start location,  the end  location and  the amount  of
		free space between each PSECT.  The file used by  LINK
		to set up the PSECTS is called LNKSCH.CCL. You  should
		look at this file to get an idea of what's happening.
		
STEP 5		Now edit the control and command files as necessary to
		reflect your environment. This will mean, among  other
		things,   changing   or   eliminating   logical   name
		definitions.  Do NOT change the order of the PSECTS in
		the LNKSCH.CCL file. Also  do not change the  starting
		value for any PSECT.  The starting value is the  value
		given to the /SET: switch.
		
STEP 6		Submit  the  control  file  with  /TAG:SINGLE  switch.
		Ensure that the control  file is correct and  reflects
		accurately logical name definitions and the .CCL file.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 118
MONITOR BUILDING HINTS


		Also this portion  of the .CTL  file has the  commands
		necessary to compile the changed module.
		
STEP 7		When the job ends, examine your log file. Correct  any
		compilation or  missing files  errors and  go back  to
		STEP 6. Continue with STEP 8 only after all errors are
		eliminated.
		
STEP 8		At this  point  you  should have  a  MONITR.EXE.   Now
		examine the section  in the  log file  which gives  an
		outline of  the  PSECTS.   If any  PSECTS  overlap,  a
		message will  indicate  the  same.  If  there  are  no
		overlapping messages, go to  STEP 11. NOTE: There  are
		some   instances  where  PSECTs  can  overlap.  POSTCD
		and SYVAR  PSECTs are  allowed to  overlap any  xxxVAR
		PSECT. This will  not gain  very much in  storage -  4
		pages to be exact. If  you  follow the build procedure
		then overlapping  PSECTs are not allowed and therefore
		must  be  resolved.  You  are  once  again advised NOT
		to re-organize the monitor's address space.
		
STEP 9		Start with  the  first  overlapping.  Figure  out  the
		amount of words by which  the first PSECT overlap  its
		following PSECT.  Now  add  this value  to  the  start
		location of  the overlapped  PSECT. This  value  quite
		possibly will  be  location  within  a  page  i.e.  an
		address of the form 125300,  where the page number  is
		125 and the offset into the page is 300. The  starting
		address of many  PSECTs is  required to be  on a  page
		boundary i.e. an  address of the  form 126000. A  good
		rule to  follow is:  IF THE  PSECT STARTED  ON A  PAGE
		BOUNDARY BEFORE  THE BUILD,  THEN KEEP  IT ON  A  PAGE
		BOUNDARY. This would mean that you may be required  to
		add an additional value to round up to the next  page.
		For example  the  125300  value would  be  rounded  to
		126000 if the  PSECT is required  on a page  boundary.
		The PSECT  sequence and  starting  values are  in  the
		LNKSCH.CCL file.  NOTE: the  values are  all given  in
		OCTAL so add in OCTAL.
		
STEP 10		EDIT the  LNKSCH.CCL file  to reflect  this new  start
		value for the  overlapped PSECT.  Go back  to STEP  6.
		Repeat these  steps  until  there are  no  more  error
		messages. Note that changing the start location of the
		overlapped PSECT can cause it to overlap its following
		PSECT and  the  same  procedure must  be  followed  to
		resolve any conflicts. Of  course you must be  careful
		to ensure that you do not outgrow the monitors address
		space. A total of the  length of all PSECTs will  tell
		you if the Monitor is too large.
		
STEP 11		At this point you should have a good Monitor. Save  it
		in the proper directory. The final test is getting  it
		up and running.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 119
EXEC DEBUGGING


                             EXEC DEBUGGING
                             --------------


Now that most SWS have micro fiche of the released 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 other chapters in 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 the 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 <ESC>G , echoed as $G.  This starts
your program which is the EXEC and so now  you  are  at  EXEC  command
level.

		@ENABLE
		$^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.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 120
EXEC DEBUGGING


EXAMPLE EXITING FROM DDT:

		@GET MYEXEC.EXE	
		@SET NO CONTROL-C-CAPABILITY
		@START
		@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
		@SAV MYEXEC.EXE.2	; address space.  You can save it, say.




EXAMPLE, EXITING FROM YOUR RUNNING EXEC:

		@GET MYEXEC.EXE
		@START
		@MONNAM.TXT,,TOPS-20 MONITOR(VERSION #)
		@ENA
		$^EEDDT
		DDT
		.
		.
		.
		CINITF/  -1  0		; clear initialization flag
		$G			; running your EXEC
		.
		.
		$^EQUIT			; return to higher (system) EXEC
		$			; you are in system EXEC
		$SAV NEWEXEC		; etc.



EXAMPLE, EXITING FROM YOUR RUNNING EXEC WITH POP:

		@GET MYEXEC.EXE
		@START
		@MONNAM.TXT,,TOPS-20 MONITOR(VERSION#)
		@
		.
		.
		.
		@POP			; return to higher (system) EXEC.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 121
EXEC DEBUGGING


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

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 MINI-EXEC always.   First  you
must  issue ^EQUIT to get into the MINI-EXEC.  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
MINI-EXEC.  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
	$
	$START
	@MONNAM.TXT, TOPS-20 MONITOR (VERSION)
		.			; lets say you can't do anything
		.			; you are in your EXEC
		.			; get out, get into MINI-EXEC
	^P
	INTERRUPT AT 12345
	MX>S				; MINI-EXEC prompt followed by start.
	$				; you are now in the system EXEC.


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 MINI-EXEC
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
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 122
EXEC DEBUGGING


	MX>G <MYAREA>MYEXEC.EXE.2
	MX>S
	@		      ; Now you are in your EXEC
	  .
	  .
	  .		      ; Lets say you want to get out 
	@^P		      ; Control-P to get to MINI-EXEC
	INTERRUPT AT 12345
	MX>R		      ; "RESET" resets your address 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.  REPLACING THE SYSTEM EXEC


     Once you have made a change to your personal copy  of  the  EXEC,
you  may  wish to have your edited EXEC run as the SYSTEM EXEC.  It is
necessary  to  make  the  saved  EXEC  non-writable  before  using  it
system-wide.


	EXAMPLE:

	@ENABLE (CAPABILITIES) 
	$GET (PROGRAM) PS:<SYSTEM>EXEC.EXE
	$INFORMATION (ABOUT) MEMORY-USAGE 

	81. pages, Entry vector loc 6000 len 3

	0	 PS:<SYSTEM>EXEC.EXE.1  1   R, CW, E
	6-125	 PS:<SYSTEM>EXEC.EXE.1  2-121   R, E

	$!MAKE THE EXEC WRITABLE SO WE CAN EDIT IT
	$SET PAGE-ACCESS (OF PAGES) 6:125 (ACCESS) COPY-ON-WRITE 
	$DDT
	DDT
	.		;Make the edits
	.		
	^Z
	$
	$!MAKE THOSE PAGES NON-WRITABLE
	$SET PAGE-ACCESS (OF PAGES) 6:125 (ACCESS) NO WRITE 
	$SET PAGE-ACCESS (OF PAGES) 6:125 (ACCESS) NO COPY-ON-WRITE 
	$!SAVE THE NEW EXEC
	$SAVE EXEC.EXE.2 !New generation! (PAGES FROM) 6 (TO) 125 
	 EXEC.EXE.2 Saved
	$!RENAME THE SYSTEM EXEC SO WE CAN GET IT BACK IF WE NEED IT
	$RENAME (EXISTING FILE) PS:<SYSTEM>EXEC.EXE.* (TO BE) PS:<SYSTEM>OLD-EXEC.EXE
	$!AND COPY THE NEW ONE INTO PS:<SYSTEM>
	$COPY (FROM) EXEC.EXE.2 (TO) PS:<SYSTEM>EXEC.EXE.197 !New generation!
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 123
EXEC DEBUGGING


VI.  OTHER INFORMATION:


     When searching for symbols you may notice that  the  module  name
DDT  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	MODULE NAME	FILENAME	MODULE NAME
	===========================	===========================
	EXECDE.MAC	XDEF		EXEC0.MAC	EXEC0
	EXECGL.MAC	XGLOBS		EXEC1.MAC	EXEC1
	EXECPR.MAC	PRIV		EXEC2.MAC	EXEC2
	EXECED.MAC	CANDE		EXEC3.MAC	EXEC3
	EXECCS.MAC	CSCAN		EXEC4.MAC	EXEC4
	EXECSU.MAC	SUBRS		EXECMT.MAC	EXECMT
	EXECVR.MAC	VER		EXECQU.MAC	EXECQU
	EXECMI.MAC	MIC		EXECSE.MAC	EXECSE
					EXECP.MAC	EXECP


For  Release  5,  the  TITLE  statements in the EXEC modules have been
changed to match the module names  so  that  this  concordance  is  no
longer necessary.

     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	      ; location of symbol table pointer
	776456/  743200,,23540     762600,,54463


VII.  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 you're
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 124
EXEC DEBUGGING


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

	@ENABLE
	$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.


     Various  methods  may  be  used  to  write-enable  the  EXEC  for
patching.   You  can  use  the  GET,  SAVE method above, or SET PAGE n
COPY-ON-WRITE, or the $W command in DDT to achieve the same results.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 125
RECOVERING FROM A BAD EXEC


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

     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			; load in the monitor
BOOT>/G141		; start up EDDT

EDDT
DBUGSW[   0   2		; set system as debugging
EDDTF[   0   1		; keep EDDT around

GOTSWM$B		; set a breakpoint after the swappable
			; part of the monitor has been loaded
147$G			; start the system
GOTSWM$1B>>   STEX+1/   HRROI T2,BOOTER+51   HRROI T2,FFF
FFF[   ""PS:<SYSTEM>OLD-EXEC.EXE"
FFF:			; change the name of the EXEC file
0$1B			; remove the GOTSWM breakpoint
$P			; proceed to bring up the system

^C			; and Control-C to get the new EXEC

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.     Of course the  ^EQUIT, GET from MINI-EXEC is
still a valid sequence for starting a new top-level fork.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 126
Debugging the GALAXY System


                      Debugging the GALAXY System
                      ---------------------------







1.0  INTRODUCTION

The GALAXY system presents a unique problem to the software specialist
who  is trying to debug one of its components.  Usually, any user mode
program can be debugged under TOPS-20 by running a copy of it,  loaded
with  DDT,  taking  appropriate  care  that nothing is done which will
affect any users of the system.   For  GALAXY,  however,  it  is  very
difficult  to not affect users of the system.  For example, if you are
trying to debug BATCON, you will find that QUASAR  will  very  happily
schedule batch jobs submitted by other users to be run by your BATCON.
If you are not careful, you can cause those batch jobs to be lost,  or
at least slowed down, while you are debugging.

Debugging QUASAR or ORION would be even worse.  Users would see PRINT,
SUBMIT,  etc.   commands  hang  when  you  hit a breakpoint in QUASAR.
Operators would be unable to control any system components if you were
breakpointed  in  ORION.   On  top  of  this,  the monitor knows about
QUASAR, and you may lose messages which  happen  when  users  close  a
spooled lineprinter file, or when a job logs out.

To solve these problems, the concept of a "private GALAXY system"  has
been implemented by software engineering in version 4 of GALAXY.  When
a private GALAXY system  is  operating,  all  of  its  components  are
completely  independent  of  the  primary  GALAXY system.  QUASAR, the
queue maintainer, keeps queues  that  are  separate  from  the  system
queues  and  are  failsofted  to  a different master queue file.  This
QUASAR communicates only with other components  in  the  same  private
system.   It  is  even possible to run several complete private GALAXY
systems, with the restrictions that:

     1.  All components in a private system must run  under  the  same
         user name.

     2.  Only one private system may be run by a given user.

     3.  Each  private  QUASAR  must  be  connected  to  a   different
         directory.

     4.  Each  private  ORION  must  be  connected  to   a   different
         directory.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 127
BUILDING A PRIVATE GALAXY SYSTEM


2.0  BUILDING A PRIVATE GALAXY SYSTEM

Since the changes necessary to create a  private  GALAXY  system  were
implemented  in  the version 4 source code, it is relatively simple to
build the system.  The recommended procedure is as follow:

     1.  Create a directory to for the private GALAXY system.

     2.  Restore  the  file  EXEC-FOR-DEBUGGING-GALAXY.EXE  from   the
         SWSKIT to this newly created directory.  For Release 5 of the
         EXEC, the distributed EXEC replaces the need for this special
         program.

     3.  Restore each of the following files from  the  "Subsys  files
         for  TOPS20  V5"  saveset on the TOPS-20 distribution tape to
         this directory.

           BATCON.EXE
           CDRIVE.EXE
           GLXLIB.EXE
           LPTSPL.EXE
           OPR.EXE
           ORION.EXE
           PLEASE.EXE
           QMANGR.EXE
           QUASAR.EXE
           SPRINT.EXE
           SPROUT.EXE

     4.  For each component in the above list  except  GLXLIB.EXE  and
         QMANGR.EXE, perform the following steps:

         1.  Give the EXEC command "GET xxxxxx.EXE"

         2.  Give the command "DEPOSIT 135 -1"

         3.  Give the command "SAVE xxxxxx"
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 128
EXAMPLE OF A PRIVATE GALAXY BUILD


3.0  EXAMPLE OF A PRIVATE GALAXY BUILD

It is not strictly necessary to restore all of the  GALAXY  components
for  a  one  time  only  debugging session.  To debug a component like
BATCON, you would need at a minimum:

     1.  Your own copy of BATCON

     2.  Your own copy of QUASAR for BATCON to speak to

     3.  Your own copy of ORION for BATCON and QUASAR to speak to

     4.  A copy of OPR to speak to ORION to control BATCON

     5.  An EXEC which knows about your QUASAR to make queue entries

The following is a log of an example build of a private GALAXY system:


 TOPS-20 Command processor 4(560)
@ENABLE (CAPABILITIES) 
$!
$! First connect to a debugging directory
$!
$CONNECT (TO DIRECTORY) MISC:<HEMPHILL.GALAXY.DEBUG> 
$!
$! Now build and save debugging .EXE files
$!
$! QUASAR, the queue maintainer
$!
$GET (PROGRAM) SYS:QUASAR.EXE.55 
$DEPOSIT (MEMORY LOCATION) 135 (CONTENTS) -1
 [Shared] 
$SAVE (ON FILE) QUASAR.EXE.1 !New file! (PAGES FROM) 
 QUASAR.EXE.1 Saved
$!
$! ORION, the message clearinghouse
$!
$GET (PROGRAM) SYS:ORION.EXE.53 
$DEPOSIT (MEMORY LOCATION) 135 (CONTENTS) -1
 [Shared] 
$SAVE (ON FILE) ORION.EXE.1 !New file! (PAGES FROM) 
 ORION.EXE.1 Saved
$!
$! OPR, the operator interface
$!
$GET (PROGRAM) SYS:OPR.EXE.55 
$DEPOSIT (MEMORY LOCATION) 135 (CONTENTS) -1
 [Shared] 
$SAVE (ON FILE) OPR.EXE.1 !New file! (PAGES FROM) 
 OPR.EXE.1 Saved
$!
$! BATCON, the batch controller
$!
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 129
EXAMPLE OF A PRIVATE GALAXY BUILD


$GET SYS:BATCON.EXE.39 
$DEPOSIT (MEMORY LOCATION) 135 (CONTENTS) -1
 [Shared] 
$SAVE (ON FILE) BATCON.EXE.1 !New file! (PAGES FROM) 
 BATCON.EXE.1 Saved
$!
$! Now a directory of what we've got
$!
$VDIRECTORY (OF FILES) *.*.* 

   MISC:<HEMPHILL.GALAXY.DEBUG>
 BATCON.EXE.1;P777700    16 8192(36)   13-Feb-80 22:00:37 
 EXEC-FOR-DEBUGGING-GALAXY.EXE.1;P777700
			 82 41984(36)  13-Feb-80 04:33:50 
 OPR.EXE.1;P777700       31 15872(36)  13-Feb-80 22:00:09 
 ORION.EXE.1;P777700     44 22528(36)  13-Feb-80 21:59:45 
 QUASAR.EXE.1;P777700    40 20480(36)  13-Feb-80 21:59:27 

 Total of 213 pages in 5 files
$
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 130
RUNNING THE PRIVATE GALAXY SYSTEM


4.0  RUNNING THE PRIVATE GALAXY SYSTEM

Starting and running a private GALAXY system  is  similar  to  running
GALAXY  in the usual manner.  First QUASAR and ORION are started, then
the component you wish to debug.  You will  also  need  OPR  to  issue
operator  commands and the modified EXEC to make queue entries.  Since
you will need about five jobs, it is usually most  convenient  to  run
each component as a separate subjob under PTYCON.



4.1  Starting QUASAR

QUASAR and ORION should be started before  everything  else.   Nothing
evil happens if you start them last, but all the other components will
be waiting for these two to start.  A suggested procedure is:

     1.  Define a subjob "Q"

     2.  Connect to it

     3.  LOGIN a job under the same user name

     4.  CONNECT that job to  the  directory  in  which  you  did  the
         private GALAXY build

     5.  ENABLE

     6.  RUN QUASAR




4.2  Starting ORION

Starting ORION is as painless as starting QUASAR:

     1.  Define a subjob "O"

     2.  Connect to it

     3.  LOGIN a job under the same user name

     4.  CONNECT that job to  the  directory  in  which  you  did  the
         private GALAXY build

     5.  ENABLE

     6.  RUN ORION
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 131
Starting OPR


4.3  Starting OPR

OPR starts up using the same formula as QUASAR and ORION:

     1.  Define a subjob "OPR"

     2.  Connect to it

     3.  LOGIN a job under the same user name

     4.  CONNECT that job to  the  directory  in  which  you  did  the
         private GALAXY build

     5.  ENABLE

     6.  RUN OPR

     7.  You may now type OPR commands to  see  if  QUASAR  and  ORION
         appear to be healthy.




4.4  Starting The Component To Be Debugged

If the component you wish to debug is QUASAR, ORION, or OPR, then  you
have  already  started  it.  Breakpoints could have been set, and when
they were hit, the component could  have  been  debugged  without  any
noticable  affect  on other users of the system.  If you wish to debug
PLEASE, BATCON, LPTSPL, CDRIVE, SPRINT, or SPROUT, do the following:

     1.  Define a subjob with an appropriate ID (e.g.  B for BATCON)

     2.  Connect to it

     3.  LOGIN a job under the same user name

     4.  CONNECT that job to  the  directory  in  which  you  did  the
         private GALAXY build

     5.  ENABLE

     6.  GET the component

     7.  Enter DDT

     8.  Set breakpoints, then start the program
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 132
Starting the Modified EXEC


4.5  Starting The Modified EXEC

The file "EXEC-FOR-DEBUGGING-GALAXY.EXE" which has  been  supplied  on
the  SWSKIT  has  exactly two commands added to its repertoire.  These
are "^ESET DEBUGGING-GALAXY" and  "^ESET  NO  DEBUGGING-GALAXY".   The
effect  of  these commands is to select which one of two PIDs (Process
IDs) to communicate with:  the system QUASAR or  the  private  QUASAR.
If  "NO  DEBUGGING-GALAXY" is set, then PRINT, SUBMIT, CANCEL, MODIFY,
and the INFORMATION commands will all  cause  communication  with  the
system  QUASAR.   If "DEBUGGING-GALAXY" is set for this EXEC, then the
commands listed will communicate with the private QUASAR run  by  that
user.   For  Release  5  of TOPS-20, the distributed EXEC incorporates
this  functionality  in  the  "^ESET  PRIVATE-QUASAR"  and  "^ESET  NO
PRIVATE-QUASAR" commands, and the special EXEC is unneeded.

     1.  Define a subjob "E"

     2.  Connect to it

     3.  LOGIN a job under the same user name

     4.  CONNECT that job to  the  directory  in  which  you  did  the
         private GALAXY build

     5.  RUN EXEC-FOR-DEBUGGING-GALAXY (or the Release 5 EXEC)

     6.  ENABLE

     7.  ^ESET DEBUGGING-GALAXY (or PRIVATE-QUASAR)
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 133
EXAMPLE DEBUGGING SESSION


5.0  EXAMPLE DEBUGGING SESSION

The following is a log of a sample debugging session:


 TOPS-20 Command processor 4(560)
@!
@! First run PTYCON, so we can control five jobs from one terminal
@!
@PTYCON.EXE.7 
PTYCON> !
PTYCON> ! Now start up QUASAR as subjob Q
PTYCON> !
PTYCON> DEFINE (SUBJOB #) 0 (AS) Q
PTYCON> CONNECT (TO SUBJOB) Q
[CONNECTED TO SUBJOB Q(0)]

 2102 Development System, TOPS-20 Monitor 4(3245)
@LOG HEMPHILL (PASSWORD) 
 Job 21 on TTY222 13-Feb-80 22:18:05
Structure PS: mounted
Structure MISC: mounted
@ENABLE (CAPABILITIES) 
$!
$! Connect to directory where debugging .EXE files are
$!
$CONNECT (TO DIRECTORY) MISC:<HEMPHILL.GALAXY.DEBUG> 
$!
$! Finally run the component
$!
$RUN (PROGRAM) QUASAR.EXE.1 
% QUASAR GLXIPC Becoming  [HEMPHILL]QUASAR     (PID = 66000031)
% QUASAR GLXIPC Waiting for ORION to start
^X
PTYCON> !
PTYCON> ! Now start up ORION as subjob O
PTYCON> !
PTYCON> DEFINE (SUBJOB #) 1 (AS) O
PTYCON> CONNECT (TO SUBJOB) O
[CONNECTED TO SUBJOB O(1)]

 2102 Development System, TOPS-20 Monitor 4(3245)
@LOG HEMPHILL (PASSWORD) 
 Job 22 on TTY223 13-Feb-80 22:19:25
Structure PS: mounted
Structure MISC: mounted
@ENABLE (CAPABILITIES) 
$!
$! Connect to directory where debugging .EXE files are
$!
$CONNECT (TO DIRECTORY) MISC:<HEMPHILL.GALAXY.DEBUG> 
$!
$! Finally run the component
$!
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 134
EXAMPLE DEBUGGING SESSION


$RUN (PROGRAM) ORION.EXE.1 
% ORION  GLXIPC Alternate [HEMPHILL]QUASAR     (PID = 66000031)
% ORION  GLXIPC Becoming  [HEMPHILL]ORION      (PID = 70000032)
**** Q(0) 22:19:58 ****
% QUASAR GLXIPC Alternate [HEMPHILL]ORION      (PID = 70000032)
**** O(1) 22:19:58 ****
^X
PTYCON> !
PTYCON> ! Now start up OPR as subjob OPR
PTYCON> !
PTYCON> DEFINE (SUBJOB #) 2 (AS) OPR
PTYCON> CONNECT (TO SUBJOB) OPR
[CONNECTED TO SUBJOB OPR(2)]

 2102 Development System, TOPS-20 Monitor 4(3245)
@LOG HEMPHILL (PASSWORD) 
 Job 23 on TTY224 13-Feb-80 22:20:29
Structure PS: mounted
Structure MISC: mounted
@ENABLE (CAPABILITIES) 
$!
$! Connect to directory where debugging .EXE files are
$!
$CONNECT (TO DIRECTORY) MISC:<HEMPHILL.GALAXY.DEBUG> 
$!
$! Finally run the component
$!
$RUN (PROGRAM) OPR.EXE.1 
% OPR    GLXIPC Alternate [HEMPHILL]QUASAR     (PID = 66000031)
% OPR    GLXIPC Alternate [HEMPHILL]ORION      (PID = 70000032)
OPR>
22:19:59 	  -- Network Node 1031 is Online --

22:19:59 	  -- Network Node 2137 is Online --

22:19:59 	  -- Network Node 4097 is Online --

22:19:59 	  -- Network Node DN20A is Online --

22:19:59 	  -- Network Node MILL20 is Online --

22:19:59 	  -- Network Node SYS880 is Online --
OPR>!
OPR>! Let's take a look at our brand new queues
OPR>!
OPR>SHOW QUEUES 
OPR>
22:21:21 	  --The Queues are Empty--
OPR>SHOW STATUS PRINTER 
OPR>
22:21:27 	  --There are no Devices Started--
OPR>^X
PTYCON> !
PTYCON> ! Now start up BATCON as subjob B
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 135
EXAMPLE DEBUGGING SESSION


PTYCON> !
PTYCON> DEFINE (SUBJOB #) 3 (AS) B
PTYCON> CONNECT (TO SUBJOB) B
[CONNECTED TO SUBJOB B(3)]

 2102 Development System, TOPS-20 Monitor 4(3245)
@LOG HEMPHILL (PASSWORD) 
 Job 24 on TTY225 13-Feb-80 22:21:49
Structure PS: mounted
Structure MISC: mounted
@ENABLE (CAPABILITIES) 
$!
$! Connect to directory where debugging .EXE files are
$!
$CONNECT (TO DIRECTORY) MISC:<HEMPHILL.GALAXY.DEBUG> 
$!
$! Finally run the component
$!
$RUN (PROGRAM) BATCON.EXE.1 
% BATCON GLXIPC Alternate [HEMPHILL]QUASAR     (PID = 66000031)
% BATCON GLXIPC Alternate [HEMPHILL]ORION      (PID = 70000032)
^X
PTYCON> !
PTYCON> ! Now start up special EXEC as subjob E
PTYCON> !
PTYCON> DEFINE (SUBJOB #) 4 (AS) E
PTYCON> CONNECT (TO SUBJOB) E
[CONNECTED TO SUBJOB E(4)]

 2102 Development System, TOPS-20 Monitor 4(3245)
@LOG HEMPHILL (PASSWORD) 
 Job 19 on TTY226 13-Feb-80 22:23:00
Structure PS: mounted
Structure MISC: mounted
@CONNECT (TO DIRECTORY) MISC:<HEMPHILL.GALAXY.DEBUG> 
@!
@! Run the special EXEC, which is provided on the SWSKIT
@!
@RUN (PROGRAM) EXEC-FOR-DEBUGGING-GALAXY.EXE.1 

 TOPS-20 Command processor 4(560)-1
@ENABLE (CAPABILITIES) 
$!
$! Make this EXEC switch from system queues to private queues
$!
$^ESET DEBUGGING-GALAXY 
$!
$! Use ordinary EXEC commands to examine private queues
$!
$INFORMATION (ABOUT) OUTPUT-REQUESTS 
[The Queues are Empty]
$INFORMATION (ABOUT) BATCH-REQUESTS 
[The Queues are Empty]
$!
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 136
EXAMPLE DEBUGGING SESSION


$! Now switch back to look at system queues
$!
$^ESET NO DEBUGGING-GALAXY 
$INFORMATION (ABOUT) OUTPUT-REQUESTS 

Printer Queue:
Job Name  Req#  Limit            User
--------  ----  -----  ------------------------
* KLERR      6   1197  DEUFEL                     On Unit:0
   Started at 22:05:47, printed 314 of 1197 pages
  XXX        3     18  KAMANITZ                   /Dest:4097
  MS-OUT    18    117  BRAITHWAITE                /Unit:0
There are 3 Jobs in the Queue (1 in Progress)

$INFORMATION (ABOUT) BATCH-REQUESTS 

Batch Queue:
Job Name  Req#  Run Time            User
--------  ----  --------  ------------------------
* DUMP      16  02:00:00  OPERATOR                In Stream:0
    Job# 17 Running DUMPER Last Label: A Runtime 0:23:55
  BATCH      2  00:05:00  BLIZARD                 /Proc:FOO
  SOURCE     8  00:05:00  BLOUNT                  /After:14-Feb-80  0:00
  SRCCOM    12  00:05:00  MURPHY                  /After:14-Feb-80  0:00
  QJD4R     13  00:05:00  SROBINSON               /After:19-Feb-80  0:00
  QAR       10  00:05:00  BLOUNT                  /After:19-Feb-80  0:14
  SAVE       1  00:05:00  FICHE                   /After:19-Feb-80  9:10
There are 7 Jobs in the Queue (1 in Progress)

$!
$! Now let's submit a batch job to our own BATCON
$!
$^ESET DEBUGGING-GALAXY 
$!
$! Make a trivial batch control file
$!
$COPY (FROM) TTY: (TO) A.CTL.1 !New file! 
 TTY: => A.CTL.1

@SY A
^Z
$!
$! And submit the job
$!
$SUBMIT (BATCH JOB) A.CTL.1 
[Job A Queued, Request-ID 1, Limit 0:05:00]
$!
$! Now examine private queues
$!
$INFORMATION (ABOUT) BATCH-REQUESTS 

Batch Queue:
Job Name  Req#  Run Time            User
--------  ----  --------  ------------------------
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 137
EXAMPLE DEBUGGING SESSION


  A          1  00:05:00  HEMPHILL              
There is 1 Job in the Queue (None in Progress)

$!
$! Our job is in the batch queue, but no batch-streams have been started
$!
$^X
PTYCON> CONNECT (TO SUBJOB) OPR
[CONNECTED TO SUBJOB OPR(2)]

OPR>START (Object) BATCH-STREAM (Stream Number) 0
OPR>
22:25:40 	Batch-Stream 0  --Startup Scheduled--

22:25:40 	Batch-Stream 0  --Started--
OPR>
22:25:40 	Batch-Stream 0  --Begin--
		Job A Req #1 for HEMPHILL
OPR>
22:25:51 	Batch-Stream 0  --End--
		Job A Req #1 for HEMPHILL
OPR>
^X
PTYCON> !
PTYCON> ! Cleaning up is easy
PTYCON> !
PTYCON> KILL (SUBJOB) ALL
PTYCON> EXIT (FROM PTYCON) 
@
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 138
TECHNICAL DETAILS


6.0  TECHNICAL DETAILS

This section is to explain what happens differently when  a  component
has  had  location  135  (.JBOPS)  poked  to  -1, and to present a few
helpful tidbits of information about debugging some of  the  programs.
.JBOPS  incidentally  is  the word in the job data area (defined under
TOPS-10) which is reserved for a  program's  OTS.   GALAXY  references
this location by the symbol "DEBUGW".



6.1  GLXLIB

GLXLIB is the GALAXY library.  It consists of  a  code  segment  which
starts  at  address 400000 and a data segment at address 600000.  Each
of the programs QUASAR, ORION, OPR, PLEASE,  BATCON,  LPTSPL,  CDRIVE,
SPRINT,  and  SPROUT uses it.  Part of the initialization code of each
of these programs maps in GLXLIB as a  "high  segment".   This  is  in
effect  an  object  time  system  for  GALAXY, with many commonly used
routines.  Most of the support for the private  GALAXY  system  is  in
this  library,  enough so that OPR, PLEASE, BATCON, LPTSPL, SPRINT and
SPROUT actually have no code which cares whether they are  part  of  a
private  GALAXY.   The  initialization code in each component looks in
three places to find GLXLIB.EXE:  first on the structure and directory
that  the  component  itself came from, second on DSK:, third on SYS:.
This search order is the same for  both  the  system  GALAXY  and  the
private one.

     The actual changes implemented for  the  private  GALAXY  are  as
follows:

     1.  Ordinarily, a component which stopcodes  will  save  a  crash
         file on disk.  When debugging, however, the crash file is not
         written.  In either case, if DDT is loaded with the  program,
         the stopcode will invoke a jump to DDT.

     2.  GALAXY components do not require receiving privileged packets
         under debugging.

     3.  Ordinarily, QUASAR and ORION get special system PIDs for IPCF
         communications.   When debugging, they get PIDs with names of
         the  form  "[username]QUASAR"  and  "[username]ORION".    All
         GALAXY components will then look for these PID names.  Even a
         pseudo-GALAXY component, such as MOUNTR or  IBMSPL,  will  be
         able to find these PIDs if its location 135 has been poked to
         -1, simply because it uses GLXLIB.

     4.  GALAXY components print messages like:
         "% QUASAR GLXIPC Waiting for ORION to start"
         only while debugging.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 139
TECHNICAL DETAILS


     5.  ORION and QUASAR print  messages  about  PIDs  they  acquire,
         like:
         "% QUASAR GLXIPC Becoming  [HEMPHILL]QUASAR     (PID =
         66000031)"

     6.  All components print messages about  the  special  PIDs  they
         find for QUASAR and ORION, like:
         "% ORION  GLXIPC Alternate [HEMPHILL]QUASAR     (PID =
         66000031)"




6.2  QUASAR

     1.  QUASAR reads and writes private  queues  from  its  connected
         directory.  The full filespec is 
         "DSK:PRIVATE-MASTER-QUEUE-FILE.QUASAR"

     2.  QUASAR does absolutely no  privilege  checking.   Anyone  can
         modify or kill any request in the queues (if they know how to
         speak to this private QUASAR).




6.3  ORION

     1.  ORION  will  create  a   log   file   under   the   name   of
         "DSK:ORION-TEST.LOG"                instead                of
         "PS:<SPOOL>ORION-SYSTEM-LOG.001", and does no renaming of any
         old log files present.

     2.  ORION will not set up any NSP  servers  when  debugging.   It
         therefore  will  not  speak  to  remote nodes to run OPRs for
         them.  However, there  are  hooks  for  ORION  to  initialize
         "SRV:128" instead of the usual "SRV:47" when debugging.




6.4  QMANGR

QMANGR has also been modified to look for a private  QUASAR's  PID  if
the low segment has a non-zero entry in .JBOPS.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 140
TECHNICAL DETAILS


6.5  CDRIVE

CDRIVE can pose a problem to debug,  since  it  has  potentially  many
inferior forks all executing the same code, so each fork automatically
loads SDDT into its address space and jumps to it when it  starts  up.
After setting any breakpoints or otherwise modifying this fork's code,
the debugger types "GO<ESC>G" to resume the fork.  While debugging, if
the  fork  terminates (crashes), CDRIVE will not go through its normal
purging of the crashed fork, so that its status can be examined.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 141
EXAMINING GALAXY CRASH FILES


7.0  EXAMINING GALAXY CRASH FILES

All GALAXY components use the stopcode facility  supplied  by  GLXLIB.
This  facility  dumps  the  ACs, program error codes, associated error
messages, program version numbers, and the last nine locations of  the
stack  onto  the  controlling  terminal  of  the program executing the
stopcode.  In addition, a crash file is created with the name  of  the
form:   PS:<SPOOL>program-stopcode-CRASH.EXE.  This .EXE file contains
the entire core image  of  the  program  which  has  crashed,  and  is
extremely   useful   in  determining  the  cause  of  the  crash.   In
particular, there is a block of data referred to as the "crash  block"
which usually contains the information most pertinent to the debugger.
This information can be read with either DDT or FILDDT.  Its  contents
are tabulated as follows:

 Location  Data

 .SPC   PC of stopcode

 .SCODE   SIXBIT name of stopcode

 .SERR   Last TOPS-20 error code

 .SACS   Contents of the sixteen accumulators

 .SPTBL   Base address of page table used by
      GLXMEM

 .SPRGM   Name of program in SIXBIT

 .SPVER   Program version number

 .SPLIB   GLXLIB version number

 .LGERR   Last GALAXY error code

 .LGEPC   PC of last GALAXY error return
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 142
DEBUGGING MOUNTR


                            DEBUGGING MOUNTR
                            ----------------



1.0  INTRODUCTION

     This write-up was prepared to assist developers  and  maintainers
in understanding and debugging the TOPS-20 tape and structure mounting
program, MOUNTR.   It  is  assumed  that  the  reader  has  a  working
knowledge  of TOPS-20 assembler language coding and the set of TOPS-20
monitor calls.



2.0  SOURCES OF INFORMATION

     This document will serve primarily as a guide to debugging MOUNTR
crashes.   Much of the information needed to understand the data bases
and the operation of MOUNTR resides within the first 20 or 30 pages of
the MOUNTR code itself.  Just make a listing and start reading.



3.0  DEBUGGING A LIVE MOUNTR

     MOUNTR can  be  debugged  as  a  standard  GALAXY  component,  by
depositing -1 in location 135 of MOUNTR.EXE.  MOUNTR will aquire a PID
for a private copy of QUASAR and will communicate with it.

     To debug a MOUNTR which is actually recognized by the  system  as
the  "real"  MOUNTR  it is usually best to run it as a seperate job by
including the following commands in SYSJOB.RUN:

     JOB n /LOGIN OPERATOR XX OPERATOR
     ENABLE
     GET SYS:MOUNTR
     START
     /

     This job can be reached by use of the ADVISE command, MOUNTR  can
be  killed  and a new copy can be started with appropriate breakpoints
or patches installed.  Before MOUNTR can be patched or breakpointed it
is  necessary  to issue the DDT command $W since MOUNTR write protects
itself during execution.  For example:

     @ENABLE
     $ADVISE OPERATOR
      TTY2, NRT20
      TTY235, OPR
      TTY234, MOUNTR
      TTY233, PTYCON
      TTY232, EXEC
     TTY: 234
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 143
DEBUGGING A LIVE MOUNTR


      [Pseudo-terminal, confirm]
      Escape character is <CTRL>E, type <CTRL>^? for help
      OPERATOR Job 3 MOUNTR

     LINK FROM MOSER, TTY 60
      [Advising]
     ^C                                   !KILL OLD MOUNTR
     ^C
     $GET SYS:MOUNTR                      !GET A NEW ONE
     $DDT                                 !ENTER DDT
     DDT
     $W                                   !YOU MUST DO THIS
     USM/   MOVEI 2,BSRRTA#   .$B         !SET SOME BREAKPOINTS OR WHATEVER
     DDSCIH/   JSP 16,SAVEQR#   .$B   
     ^Z                                   !EXIT DDT
     $START                               !START MOUNTR

     Depositing 1 in location CDFLG will enable CONTROL-D  interrupts.
Typing CONTROL-D when enabled causes MOUNTR to enter DDT.



4.0  MOUNTR CRASHES

When MOUNTR crashes, it saves its core image in the file,

     PS:<SPOOL>MOUNTR-CRASH.EXE

All crashes are initiated by a CALL STOP instruction.  This may result
from  a  logic  inconsistency,  or  it can happen if MOUNTR receives a
software interrupt on a panic channel.  The STOP routine gathers  some
important  data  and saves it in core.  It then types a message giving
the name of the filespec wherein it is  saving  the  core  image,  and
issues  an SSAVE JSYS to save the image.  After restoring the ACs from
the time of the crash, MOUNTR halts.

To begin debugging a MOUNTR crash, follow these steps:

     1.  GET PS:<SPOOL>MOUNTR-CRASH.EXE

     2.  Get into DDT and type STOP1$G.  This will load DDT's ACs with
         MOUNTR's  ACs  at the time of the crash and exit to the EXEC.
         Give the DDT command to the EXEC again to get back into DDT.

     3.  Look at P (AC 17).  If it contains PDL1+something, there  has
         been  a  stack  trap,  and  the routine STOPP was called as a
         result.  The location BADP contains the contents of P at  the
         time of the trap.

     4.  If P contains PDL+something, type TAB to look at the  top  of
         the  stack.   This  will  contain one plus the address of the
         CALL STOP instruction.   Type  TAB  and  ^H  to  display  the
         CALL STOP instruction that invoked the crash.  If MOUNTR died
         as a result of a panic channel interrupt, LPC1  will  contain
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 144
MOUNTR CRASHES


         one  plus  the address of the instruction which was executing
         at the time of the interrupt.



The following locations and data structures are  helpful  in  locating
the cause of difficulties in MOUNTR:


NAME FUNCTION
---- --------
CRSHAC Contains the ACs at the time the STOP routine was called.

LPC1 For crashes caused by panic channel interrupts, LPC1 contains one
        plus the address of the instruction that caused the crash.

LSTERR Contains the last TOPS-20 error.

MRPDB PDB for last IPCF message received by MOUNTR

MSTRBK Used as an argument block for MTOPR and MSTR monitor calls.

RBUF Last IPCF message received  by  MOUNTR  (particularly  useful  if
        SSSDAT+1 contains MRCVIH, indicating that MOUNTR crashed while
        processing an incoming IPCF message).

SSSDAT When MOUNTR crashes,  SSSDAT+1  contains  the  address  of  the
        routine that was invoked by MOUNTR's scheduler.  Starting here
        and using the stack, you can trace the execution  of  MOUNTR's
        code that led to the crash.

TBUF Last IPCF message sent by MOUNTR.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                             Page 145
DEBUGGING PA1050


                           DEBUGGING PA1050
                           ----------------


In order to debug the compatibility package you must have  a  copy  of
the  file called PAT.EXE.  PA1050 is just the system name for PAT.  If
there is no copy of PAT.EXE,  then  take  the  source  program  called
PAT.MAC, and assemble it, thereby creating a sharable save file called
PAT.EXE.  To debug the compatibility package the following  steps  are
required.

$RESET
$GET PROG          ;Where PROG may be any program you choose
$MERGE PAT         ;PAT is the source name for PA1050
$DDT
PAT$:   MOVBF$B    ;You set your breakpoints here
DEBUG$G
$G                 ;You must type  $G  twice  because  of  the  double
                    symbol table


                                 NOTE

               Some  of  the  error  messages  you  may
               receive  from PA1050 may not be the true
               error  message.   To  have  the  correct
               error  message printed out use an ERJMP,
               or an ERCAL after the JSYS it fails  on.
               For  more information on ERJMP and ERCAL
               refer to  the  Monitor  Calls  Reference
               Manual.


In order to build the compatibility package the  following  steps  are
required:

$LOAD /CREF PAT.MAC
$START
$SAVE PAT
$GET PAT
$DDT
MAKEPF$G
Output file: PA1050.EXE
$DDT
UDDT
40000,,0$X
^Z
$I MEM

The start after loading causes  the  program  to  be  moved  from  its
location  to  its  running location in high core.  The symbol table is
also moved, and the pointer adjusted.  A sharable save file  of  pages
700-777  must  be  made  for  debugging.   This  is  created  when you
MAKEPF$G, then execute 40000,,0 in UDDT.  When  you  type  I  MEM  you
should now have PA1050.EXE in 700-730.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 146
COPYING FLOPPY DISKS


                          COPYING FLOPPY DISKS
                          --------------------


This is  a description  of the  front end  program COP  (quick  floppy
copy). This program  should be  used to  create backup  copies of  the
distributed set of floppies.

CAUTIONARY NOTES ABOUT FLOPPY DISKS:

1)	Only IBM floppies should be used.  Other floppies  may
	destroy the DX11 drives.

2)	Floppies have  a  finite  life while  mounted  in  the
	drive. The heads do not  float, and the floppies  turn
	continuously.  This causes the magnetic surface to  be
	eaten away. Minimum floppy life is something like  200
	hours.

3)	Floppies which are dropped, badly shocked, or used  as
	frisbees will lose their  sector headers, and will  be
	good for nothing.

4)	Never put a floppy which you suspect is bent into  the
	drive -- it may damage the drive. 

5)	COP  is discussed  also in  the  Front End File System
	Specification  manual  in  Volume  14 of  the  TOPS-20
	Software Notebooks, section 3.2.


COP COMMANDS:

	The basic COP command string is of the form:

	  COP> <destination device>/<switch>=<source device>

	To  enter  COP, type a Control-backslash to get to the
	Parser,  then  MCR COP  to start up COP.  The floppies
	should have  already been mounted with  MCR MOUNT, and
	should  then be dismounted with  MCR DMOUNT  after the
	copy.

COP SWITCHES:

	/HE	Help, types a list of switches
	/RD	Read Device, check for errors
	/CP	Copy (default action)
	/VF	Verify copy (default when copy in effect)
	/ZE	Zero the device
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 147
COPYING FLOPPY DISKS


COP EXAMPLE:

	The  following  sequence  of commands will  succeed in
	copying  the contents of the floppy in DX0:  (the left
	hand drive) onto the floppy in DX1:, and verifying the
	operation.

	^\
	PAR>MCR MOU
	MOU>DX0:
	Mount completed
	MOU>DX1:
	Mount completed
	MOU>^Z
	^\
	PAR>MCR COP
	COP>DX1:=DX0:
	COP>^Z
	^\
	PAR>MCR DMO
	DMO>DX0:
	Dismount Complete
	DMO>DX1:
	Dismount Complete
	DMO>^Z

	The copy takes about two minutes, the verify about the same.
	Take  care to  specify the  correct source  and  destination
	devices.

CAUTIONARY NOTE--

	If you  COP for  many generations  you will  build  up
	ghost bad  blocks until  RSX will  declare the  floppy
	useless. This is  because in each  generation the  bad
	block file of the  old floppy is  copied onto the  new
	(which will have its bad blocks in different  physical
	locations).  A way around this  is to use PIP for  any
	non-boot copies once every several generations.  
TOPS-20 TROUBLE-SHOOTING HANDBOOK                               Page 148
THE SWSKIT TOOLS PROGRAMS


                       THE SWSKIT TOOLS PROGRAMS
                       -------------------------





Included on the SWSKIT are a number of utility programs,  as  summarized
below.   These tools have been found to have at least some usefulness in
the past in a debugging environment.  Most of these programs require the
user  to have WHEEL or OPERATOR privileges to work, but also most are of
the "show and tell but don't touch" category, so  they  are  in  general
"safe" to run.

We have cleaned up some of the old ones a bit, added a few new ones, and
checked them all out to the extent that they will all run.  There should
even be some documentation, at least a HELP file, with each program.

While we do not actively "support" these programs, we are quite  willing
to accept complaints and suggestions and submissions from the field.

These are the "standard" tools;  the Marlboro Support Group is generally
familiar  with  their  operation and quirks, and in providing support to
the field may request that one or more of the  programs  be  used  at  a
customer  site  to  diagnose or assist in correcting a problem.  This is
generally more effective than random poking about in DDT, or  trying  to
learn the peculiarities of whatever the customer may have available.

And now, the current collection:




          PROGRAM                       DESCRIPTION
          -------                       -----------


          ACTDMP              This    program    will    convert    an
                              ACCOUNTS-TABLE.BIN   file  back  into  a
                              sequence of commands that created it for
                              debugging purposes.

          CHANS               This   program   will   produce   system
                              configuration, and status information on
                              tapes and disks.

          DIRPNT              This program will list the  contents  of
                              the blocks in a disk directory.

          DIRTST              This program will check the format,  and
                              list   any  invalid  data  in  directory
                              files.
TOPS-20 TROUBLE-SHOOTING HANDBOOK                             Page 149
THE SWSKIT TOOLS PROGRAMS


          PROGRAM                       DESCRIPTION
          -------                       -----------

          DS                  This  program  will   provide   software
                              diagnostic help concerning the disk file
                              system.   It  can   also   perform   the
                              functions of READ, FILADR, and UNITS.

          DSKERR              This program will provide  a  convenient
                              listing of the hard and soft disk errors
                              that have occurred.

          DX20PC              This program will trace the microcode PC
                              in the DX20.

          ENVIRONMENT         This  program  will  type  out  CPU  and
                              memory configuration information.

          JSTRAP              This program will produce information in
                              a  log on any JSYS, including the PC and
                              arguments used.

          MONRD               This program will allow  you  to  easily
                              examine the running monitor.

          MTEST               This  program  will  allow  the  you  to
                              insert   MONITOR  instruction  execution
                              tests anywhere in the monitor.

          REV                 This program will allow  you  to  easily
                              alter, edit, delete, obtain information,
                              etc.  on files.

          SWSERR              This  program  produces   a   convenient
                              listing of BUG HLT/CHK/INF occurrences.

          TYPVF7              This program is useful  for  typing  out
                              the contents of a VFU file in a readable
                              form.

          UNITS               This   program   will   produce   status
                              information on disk drives.



[End of Handbook]