skip book previous and next navigation links
go up to top of book: HP OpenVMS System Manager's Manual, Volume 2:... HP OpenVMS System Manager's Manual, Volume 2:...
go to beginning of chapter: Testing the System with UETP Testing the System with UETP
go to previous page: Troubleshooting: Possible UETP Errors Troubleshooting: Possible UETP Errors
go to next page: Getting Information About the SystemGetting Information About the System
end of book navigation links

UETP Tests and Phases  



This section explains, in detail, the organization of UETP and the individual components within the test package. You run UETP by starting a master command procedure containing commands to start each test phase. The procedure begins by prompting you for information needed by the various test phases. (See Starting UETP for a detailed description of starting UETP.)

The master command procedure, UETP.COM, contains commands that initiate each test phase. UETP.COM also contains commands that do such tasks as defining logical names and manipulating files generated by the tests.

The UETP.COM procedure also issues commands to start the test controlling program UETPHAS00.EXE, which, in turn, controls each test phase. The test controller starts up multiple detached processes. It also reports their completion status and other information the processes report to it.

The sections that follow describe the various UETP test phases.

Initialization Phase  

The following actions occur during the initialization phase:

A summary of UETINIDEV.DAT always exists in UETP.LOG, and UETINIT01.EXE sends that summary to the console if you have requested the long report format.

Device Test Phase  

The device test phase includes separate tests for each type of device, such as disk, magnetic tape, line printer, and terminal. This section explains the device test phase and presents instructions for testing a single device. If you want to run the entire device test phase individually, refer to Running a Subset of Phases.

How the Device Phase Works  

The UETP device test phase starts an executable image, the phase controller UETPHAS00, which creates a detached process for every device controller to be tested. For example, if a system includes three terminal controllers, one line printer controller, and two disk controllers, the image creates six detached processes. In parallel, the detached processes execute images that test the various types of devices.

The initialization phase of UETP creates a file called UETINIDEV.DAT and a file called UETCONT00.DAT. UETINIDEV.DAT contains data on the controllers in the system supported by OpenVMS and their associated devices; UETCONT00.DAT associates a device test image with each testable controller.

UETPHAS00 uses the information in UETCONT00.DAT to find a device controller name to pass to each detached process that it creates. UETPHAS00 passes the controller name by writing it to a mailbox that is SYS$INPUT to individual tests. Each detached process uses that data to determine which controller to test. The test image then searches UETINIDEV.DAT for the device controller and for all testable units on that controller. The phase controller terminates when all devices on all controllers have completed testing.

Because UETCONT00.DAT is deleted automatically at the end of a UETP run, you cannot run the device phase unless you start UETP.COM; you can run only individual test images. UETINIDEV.DAT exists in SYS$TEST unless you delete it.

Running a Single Device Test  

You must be logged in to the SYSTEST account to run the individual tests as described in this section. Also, a copy of UETINIDEV.DAT must exist. If a copy of the file is not present from a previous run (a run of the entire UETP or a run of the device test phase creates UETINIDEV.DAT), you can create it. Note that when you run a single test, no log file is created; the test sends all its output to your terminal.

If you do not want to test all the device types, you can test a specific controller by choosing a test image name from Device Tests (VAX Only) (for VAX systems) or Device Tests (Alpha Only) (for Alpha and I64 systems) and executing it as in the following example:

$ RUN UETTTYS00
Controller designation?: TTB
UETP prompts you for the controller designation and the device code. Unless you are testing your own terminal, you must explicitly designate a controller name. If you are running the terminal test, you can press Return to test your terminal only.

If you plan to repeat the run several times, you might find it more convenient to define the logical name CTRLNAME as follows:

$ DEFINE CTRLNAME TTB
$ RUN UETTTYS00
When you define the controller name in this way, the logical name CTRLNAME remains assigned after the test completes. To deassign this logical name, use the DCL command DEASSIGN as follows:
$ DEASSIGN CTRLNAME

Format of UETINIDEV.DAT  

