Trailing-Edge
-
PDP-10 Archives
-
k20v7b
-
mfg/klad20_mfg_guide.doc
There are no other files named klad20_mfg_guide.doc in the archive.
CHAPTER 1 STARTING UP THE SYSTEM
1.1 BOOTING THE SYSTEM . . . . . . . . . . . . . . . . 1-1
1.2 ATTACHING TO PTYCON . . . . . . . . . . . . . . . 1-7
1.3 PTYCON JOBS . . . . . . . . . . . . . . . . . . . 1-7
1.4 LOGGING ONTO THE SYSTEM . . . . . . . . . . . . . 1-8
1.5 JOB PARAMETERS. . . . . . . . . . . . . . . . . . 1-9
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 CI20. . . . . . . . . . . . . . . . . . . . . . 2-5
2.2.8 NI20. . . . . . . . . . . . . . . . . . . . . . 2-6
2.2.9 DC20 Lines. . . . . . . . . . . . . . . . . . . 2-6
2.2.10 Lineprinters. . . . . . . . . . . . . . . . . . 2-6
2.2.11 DN20's . . . . . . . . . . . . . . . . . . . . . 2-6
2.2.11.1 CONFIGURING FOR DECNET. . . . . . . . . . . . 2-7
2.2.11.2 Configuring For IBMCON. . . . . . . . . . . . 2-9
2.2.12 AN20. . . . . . . . . . . . . . . . . . . . . 2-10
2.2.13 Memory Size. . . . . . . . . . . . . . . . . . 2-10
2.2.14 Test Process. . . . . . . . . . . . . . . . . 2-10
2.2.15 CONFIG INSTRUCTIONS. . . . . . . . . . . . . . 2-10
2.3 CHANGING THE CONFIGURATION . . . . . . . . . . . 2-11
2.4 BUILDING THE DECNET NODES. . . . . . . . . . . . 2-13
2.5 BUILDING THE DISK STRUCTURES. . . . . . . . . . 2-15
2.6 INITIALIZING THE ERROR FILES . . . . . . . . . . 2-17
2.7 RUNNING MAKDMP . . . . . . . . . . . . . . . . . 2-17
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
Page 2
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
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
Page 3
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. This document was last edited
for use on KLAD20 revision:
KLAD20-AB-6.1-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.
4. Updated for CI20, NI20, Process variables, TOPS20 Rel 6.1,
Decnet Phase IV Aug. 1985 - Tom Duda.
5. Jan 1987 - Tom Duda; Changed name of document from
KLAD20-USER-GUIDE to KLAD20_MFG_GUIDE to avoid confusion with
KLAD20 document put out by Rel Eng. Updated to state for
which KLAD20 release the document was last edited rather than
for which release it is intended.
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
Page 4
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 VB15-21 14:06 21-FEB-85
[SY0: REDIRECTED TO DB0:]
[DB0: MOUNTED]
KLI -- VERSION VB15-15 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
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 2.0[400] 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 4 4 4
KLI -- CONFIGURE MOS MEMORY [ALL,YES,NO]?
KLI>"ALL"
LOGICAL MEMORY CONFIGURATION.
ADDRESS SIZE INT TYPE CONTROLLER
00000000 768 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]
If there is a CI20 on the system the CI Microcode is then loaded via
<SYSTEM>IPALOD.EXE which contains the microcode.
[IPALOD: UCODE 674 BEING LOADED INTO CI-20]
[IPALOD: UCODE 674 LOADING COMPLETED]
At this point SETSPD runs and examines the file <SYSTEM>6-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,
1985 at 1:05 pm could be entered as:
"2-MAY-85 1305"
OR
"5-2-85 1305"
OR
"5-2-85 105PM"
YOU HAVE ENTERED FRIDAY, 2-MAY-1985 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.
STARTING UP THE SYSTEM Page 1-4
WHY RELOAD? "OTHER CONFIG"
RUN CHECKD?
Note:
If there is a CI20 on the system, typically before you get a chance to
answer to the "RUN CHECKD?" promt, you should see the following
BUGINF's that denote the initialliazion of the CI port. Remember to
answer "Y" or "N" after the BUGINF's.
"KLPLOA" CI-20 U-CODE RELOAD IN PROGRESS
"KLPSTR" PYYKLP: CI-20 STARTED
"KLPOVC" OPENED VIRTUAL CIRCUIT (if HSC50 Online)
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
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
*****
2-MAY-85 13:10:03 - TGHA 4(0) IN OPERATION.
*****
SYSJOB 6A(20) STARTED AT 2-MAY-85 1310
The SYSJOB program reads the file PS:<SYSTEM>6-1-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 6-1-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
6-1-PTYCON.ATO OPR will take the command file SYSTEM.CMD to
automaticaly start up the batch streams, line printer, card reader
etc.
STARTING UP THE SYSTEM Page 1-5
If ther is an NI20 on the system you should also see the Microcode
loading message:
[KNILDR: LOADING MICROCODE VERSION 1(162) INTO ETHERNET CHANNEL 0]
RUN SYS:ORION
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:6-1-PTYCON.ATO
/JOB 1/LOG OPERATOR XX OPERATOR
ENA
RUN SYS:BATCON
/
SJ 0:
SJ 0: @LOG OPERATOR OPERATOR
SJ 0: JOB 1 ON TTY206 2-MAY-85 13:11:47
SJ 1: @LOG OPERATOR OPERATOR
SJ 1: JOB 2 ON TTY207 2-MAY-85 13:11:47
SJ 0: FRIDAY, MAY 2 1985 13:11:48
SJ 1: FRIDAY, MAY 2 1985 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:6-1-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
STARTING UP THE SYSTEM Page 1-6
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-7
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 6.1(6625)
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
STARTING UP THE SYSTEM Page 1-8
TEST PACKAGE program. See RUNNING THE ACCEPTANCE.
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.
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
@"LOG F-S FS" ; to login to F-S
or
@"LOG MFG MFG" ;to login to MFG
STARTING UP THE SYSTEM Page 1-9
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".
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
STARTING UP THE SYSTEM Page 1-10
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 6-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
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 6-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
CONFIGURING THE SYSTEM Page 2-2
KERNEL process which includes Lineprinters, DC20's and DN20's (and
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 (not supported) 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
CI20 CI20 Loopback testing x x
NI20 NI20 Loopback testing x 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
PROCESS System or Peripheral testing x x
The following paragraphs describe the CONFIG dialogue for each
CONFIGURING THE SYSTEM Page 2-3
configuration category when you are configuring the entire system.
For help on the "CHANGE" command refer to section "CHANGING THE
CONFIGURATION".
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
CONFIGURING THE SYSTEM Page 2-4
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
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 6-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 CI20. -
In Mfg. CI20's are accepted one of two ways. It is tested via the
standard disk tests if disk(s) are configured on channel 7 HCS50/RAxx
(ie HSC31.VER) or if an HSC50 is not connected then it is tested via
CI20 diagnostics in loopback mode (CILOOP.VER).
If you have already configured a disk on Channel 7 CONFIG will assume
that you do not wish to run the loopback tests on the CI and will
output the following message:
CI20 Loopback Test disabled because Disk(s) configured on Channel 7
Otherwise CONFIG will ask:
Does the system have a CI20 (Y,N) ? ? "Y"
If you answer "Y" CONFIG will enable the CILOOP test and place a
command in 6-1-PTYCON.ATO to "SET PORT CI UNAVAILABLE" needed to allow
the diagnostics to run on the CI.
CONFIGURING THE SYSTEM Page 2-6
2.2.8 NI20. -
NI20's are tested in loopback mode in Mfg.
Does the system have a NI20 (Y,N) ? ? Y
If you answer "Y" CONFIG enables NILOOP diagnostic tests and places
the command "SET PORT NI UNAVAILABLE" into the 6-1-PTYCON.ATO needed
to allow the diagnostics to run on the NI.
2.2.9 DC20 Lines. -
Enter the amount of DC20 lines X on FE0 in OCTAL. CONFIG will use
this value to modify 6-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.10 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
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.11 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".
CONFIGURING THE SYSTEM Page 2-7
2.2.11.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 2 KDP's.
5. Maximum of 8 DUP's (4 per KDP) at 9.6K or 19.2K baud
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 2 DUP's at 9.6K - *
9. Maximum of 2 DMR's at 56K with 4 Dup's at 9.6K - *
10. Maximum of 1 DMR at 56K with 6 Dup's at 9.6K - *
* - limits determined by MFG evaluation using DN20N1 test.
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
CONFIGURING THE SYSTEM Page 2-8
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.
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.
CONFIGURING THE SYSTEM Page 2-9
2.2.11.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.
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.
CONFIGURING THE SYSTEM Page 2-10
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.12 AN20. -
IS THERE AN AN20 ON THIS SYSTEM ? (Y,N) "N"
If you answer "Y" to the previous question CONFIG will edit the
6-1-PTYCON.ATO file to login a subjob (AN20) and run diagnostic DDANB
to test the AN20.
2.2.13 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. HOW MUCH K TOTAL OF MEMORY ? 2048 NOTE: USING
PREFIX "6-1-"
2.2.14 Test Process. -
In Mfg there are basically two types of acceptance: Systems
acceptance and Peripheral acceptance. If the entire system is to be
tested or if the CPU and/or Memory is to be tested then you should
select the "S" or System process. This will cause CPU and Memory
diagnostic tests to be run along with the UETP language tests in
addition to the appropriate peripheral tests.
If only a peripheral is being tested ie an "add on" HSC50/RAxx then
select the "P" Peripheral process wich will cause only the selected
peripheral tests to run.
Type 'H' for help.
Test Process (S = System, P = Peripheral, H) ? "S"
2.2.15 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.
CONFIGURING THE SYSTEM Page 2-11
Peripheral Tests:
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
Warning: There are some bugs with the "CHANGE" , "ADD", and "REMOVE"
commands. Use of these commands is not recomended for infrequent
reconfigurations.
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 6-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-12
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-13
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 (on KDP-0)
then $"COPY <MFG>DN1-DUP2.SYS <SUBSYS>DN20N1.SYS.0"
or 1 DMR AND 2 DUP'S (on KDP-0)
then $"COPY <MFG>DN1-DMR1-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
CONFIGURING THE SYSTEM Page 2-14
see if the CTL files are finished. You will otherwise not be notified
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-15
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-85 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-16
$"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-17
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 and create a new DUMP.EXE to reflect the
current amount of memory (2048K in the following example). Otherwise
if the system crashes there will be no dump and the system will not
automatically reboot.
$"CONN <SYSTEM>"
$"DEL DUMP.EXE"
$"EXP"
$"RUN <UTILITIES>MAKDMP"
MAKDMP>"CREATE PS:<SYSTEM>DUMP.EXE 2048"
MAKDMP>"EXIT"
or to make life easier use the mic file:
$"CONN <MFG>"
$"DO MAKDMP 2048"
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 6-1-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:
@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 6-1-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 6-1-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-85 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-85 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-85 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
RUNNING THE ACCEPTANCE Page 3-6
system.
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:
MANUAL TESTS Page 4-2
$"COPY <SUBSYS>DN20N1.SYS <MFG>DN1-DMR2-DMC1-DUP2.SYS
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
MANUAL TESTS Page 4-6
(then type)
"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
SYSTEM ERROR REVIEW Page 5-2
be sufficient to evaluate the system. For any system errors such as
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
Page A-2
CI20 TESTS
----------
CILOOP.VER, CILOOP.MAX
HSC31.VER
NI20 TESTS
----------
NILOOP.VER, NILOOP.MAX
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.