Trailing-Edge
-
PDP-10 Archives
-
6.1_emacs_manuals_1er
-
manuals/klad20-user-guide.rno
There are no other files named klad20-user-guide.rno in the archive.
.style headers 2,1,6,7,4,1,0,7,2
.skip 7
.NO FLAGS
.RIGHT MARGIN 70
.CENTER;INTRODUCTION
.SKIP 3
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.
.skip 1
This document is intended as a guide to performing the Monitor acceptance
portion of the current Manufacturing test process
using the lastest revision of the KLAD20 pack only which is:
.SKIP 1
KLAD20-5.1-Y-A.
.skip 3
History:
.list
.le;Originated May 1980 as HAND20.MEM - Tom Duda
.le;Updated for new system options 1981 - 1983 Bob Sthilaire.
.le;Updated for current CONFIG version, DECNET testing, and general
format and accuracy Sept. 1984 - Tom Duda.
.end list
.skip 2
.test page 10
Format:
.skip 1
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).
.skip 1
A "^" means the CTRL key. A "^X" means hold down the CTRL key
and depress the X key.
.skip 1
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.
.skip 1
A "<CR>" means the RETURN key. This is used when no input preceeds
a carriage return. For all other commands the "<CR>"
following the command is implied.
.right margin 70
.CHAPTER STARTING UP THE SYSTEM
.HL1 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.
.skip 1
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.
.skip 1
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.
.skip 1
In any case the BOOT ENABLE switch must be depressed simutaneously with
the desired boot switch to start the boot.
.literal
-----------------------------------------------------------------
! !
! 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
.end literal
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.
.skip 1
Set the PDP11 switches to octal 207 and simultaneously depress
the SW REG and BOOT ENABLE switches shown above.
.literal
RSX-20F VB13-41D 14:06 21-FEB-80
[SY0: REDIRECTED TO DB0:]
[DB0: MOUNTED]
KLI -- VERSION VB15-13 RUNNING
KLI -- ENTER DIALOG [NO,YES,EXIT,BOOT]?
KLI>"YE"
KLI -- KL10 S/N: 2485., MODEL B, 50 HERTZ
KLI -- KL10 HARDWARE ENVIRONMENT:
MCA25 CACHE PAGER
MOS MASTER OSCILLATOR
EXTENDED ADDRESSING
INTERNAL CHANNELS
CACHE
KLI -- SELECT PAGE TABLE [FILE,BOTH,0,1]?
KLI>"BOTH"
KLI -- PAGE TABLE SELECTED: 0,1
KLI -- RELOAD MICROCODE [YES,VERIFY,FIX,NO]?
KLI>"YE"
KLI -- MICROCODE VERSION 352 LOADED
KLI -- RECONFIGURE CACHE [FILE,ALL,YES,NO]?
KLI>"ALL"
KLI -- ALL CACHES ENABLED
KLI -- CONFIGURE KL MEMORY [FILE,ALL,REVERSE,FORCE,YES,NO]?
KLI>"FORCE" (initializes the MF20)
KLI -- STARTING MF20 DBE SCAN. WAIT 25 SEC/256K.
MEMORY RESOURCES:
CONTROLLER ADDRESS TYPE MODULES/GROUPS
7 6 5 4 3 2 1 0
10 MF20 0 0 0 0 0 0 0 4
KLI -- CONFIGURE MOS MEMORY [ALL,YES,NO]?
KLI>"ALL"
LOGICAL MEMORY CONFIGURATION.
ADDRESS SIZE INT TYPE CONTROLLER
00000000 256 4 MF20 10
KLI -- LOAD KL BOOTSTRAP [FILE,YES,NO,FILENAME]?
KLI>"YE"
KLI -- WRITE CONFIGURATION FILE [YES,NO]?
KLI>"YE"
KLI -- CONFIGURATION FILE WRITTEN
.end lit
When the Configuration file is written the default configuration
(DSK Boot) will be that which was just entered.
.literal
KLI -- BOOTSTRAP LOADED AND STARTED
.end literal
At this point the default bootstrap program BOOT.EXB has been
loaded into the Ten memory and the Ten continues the dialogue...
.literal
BOOT> "<CR>"
.end literal
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.
.literal
[PS MOUNTED]
.end literal
At this point SETSPD runs and examines the file <SYSTEM>5-1-CONFIG.CMD
to initialize various system parameters i.e setting tty speeds, defining
system logical names, loading lpt rams etc.
.literal
system restarting, wait...
ENTER CURRENT DATE AND TIME:
.end literal
The following are examples of acceptable formats. For example
MAY 2, 1980 at 1:05 pm could be entered as:
.literal
"2-MAY-80 1305"
OR
"5-2-80 1305"
OR
"5-2-80 105PM"
YOU HAVE ENTERED FRIDAY, 2-MAY-1980 105 PM,
IS THIS CORRECT (Y,N) "Y"
.end literal
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.
.literal
WHY RELOAD?
.end literal
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:
.br
"OTHER RESTART AFTER REPLACING BAD HEAD 6 ON RP06 #2543"
.br
In any case the response will be recorded in the system reload entry
in SPEAR.
.literal
WHY RELOAD? "OTHER CONFIG"
RUN CHECKD?
.end literal
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.
.literal
RUN CHECKD? "Y"
[CHECKING FILE CONSISTENCY]
[WORKING ON STRUCTURE - PS:]
%REBUILDING SYMBOL TABLE FOR PS:<ROOT-DIRECTORY> [OK]
%REBUILDING SYMBOL TABLE FOR PS:<DNGEN> [OK]
%REBUILDING SYMBOL TABLE FOR PS:<UETP> [OK]
LOCAL COUNT OF FILE PAGES: 22793
LOCAL COUNT OF OVERHEAD PAGES: 12672
LOCAL COUNT OF USED PAGES: 35465
THERE ARE NO LOST PAGES.
RUNNING DDMP
SYSJOB 4(11) STARTED AT 2-MAY-80 1310
.end literal
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.
.literal
RUN SYS:ORION
****
2-MAY-82 13:11:22 -TGHA 2(6) RUNNING FIRST TIME.
****
RUN SYS:MAPPER
RUN SYS:QUASAR
RUN SYS:MOUNTR
RUN SYS:INFO
RUN SYS:MAILER
RUN SYS:MAPPER
RUN SYS:CDRIVE
JOB 0 /LOG OPERATOR XX OPERATOR
ENA
^ESET LOGIN PSEUDO
^ESET LOGIN CONSOLE
^ESET OPERATOR
PTYCON
GET SYSTEM:PTYCON.ATO
/JOB 1/LOG OPERATOR XX OPERATOR
ENA
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
.end literal
At this point the system is ready for timesharing. If the system
has already been configured for the automatic UETP startup the SYSJOB.RUN
file will cause the PTYCON subjob UETP to take UETP.CMD
which will in turn start up the
UETP acceptance. If this is the case you should wait for the
auto files to finish starting up all the tests before attaching
to the PTYCON job (explained in the following section) and continue with
section "STARTING THE ACCEPTANCE". If you have not yet configured
the system for acceptance refer to Chapter 2 "CONFIGURING THE SYSTEM".
.page
.hl1 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)
.literal
"^C"
You will get a response similar to:
MFG EVALUATION SYSTEM 2091 , TOPS-20 Monitor 5.1(5101)
Type: "ATT OPERATOR 1"
Response will be:
[Attached to tty(some #), confirm]
Type: "<CR>"
Response is:
Password:
Type the operator password which is "KLAD" and "<CR>".
Note: The password will not echo.
To get to the PTYCON level type:
"^X"
.end literal
.hl1 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.
.skip 1
There will be at least three jobs running
under the PTYCON job.
.literal
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
.end literal
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.
.skip 1
Subjob 1 defined as UETP will be used to run the UETP USER
ENVIRONMENT TEST PACKAGE program. See RUNNING THE ACCEPTANCE.
.skip 1
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.
.skip 1
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...
.literal
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:
.end literal
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.
.skip 1
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.).
.skip 1
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.
.skip 1
The same problem could develop if PTYCON, OPR or UETP were left
at EXEC level by means of the PUSH command.
.skip 1
Another way to inadvertently crash UETP or OPR is to
partially type in a command (or any characters)
to these programs and to leave it
in that state for long time periods.
To avoid this it is good practice to
hit a "<CR>" and make sure you get a prompt from the subjob before
issuing a "^X".
.HL1 LOGGING ONTO THE SYSTEM
There are three areas on the KLAD pack that you can log into:
<OPERATOR>, <F-S>, <MFG>
.literal
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
.end literal
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.
.skip 1
.hl1 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.
.skip 1
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.
.literal
$"DE?" Command, one of the following:
DEASSIGN DEBUG DECLARE DEFINE
DELETE DEPOSIT DETACH
or kept fork name,
or system program name
$DE
.end literal
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:
.literal
$"DEF$INE (LOGICAL NAME) "
.end lit
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.
.skip 1
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".
.skip 1
.SKIP 1
If a LOGIN.CMD file exists in the area that you login to,
it is automatically executed at the time you login.
LOGIN.CMD files are generally used to execute any commands that you would
otherwise normally type in each time you login i.e.
to set up parameters for your job or terminal.
.skip 1
Only the output from the system is echoed while the LOGIN.CMD file
is being executed. To see what the commands are type:
.literal
$"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"
.end literal
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.
.literal
$"DEF$INE (LOGICAL NAME) DSK:$ (AS) <MFG>"
$"CONN$ECT (TO DIRECTORY) <OPER$ATOR>"
$"DIR$ECTORY (OF FILES) "
.end literal
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
.lit
$"DEF DSK:"
.end literal
Another definition that could have a large effect on your job is "SYS:".
SYS: is typically defined by the system from a command in the
5-1-CONFIG.CMD file: For example:
.lit
$"DEF SYS: PS:<SUBSYS>,PS:<UTILITIES>,PS:<MFG>"
.end literal
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".
.skip 1
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.
.right margin 70
.chapter CONFIGURING THE SYSTEM
.hl1 WHEN TO RUN THE CONFIGURATION PROGRAM
.literal
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
.end literal
.note
Insure that any updates that are required for your system
are installed prior to running the CONFIG program.
.end note
.HL1 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.
.literal
PTYCON>"C O"
@"ENA"
$"CONFIG"
TOPS20 CONFIGURATOR PROGRAM VER 5-1-
TYPE 'H' FOR HELP
PASSWORD ? "MFG"
.end literal
There are two passwords: "MFG" and "F-S". If you type "F-S" CONFIG
will assume that this is a field installation and will prompt you
for all devices that it can handle in a field environment.
If you type "MFG" CONFIG limits the dialogue to
devices which are part of the MFG KERNEL process
which includes Lineprinters, DC20's and DN20's (and does not include
Disk, Magtape and AN20 units).
.skip 1
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.
.literal
COMMAND (at least 2 characters) ? "AUD"
USER AUDIT ENABLED
.end literal
.hl2 CONFIG COMMANDS.
.skip 1
To get a list of commands at the "COMMAND" prompt type "H".
.literal
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)
.end literal
The first time you run CONFIG you should respond with "CONFIGURE"
since you don't know exactly what has already been configured.
Once this has been done (you know exactly how it has been configured)
you can then use the "CHANGE" command to reconfigure only a specified
configuration category or use the "ADD" or "REMOVE" commands (not supported)
to remove or add tests for individual devices.
.skip 1
The following is a list of each configuration category that will
be entered for either F-S or MFG.
.literal
CATEGORY Input Description MFG F-S
---------------------------------------------------------------------
CUSTOMER NAME System name and serial # x
TIME UETP acceptance runtime default x x
AUTO UETP Auto startup on system boot x x
DISK DRIVE Disks other than PS to be tested x
Channel #, Controller #, Unit #
MAGTAPE Magtapes/Densities to be tested x
DC20 LINES # of FE0 tty lines x x
LINEPRINTER LPT's VFU type and charater set x x
DN20 DN20 syncronous line configuration x x
AN20 AN20 on system or not x
MEMORY #K of memory on system x x
.end literal
The following paragraphs describe the CONFIG dialogue for
each configuration category when you are configuring the entire system.
For help on the "CHANGE" command refer to section "CHANGING
THE CONFIGURATION".
.skip 1
.literal
COMMAND (at least 2 characters) ? "CO"
.end lit
.hl2 Customer name.
.literal
Customer name ........ ? "MFG Evaluation System"
System serial number .. ? "2091"
.end literal
CONFIG inserts the info just entered into the <SYSTEM>MONNAM.TXT
file which will be displayed whenever you login (after system is rebooted).
.hl2 ACCEPTANCE RUNTIME.
.literal
ACCEPTANCE RUN TIME(HH:MM,PASSES,OR CONT) ? "24:"
.end literal
The value entered here will be inserted into file RELIAB.CMD
as the default test time for the UETP tests.
.skip 1
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.
.hl2 UETP Auto Start.
.literal
Disable UETP ATO start up ? "N"
.end literal
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.
.hl2 Disk Drives.
.literal
TYPE 'H' FOR HELP 'E' TO EXIT
Enable DISK DRIVE testing ? "Y"
.end literal
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".
.literal
What is the controller ID NO. (RP20=0,RP06/7=-1,ETC.) ? "-1"
.end literal
For RH20-RP04/06/07 drives there is no intermediate controller so "-1"
is used by software to denote this. For other disks i.e. HSC50-RA81 the
hardware selectable controller number must be entered.
.literal
Type in the STRUCTURE NAME (E.G. 'USER') ? "DSK11"
.end literal
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.
.literal
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)
.end literal
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.
.lit
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
.end lit
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".
.literal
What is the controller ID NO. (RP20=0,RP06/7=-1,ETC.) ? "E"
.end literal
.hl2 Magtapes.
.skip 1
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.
.skip 1
During system boot,
unless the 5-1-CONFIG.CMD file is edited to explicitly define
MTA's, (this is NOT done by CONFIG)
the TOPS-20 Monitor assigns MTA0 through
MTA7 to tape drives in the physical order that it sees them.
That is according to the
following priority scheme: RH20#, TM# (or other controller#), and UNIT#.
.skip 1
The following diagram is an example of MTA assigment for
multi drive system:
.test page 12
.literal
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
.end literal
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).
.skip 1
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:
.literal
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"
.end literal
.hl2 DC20 Lines.
.skip 1
Enter the amount of DC20 lines
X on FE0 in OCTAL. CONFIG will use this value to modify
5-1-CONFIG.CMD and turn on tty lines 1-X at 9600 baud. All
others are set to speed 0 (turned off).
.literal
How many DC20 lines (0-200 octal) ? "40"
.end literal
.hl2 Lineprinters.
.skip 1
Use the following table
to determine the answers to the next questions.
.literal
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"
.end literal
.hl2 DN20's
.skip 1
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.
.skip 1
In MFG the DECNET software, which supports DMR's DMC's
and DUP's is always used for testing.
.skip 1
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".
.hl3 CONFIGURING FOR DECNET.
.skip 1
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.
.skip 1
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.
.skip 1
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.
.list
.le;Minimum of 128K of memory in DN20
.le;Minimum of 1 synchronous line.
.le;Maximum of 0 asyncronous lines.
.le;Maximum of 8 synchronous lines (DMR,DMC,DUP)
.le;Maximum of 6 high speed lines (DMR,DMC)
.le;Maximum of 2 DMR's at 1 Meg baud.
.le;Maximum of 4 DMR's at 56K (no other lines)
.le;Maximum of 3 DMR's at 56K with 4 or less DUP's at 9.6K - *
.le;Maximum of 2 DMR's at 56K with 5 or 6 Dup's at 9.6K - *
.le;Maximum of 2 KDP's.
.le;Maximum of 8 DUP's (4 per KDP) at 9.6K or 19.2K baud
.end list
.literal
* - limits determined by MFG evaluation.
Note: Rules for DMC's same as DMR's.
In a configuration of mixed DMR's and DMC's the base
address of the DMC's must be lower than the DMR's.
.end literal
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.
.skip 1
Each DUP must be connected to a null modem test box
with clock set at 9.6K. Each null modem must have 2 DUP's connected to it.
If there is an odd number of DUP's in the configuration the
last DUP will be ommitted from the configuration unless the DN20 contains
only 1 DUP (and no other lines). In this case MFG will temporarily
add a second DUP for testing.
.skip 1
If there are 2 KDP's divide the DUP's equally between the two. (This
is independent of hardware setup)
.literal
HOW MANY DN20 FRONT ENDS ? (0-3) "2"
Enable IBMCON? "NO"
.end literal
In MFG the answer to the previous question should always be "NO"
which will cause CONFIG to set up for testing with DECNET.
.skip 1
.note;"KDP" refers to a KMC which is configured to handle DUP's.
.end note
.test page 8
.literal
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
.end literal
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.
.skip 1
At the completion of the CONFIG dialogue you will be instructed
to submit these control files to finish building the configuration.
.skip 1
Continue with section AN20.
.skip 1
.HL3 Configuring for IBMCON.
.skip 1
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.
.skip 1
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").
.test page 11
.literal
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
.end literal
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..)
.SKIP 1
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.
.skip 1
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)
.literal
PS:<SYSTEM>DNLOAD.ATO FINISHED
.end literal
.hl2 AN20.
.literal
IS THERE AN AN20 ON THIS SYSTEM ? (Y,N) "N"
.end literal
If you answer "Y" to the previous question CONFIG will
edit the PTYCON.ATO file to login a subjob (AN20) and
run diagnostic DDANB to test the AN20.
.skip 1
.hl2 Memory Size.
.literal
HOW MANY K TOTAL OF MEMORY ? "1024"
.end literal
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.
.hl2 CONFIG INSTRUCTIONS.
.skip 1
When the configuration dialogue is completed CONFIG
displays all the commands in the RELIAB.CMD for tests
other than the standard UETP language tests.
.test page 10
.literal
RELIAB ROUTINES
ENABLE DSK11/CYCLE:10/TIME:01:00:00
ENA MTA0/DEPTH:MAX/CYCLE:10/TIME:01:00:00
ENA MTA1/DEPTH:MAX/CYCLE:10/TIME:01:00:00
ENA LPT0/CYCLE:10
ENA LPT1/CYCLE:10
ENA DN20N1/LIMIT:10
ENA DN20N2/LIMIT:10
PLEASE SUBMIT <MFG>DN20N1.CTL/TIME
PLEASE SUBMIT <MFG>DN20N2.CTL/TIME
$
.end lit
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.
.list
.le;AN20 - You must copy the AN20 supportable monitor to the default
monitor as instructed by CONFIG.
.le;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".
.LE;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".
.end list
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.
.hl1 CHANGING THE CONFIGURATION
If you had made a mistake or for any reason wish to change the
configuration you could run CONFIG again and change the configuration
for devices in a specific device category as opposed
to going through the entire dialogue. For example:
.literal
$"CONFIG"
TOPS20 CONFIGURATOR PROGRAM VER 5-1-
TYPE 'H' FOR HELP
PASSWORD ? "MFG"
COMMAND (at least 2 characters) ? "AU"
USER AUDIT ENABLED
COMMAND (at least 2 characters) ? "CH"
.end lit
.test page 17
.literal
CHANGE> ? "H"
Commands are:
CUSTOMER NAME
AN20
MAGTAPE
DC20 LINES
LINEPRINTER
DISK DRIVE
AUTO UETP
TIME
DN20
MEMORY
RETURN
EXIT
.end literal
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.
.test page 15
.literal
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"
$
.end lit
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.
.page
.HL1 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.
.skip 1
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.
.literal
on DN20 on DTE-1 if you have:
1 DMR
then $"COPY <MFG>DN1-DMR1.SYS <SUBSYS>DN20N1.SYS.0"
or 2 DUP'S
then $"COPY <MFG>DN1-DUP2.SYS <SUBSYS>DN20N1.SYS.0"
or 3 DMR'S AND 2 DUP'S ON KDP-0 AND 2 DUP'S ON KDP-1
then $"COPY <MFG>DN1-DMR3-DUP2-DUP2.SYS <SUBSYS>DN20N1.SYS.0"
.END LIT
If your configuration does not match one of the ones above
you will have to build it.
.skip 1
Note:
.br
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.
.skip 1
The following example shows how to build a single DN20 node using
the <MFG>DN20N1.CTL file created by CONFIG.
.literal
$"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"
.end lit
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.
.skip 1
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.
.skip 1
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.
.skip 1
By using the "Information about Batch" command examine
the queues to see if the CTL files are finished. You will
otherwise not be notified unless there is an error.
.literal
$"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)
$
.end literal
When the batch jobs have finished, as a quick check to be sure
that the FE software was successfully built, do the following:
.literal
$"V$DIRECTORY (OF FILES) SYS:DN20N1.SYS"
.end lit
You should see the file PS:<SUBSYS>DN20N1.SYS with a write date
equal to the current date and time.
.page
.HL1 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.
.skip 1
To run UNITS type:
.right margin 75
.test page 15
.literal
@"ENA" (enable priv.)
$"UNITS"
Status of Disk Units at 6-Sep-84 17:28:48
Mounted? Type Channel Drive Controller Structure name Logical unit
-------- ---- ------- ----- ---------- -------------- ------------
Yes RP06 0 0 -- PS: 0 (1 of 1)
No RP07 1 1 -- Bad home blocks
Yes RA81 7 1 3 USERA: 0 (1 of 1)
.end literal
Note:
.skip 1
"Bad home blocks" means the system does not recognize a structure
on the disk (i.e. one has not been built yet)
.skip 1
Or to get a status of the disks with OPR type:
.literal
$"OPR"
OPR> "SHOW STATUS DISK-DRIVE "
.END LIT
.; OPR>
.;13:05:14 --Disk Drive Status--
.;
.; FREE DRIVES:
.;
.; Type Chan Ctrl Drive Structure
.; ---- --------------- ---------
.; RP07 1 1 (none)
.;
.; MOUNTED DRIVES:
.;
.; Structure Type Chan Ctrl Drive Count Options
.; ------------- ---- --------------- ----- -------
.; PS: RP06 1 0 0 Domestic
.; USERA: RA81 7 3 1 0 Regulated
.;
.; OPR> "EXIT"
.;.end literal
.right margin 70
NOTE:
.skip 1
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:
.literal
$"IPALOD"
.end literal
And reboot the HSC50 and MONITOR. See HSC50-USER-GUIDE
.skip 1
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:
.test page 9
.literal
$"STRTST"
STRTST> "DIS$MOUNT (STRUCTURE) USERA"
STRUCTURE USERA SUCCEFULLY DISMOUNTED
STRTST> "EXIT"
$
.end literal
Now we can use the mic files to rebuilt the structures. Type:
.literal
$"DO <MFG>HSC31.MIC"
.end lit
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.
.literal
$"DO <MFG>DSK11"
.end literal
Once the structures have been built you should be able
to mount it with STRTST.
.literal
$"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
.end literal
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.
.PAGE
.HL1 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:
.lit
$"DEL <SYSTEM-ERROR>ERROR.SYS"
$"DEL <SYSTEM>TGHAV2.*"
$"DEL <UETP.RUN>*.*"
or use the MIC file:
$"DO <MFG>DEL$ETE-SYSERR.MIC"
NOTE:
.end lit
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.
.skip 1
Once the acceptance has been started ERROR.SYS and TGHAV2.*
should never be deleted until the acceptance is complete and signed
off.
.HL1 RUNNING MAKDMP
If this is the first time you have configured the system or
any time that the amount of memory on the system has been changed you
should run the MAKDMP program so that DUMP.EXE will dump the correct
amount of memory in the case of a system crash.
.literal
$"CONN <SYSTEM>"
$"DEL DUMP.EXE"
$"EXP"
$"RUN <UTILITIES>MAKDMP"
.end literal
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 RUNNING THE ACCEPTANCE
.right margin 70
.HL1 PRE ACCEPTANCE CHECKS
Before starting the acceptance make sure that all diagnostic
and reliability tests have succesfully completed.
.skip 1
For MFG acceptance be sure all previous Q.C. checkpoints
have been signed off.
.skip 1
Run a pass of DDRPI RONLY test on the KLAD drive using the
KLAD pack to insure there are no compatability problems.
.skip 1
BE SURE SWITCHES ARE SET CORRECTLY ON THE LP20 LOGIC BOARDS
else the 11/40 may hang at the time DB0 is mounted.
.skip 1
Insure that all devices are connected and on line.
.skip 3
.HL1 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.
.skip 1
Before attaching to PTYCON you should wait for PTYCON.ATO to
finish executing (UETP tests started with the BEGIN command)
to insure that what you type does not conflict with the
auto file. However (if careful) you may attach during
execution of the auto file to get control of the CTY
before the tests start at the point where it pauses:
.literal
UETP> PUSH
@PAUSE
.END LIT
At this point you have 15 seconds to do the attach.
Immediately after typing the password, DO NOT type anything
more if you wish the acceptance to start. Otherwise type
a "^X" immediately and the remainder of PTYCON.ATO file
will be aborted (the tests will not start).
.SKIP 1
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:
.literal
PTYCON> "C UETP"
$"POP" (if PTYCON.ATO had been aborted before the POP)
UETP> "TAKE RELIAB$"
or restart the UETP subjob altogether:
"^X"
PTYCON> "GET <MFG>UETP.ATO"
.end literal
At the completion of the RELIAB.CMD file the status command is
issued to UETP.
.literal
UETP>"STATUS"
[27-May-80 10:21:38]
Test Depth Status Cycle Times Error Error Start
name run count limit time
====== ===== ======= ===== ===== ===== ===== =====
LPT0 VER Running 24:00 0 0 0 10:16
DN20N1 VER Queued 24:00 0 0 0 10:16
DSK11 VER Running 24:00 0 0 0 10:16
HSC31 VER Running 24:00 0 0 0 10:16
MTA0 MAX Running 24:00 0 0 0 10:16
MTA1 CMP Queued 24:00 0 0 0 10:16
ALGOL VER Queued 24:00 0 0 0 10:16
APL VER Queued 24:00 0 0 0 10:16
APLSF VER Queued 24:00 0 0 0 10:16
.end literal
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:
.literal
UETP>"MODIFY ALL/DEPTH:VER/CYCLE:48:00"
.end literal
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.
.literal
UETP>"MODIFY ALL/DEPTH:MAX/CYCLE:48:00"
UETP>"MODIFY ALL/DEPTH:COM/CYCLE:48:00"
.end literal
Now if we type the status command we should see that the
modification has been completed.
.literal
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
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
.end literal
NOTE:
.skip 1
The following devices are not automatically tested by the
system via CONFIG.
.list
.le;DC20's
.end list
If you are to test DC20's refer to Chapter "MANUAL TESTS"
DC20 LINES TEST.
.page
.right margin 70
.hl1 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.
.list
.le;Examine the batch streams and UETP status
to ensure that all tests are running and without
any software detectable errors.
.le;Review SPEAR to evaluate the hardware errors.
.le;Run TGHA (systems with moss) to evaluate MF20 performance.
.end list
.hl2 THE BATCH JOBS
.skip 1
To examine the state of the batch jobs type the INFORMATION
(about) BATCH-REQUESTS command.
.literal
$"I B"
Batch Queue:
Job Name Req# Run Time User
-------- ---- -------- ------------------------
* DSK11 61 10:00:00 F-S In Stream:2
Job# 7 Running PAGES Last Label: BEGIN2 Runtime 0:00:44
* HSC31 62 10:00:00 F-S In Stream:3
Job# 10 Running PAGES Last Label: BEGIN2 Runtime 0:00:39
* MTA0 63 10:00:00 F-S In Stream:0
Job# 9 Running TAPWRT Last Label: FIX3 Runtime 0:00:12
* DBMS 65 10:00:00 F-S In Stream:1
Job# 8 Running FORTRA Last Label: DBFO2 Runtime 0:00:14
MTA1 80 10:00:00 F-S
ALGOL 66 10:00:00 F-S
APL 67 10:00:00 F-S
APLSF 68 10:00:00 F-S
BASIC 69 10:00:00 F-S
CBLSRT 70 10:00:00 F-S
RANCBL 71 10:00:00 F-S
RANFOR 72 10:00:00 F-S
CPUBAS 73 10:00:00 F-S
MEMBAS 74 10:00:00 F-S
CPUREL 75 10:00:00 F-S
MEMREL 76 10:00:00 F-S
DN20N1 79 10:00:00 F-S
LPT0 59 10:00:00 F-S /After:27-May-80 10:22
There are 18 Jobs in the Queue (4 in Progress)
.end literal
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.
.hl1 UETP STATUS
Another way to examine the batch jobs and to get a summary of
the test run is with the UETP STATUS command.
.right margin 70
.literal
UETP>"STATUS"
[27-May-80 22:21:38]
Test Depth Status Cycle Times Error Error Start
name run count limit time
====== ===== ======= ===== ===== ===== ===== =====
LPT0 VER Ended 10 10 0 0 10:16
DN20N1 VER Queued 72:00 11 1 0 10:16
DSK11 VER Running 72:00 5 0 0 10:16
HSC31 VER Running 72:00 5 0 0 10:16
MTA0 MAX Running 10 7 0 0 10:16
MTA1 MAX Aborted 10 1 1 0 10:16
DBMS VER Stopped 72:00 17 0 0 10:16
ALGOL VER Queued 72:00 21 0 0 10:16
APL VER Queued 72:00 37 0 0 10:16
APLSF VER Queued 72:00 25 0 0 10:16
BASIC VER Queued 72:00 23 0 0 10:16
CBLSRT VER Queued 72:00 35 0 0 10:16
RANCBL VER Queued 72:00 45 0 0 10:16
COBOLD VER Queued 72:00 43 0 0 10:16
SORT VER Queued 72:00 43 0 0 10:16
FORTRA VER Queued 72:00 43 0 0 10:16
.end literal
Examine the Status column. The following list describes each
of the possible status conditions:
.literal
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.
.end literal
For a complete description of UETP commands refer to the
"TOPS10/TOPS20 USER-ENVIRONMENT TEST PACKAGE PROCEDURES/REFERENCE MANUAL"
Document # AA-D606B-TK.
.skip 1
Also check to see that the Times Run count for each test
is incrementing on a regular basis.
.skip 1
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.
.literal
"^X"
PTYCON> "CONN O"
$"CONN <UETP.RUN>"
$"PRINT MTA1.ERL"
.end literal
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.
.literal
COPY <UETP.RUN>RANFOR.LOG <MFG>RANFOR.LOG
.end literal
Any error reporting from UETP will attempt to direct you to
the cause of the error. The type of errors to look for are:
.literal
TIME-OUT ERRORS
ERRORS ASSIGNING DEVICE (i.e. MAGTAPE)
UNEXPECTED ERRORS IN A BATCH STREAM
.end literal
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:
.literal
? DIFFERENCE ENCOUNTERED
.end literal
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.
.hl1 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:
.literal
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]
.end literal
.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.
.end note
To stop a single job for example the MTA0 job type:
.literal
UETP>"ABORT MTA0/DEPTH:MAX"
.end literal
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.
.literal
UETP>"ABORT RANFOR"
UETP>"DISABLE RANFOR"
UETP>"ENABLE RANFOR"
UETP>"BEGIN"
.end literal
If all the jobs were stopped the easiest way to restart them is:
.literal
UETP>"ABORT ALL"
UETP>"ABORT ALL/DEPTH:MAX"
UETP>"DIS ALL"
UETP>"DIS ALL/DEPTH:MAX"
UETP>"TAKE RELIAB.CMD"
UETP>"BEGIN"
.end lit
Refer to Chapter "SYSTEM ERROR REVIEW" for reviewing the error files.
.skip 1
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.
.page
.right margin 70
.chapter 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.
.hl1 DC20 LINES TEST
For each DC20 line on the system do the following:
.LIST
.LE;Attach the terminal to the line
.LE;Type: "^C"
.LE;Type: "SYS" and verify that the character are typed correctly
.LE;Type: "LOGO" and verify that the line number is correct.
.LE;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:
.END LIST
.literal
$"TRAK20"
TRAK20> "WATCH"
.end literal
.hl1 DN20 - DECNET
.br
.hl2 RELOADING THE NODE.
.skip 1
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:
.lit
On DTE-1 a DN20 with 2 DMR's and 1 DMC and 2 DUP's on KDP-0:
$"COPY <SUBSYS>DN20N1.SYS <MFG>DN1-DMR2-DMC1-DUP2.SYS
.end lit
Now copy the MCB file for a minimum configuration (1 DMR).
.lit
$"COPY <MFG>DN1-DMR1.SYS <SUBSYS>DN20N1.SYS.0"
.end lit
Note:
.skip 1
You can restore the original configuration later by copying the saved file
back to <SUBSYS> as with the command above and reloading the node.
.skip 1
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:
.skip 1
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):
.lit
"^X"
PTYCON> "GET SYSTEM:NETWRK.ATO"
.end lit
.skip 1
Assuming the DECNET support programs
are running, do the following to reload and start DN20N1.
.literal
$"DO DN1-START.MIC"
.end lit
.hl2 DECNET TESTS FOR SYNCHRONOUS LINES
.skip 1
Assuming the DN20N1 node is online do the following
to manually exercise the node.
.literal
@"ENA"
$"CONN <MFG>"
$"DO DN20N1.MIC"
.end lit
This will perform a test simular to the UETP test
except that it will be run from the terminal instead of
under batch.
.skip 1
To look at a summary for the node (This can be done while
DN20N1 is running under UETP) type:
.literal
$"DO <MFG>DN1-SHOW"
.end lit
To stop DN20N1 (crashes the front end) and optionally load
DECX into FE1 type:
.lit
$"DO <MFG>DN1-STOP.MIC"
.end lit
.HL1 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.
.skip 1
To reload the DN20 with the IBM protocol type:
.literal
$"DNLOAD"
DNLOAD> "LOAD DTE $1 <DN64-BINARIES>D6TK3.BIN"
.end literal
If the DN20 was already running it would crash and then reload.
Once the DN20 is loaded exit the DNLOAD program:
.literal
DNLOAD> "EXIT"
$
.end literal
On a terminal other than the CTY run PTYCON and create a
subjob for each DUP. Login each job and run D60SPD I.E.
.literal
PTYCON
PTYCON> "DEF $0 (AS) AIN"
PTYCON> "C AIN"
"^C"
@"LOG F-S FS"
@"ENA"
$"D60SPD"
D60SPD> "^X"
PTYCON> "DEF $1 (AS) AOUT"
etc.
.end literal
By using the D60SPD.ATO file in the <MFG> you can automatically
set up six jobs as shown above. I.E
.literal
@"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>
.end literal
D60SPD is a program that simulates the protocol sent over the
DUP's. The commands are outlined:
.literal
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
.end literal
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.
.skip 1
The following is an example of transfering a file.
.literal
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]
.end literal
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:
.literal
"^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]
.end literal
When the file has been transferred run FILCOM and compare the
received and transmitted data:
.literal
$"FILCOM"
*"=DN64.DAT,REC.DAT"
.end literal
The response should be "NO DIFFERENCES ENCOUNTERED". Continue
with the D60SPD commands for the remainder of the lines.
.skip 1
To do a continuous transfer of data follow the same procedure
as described above only do not specify a file i.e.
.literal
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"
.end literal
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:
.literal
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
.end literal
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.
.literal
PTYCON> "AOUT-EOF"
.end literal
When testing on all lines is complete kill off the PTYCON
subjobs and exit to get back to the EXEC level:
.literal
PTYCON> "KILL ALL"
PTYCON> "EXIT"
$
.end literal
.HL1 DN20 CRASH DUMP
.HL 2 IBMCON SELECTED
.skip 1
If the DN20 stops record the address on the 11/34 panel. Next
dump the contents of the DN20 by running DNLOAD:
.literal
$"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["
.end literal
Refer the <DN64-SOURCES>D6TK3.LST and IBMCON.MAN for a
breakdown of the codes.
.HL2 DECNET SELECTED (IBMCON DE-SELECTED)
.skip 1
In the case of a DN20 crash, DECNET automatically dumps
the contentss of the DN20 memory to file SYS:DN20N1.DMP.
.skip 1
Further help TBS at a later date.
.hl1 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:
.literal
$"DEF DSK: DSK:,<1-DIAGNOSTICS>,<2-DIAGNOSTICS>,<3-DIAGNOSTICS>"
or use the mic file in the <MFG> area
$"DO <MFG>DIAG$"
.end literal
You may now run DIAMON or DFDNA to call in the desired
diagnostics. When you are done remove the DSK definition by typing:
.literal
$"DEF DSK:"
.end lit
.CHAPTER SYSTEM ERROR REVIEW
.right margin 70
.hl1 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.
.skip 1
SPEAR -1 listing which is up to date within 24 hours.
.skip 1
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.
.test page 10
.literal
$"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"
.end literal
Depending on the type and amount of errors the SHORT listing
may not be sufficient to evaluate the system. For any system errors
such as BUGINF, BUGHLT, or device errors that are not due to bad media
produce a FULL listing.
.skip 1
For a complete description of SPEAR commands refer to the SPEAR.MAN
.page
.hl1 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.
.literal
$"CONN <MFG>"
$"DO SPEAR ,FULL"
.end literal
This will make a listing file "RETRIE.RPT"
Now run massrt to sort the errors:
.literal
$"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 ...........................................
.end literal
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.
.skip 1
Now set up to look at the tape errors. Sort by program because the
same logical spot may be different for different programs.
.literal
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 ..........................................
.end literal
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?.
.literal
COMMAND (G,S,D,L,F,B,R,Q,H) ? "R?"
.end literal
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.
.literal
COMMAND (G,S,D,L,F,B,R,Q,H) ? "Q"
EXIT
$
The file may then be printed out:
$"PRINT MASSRT.LOG"
.end literal
Read <MFG>MASSRT.HLP for a detailed explanation of the MASSRT
program.
.page
.HL1 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.
.test page 15
.literal
$"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
.end literal
For a complete description of TGHA read TGHA-II.DOC
.page
.HL1 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.
.literal
$"DO <MFG>REVIEW.MIC (PARAMETERS) "
.end literal
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.
.skip 1
REVIEW.MIC will assemble the following information into one
file "REVIEW.TXT" which can then be typed or printed.
.literal
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)
.end literal
.hl1 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.
.skip 1
Also save the final UETP STATUS which should be typed on the
CTY at completion of the acceptance.
.right margin 70
.chapter 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:
.literal
$"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"
.end literal
This should have gotten most of the files that were to be
deleted. Now get a directory of new files:
.literal
$"DIR <*>*.*,"
$$"SINCE MM-DD-YY"
$$"<CR>"
.end literal
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
.right margin 70
.hl1 Uetp selectable tests
.literal
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
.end lit
.appendix
.right margin 70
.hl1 MFG SPECIAL FILES.
.LITERAL
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.
----------------------------------------------------------------------
.end lit
.test page 10
.lit
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
and 2 DUP' on KDP-1
DN1-DUP2.SYS DECNET MCB monitor for DN20 on FE1
with 2 DUP's
----------------------------------------------------------------------
.end lit
.test page 10
.lit
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.
----------------------------------------------------------------------
.end lit
.test page 10
.lit
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.
----------------------------------------------------------------------
.end lit
.test page 10
.lit
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.
.END LITERAL