The UETINIDEV.DAT file is an ASCII sequential file that you can type or edit if necessary. The contents of this file are shown in the following command sequence:

$ TYPE UETINIDEV.DAT
    
DDB x ddd
UCB y uuuuu nnnnnnnnn.nnn
END OF UETINIDEV.DAT
The symbols in this example are defined as follows:

Symbol Value
x
T, if testable units exist for this controller; N, if this controller is not to be tested
y
T, if this unit is testable; N, if this unit is not testable
ddd
Device controller name, for example DUA
uuuuu
Device unit number, for example 25
nnnnnnnnn.nnn
UETP device test name for the unit, for example, UETDISK00.EXE

UETINIDEV.DAT contains a DDB (device data block) line for each controller connected or visible to your system. After the DDB line is a UCB (unit control block) line for each unit connected to that controller. A device test can test a particular device only if both the DDB line and the UCB line indicate that the device is testable.

Running a Test in Loop Mode  

If you want to put extra stress on a device, you can run the device test in loop mode, which causes the test to run indefinitely. For example:

$ DEFINE MODE LOOP
$ RUN UETDISK00
Controller designation?: DRA
%UETP-I-TEXT, End of pass 1 with 980 iterations at 22-JUN-2004 16:18:51:03

^C
You must use Ctrl/C to terminate the test run. If you use Ctrl/Y, UETP does not complete cleanup procedures.

Functions of Individual Device Tests  

For each disk in the system, the disk test allocates two files into which it randomly writes blocks of data. The test then checks the data, reports any errors to SYS$OUTPUT, and deletes the disk files.

When you run the disk test phase in a cluster environment, the test accesses all disks that are mounted by the system being tested, and users of the disk being tested might encounter an insufficient disk space problem. You should warn users on remote nodes (who share disks with users on the local system) that UETP might be testing a disk they are using.

The magnetic tape test exercises all the magnetic tape drives in the system. The test creates a large file on each mounted magnetic tape, into which it writes multiple sequential records of varying sizes. After writing the records, the test rewinds the magnetic tape, validates the written records, and reinitializes the magnetic tape.

The terminal and line printer test generates several pages or screens of output, in which each page or screen contains a header line and a test pattern of ASCII characters. A header line contains the test name, the device name, the date, and the time.

For the laboratory peripheral accelerator (LPA11-K), the test image determines the configuration on the LPA11-K's I/O bus. The image loads all types of microcode to the LPA11-K and reads or writes data for each device on the LPA11-K I/O bus.

The communications device tests fill the transmit message buffer with random data; then, using loopback mode, the tests transmit and receive the message several times. To check that the looped-back data is correct, an AST routine is associated with a $QIO read to compare the received message against the transmitted message. The procedure is repeated using messages of different lengths.

The interface device tests put the devices they are testing in maintenance mode, write random data, and then verify the data.

The vector processor device test performs simple vector-scalar and vector-vector arithmetic operations and compares the results with expected values. The test also uses vector-related system service extensions and forces the system to generate arithmetic and memory management exceptions.

Device Tests (VAX Only) lists the device test images and the devices to be tested on VAX systems.

Table 1   Device Tests (VAX Only)
Test Image Name Devices Tested
UETDISK00.EXE
Disks
UETTAPE00.EXE
Magnetic tape drives and tape cartridge drives
UETTTYS00.EXE
Terminals and line printers
UETLPAK00.EXE
LPA11-K
UETCOMS00.EXE
DMC11, DMR11
UETDMPF00.EXE
DMF32, DMP11
UETDR1W00.EXE
DR11-W
UETDR7800.EXE
DR780, DR750
UETCDRO00.EXE
RRD40, RRD42, RRD50
UETUNAS00.EXE
Ethernet Adapters
UETVECTOR.EXE
Vector Processor, VVIEF

Device Tests (Alpha Only) lists the device test images and the devices to be tested on Alpha systems.

