Google
 

Trailing-Edge - PDP-10 Archives - 6.1_emacs_manuals_1er - manuals/klad20-user-guide.doc
There are no other files named klad20-user-guide.doc in the archive.


CHAPTER 1       STARTING UP THE SYSTEM

        1.1     BOOTING THE SYSTEM . . . . . . . . . . . . . . . . 1-1
        1.2     ATTACHING TO PTYCON  . . . . . . . . . . . . . . . 1-6
        1.3     PTYCON JOBS  . . . . . . . . . . . . . . . . . . . 1-6
        1.4     LOGGING ONTO THE SYSTEM  . . . . . . . . . . . . . 1-7
        1.5     JOB PARAMETERS.  . . . . . . . . . . . . . . . . . 1-8


CHAPTER 2       CONFIGURING THE SYSTEM

        2.1     WHEN TO RUN THE CONFIGURATION PROGRAM  . . . . . . 2-1
        2.2     RUNNING THE CONFIGURATION PROGRAM  . . . . . . . . 2-1
        2.2.1     CONFIG COMMANDS. . . . . . . . . . . . . . . . . 2-2
        2.2.2     Customer Name. . . . . . . . . . . . . . . . . . 2-3
        2.2.3     ACCEPTANCE RUNTIME.  . . . . . . . . . . . . . . 2-3
        2.2.4     UETP Auto Start. . . . . . . . . . . . . . . . . 2-3
        2.2.5     Disk Drives. . . . . . . . . . . . . . . . . . . 2-3
        2.2.6     Magtapes.  . . . . . . . . . . . . . . . . . . . 2-4
        2.2.7     DC20 Lines.  . . . . . . . . . . . . . . . . . . 2-5
        2.2.8     Lineprinters.  . . . . . . . . . . . . . . . . . 2-5
        2.2.9     DN20's . . . . . . . . . . . . . . . . . . . . . 2-6
        2.2.9.1     CONFIGURING FOR DECNET.  . . . . . . . . . . . 2-6
        2.2.9.2     Configuring For IBMCON.  . . . . . . . . . . . 2-8
        2.2.10    AN20.  . . . . . . . . . . . . . . . . . . . . . 2-9
        2.2.11    Memory Size. . . . . . . . . . . . . . . . . . . 2-9
        2.2.12    CONFIG INSTRUCTIONS. . . . . . . . . . . . . .  2-10
        2.3     CHANGING THE CONFIGURATION . . . . . . . . . . .  2-10
        2.4     BUILDING THE DECNET NODES. . . . . . . . . . . .  2-12
        2.5     BUILDING THE DISK STRUCTURES.  . . . . . . . . .  2-14
        2.6     INITIALIZING THE ERROR FILES . . . . . . . . . .  2-16
        2.7     RUNNING MAKDMP . . . . . . . . . . . . . . . . .  2-16


CHAPTER 3       RUNNING THE ACCEPTANCE

        3.1     PRE ACCEPTANCE CHECKS  . . . . . . . . . . . . . . 3-1
        3.2     STARTING THE ACCEPTANCE  . . . . . . . . . . . . . 3-1
        3.3     MONITORING THE ACCEPTANCE  . . . . . . . . . . . . 3-4
        3.3.1     THE BATCH JOBS . . . . . . . . . . . . . . . . . 3-4
        3.4     UETP STATUS  . . . . . . . . . . . . . . . . . . . 3-5
        3.5     STOPPING AND RESTARTING THE JOBS.  . . . . . . . . 3-6


CHAPTER 4       MANUAL TESTS

        4.1     DC20 LINES TEST  . . . . . . . . . . . . . . . . . 4-1
        4.2     DN20 - DECNET  . . . . . . . . . . . . . . . . . . 4-1
        4.2.1     RELOADING THE NODE.  . . . . . . . . . . . . . . 4-1
        4.2.2     DECNET TESTS FOR SYNCHRONOUS LINES   . . . . . . 4-2
        4.3     DN20 IBMCON  . . . . . . . . . . . . . . . . . . . 4-3
        4.4     DN20 CRASH DUMP  . . . . . . . . . . . . . . . . . 4-5
        4.4.1     IBMCON SELECTED  . . . . . . . . . . . . . . . . 4-5
        4.4.2     DECNET SELECTED (IBMCON DE-SELECTED) . . . . . . 4-6
        4.5     RUNNING DIAGNOSTICS IN USER MODE . . . . . . . . . 4-6
                                                                Page 2


CHAPTER 5       SYSTEM ERROR REVIEW

        5.1     SPEAR REVIEW . . . . . . . . . . . . . . . . . . . 5-1
        5.2     MASSRT . . . . . . . . . . . . . . . . . . . . . . 5-3
        5.3     MF20-TGHA  . . . . . . . . . . . . . . . . . . . . 5-5
        5.4     REVIEW.MIC . . . . . . . . . . . . . . . . . . . . 5-6
        5.5     DATA COLLECTION  . . . . . . . . . . . . . . . . . 5-6


CHAPTER 6       CLEANING UP THE PACK


APPENDIX A

        A.1     UETP SELECTABLE TESTS  . . . . . . . . . . . . . . A-1


APPENDIX B

        B.1     MFG SPECIAL FILES. . . . . . . . . . . . . . . . . B-1







                             INTRODUCTION



This  document  contains  the  directions  and  parameters   for   the
Manufaturing TOPS-20 UETP acceptance run for KL10 systems and options.
Covered  in  this  hand  book  are  the  start-up  and   configuration
procedures  as  well  as  help in the monitoring and evaluation of the
acceptance run.

This document is  intended  as  a  guide  to  performing  the  Monitor
acceptance portion of the current Manufacturing test process using the
lastest revision of the KLAD20 pack only which is:

        KLAD20-5.1-Y-A.



History:

     1.  Originated May 1980 as HAND20.MEM - Tom Duda

     2.  Updated for new system options 1981 - 1983 Bob Sthilaire.

     3.  Updated for  current  CONFIG  version,  DECNET  testing,  and
         general format and accuracy Sept.  1984 - Tom Duda.
                                                                Page 3


Format:

Throughout this document quotation marks  "  "  are  used  to  delimit
commands  that  are  to  be typed into the system.  (Type only what is
enclosed in the quotation marks.  Do not type the quotation marks).

A "^" means the CTRL key.  A "^X" means hold down  the  CTRL  key  and
depress the X key.

