Google
 

Trailing-Edge - PDP-10 Archives - k20v7c - mfg/src/klad20_mfg_guide.rno
There are no other files named klad20_mfg_guide.rno in the archive.
.style headers 2,1,6,7,4,1,0,7,2
.skip 7
.NO FLAGS
.RIGHT MARGIN 70
.PAGE
.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.
This document was last edited for use on KLAD20 revision:
.SKIP 1
	KLAD20-AB-6.1-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.
.le;Updated for CI20, NI20, Process variables, TOPS20 Rel 6.1,
Decnet Phase IV Aug. 1985 - Tom Duda.
.le;Jan 1987 - Tom Duda;
Changed name of document from KLAD20-USER-GUIDE to KLAD20_MFG_GUIDE
to avoid confusion with KLAD20 document put out by Rel Eng.
Updated to state for which KLAD20 release the document was last edited
rather than for which release it is intended.
.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 VB15-21 14:06 21-FEB-85

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

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

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

	10	    MF20  0 0 0 0 0 4 4 4

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

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

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

.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

If there is a CI20 on the system the CI Microcode is then loaded
via <SYSTEM>IPALOD.EXE which contains the microcode.

.lit

[IPALOD: UCODE 674 BEING LOADED INTO CI-20]

[IPALOD: UCODE 674 LOADING COMPLETED]

.end lit

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

.literal

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

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

.literal

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

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

.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

Note:
.skip 1
If there is a CI20 on the system, typically before you get a
chance to answer to the "RUN CHECKD?" promt, you should see
the following BUGINF's that denote the initialliazion of the CI port.
Remember to answer "Y" or "N" after the BUGINF's.
.lit

"KLPLOA"	CI-20 U-CODE RELOAD IN PROGRESS
"KLPSTR"	PYYKLP: CI-20 STARTED
"KLPOVC"	OPENED VIRTUAL CIRCUIT (if HSC50 Online)

.end lit

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

*****
2-MAY-85 13:10:03 - TGHA 4(0) IN OPERATION.
*****

SYSJOB 6A(20) STARTED AT  2-MAY-85 1310

.end literal

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

.literal

[KNILDR: LOADING MICROCODE VERSION 1(162) INTO ETHERNET CHANNEL 0]

RUN SYS:ORION
RUN SYS:MAPPER
RUN SYS:QUASAR
RUN SYS:MOUNTR
RUN SYS:INFO
RUN SYS:MAILER
RUN SYS:MAPPER
RUN SYS:CDRIVE
JOB 0 /LOG OPERATOR XX OPERATOR
ENA
^ESET LOGIN PSEUDO
^ESET LOGIN CONSOLE
^ESET OPERATOR
PTYCON
GET SYSTEM:6-1-PTYCON.ATO
/JOB 1/LOG OPERATOR XX OPERATOR
ENA
RUN SYS:BATCON
/
SJ  0:
SJ  0: @LOG OPERATOR OPERATOR
SJ  0:  JOB 1 ON TTY206 2-MAY-85 13:11:47
SJ  1: @LOG OPERATOR OPERATOR
SJ  1:  JOB 2 ON TTY207 2-MAY-85 13:11:47
SJ  0:  FRIDAY, MAY 2 1985 13:11:48
SJ  1:  FRIDAY, MAY 2 1985 13:11:52
SJ  0:  END OF LOGIN.CMD.1
SJ  0: $ENA
SJ  1:  END OF LOGIN.CMD.1
SJ  1: $ENA
SJ  1: $RUN SYS:BATCON
SJ  0: $^ESET LOGIN PSEUDO
SJ  0: $^ESET LOGIN CONSOLE
SJ  0: $^ESET OPERATOR
SJ  0: $PTYCON
SJ  0: PTYCON> GET SYSTEM:6-1-PTYCON.ATO
SJ  0: PTYCON> SILENCE

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

.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
.skip 1
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 6.1(6625)