Table 2   Device Tests (Alpha Only)
Test Image Name Devices Tested
UETDISK00.EXE
Disks
UETTAPE00.EXE
Magnetic tape drives and tape cartridge drives
UETTTYS00.EXE
Terminals and line printers
UETCDRO00.EXE
RRD42
UETUNAS00.EXE
Ethernet adapters

System Load Test Phase  

The purpose of the system load test is to simulate a number of terminal users who are demanding system resources simultaneously. The system load tests, directed by the file UETLOAD00.DAT, create a number of detached processes that execute various command procedures. Each process simulates a user logged in at a terminal; the commands within each procedure are the same types of commands that a user enters from a terminal. The load test creates the detached processes in quick succession, and the processes generally execute their command procedures simultaneously. The effect on the system is analogous to an equal number of users concurrently issuing commands from terminals. In this way, the load test creates an environment that is similar to normal system use.

The load test uses the logical name LOADS to determine the number of detached processes to create. When you initiate the UETP command procedure, it prompts for the number of users to be simulated (see Defining User Load for Load Test) and consequently the number of detached processes to be created. Your response, which depends on the amount of memory and the swapping and paging space in your system, defines the group logical name LOADS.

The UETP master command procedure deassigns all group logical names assigned by its tests as part of the termination phase. The group logical name LOADS remains assigned only if the UETP package does not complete normally.

The command procedures executed by the load test can generate a large amount of output, depending on the number of detached processes created. For each detached process (or user), the test creates a version of an output file called UETLOnnnn.LOG (nnnn represents a string of numeric characters). The console displays only status information as the load test progresses.

Whether the load test runs as part of the entire UETP or as an individual phase, UETP combines the UETLOnnnn.LOG files, writes the output to the file UETP.LOG, and deletes the individual output files.

You can run the system load test as a single phase by selecting LOAD from the choices offered in the startup dialog. (See Running a Subset of Phases.)

DECnet for OpenVMS Test Phase  

If DECnet for OpenVMS software is included in your OpenVMS system, a run of the entire UETP automatically tests DECnet hardware and software. Because communications devices are allocated to DECnet and the DECnet devices cannot be tested by the UETP device test, UETP will not test the Ethernet adapter if DECnet for OpenVMS or another application has allocated the device. The DECnet node and circuit counters are zeroed at the beginning of the DECnet test to allow for failure monitoring during the run.

As with other UETP phases, you can run the DECnet for OpenVMS phase individually by following the procedure described in Running a Subset of Phases.

Environment  

The DECnet for OpenVMS test will work successfully on OpenVMS systems connected to all DECnet supported node types, including routing and nonrouting nodes and several different types of operating systems (such as RSTS, RSX, TOPS, and RT). To copy files between systems, the remote systems must have some type of default access. The DECnet phase tests the following nodes and circuits:

No limit exists on the number of communication lines supported by the tests. A test on one adjacent node should last no more than two minutes at normal communications transfer rates.


NoteUETP assumes your system has default access for the FAL object, even though the network configuration command procedure NETCONFIG.COM does not provide access for the FAL object by default. When you install DECnet software with the defaults presented by NETCONFIG.COM, the UETP DECnet phase can produce error messages. You can ignore these error messages. See Lack of Default Access for the FAL Object for more information.

How the DECnet Phase Works  

