Trailing-Edge
-
PDP-10 Archives
-
6.1_emacs_manuals_1er
-
manuals/klad-user-guide.mem
There are no other files named klad-user-guide.mem in the archive.
CHAPTER 1 STARTING UP THE SYSTEM
1.1 BOOTING THE SYSTEM . . . . . . . . . . . . . . . . 1-1
1.2 ATTACHING TO PTYCON . . . . . . . . . . . . . . . 1-5
1.3 PTYCON JOBS . . . . . . . . . . . . . . . . . . . 1-5
1.4 LOGGING ONTO THE SYSTEM . . . . . . . . . . . . . 1-6
CHAPTER 2 CONFIGURING THE SYSTEM
2.1 WHEN TO RUN THE CONFIGURATION PROGRAM . . . . . . 2-1
2.2 RUNNING THE CONFIGURATION PROGRAM . . . . . . . . 2-1
2.3 RUNNING MAKDMP . . . . . . . . . . . . . . . . . . 2-4
2.4 INITIALIZING THE ERROR FILES . . . . . . . . . . . 2-4
2.5 CHANGING THE CONFIGURATION . . . . . . . . . . . . 2-4
2.6 CONFIGURING FOR DUP11'S ONLY (IBMCON SELECTED) . . 2-5
2.7 CONFIGURING FOR RA81 . . . . . . . . . . . . 2-6
CHAPTER 3 MANUAL TESTS
3.1 DC20 LINES TEST . . . . . . . . . . . . . . . . . 3-1
3.2 DECNET TESTS FOR SYNCHRONOUS LINES . . . . . . . . 3-1
3.3 DN20/DUP TESTS.(IBMCON SELECTED) . . . . . . . . . 3-2
3.4 DN20 CRASH DUMP . . . . . . . . . . . . . . . . . 3-4
3.4.1 IBMCON SELECTED . . . . . . . . . . . . . . . . 3-4
3.4.2 DECNET SELECTED (IBMCON DE-SELECTED) . . . . . . 3-4
3.4.3 RUNNING DIAGNOSTICS IN USER MODE . . . . . . . . 3-4
CHAPTER 4 RUNNING THE ACCEPTANCE
4.1 PRE ACCEPTANCE CHECKS . . . . . . . . . . . . . . 4-1
4.2 STARTING THE ACCEPTANCE . . . . . . . . . . . . . 4-2
4.3 MONITORING THE ACCEPTANCE . . . . . . . . . . . . 4-3
4.4 THE BATCH JOBS . . . . . . . . . . . . . . . . . . 4-3
4.5 UETP STATUS . . . . . . . . . . . . . . . . . . . 4-4
4.6 STOPPING AND RESTARTING THE JOBS. . . . . . . . . 4-5
CHAPTER 5 SYSTEM ERROR REVIEW
5.1 SPEAR REVIEW . . . . . . . . . . . . . . . . . . . 5-1
5.2 MASSRT . . . . . . . . . . . . . . . . . . . . . . 5-2
5.3 MF20-TGHA . . . . . . . . . . . . . . . . . . . . 5-4
5.4 REVIEW.MIC . . . . . . . . . . . . . . . . . . . . 5-5
5.5 DATA COLLECTION . . . . . . . . . . . . . . . . . 5-5
CHAPTER 6 CLEANING UP THE PACK
Page 2
APPENDIX A
A.1 UETP SELECTABLE TESTS . . . . . . . . . . . . . . A-1
skip 9
INTRODUCTION
This guide book contains the monitor run directions and
parameters for the Tops-20 Uetp acceptance run. Covered in this
hand book are the start-up and configuration procedures as well
as help in the monitoring of the acceptance run.
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 microcode will
automaticly 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 of the three
cases the BOOT ENABLE switch must depressed at the same time.
-----------------------------------------------------------------
! !
! 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 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 as
shown above.
RSX-20F VB13-41D 14:06 21-FEB-80
[SY0: REDIRECTED TO DB0:]
STARTING UP THE SYSTEM Page 1-2
[DB0: MOUNTED]
KLI -- VERSION VB12-12 RUNNING
KLI -- ENTER DIALOG [NO,YES,EXIT,BOOT]?
KLI>YE
KLI -- KL10 S/N: 2485., MODEL B, 50 HERTZ
KLI -- KL10 HARDWARE ENVIRONMENT:
MOS MASTER OSCILLATOR
EXTENDED ADDRESSING
INTERNAL CHANNELS
CACHE
KLI -- RELOAD MICROCODE [YES,VERIFY,FIX,NO]?
KLI -- YE
KLI -- MICROCODE VERSION 231 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
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> (type carriage return)
A carriage return loads the default monitor
<SYSTEM>MONITR.EXE. For F.A.T'. 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>6-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
STARTING UP THE SYSTEM Page 1-3
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 trying to evaluate
SPEAR.
WHY RELOAD?
Tops-20 will accept any answer (maximum of 80 characters)
which will be recorded in the system reload entry in SPEAR. Type in
an accurate description for example "RESTART AFTER REPLACING BAD HEAD
6 ON RP06 2543" that will help in evaluating SPEAR at a later date.
RUN CHECKD? (type Y or N)
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.
[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
STARTING UP THE SYSTEM Page 1-4
/JOB 1/LOG OPERATOR XX OPERATOR
ENA
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 PTYCON to get UETP.CMD which will in turn
start up the UETP acceptance. See STARTING THE ACCEPTANCE.
STARTING UP THE SYSTEM Page 1-5
1.2 ATTACHING TO PTYCON
After the system has completed it's ato boot you should attach
to the Operator job which is running PTYCON to get access to the
subjobs running under it.
Type C
You will get a response similar to :
SN: 1234 RELEASE 5.1, KLAD20-W-5.1-A, TOPS-20 Monitor 5(4747)
@
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
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. 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
See PTYCON.HLP for a complete list of PTYCON commands.
STARTING UP THE SYSTEM Page 1-6
1.4 LOGGING ONTO THE SYSTEM
There are two areas on the KLAD pack that you can log into:
The F-S area and the OPERATOR area. To login type:
C
LOG OPERATOR KLAD ;to login to operator
or
LOG F-S FS ; to login to F-S
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 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
KLAD-20 ACCEPTANCE CONFIGURATION PROGRAM Password? MFG for
Manufacturing H for help Type
COnfig to initialize system ato files
and to configure all devices Type
CHange to change individual lines in
ato files for selected groups of devices
The first time you run CONFIG you should respond with "CO"
since you don't know exactly what has already been configured.
CO
CUSTOMER NAME ?.......... CUSTOMER INC.
SYSTEM SERIAL NUMBER ?... 1234
PS:<SYSTEM>MONNAM.TXT DONE!
CONFIGURING THE SYSTEM Page 2-2
CONFIG tells you what files are being modified as it writes
them. The system name and serial number just entered will be
displayed the next time the system is loaded and you login. This
section is for magtapes.
MTA's TO BE TESTED:
Type E when done H for help
Density to be tested (e.g. TU78=6250)?
...
MTA0
MTA1
E
PS:<UETP.LIB>MTA0.MAX DONE!
PS:<UETP.LIB>MTA1.MAX DONE!
These tests just created will run TAPWRT,TAPRED. The
next section is for 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 LINE PRINTERS ? (0-2) 2
DOES LPT0 HAVE A PROGRAMMABLE VFU ? (Y,N) N
DOES LPT0 HAVE LOWERCASE ? (Y,N) N
DOES LPT1 HAVE A PROGRAMMABLE VFU ? (Y,N) Y
DOES LPT1 HAVE LOWERCASE ? (Y,N) Y
These next two sections are self explanatory.
IS THERE AN AN20 ON THIS SYSTEM ? (Y,N) N
The next section is for DN20's(IBMCON de-selected). DN20's
containing synchronous lines are tested under the monitor by loading
decnet tests. CONFIG will make files for building, loading and
testing the node. These files are valid for use only on DN20's with
at least 128 K of memory. These Decnet tests will test both
DUP's and DMR's under Uetp.
HOW MANY DN20 FRONT ENDS ? (0-3) 2
Enable IBMCON? No
NOTE: Do not use test in MFG- answer "N"
HOW MANY DUPS IN DN20 ON DTE 1 ? (0-8) 0
HOW MANY DMC'S IN DN20 ON DTE 1 ? (0-4) 0
HOW MANY DMR's IN DN20 ON DTE 1 ? (0-4) 1
HOW MANY DUPS IN DN20 ON DTE 2 ? (0-8) 2
HOW MANY DMC'S IN DN20 ON DTE 2 ? (0-4) 0
HOW MANY DMR's IN DN20 ON DTE 2 ? (0-4) 0
The following files are those used to build, load the Decnet
nodes and run UETP or a manual loopback test on the synchronous lines.
The node type is DN20 and the front end number is signified by the NX
where X is the Dte number on which the front end is connected.
CONFIGURING THE SYSTEM Page 2-3
PS:<MFG>DN20N1.CTL CTL files to build the synchronous lines.
PS:<MFG>DN20N1.VER UETP files to test the synchronous lines.
PS:<MFG>DN20N1.CMD OPR CMD file to load the node.
PS:<MFG>DN20N1.MIC MIC files are used for manual tests
NOTE: For DN20 options type "SUB <MFG>DN20N1/TIME"
to build you MCB software.
PS:<SYSTEM>6-CONFIG.CMD DONE!
TIME TO RUN ACCEPTANCE (PASSES,HOURS,CONT) 24:00 (HH:MM)
If you had changed auto uetp- the GET SYSTEM:UETP.ATO command
in SYSJOB.RUN would not be executed allowing you to manually start
UETP and select your choice of tests.
PS:<UETP.LIB>RELIAB.CMD DONE!
Reliab.cmd is a command file taken by UETP under UETP.ATO to
enable the various UETP tests. CONFIG always enables the tests used
in F.A.T. for any devices that are in the Configuration. You could
run CONFIG to configure the devices into the system and then edit this
file to change any tests that you wish to run.
PS:<SYSTEM>UETP.ATO DONE!
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.
PS:<SYSTEM>PTYCON.ATO DONE!
PS:<SYSTEM>SYSJOB.RUN DONE!
PS:<SYSTEM>SYSTEM.CMD DONE!
Correct Monitor is 2060-MONMAX
NOTE: 2060-MONMAX IS THE DEFAULT MONITOR
EXIT
$
NOTE
TO INSURE THAT THE CONFIGURATION CHANGES
ARE IMPLEMENTED, THE SYSTEM SHOULD BE
RELOADED.
CONFIGURING THE SYSTEM Page 2-4
2.3 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 dump.
$CONN <SYSTEM>
$DEL DUMP.EXE
$EXP
$RUN <UTILITIES>MAKDMP
2.4 INITIALIZING THE ERROR FILES
Prior to starting the acceptance for the first time, you
should delete any error files that may contain data from previous
systems. Do the following.
$DEL <SYSTEM-ERROR>ERROR.SYS
$DEL <SYSTEM>TGHAV2.*
$DEL <UETP.RUN>*.*
or use the mic file
$DO <MFG>DELETE-SPEAR.MIC
Once the acceptance has been started ERROR.SYS and TGHAV2.*
should never be deleted until the acceptance is complete and signed
off.
2.5 CHANGING THE CONFIGURATION
If you had made a mistake or for any reason wish to change the
configuration you could run CONFIG again and make a change as opposed
to going through the entire dialogue. For example:
$CONFIG
KLAD-20 ACCEPTANCE CONFIGURATION PROGRAM
Password?
H for help
type each group to be reconfigured, cr after each
type EX when finished
GROUPs are:
- Disks
- Magtapes
- Line Printers
- Memory Size
- DC20 Lines
- System Name/Serial
- DN20s front ends and line units
- AN20s
- Length of Time to Run Acceptance
- Sel/Des UETP.ATO startup
CONFIGURING THE SYSTEM Page 2-5
*EX
HOW MANY DN20 FRONT ENDS ? (0-3) 0
PS:<SYSTEM>6-CONFIG.CMD DONE!
PS:<UETP.LIB>RELIAB.CMD DONE!
PS:<SYSTEM>SYSJOB.RUN DONE!
EXIT
$
2.6 CONFIGURING FOR DUP11'S ONLY (IBMCON SELECTED)
The next section is for DN20's(IBMCON 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. These test files are
valid for use only on DN20's with at least 128 K of memory.
Therefore do not specify DMC/DMR'S in the configuration if the
DN20 does not have 128 K.
HOW MANY DN20 FRONT ENDS ? (0-3) 2
Enable IBMCON? Yes (Testing DUP11'S only)
HOW MANY DUPS IN DN20 ON DTE 1 ?(0-8) 3
DUPS ARE TESTED IN PAIRS MUST BE AN EVEN NUMBER
HOW MANY DUPS IN DN20 ON DTE 1 ? (0-8) 0
HOW MANY DMC'S IN DN20 ON DTE 1 ? (0-4) 0
HOW MANY DMR's IN DN20 ON DTE 1 ? (0-4) 1
HOW MANY DUPS IN DN20 ON DTE 2 ? (0-8) 2
HOW MANY DMC'S IN DN20 ON DTE 2 ? (0-4) 0
HOW MANY DMR's IN DN20 ON DTE 2 ? (0-4) 0
PS:<UETP.LIB>DN12A.VER EXISTS
PS:<UETP.LIB>DN12SA.SEND EXISTS
These Uetp test files 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..)
The following files are those used to build, load the
Decnet nodes and run a manual loopback test on the DMC/DMR's.
The node type is DN20 and the front end number is signified by
the NX where X is the Dte number on which the front end is
connected. Note that tst files were not made for the second
front end which does not include any DMC's.
PS:<MFG>DN20N1.CTL CTL files to build the synchronous
lines.
CONFIGURING THE SYSTEM Page 2-6
PS:<MFG>DN20N1.VER UETP files to test the synchronous
lines.
PS:<MFG>DN20N1.CMD OPR CMD file to load the node.
PS:<MFG>DN20N1.MIC MIC files are used for manual tests
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 DONE!
When you are done running the CONFIG program, before you
shut down the system, type :
SUBMIT <MFG>DN20N1.CTL/TIME
This is the Ctl file that will build the Decnet node.
Wait until the batch job is finished then load the Decnet
software. Refer to the section DECNET TESTS for manual test on
DMC/DMR'S upon completion of DUP11 tests.
2.7 CONFIGURING FOR RA81
The following procedure for installing an RA81 on a
TOPS20 system, should be used after configuring the system with
CONFIG.exe.
TYPE:
@ENA (enable priv.)
CONN <MFG> (connect to the MFG directory)
UNITS (find out if the RA81'S have a structure name)
Status of Disk Units:
Mounted? Type Channel Cont. Drive Structure Logical unit
-------- ---- ------- ----- ----- ------- -----------
YES RP06 0 -1 0 PS: 0 (1 of 1)
YES RA81 7 1 1 USERA: 0 (1 of 1)
Note: If not load the KLIPA UCODE
Type:
IPALOD
and reboot the HSC50 and MONITOR (see HSC50-USER-GUIDE.MEM or CHAPTER 1.1 )
Or use OPR as follows:
OPR
OPR> SHOW STATUS DISK-DRIVE
OPR>
13:05:14 --Disk Drive Status--
FREE DRIVES:
Type Chan Ctrl Drive Structure
---- --------------- ---------
MOUNTED DRIVES:
Structure Type Chan Ctrl Drive Count Options
------------- ---- --------------- ----- ---------
PS: RP06 0 -1 0 0 Domestic
USERA: RA81 1 7 1 0 Regulated
OPR>EXIT
$CONFIG
TOPS20 CONFIGURATOR PROGRAM
TYPE 'H' FOR HELP
COMMAND (at least 2 characters) ? ADD
CONFIGURING THE SYSTEM Page 2-7
ADD> ? DISK (e.g. RA81)
TYPE 'H' FOR HELP 'E' TO EXIT
ENABLE DISK TESTING? Y
TYPE IN THE STRUCTURE NAME (E.G. 'USER') ? USERA
WHAT CHANNEL IS THE DRIVE ON (0-7) ? 7
WHAT IS THE CONTROLLER NODE ? 1
WHAT IS THE UNIT NUMBER (0-7) ? 1
<STHILAIRE.WRK>USERA.VER FINISHED
<STHILAIRE.WRK>USERA.MIC FINISHED
TYPE IN THE STRUCTURE NAME (E.G. 'USER') ? E
ADD> ? EX
Now try mounting the structure USERA :
MOUNT STRUCTURE (NAME) USERA:
Structure USERA: mounted
If the RA81 does not have a structure name then use
USERA.MIC to create one:
TYPE: MIC
DO <MFG>USERA.MIC
Then try, as above, to mount the structure.
When UETP starts RELIAB.CMD it will submit USERA.VER which will
WRITE, and VERIFY and DELETE files on the USERA structure.
UETP will run PAGES in user mode. This test is created by the
CONFIG program.
CHAPTER 3
MANUAL TESTS
3.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
3.2 DECNET TESTS FOR SYNCHRONOUS LINES
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. Do the following:
1. Attach to the operator job running PTYCON.
2. Get System:Netwrk
3. Connect to the OPR job running under PTYCON.
4. Type: TAKE SYSTEM:DN20NX.CMD (where X is the number of the front
end (1-3) containing the synchronous lines to be tested. This will
load the node. After several minutes during which CHECK11 diagnosis
the hardware you should a message stating the the node is up.
Note: Decnet is loaded automatically with IBMCON de-selected
5. Now connect to a job at the TOPS20 command level.
Type:
X ;to get to PTYCON
CONN O ;connect to the free operator job
DO <MFG>DN20N1.MIC
This is the mic file for testing the node. Watch the
typeout and follow the instructions.
MANUAL TESTS Page 3-2
3.3 DN20/DUP TESTS.(IBMCON SELECTED)
Normally the DUP tests are run under UETP automaticly.
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
(the $ is the escape key) 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
X
PTYCON>DEF $1 (AS) AOUT
etc.
By using the D60SPD.ATO file in the <MFG> you can automaticly
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:
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
MANUAL TESTS Page 3-3
(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.
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
automaticly. 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
$
MANUAL TESTS Page 3-4
3.4 DN20 CRASH DUMP
3.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)
TRPCOD[
Refer the <DN64-SOURCES>D6TK3.LST and IBMCON.MAN for a
breakdown of the codes.
3.4.2 DECNET SELECTED (IBMCON DE-SELECTED)
MCBNRT T.B.S.
3.4.3 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>DIAGNOSTIC-DEFINE.MIC
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 4
RUNNING THE ACCEPTANCE
4.1 PRE ACCEPTANCE CHECKS
Before starting the acceptance make sure that all
diagnostic and reliability tests have been completed and the Q.C.
forms 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. If there are any RP04/06 disk
drives other than the KLAD configured into the system make sure
scratch packs are mounted on them and run DDRPI PAKINT test to
map out all spots (including soft spots). The disk tests that
run under Uetp will first run MAPOUT to remove any bad spots from
testing. If the system includes one or more DN20's there
must be at least two DUP's installed in each and there must be an
even number of DUP's installed in each. EVEN IF THESE
DUPS ARE NOT PART OF THE CUSTOMER ORDER they must be installed in
order to be able to test the front end. Thes extra temporary
lines SHOULD HAVE BEEN INSTALLED DURING THE DIAGNOSTIC CHECKOUT.
If they are being installed now the appropriate diagnostics
should be run before attempting acceptance. For each pair of
lines you will need a clock generator box (Spectron mod
ME-81FS-S). Plug the even odd line pair into the box and set the
speed to 9600. 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.
RUNNING THE ACCEPTANCE Page 4-2
4.2 STARTING THE ACCEPTANCE
Boot the system as described in the section on starting
up the system. At the completion of the PTYCON.ATO, if there are
any KMC/DUP's configured the DNLOAD.ATO file will be executed to
load the DN20's. Assuming that the UETP auto restart has been
enabled under the CONFIG program the UETP.ATO file will then be
executed which will in turn start the UETP acceptance. You may
attach to the operator job running PTYCON. If you wish to abort
the UETP startup (i.e. you want to reconfigure the system)
immediately type a X. 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:
C UETP
TAKE RELIAB
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
DN11A VER Queued 24:00 0 0 0 10:16
DSK121 VER Running 24:00 0 0 0 10:16
DSKX32 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
name run count limit time
====== ===== ======= ===== ===== ===== ===== =====
LPT0 VER Running 48:00 0 0 0 10:16
DN11A VER Queued 48:00 0 0 0 10:16
DSK121 VER Running 48:00 0 0 0 10:16
DSKX32 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
RUNNING THE ACCEPTANCE Page 4-3
APL VER Queued 48:00 0 0 0 10:16
APLSF VER Queued 48:00 0 0 0 10:16
4.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 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.
4.4 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
-------- ---- -------- ------------------------
* DSK121 61 10:00:00 F-S In Stream:2
Job 7 Running DDRPI Last Label: BEGIN2 Runtime 0:00:44
* DSKX32 62 10:00:00 F-S In Stream:3
Job 10 Running DDRPI Last Label: BEGIN2 Runtime 0:00:39
* MTA0 63 10:00:00 F-S In Stream:0
Job 9 Running MULTIO 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
DN11A 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
RUNNING THE ACCEPTANCE Page 4-4
simultaneously may vary with the amount of memory on the system.
4.5 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
DN11A VER Queued 72:00 11 1 0 10:16
DSK121 VER Running 72:00 5 0 0 10:16
DSKX32 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.
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 XXXX.ERL where XXXX is
the name of the test. This log should be examined to help
determine the cause of the failure. I.E.
RUNNING THE ACCEPTANCE Page 4-5
^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 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.
4.6 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]
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
RUNNING THE ACCEPTANCE Page 4-6
them is:
UETP>ABORT ALL
UETP>ABORT ALL/DEPTH:MAX
UETP>DIS ALL
UETP>DIS ALL/DEPTH:MAX
UETP>TAKE RELIAB.CMD
UETP>BEGIN
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.
$DO <MFG>SPEAR
(typed from the console if there is no lineprinter)
However if the listing becomes large or there is no
lineprinter on the system it may be more practical to produce it
in segments.
$DO <MFG>SPEAR -1,SHORT
Where -1 is the time of the last entry shown on the
previous listing.
Depending on the type and amount of errors the brief
listing may not 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 detailed listing. For a
complete description of SPEAR commands refer to the SPEAR.MAN
SYSTEM ERROR REVIEW Page 5-2
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.
$SUB <MFG>SPEAR
$
If you get the message PAGE LIMITED EXCEEDED PERFORMING SUMMARY
you will have to make the listing in parts:
APPEND RETRIE.RPT.1 (TO) RETRIE.RPT.2
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. 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.
SYSTEM ERROR REVIEW Page 5-3
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-4
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:
Any 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-5
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:)
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>
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 ;INCLUDES CI20 (RA81)
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
Page A-2
MTA6.VER MTA6.CMP
MTA7.VER MTA7.CMP