Type:	"ATT OPERATOR 1"

Response will be:

	[Attached to tty(some #), confirm]

Type: "<CR>"

Response is:

	Password:

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

	Note: The password will not echo.

To get to the PTYCON level type:

	"^X"

.end literal

.hl1 PTYCON JOBS
.skip 1

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
.skip 1

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.
.skip 1
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
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
6-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
.skip 1

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 6-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 (not supported)
to reconfigure only a specified
configuration category or use the "ADD" or "REMOVE" commands (not supported)
to remove or add tests for individual devices.
.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
	CI20		CI20 Loopback testing			x	x
	NI20		NI20 Loopback testing			x	x
	DC20 LINES	# of FE0 tty lines 			x	x
	LINEPRINTER	LPT's VFU type and charater set		x	x
	DN20		DN20 syncronous line configuration	x	x
	AN20		AN20 on system or not				x
	MEMORY		#K of memory on system			x	x
	PROCESS		System or Peripheral testing		x	x

.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 6-1-CONFIG.CMD file is edited to explicitly define
MTA's, (this is NOT done by CONFIG)
the TOPS-20 Monitor assigns MTA0 through
MTA7 to tape drives in the physical order that it sees them.
That is according to the
following priority scheme: RH20#, TM# (or other controller#), and UNIT#.
.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 CI20.
.skip 1

In Mfg. CI20's are accepted one of two ways. It is tested via the
standard disk tests if disk(s) are configured on channel 7 HCS50/RAxx
(ie HSC31.VER) or if an HSC50 is not connected then it is tested via
CI20 diagnostics in loopback mode (CILOOP.VER).
.skip 1
If you have already configured a disk on Channel 7 CONFIG will
assume that you do not wish to run the loopback tests on the CI and
will output the following message:

.lit

CI20 Loopback Test disabled because Disk(s) configured on Channel 7
 
.end lit

Otherwise CONFIG will ask:
.lit

	Does the system have a CI20 (Y,N) ?  ? "Y"

.end lit
If you answer "Y" CONFIG will enable the CILOOP test
and place a command in 6-1-PTYCON.ATO to "SET PORT CI UNAVAILABLE"
needed to allow the diagnostics to run on the CI.

.hl2 NI20.
.skip 1

NI20's are tested in loopback mode in Mfg.

.lit

	Does the system have a NI20 (Y,N) ?  ? Y
 
.end lit
If you answer "Y" CONFIG enables NILOOP diagnostic tests
and places the command "SET PORT NI UNAVAILABLE" into the
6-1-PTYCON.ATO needed to allow the diagnostics to run on the NI.
 
.hl2 DC20 Lines.
.skip 1

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

.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 2 KDP's.
.le;Maximum of 8 DUP's (4 per KDP) at 9.6K or 19.2K baud
.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 2 DUP's at 9.6K - *
.le;Maximum of 2 DMR's at 56K with 4 Dup's at 9.6K - *
.le;Maximum of 1 DMR at 56K with 6 Dup's at 9.6K - *
.end list

.literal

* - limits determined by MFG evaluation using DN20N1 test.

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

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

.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 6-1-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.


HOW MUCH K TOTAL OF MEMORY  ? 2048
NOTE: USING PREFIX "6-1-"
 
.hl2 Test Process.
.skip 1

In Mfg there are basically two types of acceptance:
Systems acceptance and Peripheral acceptance. If the
entire system is to be tested or if the
CPU and/or Memory is to be tested then you should select the
"S" or System process.
This will cause CPU and Memory diagnostic tests to be run
along with the UETP language tests in addition to
the appropriate peripheral tests.
.skip 1
If only a peripheral is being tested ie an "add on" HSC50/RAxx
then select the "P" Peripheral process wich will cause only the
selected peripheral tests to run.

.lit

Type 'H' for help.
Test Process (S = System, P = Peripheral, H)  ? "S"

.end lit

.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

	Peripheral Tests:
	
	ENABLE DSK11/CYCLE:10/TIME:01:00:00
	ENA MTA0/DEPTH:MAX/CYCLE:10/TIME:01:00:00
	ENA MTA1/DEPTH:MAX/CYCLE:10/TIME:01:00:00
	ENA LPT0/CYCLE:10
	ENA LPT1/CYCLE:10
	ENA DN20N1/LIMIT:10
	ENA DN20N2/LIMIT:10
	
	PLEASE SUBMIT <MFG>DN20N1.CTL/TIME
	PLEASE SUBMIT <MFG>DN20N2.CTL/TIME
	$
.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
.skip 1
Warning: There are some bugs with the "CHANGE" , "ADD", and "REMOVE"
commands. Use of these commands is not recomended for
infrequent reconfigurations.
.skip 1

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 6-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.
.skip 1

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 (on KDP-0)
then	$"COPY <MFG>DN1-DUP2.SYS <SUBSYS>DN20N1.SYS.0"

or	1 DMR AND 2 DUP'S (on KDP-0)
then	$"COPY <MFG>DN1-DMR1-DUP2.SYS <SUBSYS>DN20N1.SYS.0"

.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.
.skip 1

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-85 17:28:48

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


.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
.skip 1

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
.skip 1

If this is the first time you have configured the system or
any time that the amount of memory on the system has been changed you
should run the MAKDMP program and create a new DUMP.EXE to reflect the
current amount of memory (2048K in the following example). Otherwise
if the system crashes there will be no dump and the system will
not automatically reboot.

.literal

	$"CONN <SYSTEM>"
	$"DEL DUMP.EXE"
	$"EXP"
	$"RUN <UTILITIES>MAKDMP"
	MAKDMP>"CREATE PS:<SYSTEM>DUMP.EXE 2048"
	MAKDMP>"EXIT"

or to make life easier use the mic file:

	$"CONN <MFG>"
	$"DO MAKDMP 2048"

.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
.SKIP 1

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
.skip 1
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 6-1-PTYCON.ATO to
finish executing (UETP tests started with the BEGIN command)
to insure that what you type does not conflict with the
auto file. However (if careful) you may attach during 
execution of the auto file to get control of the CTY
before the tests start at the point where it pauses:

.literal

	@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 6-1-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 6-1-PTYCON.ATO had been aborted before the POP)
.;		UETP> "TAKE RELIAB$"
.;	
.;	or restart the UETP subjob altogether:
.;	
	"^X"
	PTYCON> "GET <MFG>UETP.ATO"

.end literal

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

.literal

	UETP>"STATUS"

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

 Test   Depth   Status    Cycle   Times   Error   Error   Start
 name                             run     count   limit   time
======  =====   =======   =====   =====   =====   =====   =====
LPT0    VER     Running   24:00       0       0       0    10:16
DN20N1  VER     Queued    24:00       0       0       0    10:16
DSK11   VER     Running   24:00       0       0       0    10:16
HSC31   VER     Running   24:00       0       0       0    10:16
MTA0    MAX     Running   24:00       0       0       0    10:16
MTA1    CMP     Queued    24:00       0       0       0    10:16
ALGOL   VER     Queued    24:00       0       0       0    10:16
APL     VER     Queued    24:00       0       0       0    10:16
APLSF   VER     Queued    24:00       0       0       0    10:16
	
.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
.skip 1

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-85 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
.skip 1

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-85 22:21:38]

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

.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.
.skip 1

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
.skip 1

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
.skip 1

.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
.skip 1

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
.skip 1

.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
.skip 1

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
.skip 1

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
.skip 1

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
.skip 1

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
.skip 1

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
.skip 1

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

CI20 TESTS
----------
 CILOOP.VER, CILOOP.MAX
 HSC31.VER

NI20 TESTS
----------
 NILOOP.VER,  NILOOP.MAX

.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