UETP (under the control of UETPHAS00.EXE) reads the file UETDNET00.DAT and completes the following steps during the DECnet for OpenVMS phase:

  1. Executes a set of Network Control Program (NCP) LOOP EXECUTOR commands to test the node on which UETP is running.
  2. Uses NCP to execute the command SHOW ACTIVE CIRCUITS. The results are placed in UETININET.TMP, from which UETP creates the data file UETININET.DAT. The UETININET.TMP file contains the following information for any circuit in the ON state but not in transition: The UETININET.TMP file is used throughout the DECnet phase to determine which devices to test.
  3. Uses the UETININET.TMP file to create an NCP command procedure for each testable circuit. Each command procedure contains a set of NCP commands to zero the circuit and node counters and to test the circuit and adjacent node by copying files back and forth.
    NoteIf you do not want the counters zeroed, do not test the DECnet for OpenVMS software.

  4. Executes the command procedures from Step 3 in parallel to simulate a heavy user load. The simulated user load is the lesser of the following values:
  5. Executes a program, UETNETS00.EXE, that uses the UETININET.DAT file to check the circuit and node counters for each testable circuit. If a counter indicates possible degradation (by being nonzero), its name and value are reported to the console. All counters are reported in the log file, but only the counters that indicate degradation are reported to the console. An example of UETNETS00 output follows.
    %UETP-S-BEGIN, UETNETS00 beginning at  22-JUN-2000 13:45:33.18
    %UETP-W-TEXT, Circuit DMC-0 to (NODENAME1) OK.
    %UETP-I-TEXT, Node  (NODENAME2) over DMC-1 response timeouts = 1.
    %UETP-I-TEXT, Circuit DMC-1 to (NODENAME2) local buffer errors = 34.
    %UETP-I-TEXT, Node  (NODENAME3) over DMP-0 response timeouts = 3.
    %UETP-S-ENDED, UETNETS00 ended at 22-JUN-2000 13:45:36.34
    Because degradation is not necessarily an error, the test's success is determined by you, not by the system. The following counters indicate possible degradation:

    For Circuits

    For Nodes

Cluster-Integration Test Phase  

The cluster-integration test phase consists of a single program and a command file that depend heavily on DECnet for OpenVMS software. This phase uses DECnet for OpenVMS software to create SYSTEST_CLIG processes on each OpenVMS node in the cluster and to communicate with each node. SYSTEST_CLIG is an account that is parallel to SYSTEST, but limited so that it can only be used as part of the cluster-integration test. The following restrictions on the SYSTEST_CLIG account are necessary for a correct run of the cluster test phase:

These items are necessary to ensure the security and privacy of your system. If the test cannot create a SYSTEST_CLIG process on an OpenVMS node, it gives the reason for the failure and ignores that node for the lock tests and for sharing access during the file test. Also, the test does not copy log files from any node on which it cannot create the SYSTEST_CLIG process. If a communication problem occurs with a SYSTEST_CLIG process after the process has been created, the test excludes the process from further lock and file sharing tests. At the end of the cluster-integration test, an attempt is made to report any errors seen by that node.

UETCLIG00.EXE has two threads of execution: the primary and the secondary. The first, or primary thread, checks the cluster configuration (OpenVMS nodes, HSC nodes, and the attached disks that are available to the node running the test). For selected OpenVMS nodes, the primary thread attempts to start up a SYSTEST_CLIG process through DECnet software. If the primary thread was able to start a SYSTEST_CLIG process on a node, the node runs the command file UETCLIG00.COM, which starts up UETCLIG00.EXE and runs the secondary execution thread.

The process running the primary thread checks to see that it can communicate with the processes running the secondary threads. It then instructs them to take out locks so that a deadlock situation is created.

The primary thread tries to create a file on some disk on selected OpenVMS and HSC nodes in the cluster. It writes a block, reads it back, and verifies it. Next, it selects one OpenVMS node at random and asks that node to read the block and verify it. The primary thread then extends the file by writing another block and has the secondary thread read and verify the second block. The file is deleted.

The secondary processes exit. They copy the contents of their SYS$ERROR files to the primary process, so that the UETP log file and console report show all problems in a central place. DECnet for OpenVMS software automatically creates a NETSERVER.LOG in SYS$TEST as the test is run, so that if necessary, you can read that file later from the node in question.

During the test run, the primary process uses the system service SYS$BRKTHRU to announce the beginning and ending of the test to each OpenVMS node's console terminal.

You can define the group logical name MODE to the equivalence string DUMP to trace most events as they occur. Note that the logical name definitions apply only to the node on which they were defined. You must define MODE on each node in the cluster on which you want to trace events.


go to previous page: Troubleshooting: Possible UETP Errors Troubleshooting: Possible UETP Errors
go to next page: Getting Information About the SystemGetting Information About the System