A "$" (enclosed in quotes means  type  the  ESC  (or  ALT)  key.   For
example:   @"DIR$"  which  when  typed  would echo as:  @DIRECTORY (OF
FILES) " The command may also appear as @"DIR$ECTORY (OF FILES)  "  to
show both the required typein "DIR$" as well as the full command.

A "<CR>" means the RETURN key.  This is used when no input preceeds  a
carriage  return.   For  all  other  commands the "<CR>" following the
command is implied.











                              CHAPTER 1

                        STARTING UP THE SYSTEM



1.1  BOOTING THE SYSTEM
To boot the system, mount the KLAD pack write enabled on  dual  ported
drive  0  which has one port connected to RH20 #0 and the other to the
RH11 in FE0.  Set the port select switch  to  the  programmable  (A/B)
position.

Normally the KLAD is booted in one of two ways;   via  the  disk  boot
switch  or  the  switch  register  switch.   By booting via the switch
register you are allowed to enter the KL initialization  dialogue  KLI
and  specify  what  memory modules and caches are to be used.  Then if
you answer "YES" to the KLI "WRITE CONFIGURATION FILE"  question,  the
configuration will be recorded in the file KL.CFG located in the front
end area DB0:[5,5].  Then if the system is booted via the disk  switch
the proper microcode will automatically be loaded and cache and memory
will be enabled according to what had been previously written into the
configuration file.

A third method is via the floppy switch.  This is necessary only  when
the  front  end monitor does not already exist on the KLAD for example
when a KLAD is being built or updated.

In any case the BOOT ENABLE switch  must  be  depressed  simutaneously
with the desired boot switch to start the boot.
        
-----------------------------------------------------------------
!                                                               !
!                         O   O                                 !
!                                                               !
!                                                               !
!     ...  ...  ...  ...      ...      ...                      !
!     : :  : :  : :  : :      : :      : :                      !
!     ...  ...  ...  ...      ...      ...                      !
!                                                               !
!  SW REG  DSK  FLPY ENA      PWR      EMER                     !
!---------------------------------------------------------------!

PDP11 SWITCHES  15  14 13 12  11 10 9  8 7 6  5 4 3  2 1 0
OCTAL 207                                X           X X X

The following is an example of booting a 2060 system.  For a  detailed
STARTING UP THE SYSTEM                                        Page 1-2


explanation  of  the  KLI  dialogue  and  monitor startup refer to the
Tops-20 Operator's Guide.

Set the PDP11 switches to octal 207 and simultaneously depress the  SW
REG and BOOT ENABLE switches shown above.

RSX-20F VB13-41D 14:06 21-FEB-80

[SY0: REDIRECTED TO DB0:]
[DB0: MOUNTED]
KLI -- VERSION VB15-13 RUNNING
KLI -- ENTER DIALOG [NO,YES,EXIT,BOOT]?
KLI>"YE"
KLI -- KL10 S/N: 2485., MODEL B, 50 HERTZ
KLI -- KL10 HARDWARE ENVIRONMENT:
        MCA25 CACHE PAGER
        MOS MASTER OSCILLATOR
        EXTENDED ADDRESSING
        INTERNAL CHANNELS
        CACHE

KLI -- SELECT PAGE TABLE [FILE,BOTH,0,1]?
KLI>"BOTH"
KLI -- PAGE TABLE SELECTED: 0,1
KLI -- RELOAD MICROCODE [YES,VERIFY,FIX,NO]?
KLI>"YE"
KLI -- MICROCODE VERSION 352 LOADED
KLI -- RECONFIGURE CACHE [FILE,ALL,YES,NO]?
KLI>"ALL"
KLI -- ALL CACHES ENABLED
KLI -- CONFIGURE KL MEMORY [FILE,ALL,REVERSE,FORCE,YES,NO]?
KLI>"FORCE" (initializes the MF20)
KLI -- STARTING MF20 DBE SCAN.  WAIT 25 SEC/256K.

MEMORY RESOURCES:
CONTROLLER ADDRESS  TYPE  MODULES/GROUPS
                          7 6 5 4 3 2 1 0

        10          MF20  0 0 0 0 0 0 0 4

KLI -- CONFIGURE MOS MEMORY [ALL,YES,NO]?
KLI>"ALL"

LOGICAL MEMORY CONFIGURATION.
  ADDRESS  SIZE  INT  TYPE CONTROLLER
 00000000  256    4   MF20  10

KLI -- LOAD KL BOOTSTRAP [FILE,YES,NO,FILENAME]?
KLI>"YE"
KLI -- WRITE CONFIGURATION FILE [YES,NO]?
KLI>"YE"
KLI -- CONFIGURATION FILE WRITTEN

When the Configuration file is written the default configuration  (DSK
Boot) will be that which was just entered.
STARTING UP THE SYSTEM                                        Page 1-3



KLI -- BOOTSTRAP LOADED AND STARTED

At this point the default bootstrap program BOOT.EXB has  been  loaded
into the Ten memory and the Ten continues the dialogue...

BOOT> "<CR>"

A carriage return loads the default monitor  <SYSTEM>MONITR.EXE.   For
MFG  purposes  the  correct Monitor generally depends on the amount of
memory on the system.  When you run the CONFIG  program  to  configure
the  system  you will be instructed to copy the correct monitor to the
default file.

[PS MOUNTED]

At this point SETSPD runs and examines the file <SYSTEM>5-1-CONFIG.CMD
to  initialize  various  system  parameters  i.e  setting  tty speeds,
defining system logical names, loading lpt rams etc.

system restarting, wait...
ENTER CURRENT DATE AND TIME:

The following are examples of acceptable formats.  For example MAY  2,
1980 at 1:05 pm could be entered as:

        "2-MAY-80 1305"
        OR
        "5-2-80 1305"
        OR
        "5-2-80 105PM"

YOU HAVE ENTERED FRIDAY, 2-MAY-1980 105 PM,
 IS THIS CORRECT (Y,N) "Y"

Double check to make sure the time is  correct  otherwise  this  "time
warp"  can  cause  much  confusion for example when trying to evaluate
SPEAR reports.

WHY RELOAD?

By typing a "?" you will recieve a list of  possible  responses  which
are abbreviations of common reasons for a reload.  By using the "OTHER
" response you can type in  a  comment  of  up  to  80  characters  to
describe the reload.  For example:
"OTHER RESTART AFTER REPLACING BAD HEAD 6 ON RP06 #2543"
In any case the response will be recorded in the system  reload  entry
in SPEAR.

WHY RELOAD? "OTHER CONFIG"

RUN CHECKD? 

CHECKD is a program that performs a bit-table  and  consistency  check
for  the  public structure.  If this is the first time you are booting
STARTING UP THE SYSTEM                                        Page 1-4


the pack or if there have been any crashes which  may  have  destroyed
disk files you should answer "Y".  If CHECKD reports any "failures" or
if there are excessive lost pages i.e.   500  lost  pages  report  the
problem to M.E.  software.

RUN CHECKD? "Y"

[CHECKING FILE CONSISTENCY]

[WORKING ON STRUCTURE - PS:]

%REBUILDING SYMBOL TABLE FOR PS:<ROOT-DIRECTORY> [OK]
%REBUILDING SYMBOL TABLE FOR PS:<DNGEN> [OK]
%REBUILDING SYMBOL TABLE FOR PS:<UETP> [OK]

LOCAL COUNT OF FILE PAGES: 22793
LOCAL COUNT OF OVERHEAD PAGES: 12672
LOCAL COUNT OF USED PAGES: 35465

THERE ARE NO LOST PAGES.

RUNNING DDMP

SYSJOB 4(11) STARTED AT  2-MAY-80 1310

The SYSJOB program reads the file  PS:<SYSTEM>SYSJOB.RUN.   This  file
contains  commands that start various system support programs.  One of
the jobs that will be started is PTYCON, the pseudo console controller
job.   It  will  then take the PTYCON.ATO command file and log in more
jobs one of which is the OPR (Operator Command Language) job.  This is
the  job  that  interfaces with system programs.  Under PTYCON.ATO OPR
will take the command file SYSTEM.CMD to  automaticaly  start  up  the
batch streams, line printer ,card reader etc.

RUN SYS:ORION

****
 2-MAY-82 13:11:22 -TGHA 2(6) RUNNING FIRST TIME.
****
RUN SYS:MAPPER
RUN SYS:QUASAR
RUN SYS:MOUNTR
RUN SYS:INFO
RUN SYS:MAILER
RUN SYS:MAPPER
RUN SYS:CDRIVE
JOB 0 /LOG OPERATOR XX OPERATOR
ENA
^ESET LOGIN PSEUDO
^ESET LOGIN CONSOLE
^ESET OPERATOR
PTYCON
GET SYSTEM:PTYCON.ATO
/JOB 1/LOG OPERATOR XX OPERATOR
ENA
STARTING UP THE SYSTEM                                        Page 1-5


RUN SYS:BATCON
/
SJ  0:
SJ  1:  SN: 1234 RELEASE 5.0, KLAD20-W-5-1.0-A, TOPS-20 MONITOR 5.1(4747)
SJ  0: @LOG OPERATOR OPERATOR
SJ  0:  JOB 1 ON TTY206 2-MAY-82 13:11:47
SJ  1: @LOG OPERATOR OPERATOR
SJ  1:  JOB 2 ON TTY207 2-MAY-82 13:11:47
SJ  0:  FRIDAY, MAY 2 1982 13:11:48
SJ  1:  FRIDAY, MAY 2 1982 13:11:52
SJ  0:  END OF LOGIN.CMD.1
SJ  0: $ENA
SJ  1:  END OF LOGIN.CMD.1
SJ  1: $ENA
SJ  1: $RUN SYS:BATCON
SJ  0: $^ESET LOGIN PSEUDO
SJ  0: $^ESET LOGIN CONSOLE
SJ  0: $^ESET OPERATOR
SJ  0: $PTYCON
SJ  0: PTYCON> GET SYSTEM:PTYCON.ATO
SJ  0: PTYCON> SILENCE

[From OPERATOR on line 210: SYSTEM IN OPERATION]
SJ  0: PTYCON.LOG.1
SJ  0: PTYCON> W ALL
SJ  0: OPR(0)     3          OPERATOR   OPR        TI          0:0:1
SJ  0: UETP(1)    5          F-S        EXEC       TI          0:0:0
SJ  0: O(2)       4          OPERATOR   EXEC       TI          0:0:0

At this point the system is ready for timesharing.  If the system  has
already  been configured for the automatic UETP startup the SYSJOB.RUN
file will cause the PTYCON subjob UETP to take UETP.CMD which will  in
turn  start  up  the  UETP acceptance.  If this is the case you should
wait for the auto files to finish starting up  all  the  tests  before
attaching  to  the PTYCON job (explained in the following section) and
continue with section "STARTING THE ACCEPTANCE".  If you have not  yet
configured  the  system for acceptance refer to Chapter 2 "CONFIGURING
THE SYSTEM".
STARTING UP THE SYSTEM                                        Page 1-6


1.2  ATTACHING TO PTYCON
After the system has completed it's ato boot you should attach the CTY
to  the  Operator  job  which  is  running PTYCON to get access to the
subjobs running under it.  To do this type:  (at the CTY)

        "^C"

You will get a response similar to:

        MFG EVALUATION SYSTEM 2091 , TOPS-20 Monitor 5.1(5101)

Type:   "ATT OPERATOR 1"

Response will be:

        [Attached to tty(some #), confirm]

Type: "<CR>"

Response is:

        Password:

Type the operator password which is "KLAD" and "<CR>".

        Note: The password will not echo.

To get to the PTYCON level type:

        "^X"


1.3  PTYCON JOBS
PTYCON (pseudo teletype controller) is a program that  allows  you  to
login  and  control  from  a single termial up to 12 independent jobs.
The following paragraphs explain some basics  about  PTYCON  that  you
will  need  to know to run the acceptance.  For a complete description
of PTYCON refer to the TOPS-20 OPERATOR'S COMMAND  LANGUAGE  REFERENCE
MANUAL # AA-H600A-TM Chapter 4.

There will be at least three jobs running under the PTYCON job.

PTYCON> "W ALL"
 OPR(0)     3          OPERATOR   OPR        TI          0:0:1
 UETP(1)    5          F-S        UETP       TI          0:0:0
 O(2)       4          OPERATOR   EXEC       TI          0:0:0

Here subjob 0 (system job  3)  defined  as  OPR  is  logged  into  the
OPERATOR  area  and  is  running  OPR,  the general operator interface
program which is used to communicate with  GALAXY  system  components.
See OPR.HLP for a complete description of the OPR commands.

Subjob 1 defined as UETP will be used to run the UETP USER ENVIRONMENT
TEST PACKAGE program.  See RUNNING THE ACCEPTANCE.
STARTING UP THE SYSTEM                                        Page 1-7


Subjob 2 defined as O is a  free  job  that  should  be  used  to  run
programs,  type files, etc from the cty.  Avoid using the OPR and UETP
jobs for such tasks as it may conflict with their normal operation.

To connect from one subjob to another you must first type  a  "^X"  to
get  to  the  PTYCON  level then type CONN JOB where JOB is the subjob
number or the name that has been defined for the subjob.  For  example
to type out a file from the CTY while the acceptance is running...

        UETP>"^X"
        PTYCON>"REFUSE ALL"     (to block output from other subjobs)
        PTYCON>"C O"
        $"CONN <UETP.RUN>"
        $"TYPE MTA0.ERL"

and when finished return to UETP...

        $"^X"
        PTYCON>"NO REFUSE ALL"
        PTYCON>"C UETP"

Warning:

The PTYCON "REFUSE" command will block  all  output  from  the  PTYCON
subjobs  until  the  "NO  REFUSE"  command  is given at which time all
output accumulated during the refused time will be output.

DO NOT LEAVE PTYCON IS THE REFUSE MODE for more than a few minutes  or
IPCF  message  buffers may overflow causing the programs running under
PTYCON to crash (i.e.  UETP, OPR etc.).

To disable output for longer periods use the "DISCARD"  command  (same
format as "REFUSE" command) which will cause PTYCON to accept messages
and discard them without printing  them.   The  output  may  still  be
recovered by examining the PTYCON.LOG file in the <OPERATOR> area.

The same problem could develop if PTYCON, OPR or  UETP  were  left  at
EXEC level by means of the PUSH command.

Another way to inadvertently crash UETP or OPR is to partially type in
a  command  (or  any  characters) to these programs and to leave it in
that state for long time periods.  To avoid this it is  good  practice
to  hit a "<CR>" and make sure you get a prompt from the subjob before
issuing a "^X".

1.4  LOGGING ONTO THE SYSTEM
There are three areas  on  the  KLAD  pack  that  you  can  log  into:
<OPERATOR>, <F-S>, <MFG>

Type:

        "^C"

        @"LOG OPERATOR KLAD"    ;to login to OPERATOR
or
STARTING UP THE SYSTEM                                        Page 1-8


        @"LOG F-S FS"           ; to login to F-S
or
        @"LOG MFG MFG"          ;to login to MFG

All three accounts listed above (OPERATOR,  F-S  and  MFG)  have  been
built  with  WHEEL  and/or  OPERATOR priveleges which allows you total
control of the system.


1.5  JOB PARAMETERS.
When you login your job will be running EXEC which is the top  process
that your job can reach.  The following paragraphs describe some basic
information about EXEC and your logged in job which may be helpful  in
controlling  the  system.  For a complete description of EXEC commands
refer to the TOPS-20 COMMANDS REFERENCE MANUAL # AA-5115B-TM.

EXEC (and many other programs) use  the  TOPS20  recognition  features
which  helps  you  to  input  commands.  EXEC uses "full recognition".
This means that at any point of inputting a command line to  EXEC  you
can  type  a "?" and EXEC will return a list of all possible key words
or arguments that can be entered at that point.  For example,  if  you
type  a "?" at the EXEC prompt ("$" when priveleges are enabled or "@"
when priveleges are not enabled)  EXEC  will  return  a  list  of  all
possible EXEC commands.  If you type part of a command and hit "?" for
example:  "DE?" EXEC returns a list of all commands begining with "DE"
and  retypes the partial command up to the point where you hit the "?"
then wait for you to finish entering the command.

        $"DE?" Command, one of the following:
         DEASSIGN   DEBUG       DECLARE     DEFINE
         DELETE     DEPOSIT     DETACH
          or kept fork name,
          or system program name
        $DE

You need type only enough characters as makes the string unique to one
command  in  the  possible list of commands.  For example to parse the
"DEFINE" command requires "DEF".  Then you can type  a  space  without
finishing  the  command  or  hit the "ESC" (or "ALT") key to have EXEC
finish the keyword and prompt you for the next.  For example:

        $"DEF$INE (LOGICAL NAME) "

Again you can hit the "?" key to get a list or description of the next
key word(S) in the command and continue in this manner using the "ESC"
and "?" keys until the last argument in the  line  is  entered.   Then
when "<CR>" is typed EXEC attempts to execute the command.

One of the commands is "RUN" which allows you to start a program (i.e.
"RUN  <MFG>CONFIG") under control of your EXEC process.  At this point
possible commands are limited to those recognized by the  program  you
are  running.  In most cases you can return to EXEC simply by typing a
"^C".
STARTING UP THE SYSTEM                                        Page 1-9


If a LOGIN.CMD file exists in the  area  that  you  login  to,  it  is
automatically  executed  at  the  time you login.  LOGIN.CMD files are
generally used to  execute  any  commands  that  you  would  otherwise
normally  type  in  each time you login i.e.  to set up parameters for
your job or terminal.

Only the output from the system is echoed while the LOGIN.CMD file  is
being executed.  To see what the commands are type:

        $"TYPE LOGIN.CMD"

To examine your terminal setup type:

        $"I$NFORMATION (ABOUT) TE$RMINAL-MODE (FOR TERMINAL) "

To see what definitions are setup for your job type:

        $"I$NFORMATION (ABOUT) L$OGICAL-NAMES (OF) J$OB"

To see what definitions are by the system for all jobs type:

        $"I$NFORMATION (ABOUT) L$OGICAL-NAMES (OF) S$YSTEM"

Some definitions can  effect  the  way  commands  are  executed.   For
example  DSK:.  Most commands that refer to a file-spec default to the
area DSK:   unless  the  area  is  specified  in  the  command.   DSK:
defaults  to the directory which you are connected to unless DSK:  has
been defined.  For example.

        $"DEF$INE (LOGICAL NAME) DSK:$ (AS) <MFG>"
        $"CONN$ECT (TO DIRECTORY) <OPER$ATOR>"
        $"DIR$ECTORY (OF FILES) "

This will give you a directory  listing  of  the  <MFG>  area  because
"DIR<CR>"  is  the  same  as  "DIR DSK:" and DSK:  has been defined as
<MFG> so "DIR<CR>" is treated as "DIR <MFG>" no matter what  area  you
are  connected  to.   You  can  reissue the "DEFINE" command to either
change the definition or delete it.  To  delete  a  definition  simply
leave out the definition in the command:  For example

        $"DEF DSK:"

Another definition that could have a  large  effect  on  your  job  is
"SYS:".   SYS:   is  typically defined by the system from a command in
the 5-1-CONFIG.CMD file:  For example:

        $"DEF SYS: PS:<SUBSYS>,PS:<UTILITIES>,PS:<MFG>"

To run any program (PRGRAM.EXE) which resides in any area  defined  as
SYS:   you  need not type "RUN <AREA>PRGRAM".  Simply type the name of
the program because EXEC, if what you type is  not  an  EXEC  command,
searches  the SYS:  area for the program and (if its there) treats the
"command" the same as "RUN <AREA>PRGRAM".

The reason why these software features have  been  mentioned  here  is
STARTING UP THE SYSTEM                                       Page 1-10


that  sometimes  auto files that you may be instructed to execute will
leave certain job parameters in a state other than normal defaults.











                              CHAPTER 2

                        CONFIGURING THE SYSTEM



2.1  WHEN TO RUN THE CONFIGURATION PROGRAM

You should run the configuration program:

        1. When you obtain a new (or different) KLAD pack

        2. Whenever a new piece of hardware is added

        3. Whenever a piece of hardware is removed

        4. Whenever a new customer name is required



                                 NOTE

               Insure  that  any   updates   that   are
               required  for  your system are installed
               prior to running the CONFIG program.



2.2  RUNNING THE CONFIGURATION PROGRAM
To configure the system connect to the operator  job  O  from  PTYCON.
With   privileges   enabled  start  the  configuration  program.   The
following is an example of the CONFIG dialogue.

        PTYCON>"C O"
        @"ENA"
        $"CONFIG"
        
        TOPS20 CONFIGURATOR PROGRAM VER 5-1-
        TYPE 'H' FOR HELP
        PASSWORD ? "MFG"
        
There are two passwords:  "MFG" and "F-S".  If you type  "F-S"  CONFIG
will  assume that this is a field installation and will prompt you for
all devices that it can handle in a field environment.   If  you  type
"MFG"  CONFIG limits the dialogue to devices which are part of the MFG
KERNEL process which includes Lineprinters,  DC20's  and  DN20's  (and
CONFIGURING THE SYSTEM                                        Page 2-2


does not include Disk, Magtape and AN20 units).

In either MFG or F-S mode the configuration limits may  be  overridden
by  giving  the "AUDIT" command.  In audit mode CONFIG will prompt you
for all devices it can handle.

        COMMAND (at least 2 characters)  ? "AUD"
        USER AUDIT ENABLED


2.2.1  CONFIG COMMANDS. -

To get a list of commands at the "COMMAND" prompt type "H".

        COMMAND (at least 2 characters)  ? "H"
        Commands are:
        
        CONFIGURE       (Configure all devices/tests)
        CHANGE          (Configure all devices/tests for specified
                                device type i.e. Disks or Magtapes)
        ADD             (Add a test)
        REMOVE          (Remove a test)
        AUDIT           (Audit mode for total system test)
        EXIT            (Exit back to Monitor)

The first time you run CONFIG  you  should  respond  with  "CONFIGURE"
since  you  don't know exactly what has already been configured.  Once
this has been done (you know exactly how it has been  configured)  you
can  then  use  the  "CHANGE"  command to reconfigure only a specified
configuration category or use the  "ADD"  or  "REMOVE"  commands  (not
supported) to remove or add tests for individual devices.

The following is a list of each configuration category  that  will  be
entered for either F-S or MFG.
        
        CATEGORY        Input Description                       MFG     F-S
        ---------------------------------------------------------------------
        CUSTOMER NAME   System name and serial #                x
        TIME            UETP acceptance runtime default         x       x
        AUTO  UETP      Auto startup on system boot             x       x
        DISK DRIVE      Disks other than PS to be tested                x
                        Channel #, Controller #, Unit #                 
        MAGTAPE         Magtapes/Densities to be tested                 x
        DC20 LINES      # of FE0 tty lines                      x       x
        LINEPRINTER     LPT's VFU type and charater set         x       x
        DN20            DN20 syncronous line configuration      x       x
        AN20            AN20 on system or not                           x
        MEMORY          #K of memory on system                  x       x

The  following  paragraphs  describe  the  CONFIG  dialogue  for  each
configuration  category  when  you  are configuring the entire system.
For help on the  "CHANGE"  command  refer  to  section  "CHANGING  THE
CONFIGURATION".
CONFIGURING THE SYSTEM                                        Page 2-3


        COMMAND (at least 2 characters)  ? "CO"
        

2.2.2  Customer Name. -

        Customer name ........   ? "MFG Evaluation System"
        System serial number ..  ? "2091"
 
CONFIG inserts the info just entered into the <SYSTEM>MONNAM.TXT  file
which will be displayed whenever you login (after system is rebooted).

2.2.3  ACCEPTANCE RUNTIME. -

        ACCEPTANCE RUN TIME(HH:MM,PASSES,OR CONT)  ? "24:"

The value entered here will be inserted into file  RELIAB.CMD  as  the
default test time for the UETP tests.

Usually acceptance is run for X number of hours.   In  this  case  you
must  include the ":" in "24:" (hours) otherwise each test will be run
for 24 passes (regardless of how long that takes).  By  typing  "CONT"
the tests will run indefinitely untill stopped by the operator.

2.2.4  UETP Auto Start. -

        Disable UETP ATO start  up  ? "N"

If you typed "Y"  (disable  auto  start)  the  UETP  tests  would  NOT
automatically  start  up  from a system boot (allowing you to manually
select and start your choice of tests).  "N" should be typed to insure
that  testing  continues  (in  the  operator's  absence) after a power
failure or other interruption.

2.2.5  Disk Drives. -

        TYPE 'H' FOR HELP 'E' TO EXIT
        Enable DISK DRIVE testing ? "Y"

If no disk drives are to be tested type "N".   Otherwise  CONFIG  will
ask   you  to  identify  system  disks  configuration  and  will  make
structure-build (.MIC) and test (.VER) files for each drive.   At  the
end of the CONFIG dialgue you will be advised to use the structure.MIC
files to build the structures for testing.  See section "BUILDING  THE
DISK STRUCTURES".


        What is the controller ID NO. (RP20=0,RP06/7=-1,ETC.) ? "-1"

For RH20-RP04/06/07 drives there is no intermediate controller so "-1"
is  used by software to denote this.  For other disks i.e.  HSC50-RA81
the hardware selectable controller number must be entered.

        Type in the STRUCTURE NAME (E.G. 'USER')  ? "DSK11"

The structure name may consist of any 1-6 apha-numeric characters  and
CONFIGURING THE SYSTEM                                        Page 2-4


is  independent  of the physical configuration.  This will be the name
by which the system refers to the disk once the  structure  is  built.
It  is  good practice to assign a logical name that will help you keep
track of disks in a multi structure system.  In this  example  "DSK11"
refers to disk unit #1 on RH20 #1.

        What CHANNEL is the DRIVE on (0-7)  ? "1"       (RH20 # 0-7)
        What is the UNIT NUMBER (0-7)  ? "1"    (Disk unit # 0-7)
        <UETP.LIB>DSK11.VER  FINISHED   (UETP test for this disk)
        <MFG>DSK11.MIC       FINISHED   (for building disk structure)

At this point the same dialogue is repeated for each additional  disk.
The  following  is  an  example  of  an  RA81  disk unit 1 on an HSC50
controller 3 which is connected to an IPA20 which is KL10 channel 7.

        TYPE IN THE STRUCTURE NAME (E.G. 'USER')  ? "HSC31"
        WHAT CHANNEL IS THE DRIVE ON (0-7)  ? "7"
        WHAT IS THE CONTROLLER ID ? "3" (NODE)
        WHAT IS THE UNIT NUMBER (0-7,ETC.)  ? "1"
        
        <UETP.LIB>HSC31.VER   FINISHED
        <MFG>HSC31.MIC        FINISHED
        
When there are no more disks  to  configure  type  "E"  to  exit  Disk
dialogue.   After  you are done running config you will "DO DSK11.MIC"
to  build  the  structure.   Refer  to  section  "BUILDING  THE   DISK
STRUCTURES".

        What is the controller ID NO. (RP20=0,RP06/7=-1,ETC.) ? "E"


2.2.6  Magtapes. -

For each magtape CONFIG will ask for density  and  name  of  the  tape
drive.  The density entered should be the maximum operating density of
the drive.  The "Tape to be tested" must be the logical name by  which
the system will identify the drive.

During system boot,  unless  the  5-1-CONFIG.CMD  file  is  edited  to
explicitly  define  MTA's,  (this  is  NOT done by CONFIG) the TOPS-20
Monitor assigns MTA0 through MTA7 to tape drives in the physical order
that  it  sees  them.   That  is  according  to the following priority
scheme:  RH20#, TM# (or other controller#), and UNIT#.

The following diagram is an example of MTA assigment for  multi  drive
system:
CONFIGURING THE SYSTEM                                        Page 2-5



        RH20 #0     RH20 #1     RH20 #2        
           |           |           |           +--TU77 #1 = MTA4
           |           |           +--TM03 #1--+
           +RP #0      |           |           +--TU77 #0 = MTA3
                       |           |
                       |           +--TM78 #0--+--TU78 #0 = MTA2
                       +--DX20--+
                                |              +--TU72 #1 = MTA1
                                +-----TX02 ----+
                                               +--TU72 #0 = MTA0

In the configuration above, if MTA2 for example was removed (or if  it
was  not  seen  by  the monitor during system boot) then TU77 #0 would
become MTA2 and TU77 #1 would become  MTA3  (and  MTA4  would  not  be
available).

Knowing what the  MTA  configuration  SHOULD  BE  answer  the  correct
maximum density and name of each magtape.  When all magtapes have been
configured type "E".  The following is an example with 2 magtapes:

        MAGTAPE ROUTINES
        TYPE 'H' FOR HELP 'E' TO EXIT
        
        TYPE  TEST DENSITY EG. 6250  ? "6250"
        Tape to be tested        ? "MTA0"
        <UETP.LIB>MTA0.MAX    FINISHED (test for 6250/1600 BPI drive)
        
        TYPE  TEST DENSITY EG."6250"  ? "1600"
        Tape to be tested        ? "MTA1"
        <UETP.LIB>MTA1.MAX    FINISHED (test for 1600/800 BPI drive)

        TYPE  TEST DENSITY EG."6250"  ? "E"


2.2.7  DC20 Lines. -

Enter the amount of DC20 lines X on FE0 in  OCTAL.   CONFIG  will  use
this  value to modify 5-1-CONFIG.CMD and turn on tty lines 1-X at 9600
baud.  All others are set to speed 0 (turned off).

        How many DC20 lines (0-200 octal)  ? "40"


2.2.8  Lineprinters. -

Use  the  following  table  to  determine  the  answers  to  the  next
questions.

        Model           VFU             LOWERCASE

        LP20A     PROGRAMMABLE          NO
        LP20B     PROGRAMMABLE          YES
        LP20C     PROGRAMMABLE          NO
        LP20D     PROGRAMMABLE          YES
CONFIGURING THE SYSTEM                                        Page 2-6


        LP20F     PROGRAMMABLE          NO
        LP20H     PROGRAMMABLE          YES


How many Linprinters are on the system (0-2)  ? "2"
Does Lpt0 have a programmable vfu  ? "Y"
Does Lpt0 have lowercase  ? "Y"
Does Lpt1 have a programmable vfu  ? "Y"
Does Lpt1 have lowercase  ? "N"


2.2.9  DN20's -

DN20's containing synchronous lines are tested under the monitor  with
either  DECNET or IBMCON software with the lines in loopback mode.  By
answering "N" to the promt "ENABLE IBMCON" CONFIG will  assume  DECNET
is to be used.

In MFG the DECNET software, which supports DMR's DMC's  and  DUP's  is
always used for testing.

IBMCON is suggested only for installations that will  run  the  IBMCON
software.   It  supports  DUP's  only.  If IBMCON is intended continue
with section "CONFIGURING FOR IBMCON".

2.2.9.1  CONFIGURING FOR DECNET. -

To accomplish DECNET testing the FE monitor file must first  be  built
to  reflect  the  hardware  configuration  in  the  DN20.   This  file
(DN20N1.SYS for FE1) will then be loaded into the FE when  the  system
is booted.  Once this has been done a single UETP test (DN20N1.VER for
FE1) is used to check out the DN20 as a DECNET node which includes all
lines that have been configured into the node.

CONFIG will make files for building,  loading  and  testing  the  node
provided the configuration is a "legal" DECNET configuration.  In some
cases  CONFIG/NETGEN  will  allow  you  to  build  the  node  but  the
configuration/  line  speeds may be such that the DN20 Unibus bandwith
limitations will cause errors during the maintenance tests.

The following table lists the line configuration limitations for  each
node.  These limitations are due to either DECNET software limitations
or DN20 Unibus bandwith.  If  the  DN20  configuration  exceeds  these
limits, line(S) must be left out of the configuration.

     1.  Minimum of 128K of memory in DN20

     2.  Minimum of 1 synchronous line.

     3.  Maximum of 0 asyncronous lines.

     4.  Maximum of 8 synchronous lines (DMR,DMC,DUP)
CONFIGURING THE SYSTEM                                        Page 2-7


     5.  Maximum of 6 high speed lines (DMR,DMC)

     6.  Maximum of 2 DMR's at 1 Meg baud.

     7.  Maximum of 4 DMR's at 56K (no other lines)

     8.  Maximum of 3 DMR's at 56K with 4 or less DUP's at 9.6K - *

     9.  Maximum of 2 DMR's at 56K with 5 or 6 Dup's at 9.6K - *

    10.  Maximum of 2 KDP's.

    11.  Maximum of 8 DUP's (4 per KDP) at 9.6K or 19.2K baud


* - limits determined by MFG evaluation.

Note:   Rules for DMC's same as DMR's.

        In a configuration of mixed DMR's and DMC's the base
        address of the DMC's must be lower than the DMR's.

For MFG testing, all DMR's will be set up at their maximum  speed  but
not  greater  than 56K baud unless the DN20 contains just 1 or 2 DMR's
only.

Each DUP must be connected to a null modem test box with clock set  at
9.6K.  Each null modem must have 2 DUP's connected to it.  If there is
an odd number of DUP's in the  configuration  the  last  DUP  will  be
ommitted  from  the  configuration unless the DN20 contains only 1 DUP
(and no other lines).  In this case MFG will temporarily add a  second
DUP for testing.

If there are 2 KDP's divide the DUP's equally between the two.   (This
is independent of hardware setup)

        HOW MANY DN20 FRONT ENDS ? (0-3) "2"
        Enable IBMCON? "NO"

In MFG the answer to the previous question should always be "NO" which
will cause CONFIG to set up for testing with DECNET.



                                 NOTE

               "KDP"  refers  to   a   KMC   which   is
               configured to handle DUP's.
CONFIGURING THE SYSTEM                                        Page 2-8



        On DN20 #1
        How many DUPs on KDP_0  ? "2"
        How many DUPs on KDP_1  ? "2"
        How many DMCs    ? "0"
        How many DMRs    ? "2"
        
        On DN20 #2
        How many DUPs on KDP_0  ? "0"
        How many DUPs on KDP_1  ? "0"
        How many DMCs    ? "0"
        How many DMRs    ? "4"
        
        <MFG>DN20N1.CTL             FINISHED
        <MFG>DN20N2.CTL             FINISHED
        
DN20N1.CTL and DN20N2.CTL are  files  used  to  build  the  front  end
software  for FE1 and FE2 respectively.  The node type is DN20 and the
front end number is signified by the NX where X is the DTE  number  to
which the front end is connected.

At the completion of the CONFIG dialogue you  will  be  instructed  to
submit these control files to finish building the configuration.

Continue with section AN20.

        

2.2.9.2  Configuring For IBMCON. -

         If IBMCON is selected DN20's containing DUP's can  be  tested
under  the monitor by loading the IBMCON protocol and running DN64 (or
equivalent) tests.  This requires that an even number of  KMC/DUPs  be
installed  and  that  the  even  odd  pairs  are  connected to a clock
generator box.

There are no IBMCON tests available for testing  DMC/DMR  lines.   The
only way to test all synchronous lines is to build the DECNET node and
do DECNET testing (Refer to section "Configuring for DECNET").

        HOW MANY DN20 FRONT ENDS ? (0-3) "2"
        Enable IBMCON? "Y"
        
        On DN20 #1
        How many DUPs on KDP_0  ? "4"
        How many DUPs on KDP_1  ? "0"
        How many DMCs    ? "0"
        How many DMRs    ? "0"
        
        On DN20 #2
        How many DUPs on KDP_0  ? "4"
        How many DUPs on KDP_1  ? "2"

Note:   When configuring for IBMCON always put the 1st 4
        DUP's on KDP_0.
CONFIGURING THE SYSTEM                                        Page 2-9



        How many DMCs    ? "0"
        How many DMRs    ? "0"
        
        <UETP.RUN>DN11A.VER         FINISHED
        <UETP.RUN>DN11SA.SEND       FINISHED
        <UETP.RUN>DN11B.VER         FINISHED
        <UETP.RUN>DN11SB.SEND       FINISHED
        <UETP.RUN>DN12A.VER         FINISHED
        <UETP.RUN>DN12SA.SEND       FINISHED
        <UETP.RUN>DN12B.VER         FINISHED
        <UETP.RUN>DN12SB.SEND       FINISHED
        <UETP.RUN>DN12C.VER         FINISHED
        <UETP.RUN>DN12SC.SEND       FINISHED
        <UETP.RUN>DN20N1.CTL        FINISHED
        <UETP.RUN>DN20N2.CTL        FINISHED

These Uetp test  files  (DN1*.SEND  and  DN1*.VER)  listed  above  are
actually  equivalent to the DN64 test files.  The number in the middle
(i.e.  12 ) is the port number and the  letter  just  before  the  "."
signifies  what  pair of KMC/DUP lines (A for lines 0,1..  B for lines
2,3..etc..)

Note that the DN20N1.CTL and DN20N2.CTL  (files  for  building  DECNET
node) were created by CONFIG even though IBMCON has been selected.  If
submitted these files may create a valid DECNET FE monitor but because
IBMCON is selected the system will come up running the DN64 software.

The next file is edited whenever any KMC/DUPS are indicated.  This  is
the  auto  file  that  loads  D6TK3.BIN  into  the  front  ends and is
initiated  by  GET  SYSTEM:DNLOAD.ATO  command   in   the   SYSJOB.RUN
file.(IBMCON enabled)

        PS:<SYSTEM>DNLOAD.ATO          FINISHED


2.2.10  AN20. -
 
        IS THERE AN AN20 ON THIS SYSTEM ? (Y,N) "N"

If you answer "Y" to  the  previous  question  CONFIG  will  edit  the
PTYCON.ATO  file  to login a subjob (AN20) and run diagnostic DDANB to
test the AN20.


2.2.11  Memory Size. -
 
        HOW MANY K TOTAL OF MEMORY ? "1024"
 
The answer to the last question is used to determine which monitor  is
correct  for  the  system and to determine how many simultaneous batch
streams will be run.
CONFIGURING THE SYSTEM                                       Page 2-10


2.2.12  CONFIG INSTRUCTIONS. -

When the configuration dialogue is completed CONFIG displays  all  the
commands  in  the  RELIAB.CMD  for  tests other than the standard UETP
language tests.

        RELIAB ROUTINES
        
        ENABLE DSK11/CYCLE:10/TIME:01:00:00
        ENA MTA0/DEPTH:MAX/CYCLE:10/TIME:01:00:00
        ENA MTA1/DEPTH:MAX/CYCLE:10/TIME:01:00:00
        ENA LPT0/CYCLE:10
        ENA LPT1/CYCLE:10
        ENA DN20N1/LIMIT:10
        ENA DN20N2/LIMIT:10
        
        PLEASE SUBMIT <MFG>DN20N1.CTL/TIME
        PLEASE SUBMIT <MFG>DN20N2.CTL/TIME
        $
CONFIG should also give any further  instructions  that  are  required
finish   the  configuration.   The  following  list  shows  additional
procedures that must be performed before the specified devices can  be
tested.

     1.  AN20 - You must copy the  AN20  supportable  monitor  to  the
         default monitor as instructed by CONFIG.

     2.  DISK DRIVES (other  than  PS)  -  You  must  build  the  test
         structure  using  the  MIC  files generated by CONFIG.  (i.e.
         DSK11.MIC, HSC31.MIC).  Refer to section "BUILDING  THE  DISK
         STRUCTURES".

     3.  DN20'S (DECNET) - You must build the node for  each  DN20  by
         submitting  the  CTL  files  generated  by  CONFIG.  Refer to
         section "BUILDING THE DECNET NODE".

Refer  to  the  appropriate  section(s)  and  complete  building   the
configuration.  After this is done continue with section "INITIALIZING
THE ERROR FILES" before reloading the system for the acceptance run.

2.3  CHANGING THE CONFIGURATION
If you had made a mistake  or  for  any  reason  wish  to  change  the
configuration  you could run CONFIG again and change the configuration
for devices in a specific device category as opposed to going  through
the entire dialogue.  For example:

        $"CONFIG"

        TOPS20 CONFIGURATOR PROGRAM VER 5-1-
        TYPE 'H' FOR HELP
        PASSWORD ? "MFG"
        COMMAND (at least 2 characters)  ? "AU"
        USER AUDIT ENABLED
        COMMAND (at least 2 characters)  ? "CH"
CONFIGURING THE SYSTEM                                       Page 2-11


        CHANGE>  ? "H"
        
        Commands are:
        CUSTOMER NAME
        AN20
        MAGTAPE
        DC20 LINES
        LINEPRINTER
        DISK DRIVE
        AUTO  UETP
        TIME
        DN20
        MEMORY
        RETURN
        EXIT

The previous list shows the various Configuration  categories.   Under
the "CHANGE" dialogue only the dialogue for the specified device group
is entered.  At this  point  you  must  enter  configuration  for  all
devices of this type.  All other configuration data is left unchanged.
        
        How many DN20 front ends (0-3) ? "1"
        Enable IBMCON (Y,N)  ? "N"
        On DN20 #1
        How many DUPs on KDP_0  ? "2"
        How many DUPs on KDP_1  ? "0"
        How many DMCs    ? "0"
        How many DMRs    ? "2"
        <UETP.RUN>DN20N1.CTL        FINISHED
        PLEASE SUBMIT <MFG>DN20N1.CTL/TIME
        CHANGE>  ? "RET"
        COMMAND (at least 2 characters)  ? "EXIT"
        $

In this last example we have changed the line  configuration  for  the
first  DN20  and have removed any other DN20's that might have been in
the configuration.
CONFIGURING THE SYSTEM                                       Page 2-12


2.4  BUILDING THE DECNET NODES.
After completing the CONFIG dialogue, If DN20 DECNET testing has  been
specified,  you must first build the FE software (before reloading the
system) to insure that the correct FE software gets loaded.

There are three configurations already built for a DN20 on DTE-1.   If
your  DN20 configuration matches the following you will merely have to
copy the correct FE file to the default file.

on DN20 on DTE-1 if you have:

        1 DMR
then    $"COPY <MFG>DN1-DMR1.SYS <SUBSYS>DN20N1.SYS.0"

or      2 DUP'S
then    $"COPY <MFG>DN1-DUP2.SYS <SUBSYS>DN20N1.SYS.0"

or      3 DMR'S AND 2 DUP'S ON KDP-0 AND 2 DUP'S ON KDP-1
then    $"COPY <MFG>DN1-DMR3-DUP2-DUP2.SYS <SUBSYS>DN20N1.SYS.0"

If your configuration does not match one of the ones  above  you  will
have to build it.

Note:
You can change the line configuration for a DN20 without reloading the
system   by   copying   the  appropriate  pre-built  FE  MCB  file  to
<SUBSYS>DN20NX.SYS.0 (.0 to  maintain  current  generation)  and  then
reloading  the  node  with  DN1-START.MIC.   See  chapter MANUAL TESTS
section DN20 - DECNET.

The following example shows how to build a single DN20 node using  the
<MFG>DN20N1.CTL file created by CONFIG.

        $"CONN <MFG>"
        $"DEF DSK:"
        $"SUB DN20N1.CTL/TIME:10:00/BA$TCH-LOG:SU$PERSEDE"

        or if you don't like typing this last line:
        $"DO SUB DN20N1"

You must now wait for the  batch  job  to  sucessfully  finish  before
shutting down the system.  This will take about 10 minutes.  The batch
job runs in 3 parts.

First the 1st  half  of  DN20N1.CTL  runs.   It's  log  file  goes  to
<MFG>DN20N1.LOG.   This  CTL  file then submits DNSYS1.CTL (which runs
immediately) and also submits  itself  again,  (to  be  run  upon  the
completion of DNSYS1) this time starting at the second half of the CTL
file.

The log file for DNSYS1 is <DN20-1>DNSYS1.LOG and the log file for the
2nd part of DN20N1 is <DN20-1>DN20N1.LOG.

By using the "Information about Batch" command examine the  queues  to
see if the CTL files are finished.  You will otherwise not be notified
CONFIGURING THE SYSTEM                                       Page 2-13


unless there is an error.

        $"I B"

        Batch Queue:
        Job Name   Req#   Run Time            User
        --------  ------  --------  ------------------------
        * DNSYS1      33  10:00:00  MFG                   In Stream:0
            Job# 9 Running VNP36 Runtime 0:00:00
          DN20N1      34  05:00:00  MFG                   In Stream:1
        
        There is 2 jobs in the queue (1 in progress)
        $

When the batch jobs have finished, as a quick check to  be  sure  that
the FE software was successfully built, do the following:

        $"V$DIRECTORY (OF FILES) SYS:DN20N1.SYS"

You should see the file PS:<SUBSYS>DN20N1.SYS with a write date  equal
to the current date and time.
CONFIGURING THE SYSTEM                                       Page 2-14


2.5  BUILDING THE DISK STRUCTURES.
Before the UETP Disk test files created by CONFIG can run a  structure
must be built on each disk with the same structure name that you input
during the disk dialogue.  Before you can build a new structure  on  a
disk  that disk must be online, write enabled, Ten formatted, and must
NOT be  already  mounted  by  the  system.   To  see  the  status  and
configuration of the disk drives on your system you can use either the
UNITS program or a command to OPR.

To run UNITS type:

        @"ENA" (enable priv.)
        $"UNITS"
        
Status of Disk Units at  6-Sep-84 17:28:48

Mounted?  Type  Channel  Drive  Controller  Structure name  Logical unit
--------  ----  -------  -----  ----------  --------------  ------------
  Yes     RP06     0        0       --      PS:              0 (1 of 1)
  No      RP07     1        1       --      Bad home blocks
  Yes     RA81     7        1       3       USERA:           0 (1 of 1)


Note:

"Bad home blocks" means the system does not recognize a  structure  on  the
disk (i.e.  one has not been built yet)

Or to get a status of the disks with OPR type:

        $"OPR"
        OPR> "SHOW STATUS DISK-DRIVE "

NOTE:

If the system does not see a HSC50-RA disk drive it may be because the
HSC  node  is down or the KLIPA ucode has not been loaded.  If this is
the case type:

        $"IPALOD"

And reboot the HSC50 and MONITOR.  See HSC50-USER-GUIDE

In the examples above we see that three disks are seen by  the  system
(they  are  online) and a structure by the name "USERA" has been built
on the RA81 and the system has mounted it.  In order  to  rebuild  the
strucure on RA81 we must first dismount it:
CONFIGURING THE SYSTEM                                            Page 2-15



        $"STRTST"
        
        STRTST> "DIS$MOUNT (STRUCTURE) USERA"
        
        STRUCTURE USERA SUCCEFULLY DISMOUNTED
        
        STRTST> "EXIT"
        $

Now we can use the mic files to rebuilt the structures.  Type:

        $"DO <MFG>HSC31.MIC"

This will run CHECKD and create a basic structure  on  the  drive  you
identified  during  the  CONFIG  dialogue  as  HSC31 (drive 1 on HSC50
controller 3).  When finished continue on building any  more  required
structures in the same manner.

        $"DO <MFG>DSK11"

Once the structures have been built you should be  able  to  mount  it
with STRTST.

        $"STRTST"
        STRTST> "M$OUNT (STRUCTURE) DSK11
        Structure DSK11 SUCCESFULLY MOUNTED
        NOW AVAILABLE AS DSK11
        STRTST> "MOU HSC31"

.skip 1

By mounting the drives with STRTST you are making the structures
available to the system. This is normally done by automatically during
system boot. Once a drive has been mounted for the system
any job may mount it via the EXEC "MOUNT" commnad:

.literal

        $"MOUNT STRUCTURE (NAME) DSK11:"
        Structure DSK11: mounted
        $"MOUNT STR HSC31:"
        Structure HSC31: mounted

When UETP starts RELIAB.CMD it will submit HSC31.VER which will WRITE,
and  VERIFY  and  DELETE  files on the HSC31 structure.  UETP will run
PAGES in user mode.  This test is created by the CONFIG program.
CONFIGURING THE SYSTEM                                            Page 2-16


2.6  INITIALIZING THE ERROR FILES
Prior to shutting down the system, before starting acceptance for  the
first  time  on  this  configuration,  you should delete any old error
files so that when you run SPEAR, TGHA, etc all errors will pertain to
this configuration only.  To do this type:

        $"DEL <SYSTEM-ERROR>ERROR.SYS"
        $"DEL <SYSTEM>TGHAV2.*"
        $"DEL <UETP.RUN>*.*"

or use the MIC file:

        $"DO <MFG>DEL$ETE-SYSERR.MIC"

NOTE:

If the system contains mos memory be sure to enter the KLI dialogue on
the next system reboot and issue the "FORCE" command to the "CONFIGURE
KL MEMORY" prompt because the MIC file deletes  TGHAV2.DAT  (the  file
that  is used by the system to keep track of mos memory error history)
which causes confusion in the software unless the MF20 is known to  be
in the initialized state when the system is booted.

Once the acceptance has been started  ERROR.SYS  and  TGHAV2.*  should
never be deleted until the acceptance is complete and signed off.

2.7  RUNNING MAKDMP
If this is the first time you have configured the system or  any  time
that  the  amount  of memory on the system has been changed you should
run the MAKDMP program so that DUMP.EXE will dump the  correct  amount
of memory in the case of a system crash.

        $"CONN <SYSTEM>"
        $"DEL DUMP.EXE"
        $"EXP"
        $"RUN <UTILITIES>MAKDMP"

AFTER ALL  CONFIGURATION  BUILDS  ARE  COMPLETE  TO  INSURE  THAT  THE
CONFIGURATION  CHANGES ARE IMPLEMENTED, THE SYSTEM SHOULD BE RELOADED.
Continue with section "RUNNING THE ACCEPTANCE".











                                 CHAPTER 3

                          RUNNING THE ACCEPTANCE



3.1  PRE ACCEPTANCE CHECKS
Before starting the acceptance  make  sure  that  all  diagnostic  and
reliability tests have succesfully completed.

For MFG acceptance be sure all previous Q.C.   checkpoints  have  been
signed off.

Run a pass of DDRPI RONLY test on the KLAD drive using the  KLAD  pack
to insure there are no compatability problems.

BE SURE SWITCHES ARE SET CORRECTLY ON THE LP20 LOGIC BOARDS  else  the
11/40 may hang at the time DB0 is mounted.

Insure that all devices are connected and on line.




3.2  STARTING THE ACCEPTANCE
Boot the system as described in the section on starting up the system.
Assuming  that the UETP auto restart has been enabled under the CONFIG
program all tests should come up  running  with  no  further  operator
input after the "RUN CHECKD?  prompt.

Before attaching to PTYCON you should wait for  PTYCON.ATO  to  finish
executing  (UETP  tests started with the BEGIN command) to insure that
what you type does not conflict  with  the  auto  file.   However  (if
careful)  you  may  attach  during  execution  of the auto file to get
control of the CTY before the  tests  start  at  the  point  where  it
pauses:

        UETP> PUSH
        @PAUSE

At this point you have 15 seconds to do the attach.  Immediately after
typing  the  password,  DO  NOT  type  anything  more  if you wish the
acceptance to start.   Otherwise  type  a  "^X"  immediately  and  the
remainder  of  PTYCON.ATO  file  will  be  aborted (the tests will not
start).
RUNNING THE ACCEPTANCE                                             Page 3-2


If the auto UETP startup had not been enabled or if you had aborted it
as described above you could then initiate it manually from the PTYCON
level by typing:

        PTYCON> "C UETP"
        $"POP"  (if PTYCON.ATO had been aborted before the POP)
        UETP> "TAKE RELIAB$"

or restart the UETP subjob altogether:

        "^X"
        PTYCON> "GET <MFG>UETP.ATO"

At the completion of the RELIAB.CMD file the status command is  issued
to UETP.

        UETP>"STATUS"

[27-May-80 10:21:38]

 Test   Depth   Status    Cycle   Times   Error   Error   Start
 name                             run     count   limit   time
======  =====   =======   =====   =====   =====   =====   =====
LPT0    VER     Running   24:00       0       0       0    10:16
DN20N1  VER     Queued    24:00       0       0       0    10:16
DSK11   VER     Running   24:00       0       0       0    10:16
HSC31   VER     Running   24:00       0       0       0    10:16
MTA0    MAX     Running   24:00       0       0       0    10:16
MTA1    CMP     Queued    24:00       0       0       0    10:16
ALGOL   VER     Queued    24:00       0       0       0    10:16
APL     VER     Queued    24:00       0       0       0    10:16
APLSF   VER     Queued    24:00       0       0       0    10:16
        
In the example shown above the tests listed will run for 24 hours from
time listed in the Start time column.  If necessary the cycle time can
be altered on the fly.  For example:

        UETP>"MODIFY ALL/DEPTH:VER/CYCLE:48:00"

Will modify all tests of depth VER to run for 48 hours.  Note that  in
this  case  there  are  tests  of  other depths which must be modified
separately.

        UETP>"MODIFY ALL/DEPTH:MAX/CYCLE:48:00"
        
        UETP>"MODIFY ALL/DEPTH:COM/CYCLE:48:00"

Now if we type the status command we should see that the  modification
has been completed.

        UETP>"STATUS"

[ 10:21:50]

 Test   Depth   Status    Cycle   Times   Error   Error   Start
RUNNING THE ACCEPTANCE                                             Page 3-3


 name                             run     count   limit   time
======  =====   =======   =====   =====   =====   =====   =====
LPT0    VER     Running   48:00       0       0       0    10:16
DN20N1  VER     Queued    48:00       0       0       0    10:16
DSK11   VER     Running   48:00       0       0       0    10:16
HSC31   VER     Running   48:00       0       0       0    10:16
MTA0    MAX     Running   48:00       0       0       0    10:16
MTA1    CMP     Queued    48:00       0       0       0    10:16
ALGOL   VER     Queued    48:00       0       0       0    10:16
APL     VER     Queued    48:00       0       0       0    10:16
APLSF   VER     Queued    48:00       0       0       0    10:16

NOTE:

The following devices are not automatically tested by the  system  via
CONFIG.

     1.  DC20's

If you are to test DC20's refer to Chapter "MANUAL TESTS"  DC20  LINES
TEST.
RUNNING THE ACCEPTANCE                                             Page 3-4


3.3  MONITORING THE ACCEPTANCE
Once the acceptance has been started you should do  the  following  at
least  every  4  hours  to  determine  that  the acceptance is running
correctly.

     1.  Examine the batch streams and UETP status to ensure that  all
         tests are running and without any software detectable errors.

     2.  Review SPEAR to evaluate the hardware errors.

     3.  Run TGHA (systems with moss) to evaluate MF20 performance.


3.3.1  THE BATCH JOBS -

To examine the state of the batch jobs type  the  INFORMATION  (about)
BATCH-REQUESTS command.

        $"I B"

Batch Queue:
Job Name  Req#  Run Time            User
--------  ----  --------  ------------------------
* DSK11     61  10:00:00  F-S                     In Stream:2
    Job# 7 Running PAGES Last Label: BEGIN2 Runtime 0:00:44
* HSC31     62  10:00:00  F-S                     In Stream:3
    Job# 10 Running PAGES Last Label: BEGIN2 Runtime 0:00:39
* MTA0      63  10:00:00  F-S                     In Stream:0
    Job# 9 Running TAPWRT Last Label: FIX3 Runtime 0:00:12
* DBMS      65  10:00:00  F-S                     In Stream:1
    Job# 8 Running FORTRA Last Label: DBFO2 Runtime 0:00:14
  MTA1      80  10:00:00  F-S                   
  ALGOL     66  10:00:00  F-S                   
  APL       67  10:00:00  F-S                   
  APLSF     68  10:00:00  F-S                   
  BASIC     69  10:00:00  F-S                   
  CBLSRT    70  10:00:00  F-S                   
  RANCBL    71  10:00:00  F-S                   
  RANFOR    72  10:00:00  F-S                   
  CPUBAS    73  10:00:00  F-S                   
  MEMBAS    74  10:00:00  F-S                   
  CPUREL    75  10:00:00  F-S                   
  MEMREL    76  10:00:00  F-S                   
  DN20N1    79  10:00:00  F-S                   
  LPT0      59  10:00:00  F-S           /After:27-May-80 10:22
There are 18 Jobs in the Queue (4 in Progress)

The "*" in front of the test name means  that  the  job  is  currently
running.   The number of batch streams that are running simultaneously
may vary with the amount of memory on the system.
RUNNING THE ACCEPTANCE                                             Page 3-5


3.4  UETP STATUS
Another way to examine the batch jobs and to get a summary of the test
run is with the UETP STATUS command.

        UETP>"STATUS"

[27-May-80 22:21:38]

 Test   Depth   Status    Cycle   Times   Error   Error   Start
 name                             run     count   limit   time
======  =====   =======   =====   =====   =====   =====   =====
LPT0    VER     Ended     10         10       0       0    10:16
DN20N1  VER     Queued    72:00      11       1       0    10:16
DSK11   VER     Running   72:00       5       0       0    10:16
HSC31   VER     Running   72:00       5       0       0    10:16
MTA0    MAX     Running   10          7       0       0    10:16
MTA1    MAX     Aborted   10          1       1       0    10:16
DBMS    VER     Stopped   72:00      17       0       0    10:16
ALGOL   VER     Queued    72:00      21       0       0    10:16
APL     VER     Queued    72:00      37       0       0    10:16
APLSF   VER     Queued    72:00      25       0       0    10:16
BASIC   VER     Queued    72:00      23       0       0    10:16
CBLSRT  VER     Queued    72:00      35       0       0    10:16
RANCBL  VER     Queued    72:00      45       0       0    10:16
COBOLD  VER     Queued    72:00      43       0       0    10:16
SORT    VER     Queued    72:00      43       0       0    10:16
FORTRA  VER     Queued    72:00      43       0       0    10:16

Examine the Status column.  The following list describes each  of  the
possible status conditions:

        ENABLED The test is in the UETP queue but has not been
                submitted to the batch system for processing.

        ENDED   The test has completed processing.

        QUEUED  The test has been submitted to the batch queue
                but is waiting for a batch stream to become
                available.

        ABORTED The test was once enabled, queued, or running
                but has been aborted via the ABORT command.

        STOPPED The test is no longer being run because:

                1.  An error limit or time limit has been exceeded
                2.  The job logged out without sending an END
                    message.

        RUNNING The job has sent a START message to UETP signaling
                that it is currently running in a batch stream.

        UNKNOWN The test status cannot be determined due to an
                internal failure of either UETP or the operating
                system.
RUNNING THE ACCEPTANCE                                             Page 3-6



For  a  complete  description  of   UETP   commands   refer   to   the
"TOPS10/TOPS20   USER-ENVIRONMENT  TEST  PACKAGE  PROCEDURES/REFERENCE
MANUAL" Document # AA-D606B-TK.

Also check  to  see  that  the  Times  Run  count  for  each  test  is
incrementing on a regular basis.

Should UETP detect an error which will be indicated in the error count
column, the log for the failing test will, upon completion of the test
pass be appended to XXX.ERL where XXX is the name of the  test.   This
log  should  be  examined  to help determine the cause of the failure.
I.E.

        "^X"
        PTYCON> "CONN O"
        $"CONN <UETP.RUN>"
        $"PRINT MTA1.ERL"

If a job is in the STOPPED state you will have to look at the log file
in  the  <UETP.RUN>area.   It  is advisable to copy the log to another
area before restarting the test since each time the job runs  the  log
from the previous pass is deleted.  i.e.

        COPY <UETP.RUN>RANFOR.LOG <MFG>RANFOR.LOG

Any error reporting from UETP will attempt to direct you to the  cause
of the error.  The type of errors to look for are:

        TIME-OUT ERRORS
        ERRORS ASSIGNING DEVICE (i.e. MAGTAPE)
        UNEXPECTED ERRORS IN A BATCH STREAM

These are usually caused by errors in a batch job beginning with  a  ?
or  %.  For example FORTRAN will run FILCOM to compare data.  If there
is an error FILCOM will return the message:

        ? DIFFERENCE ENCOUNTERED

The batch job will then go to a error handler routine in  the  control
file to run sender and report the error message to the CTY via UETP.

3.5  STOPPING AND RESTARTING THE JOBS.
If you detect any errors which require you  to  stop  the  acceptance,
stop the batch jobs in the following manner:

        UETP>"ABORT ALL"
        [10:23:14  ABORT OF ALL VERIFICATION TESTS COMPLETED]
        UETP>"ABORT ALL/DEPTH:MAX"
        [10:23:22  ABORT OF ALL MAXIMUM TESTS COMPLETED]
RUNNING THE ACCEPTANCE                                             Page 3-7


                                 NOTE

               First attempt at aborting the UETP  jobs
               may  fail  depending on the state of the
               jobs that are being  aborted.   If  this
               happens  reissue the abort command.  Use
               the status command to check the results.


To stop a single job for example the MTA0 job type:

        UETP>"ABORT MTA0/DEPTH:MAX"

Any time a job is stopped for any reason the  job  must  be  disabled,
then  enabled  before  the BEGIN command will submit the job(s) to the
batch queue.  I.E.

        UETP>"ABORT RANFOR"
        
        UETP>"DISABLE RANFOR"
        
        UETP>"ENABLE RANFOR"
        
        UETP>"BEGIN"
        
If all the jobs were stopped the easiest way to restart them is:

        UETP>"ABORT ALL"
        
        UETP>"ABORT ALL/DEPTH:MAX"
        
        UETP>"DIS ALL"
        
        UETP>"DIS ALL/DEPTH:MAX"
        
        UETP>"TAKE RELIAB.CMD"
        
        UETP>"BEGIN"

Refer to Chapter "SYSTEM ERROR REVIEW" for reviewing the error files.

There are a number of auto files in the <MFG> area that may be helpful
in  controlling  certain devices.  Refer to appendix MFG SPECIAL FILES
for descriptions of programs and auto  files.   Also  Chapter  "MANUAL
TESTS" for some examples.











                                 CHAPTER 4

                               MANUAL TESTS



This chapter describes routines for manually testing parts of  the  system.
Unless  directed  to  by  other  parts of this procedure (i.e.  DC20) these
routines are not normally  performed  by  MFG  for  acceptance.   They  are
provided  here  in  hopes  of  being  a  more efficient method of isolating
problems that may arise during a full blown UETP run.

4.1  DC20 LINES TEST
For each DC20 line on the system do the following:

     1.  Attach the terminal to the line

     2.  Type:  "^C"

     3.  Type:  "SYS" and verify that the character are typed correctly

     4.  Type:  "LOGO" and verify that the line number is correct.

     5.  During the course of  acceptance  for  each  DC20  on  the  system
         connect  the  terminal  to  one of it's lines and run TRAK20 for a
         minimum of 2 hours in the following manner:


    $"TRAK20"
    TRAK20> "WATCH"


4.2  DN20 - DECNET
4.2.1  RELOADING THE NODE. -

To help in islolating  a  Front  end  problem,  you  can  change  the  line
configuration  for  a  DN20  without  reloading  the  system by copying the
appropriate pre-built FE MCB file to <SUBSYS>DN20NX.SYS.0 (.0  to  maintain
current  generation)  and  then  reloading the node with DN1-START.MIC.  Be
sure to save the current configuration  MCB  file  before  the  copy.   For
example:

On DTE-1 a DN20 with 2 DMR's and 1 DMC and 2 DUP's on KDP-0:

        $"COPY <SUBSYS>DN20N1.SYS <MFG>DN1-DMR2-DMC1-DUP2.SYS
MANUAL TESTS                                                       Page 4-2


Now copy the MCB file for a minimum configuration (1 DMR).

        $"COPY <MFG>DN1-DMR1.SYS <SUBSYS>DN20N1.SYS.0"

Note:

You can restore the original configuration later by copying the saved  file
back to <SUBSYS> as with the command above and reloading the node.

Assuming the system has been configured for synchronous LINES,  the  DECNET
node(s)  have been built, and the turn around plugs on DMR's and MODEM's on
DUP11'S have been connected:

Use the following procedure to restart  the  DECNET  support  programs  run
under  PTYCON  (if  they  are not running already or if they are outputting
errors):

        "^X"
        PTYCON> "GET SYSTEM:NETWRK.ATO"


Assuming the DECNET support programs  are  running,  do  the  following  to
reload and start DN20N1.

        $"DO DN1-START.MIC"


4.2.2  DECNET TESTS FOR SYNCHRONOUS LINES -

Assuming the DN20N1 node is online do the following  to  manually  exercise
the node.

        @"ENA"
        $"CONN <MFG>"
        $"DO DN20N1.MIC"

This will perform a test simular to the UETP test except that  it  will  be
run from the terminal instead of under batch.

To look at a summary for the node (This can be done while DN20N1 is running
under UETP) type:

        $"DO <MFG>DN1-SHOW"

To stop DN20N1 (crashes the front end) and optionally load  DECX  into  FE1
type:

        $"DO <MFG>DN1-STOP.MIC"
MANUAL TESTS                                                       Page 4-3


4.3  DN20 IBMCON
Normally the DUP tests are run under UETP automatically.   However  in  the
event that you want a quick verify of the DN20 hardware, manual testing may
prove to be much quicker.

To reload the DN20 with the IBM protocol type:

        $"DNLOAD"
        DNLOAD> "LOAD DTE $1 <DN64-BINARIES>D6TK3.BIN" 

If the DN20 was already running it would crash and then reload.   Once  the
DN20 is loaded exit the DNLOAD program:

        DNLOAD> "EXIT"
        $

On a terminal other than the CTY run PTYCON and create a  subjob  for  each
DUP.  Login each job and run D60SPD I.E.

        PTYCON
        PTYCON> "DEF $0 (AS) AIN"
        PTYCON> "C AIN"
        "^C"
        @"LOG F-S FS"
        @"ENA"
        $"D60SPD"
        D60SPD> "^X"
        PTYCON> "DEF $1 (AS) AOUT"
        
        etc.

By using the D60SPD.ATO file in the <MFG> you can automatically set up  six
jobs as shown above.  I.E

        @"ENA
        $"PTYCON"
        PTYCON> "GET <MFG>D60SPD.ATO"

PTYCON> SILENCE
PTYCON> WHAT ALL
AIN(0)     13         F-S      D60SPD         TI         0:0:0
AOUT(1)    14         F-S      D60SPD         TI         0:0:0
BIN(2)     12         F-S      D60SPD         TI         0:0:0
BOUT(3)    8          F-S      D60SPD         TI         0:0:0
CIN(4)     10         F-S      D60SPD         TI         0:0:0
COUT(5)    4          F-S      D60SPD         TI         0:0:0
PTYCON>

D60SPD is a program that simulates the protocol sent over the  DUP's.   The
commands are outlined:
        
        SET SIM/PORT:11/DEVICE:0/LINE:0/3780
        
        where:
        
MANUAL TESTS                                                       Page 4-4


                SET is the command to initiate action on the DUP
                SIM is the switch to turn on the simulator mode
                PORT is the Node port 11-13 (DTE)
                DEVICE must always be = 0
                LINE is the DUP line number 0 through 5
                3780 is the connecting node type

There are two methods of testing the DUP lines.  By transfering a file  out
through  one  DUP  and  looping  it  back  in through another or by doing a
continuous data transfer.

The following is an example of transfering a file.

        PTYCON> "C AIN"
        D60SPD>"SET SIM/P:11/D:0/L:0/3780"
        
        (wait for the tty to stop typing then:)
        
        D60SPD>"INPUT/REC.DAT/TIME:60"
        
        (response should be)
        
        [WAITING FOR AN INPUT REQUEST]

Line 0 is now ready to input to the file REC.DAT.  Now set up the line that
is looped to it to send a file:

        "^X"
        PTYCON> "C AOUT"
        
        D60SPD>"SET SIM/P:11/D:0/L:1/3780"
        
        D60SPD>"OUTPUT/DN64.DAT/TIME:60"
        
                The following responses are from the DUP's
        
                [INPUT PERMISSION REQUESTED]
                [INPUT PERMISSION GRANTED]
                [OUTPUT PERMISSION REQUESTED]
                [OUTPUT PERMISSION GRANTED]
                [RECEIVING INPUT]
                [INPUT COMPLETE]

When the file has been transferred run FILCOM and compare the received  and
transmitted data:

        $"FILCOM"
        *"=DN64.DAT,REC.DAT"

The response should be "NO DIFFERENCES  ENCOUNTERED".   Continue  with  the
D60SPD commands for the remainder of the lines.

To do a continuous transfer of data follow the same procedure as  described
above only do not specify a file i.e.
MANUAL TESTS                                                       Page 4-5


        PTYCON> "C AIN"
        D60SPD>"SET SIM/PORT:11/DEV:0/LIN:0/3780"
        D60SPD>"IN"
        "^X"
        PTYCON> "C AOUT"
        D60SPD>"SET SIM/PORT:11/DEV:0/LINE:1/3780"
        D60SPD>"OUT"
        "^X"

You can use the KDP*.ATO files in the <MFG> area to do this  automatically.
For example assuming the AIN and AOUT subjobs are running D60SPD type:

        PTYCON> "GET <MFG>KDP1A.ATO"

or for lines 2,3 KDP1B.ATO      subjobs BIN and BOUT
             4,5 KDP1C.ATO      subjobs CIN and COUT

or lines in the DN20 on DTE 2:

             0,1 KDP2A.ATO      subjobs AIN and AOUT
             2,3 KDP2B.ATO      subjobs BIN and BOUT
             4,5 KDP2C.ATO      subjobs CIN and COUT

Once the lines have begun transferring the tty  will  periodicly  output  a
status line.  To stop the transfer send the EOF command to the line(s) that
is transferring i.e.

        PTYCON> "AOUT-EOF"

When testing on all lines is complete kill off the PTYCON subjobs and  exit
to get back to the EXEC level:

        PTYCON> "KILL ALL"
        PTYCON> "EXIT"
        $


4.4  DN20 CRASH DUMP
4.4.1  IBMCON SELECTED -

If the DN20 stops record the address on the 11/34  panel.   Next  dump  the
contents of the DN20 by running DNLOAD:

        $"DNLOAD"
        DNLOAD>"DUMP 1 DTELD1.DMP"
        DNLOAD>"EXIT"
        $

        To find the trap code form the DUMP file type:


        $"RUN <DN64-SOURCES>D6TK3.EXE"
        _______.DMP/DTE

(then type)
MANUAL TESTS                                                       Page 4-6



        "TRPCOD["

Refer the <DN64-SOURCES>D6TK3.LST and IBMCON.MAN for  a  breakdown  of  the
codes.

4.4.2  DECNET SELECTED (IBMCON DE-SELECTED) -

In the case of a DN20 crash, DECNET automatically dumps  the  contentss  of
the DN20 memory to file SYS:DN20N1.DMP.

Further help TBS at a later date.

4.5  RUNNING DIAGNOSTICS IN USER MODE
To run diagnostics in USER mode you must first define the logical name  DSK
as  all the areas that contain the programs you will need.  Normally the 1,
2, and 3-DIAGNOSTIC areas.  To do this type:
                                                                      
$"DEF DSK: DSK:,<1-DIAGNOSTICS>,<2-DIAGNOSTICS>,<3-DIAGNOSTICS>"

or use the mic file in the <MFG> area

        $"DO <MFG>DIAG$"

You may now run DIAMON or DFDNA to call in the desired  diagnostics.   When
you are done remove the DSK definition by typing:

        $"DEF DSK:"











                                 CHAPTER 5

                            SYSTEM ERROR REVIEW



5.1  SPEAR REVIEW
As the person  assinged  to  this  system  during  acceptance,  it  is
required  that  you  maintain  at  least  the following information on
hardcopy during the acceptance.

SPEAR -1 listing which is up to date within 24 hours.

Preferably the listing should be a single listing  showing  all  SPEAR
sequences  from  sequence  1 to present.  To run SPEAR you may use the
SPEAR.MIC file in the <MFG> area in the following manner.

        $"DO <MFG>SPEAR$ (PARAMETERS) A,B,C"

where parameters are:

        A = Begin time: 
        B = Report: (SHORT OR FULL)
        C = Output dev: 

If a parameter is omitted it defaults to:

        Begin time:     EARLIEST
        Report:         SHORT
        Output Dev:     DSK:RETRIE.RPT

So to get a short listing for -1 Day on the tty type:

        @"DO <MFG>SPEAR -1,,TTY"

Or to get a full listing from seqence 1 to be printed on the
lineprinter type:

        @"DO <MFG>SPEAR ,FULL"

and when this completes:

        @"PRINT RETRIE.RPT"

Depending on the type and amount of errors the SHORT listing  may  not
be  sufficient  to evaluate the system.  For any system errors such as
SYSTEM ERROR REVIEW                                                Page 5-2


BUGINF, BUGHLT, or device errors that are not due to bad media produce
a FULL listing.

For a complete description of SPEAR commands refer to the SPEAR.MAN
SYSTEM ERROR REVIEW                                                Page 5-3


5.2  MASSRT
To review SPEAR that involves many masbus device errors use the MASSRT
program  which  is  designed  to  aid you in distinguishing electrical
errors from errors caused by bad media.   Before  running  MASSRT  you
must  first  make a disk listing of the masbus errors that you wish to
look at.

        $"CONN <MFG>"
        $"DO SPEAR ,FULL"

This will make a listing file "RETRIE.RPT" Now run massrt to sort  the
errors:

        $"MASSRT"
        
        MASSRT - DISK AND TAPE ERROR SORTING PROGRM
        
        COMMAND (G,S,D,L,F,B,R,Q,H) ? "F"
        
        TYPE FILENAME OF SPEAR LISTING "RETRIE.RPT"
        
                First make a tally of disk spots:
        
        COMMAND (G,S,D,L,F,B,R,Q,H) ? "DD3"
        O.K.

        COMMAND (G,S,D,L,F,B,R,Q,H) ? "G"

**************************************************************
MASBUS.LST*SEQ: 175= FRI 7 DEC 79 12:16:57 TO SEQ: 199=
**************************************************************
TIME OF LAST ERROR     SER#  MEDIA  CYL SUR SEC REPT T  CREG  EREG RH STAT 
--------------------------------------------------------------
SAT 8 DEC 79 19:37:34  0112. DP000  121   1  8  NONE S  READ  DCK
FRI 7 DEC 79 14:30:40  0112. DP000  546   2  0  NONE S  READ  DCK
SUN 9 DEC 79 09:24:16  0112. DP000  342   3 16  NONE S  READ  DCK
MON 10 DEC 79 03:43:29 0112. DP000  461   3  4     1 S  READ  DCK
MON 10 DEC 79 07:14:19 0112. DP000  461   3  4     2 S  READ  DCK
SAT 8 DEC 79 23:34:42  0112. DP000  461   3  8  NONE S  READ  DCK
SUN 9 DEC 79 04:02:08  0112. DP000  461   3  8  NONE S  READ  DCK
FRI 7 DEC 79 16:18:35  0112. DP000  619  11  8  NONE S  READ  DCK
FRI 7 DEC 79 18:10:06  0112. DP000  478  12 16  NONE S  READ  DCK
SUN 9 DEC 79 10:46:10  0112. DP000    6  13 16  NONE S  READ  DCK
SAT 8 DEC 79 13:22:03  0112. DP000  592  13  0  NONE S  READ  DCK
MON 10 DEC 79 05:56:36 0112. DP000  548  16  8  NONE S  READ  DCK
MON 10 DEC 79 06:34:54 0112. DP000  592  16  4  NONE S  READ  DCK
MON 10 DEC 79 05:48:51 0112. DP000  462  18 12  NONE S  READ  DCK
SAT 8 DEC 79 00:18:49  0112. DP000  548  18 16  NONE S  READ  DCK
TOTAL ERRORS = 0018 ...........................................

Examine the typeout for excessive errors on any particular surface  or
other  patterns  that may indicate an electrical failer.  In this case
the only errors are DCKS so a detailed SPEAR is not necessary for  the
disks.
SYSTEM ERROR REVIEW                                                Page 5-4


Now set up to look at the tape errors.  Sort by  program  because  the
same logical spot may be different for different programs.

        COMMAND (G,S,D,L,F,B,R,Q,H) ? "S"
        
        SORT BY CYL/PROGRAM........... (Y,N,E) ? "Y"
        EXAMINE SPOTS ONLY............ (Y,N,E) ? "E"
        
                Select tape entries.
        
        COMMAND (G,S,D,L,F,B,R,Q,H) ? "DT3"
        O.K.
        
        COMMAND (G,S,D,L,F,B,R,Q,H) ? "G"

*************************************************************
MASBUS.LST*SEQ: 175= FRI 7 DEC 79 12:16:57 TO SEQ: 199=
*************************************************************
TIME OF LAST ERROR     SER  MEDIA  PGM   FIL  REC REPT T  CREG
-------------------------------------------------------------
FRI 7 DEC 79 13:52:30 6281. MT100 MULTIO   0 1403 NONE H WRITE?
SUN 9 DEC 79 11:43:23 6281. MT100 MULTIO   0 2144 NONE S WRITE
FRI 7 DEC 79 21:41:39 6281. MT100 MULTIO   0 2356 NONE S WRITE
FRI 7 DEC 79 13:24:38 6281. MT100 MULTIO   0 5964 NONE H WRITE?
SAT 8 DEC 79 07:23:42 6281. MT100 MULTIO   0 6225 NONE S WRITE
FRI 7 DEC 79 12:16:57 6281. MT100 MULTIO   0 7905 NONE S WRITE
TOTAL ERRORS = 0007 ..........................................

In this case there are some "suspicious" entries which are  marked  by
MASSRT  by  the ?  after the error register.  Detailed SPEAR printouts
are required for these.  The easiest way is to type R?.

        COMMAND (G,S,D,L,F,B,R,Q,H) ? "R?"

If you have a line printer you need not wait for the cty to  spit  out
these errors;  Massrt makes a log as it goes.  Type a ^O then a cr and
wait for the command prompt.  By ending the program with the Q command
the displays generated above will be saved on the file MASSRT.LOG.

        COMMAND (G,S,D,L,F,B,R,Q,H) ? "Q"
        EXIT
        $

The file may then be printed out:

        $"PRINT MASSRT.LOG"

Read <MFG>MASSRT.HLP for a detailed explanation of the MASSRT program.
SYSTEM ERROR REVIEW                                                Page 5-5


5.3  MF20-TGHA
When a memory error occurs on systems with MF20's the monitor calls on
the TGHA program to perform error correction and possibly bit swapping
for the MF20.  All such occurrences are logged in the  TGHAV2.DAT  and
TGHAV2.TRA  files.   Multiple  non fatal memory errors may occur which
are not reported to SPEAR.  To evaluate  mos  memory  performance  you
must run the TGHA program.

        $"RUN <SYSTEM>TGHA"
        TGHA>"HISTORY"
        TGHA>"TRACE"
        TGHA>"EXIT"

        $"TYPE HISTORY.LST"
        $"TYPE TRACE.LST"

        Reject any storage modules with:

                1 or more hard errors
                2 or more soft errors within a 24 hour period

For a complete description of TGHA read TGHA-II.DOC
SYSTEM ERROR REVIEW                                                Page 5-6


5.4  REVIEW.MIC
To accomplish all of the steps normally needed to evaluate the  system
performance  use  the  REVIEW.MIC  file  in  the  <MFG>  area.   It is
advisable to execute the mic file from  a  video  terminal  since  the
output  may be quite lengthy.  The output file REVIEW.TXT can later be
typed or printed.

        $"DO <MFG>REVIEW.MIC (PARAMETERS) "

Where XXX is the time of the last entry shown on the previous  review.
If  this is the first review since starting the acceptance or you wish
to review the entire acceptance do not specify  any  parameters.   The
parameters  for  this mic file are used for SPEAR switches and must be
in valid  format  for  SPEAR  else  the  mic  file  will  not  process
correctly.   You  should  avoid using any switches other than the BEG:
and END:  switches because they may conflict with the ones already  in
the mic file.

REVIEW.MIC will assemble  the  following  information  into  one  file
"REVIEW.TXT" which can then be typed or printed.        

        MONNAM.TXT (customer name and system serial number)
        UPTIME.INF (current and accumulated uptime)
        SPEAR listing SHORT
        SPEAR listing SUM
        TGHA HISTORY.LST
        TGHA TRACE.LST
        SPEAR Analyze (including detailed SPEAR entries for errors
                that are not  one of the following...

                DISKS - dck (ER02: 100000)

                TAPES - corr/crc (ER02: 100000)
                        pfe/lrc (ER02: 200)
                        nde/vpe (ER02: 100)
                        for dx20/TX (ER02: 600)


5.5  DATA COLLECTION
Save the REVIEW.TXT or equivalent for Q.C.   evaluation.   The  review
should encompass the entire valid acceptance window.  That is from the
reload starting the valid uptime to the completion of the acceptance.

Also save the final UETP STATUS which should be typed on  the  CTY  at
completion of the acceptance.











                                 CHAPTER 6

                           CLEANING UP THE PACK



After the system data has been collected and the system has been signed off
the KLAD must be "cleaned up" before it can be shipped.  Do the following:

        $"CONN <MFG>"
        $"DO DELETE-SPEAR.MIC"

which does the following:

        DELETE <SYSTEM-ERROR>ERROR.SYS
        DELETE <SYSTEM>TGHAV2.*
        DELETE <MFG>UPTIME.INF
        DELETE <UETP.RUN>*.*
        EXP <UETP.RUN>
        TAKE <UETP.LIB>CLEAN-UP.CMD

Next type :

        $"DO MFG-CLEAN.MIC" (which does the following:)

which does the following:

        DEL <MFG>*.LST
        DEL <MFG>RPT*.*
        DEL <MFG>*.LOG
        DEL <MFG>*.TXT
        EXP <MFG>

Next type:

        $"DEL <SPOOL>*.*"
        $"DEL <*>*.LOG"
        $"DEL <*>*.LST"

This should have gotten most of the files that were to be deleted.  Now get
a directory of new files:

        $"DIR <*>*.*,"
        $$"SINCE MM-DD-YY"
        $$"<CR>"
CLEANING UP THE PACK                                               Page 6-2


Where MM-DD-YY is the day after the pack was made (see  the  label  on  the
pack).  At this point you should delete only the files that you know do not
belong on the pack.











                                APPENDIX A

A.1  UETP SELECTABLE TESTS

APPLICATION TESTS                       DIAGNOSTIC TESTS
___________________                     ___________________
 ALGOL.VER                               CPUBAS.VER
 APL.VER                                 CPUREL.VER
 APLSF.VER                               MEMBAS.VER
 BASIC.VER                               MEMREL.VER
 CBLSRT.VER                              DFDXG.VER ;Diagnostic for RP20
 COBOLD.VER                              DFRPM.VER ;Diagnostic for RP07
 DBMS.VER                                USER.VER ;Pages test for Disks
 FORTRA.VER             
 RANCBL.VER             
 RANFOR.VER                     
 SORT.VER               

IBMCON TESTS                            DECNET TESTS
____________________                    ____________________
 DN22R.VER      ;KS10                    DN20N1 ;For DTE-1
 DN22S.VER      ;KS10                    DN20N2 ;For DTE-2
 DN64A.VER      ;LINE 0-1 DUP11 DTE-1    DN20N3 ;For DTE-3
 DN64B.VER      ;LINE 2-3 DUP11 DTE-1           ;All synchronous
 DN64C.VER      ;LINE 4-5 DUP11 DTE-1           ;lines with loop-
 DN64L.VER      ;IBID. EXCEPT DTE-2             ;back (MODEM ON DUP11)
 DN64M.VER
 DN64N.VER

PERIPHERAL TESTS
_________________
 LPT0.VER       ;LINEPRINTER NO. 1 
 LPT1.VER       ;LINEPRINTER NO. 2
 MTA0.MAX       ;FULL TEST FOR MAGTAPES(1600 & 6250 BPI)
                ;CREATED BY CONFIG.EXE

QUICK TEST FOR MAGTAPES                 FULL TEST FOR MAGTAPES (1600 ONLY)
_______________________                 ______________________________________
 MTA0.VER                                MTA0.CMP
 MTA1.VER                                MTA1.CMP
 MTA2.VER                                MTA2.CMP
 MTA3.VER                                MTA3.CMP
 MTA4.VER                                MTA4.CMP
 MTA5.VER                                MTA5.CMP
 MTA6.VER                                MTA6.CMP
 MTA7.VER                                MTA7.CMP











                                APPENDIX B

B.1  MFG SPECIAL FILES.

CONFIGURATION FILES.

        CONFIG.EXE      CONFIG program to configure auto files for
                        auto acceptance testing under UETP.
        CONFIG.B20      Basic source for CONFIG
        CONFIG.B19      Previous version of CONFIG
        DDRPI.B20       CONFIG source for disk testing with DDRPI.
        DN200.B20       CONFIG source for building DN200 software.
        DN20BLD.B20     CONFIG source for building DN20 software.
        MEM.B20         CONFIG source for generating multiple  tests
                        which run memory diags.
        MEM.DAT         MEM library file.
        CONMAC.MAC      Editing subroutines source

        CNF-SAVE.MIC    Copies the system/Uetp auto files into <MFG>
                        area for future restoration after a temporary
                        CONFIG change.
        CNF-REST.MIC    Copies configuration files saved by CNF-SAVE
                        to the system auto files.

        MAKDMP.MIC      Makes a new DUMP.EXE for system.

        TYPE-SYSTEM-FILES.MIC   Types all common system and UETP
                                auto files.


----------------------------------------------------------------------

DN20 - DECNET.

        DN1-START.MIC   Loads and starts DN20N1 Decnet node on FE1
        DN1-STOP.MIC    Crashes DN20N1 node and optionally
                        load DECX into FE1.
        DN1-SHOW.MIC    Runs OPR/NCP and displays counter summaries
                        for DECNET node DN20N1 (DN20 on FE1).

        DN20N1.MIC      Manual test for DN20N1

        DN1-DMR1.SYS            DECNET MCB monitor for DN20 on FE1
                                with 1 DMR.
        DN1-DMR3-DUP2-DUP2.SYS  DECNET MCB monitor for DN20 on FE1
                                with 3 DMR's, 2 DUP's on KDP-0
                                                                   Page B-2


                                and 2 DUP' on KDP-1
        DN1-DUP2.SYS            DECNET MCB monitor for DN20 on FE1
                                with 2 DUP's

----------------------------------------------------------------------

DN20 - IBMCON.

        D60SPD.ATO      Sets up 6 PTYCON subjobs for IBMCON testing

        KDP1A.ATO       Manual testing with IBMCON software.
                        For use with D60SPD.ATO - transfers data
                        between DUP's 0 and 1 on FE1.
        KDP1B.ATO       between DUP's 2 and 3 on FE1.
        KDP1C.ATO       between DUP's 4 and 5 on FE1.
        KDP2A.ATO       between DUP's 0 and 1 on FE2.
        KDP2B.ATO       between DUP's 2 and 3 on FE2.
        KDP2C.ATO       between DUP's 4 and 5 on FE2.

----------------------------------------------------------------------

ERROR EVALUATION.

        SPEAR.MIC       Runs SPEAR with SPEAR arguments supplied in
                        MIC parameters.
        SPEAR.CTL       Batch control file to review system errors.

        PVSPR.CTL       Batch file to generate reports for MFG KL10 PV
                        acceptance.

        REVIEW.MIC      Runs SPEAR, MASSRT, TGHA and generates a
                        report for MFG acceptane evaluation.

        MASSRT.EXE      Program to sort masbus disk and tape entries
                        from a SPEAR FULL report file.
        MASSRT.CBL      Cobol source.
        MASSRT.HLP      Detailed help file.
        MASSRT.MIC      Runs SPEAR and MASSRT.

        UPTIME.EXE      Program run under SYSJOB to keep track of
                        current and accumulated system uptime for
                        MFG acceptance data.
        UPTIME.INF      File updated by UPTIME.EXE every second
                        starting 15 minutes after system boot.
        UPTIME.MAC      Macro source for UPTIME.

        TDBLD.EXE       Program to compute skip displacement values
                        for RP07 disks.
        TDBLD.B20       Basic source for TDBLD.

----------------------------------------------------------------------
                                                                   Page B-3



MISCELLANEOUS.

        UETP.ATO        PTYCON auto file to intialize the UETP subjob
                        and restart UETP tests.
        UETP-SETUP.ATO  Same as UETP.ATO but does not enable or start
                        any tests.

        SUB.MIC         Submits to batch the CTL file specified by
                        parameter A.

        DIAGNOSTIC-DEFINE.MIC   Defines DSK: for running diagnsotics

        DELETE-SYSERR.MIC       Renames ERROR.SYS to RETRIE.SYS
                                and deletes log files.
        MFG-CLEAN.MIC   Deletes temporary files created by auto files
                        in the MFG area.

        PAUSE.EXE       Program that sleeps for 15 seconds used in
                        some auto files for delays between commands.
        PAUSE.MAC       Macro source.

        SLEEPR.MAC      Macro source for SLEEPR program which
                        sleeps for X number of minutes used by
                        some tests for delay.