Document revision date: 30 March 2001

A variety of errors can occur during the load test because the command procedures that are started during the tests run several utilities and do many functions. Tracking a problem can be difficult because UETP deletes the log files that are generated during the load test. (See Section 19.8.3.)

Solution

If a problem occurs during the load test and the cause is not obvious, you can modify UETP.COM to preserve the log files as follows:

1. Add the /NODELETE qualifier to the following line:

   $ TCNTRL UETLOAD00.DAT/PARALLEL_COUNT='LOADS/REPORT_TYPE='REPORT

2. Delete or comment out the following line:

   $ DELETE UETLO*.LOG;*

Rerun the load test with these changes to try to re-create the problem.

If you re-create the problem, look at the contents of the appropriate log file. You can determine which log file to read by understanding the scheme by which the load test names its processes and log files. (The log file names are derived from the process names.)

The load test creates processes that are named in the following format:

UETLOADnn_nnnn

For example:

%UETP-I-BEGIN, UETLOAD00 beginning at 22-JUN-2000 15:45:08.97 %UETP-I-BEGIN, UETLOAD02_0000 beginning at 22-JUN-2000 15:45:09.42 %UETP-I-BEGIN, UETLOAD03_0001 beginning at 22-JUN-2000 15:45:09.63 %UETP-I-BEGIN, UETLOAD04_0002 beginning at 22-JUN-2000 15:45:10.76 %UETP-I-BEGIN, UETLOAD05_0003 beginning at 22-JUN-2000 15:45:11.28 %UETP-I-BEGIN, UETLOAD06_0004 beginning at 22-JUN-2000 15:45:12.56 %UETP-I-BEGIN, UETLOAD07_0005 beginning at 22-JUN-2000 15:45:13.81 %UETP-I-BEGIN, UETLOAD08_0006 beginning at 22-JUN-2000 15:45:14.95 %UETP-I-BEGIN, UETLOAD09_0007 beginning at 22-JUN-2000 15:45:16.99 %UETP-I-BEGIN, UETLOAD10_0008 beginning at 22-JUN-2000 15:45:19.32 %UETP-I-BEGIN, UETLOAD11_0009 beginning at 22-JUN-2000 15:45:19.95 %UETP-I-BEGIN, UETLOAD02_0010 beginning at 22-JUN-2000 15:45:20.20 %UETP-I-BEGIN, UETLOAD03_0011 beginning at 22-JUN-2000 15:45:21.95 %UETP-I-BEGIN, UETLOAD04_0012 beginning at 22-JUN-2000 15:45:22.99

Note that if more than 10 processes are created, the numbering sequence for the UETLOADnn portion of the process name starts over at UETLOAD02; however, the 4 digits of the _nnnn portion continue to increase.

Each load test process creates two log files. The first log file is created by the test controller; the second log file is created by the process itself. The log file to look at for error information about any given load test process is the one that was created by the test controller (the first log file).

The load test log file derives its file name from the process name, appending the last four digits of the process name (from the _nnnn portion) to UETLO. The test-controller log file and the process log file for each process use the same file name; however, the process log file has the higher version number of the two. For example, the log files created by the process UETLOAD05_0003 would be named as follows:

UETLO0003.LOG;1 (test-controller log file)

UETLO0003.LOG;2 (process log file)

Make sure that you look at the log file with the lower version number; that file contains the load test commands and error information.

After you have isolated the problem, restore UETP.COM to its original state and delete the log files from the load test (UETL0*.LOG;*); failure to delete these files can result in disk space problems.

19.7.9 DECnet for OpenVMS Error

A DECnet error message can indicate that the network is unavailable.

Solution

• If DECnet for OpenVMS software is included in your system, determine whether the product authorization key (PAK) is registered by entering the following command:

  $ SHOW LICENSE

  
  If the PAK is not registered, invoke the License utility to register it by entering the following command:

  $ @SYS$UPDATE:VMSLICENSE

  
  For information about registering licenses, refer to the following documents:

  • The OpenVMS Upgrade and Installation Manual for your operating system
  • The OpenVMS License Management Utility Manual
• If DECnet for OpenVMS software is not included in your system, ignore the message; it is normal and does not affect the UETP run.

If you encounter other DECnet related errors, you should perform the following actions:

• Run DECnet for OpenVMS software as a single phase (see Section 19.4.1) to determine whether the error can be re-created.
• Use the Help Message or refer to the OpenVMS System Messages: Companion Guide for Help Message Users.

If no errors are displayed at the console terminal or reported in the UETP.LOG file, you should run ERROR LOG to see if any errors were logged in the ERRLOG.SYS file. Refer to the OpenVMS System Management Utilities Reference Manual for information about running the ERROR LOG.

19.7.11 No PCB or Swap Slots

The following error message indicates that no PCB or swap slots are available:

%UETP-I-BEGIN, UETLOAD00 beginning at 22-JUN-2000 07:47:16.50 %UETP-I-BEGIN, UETLOAD02_0000 beginning at 22-JUN-2000 07:47:16.76 %UETP-I-BEGIN, UETLOAD03_0001 beginning at 22-JUN-2000 07:47:16.92 %UETP-I-BEGIN, UETLOAD04_0002 beginning at 22-JUN-2000 07:47:17.13 %UETP-I-BEGIN, UETLOAD05_0003 beginning at 22-JUN-2000 07:47:17.35 %UETP-I-BEGIN, UETLOAD06_0004 beginning at 22-JUN-2000 07:47:17.61 %UETP-W-TEXT, The process -UETLOAD07_0005- was unable to be created, the error message is -SYSTEM-F-NOSLOT, no pcb or swap slot available %UETP-W-TEXT, The process -UETLOAD08_0006- was unable to be created, the error message is -SYSTEM-F-NOSLOT, no pcb or swap slot available %UETP-W-TEXT, The process -UETLOAD09_0007- was unable to be created, the error message is -SYSTEM-F-NOSLOT, no pcb or swap slot available %UETP-W-TEXT, The process -UETLOAD10_0008- was unable to be created, the error message is -SYSTEM-F-NOSLOT, no pcb or swap slot available %UETP-W-TEXT, The process -UETLOAD11_0009- was unable to be created, the error message is -SYSTEM-F-NOSLOT, no pcb or swap slot available %UETP-W-ABORT, UETLOAD00 aborted at 22-JUN-2000 07:47:54.10 -UETP-W-TEXT, Aborted via a user Ctrl/C. *************************************************** * * END OF UETP PASS 1 AT 22-JUN-2000 07:48:03.17 * * ***************************************************

Solution

To solve this problem, use the following procedure:

1. Individually rerun the phase that caused the error message (the LOAD phase in the previous example) to see if the error can be reproduced.
2. Increase the size of the page file, using either the command procedure SYS$UPDATE:SWAPFILES.COM (see Chapter 16) or SYSGEN (refer to the OpenVMS System Management Utilities Reference Manual).
3. Increase the system parameter MAXPROCESSCNT, if necessary.
4. Reboot the system.

If the keyboard does not respond or the system disk is inactive, the system might be hung.

Solution

A system hangup can be difficult to trace; you should save the dump file for reference. To learn why the system hung, run the System Dump Analyzer as described in the OpenVMS VAX System Dump Analyzer Utility Manual or the OpenVMS Alpha System Analysis Tools Manual.

Reasons for a system hangup include the following ones:

• Insufficient pool space---Increase the value of the system parameter NPAGEVIR and reboot the system.
• Insufficient page file space---Increase the page file space using the SYSGEN as described in the OpenVMS System Management Utilities Reference Manual.
• I/O device failure causing driver-permanent loop---Call a Compaq support representative.

If default FAL access is disabled at the remote node selected by UETP for DECnet testing (the adjacent node on each active circuit, or a node defined by the group logical name UETP$NODE_ADDRESS), messages similar to the following ones appear:

%UETP-W-TEXT, The process -SVA019841_0001- returned a final status of: %COPY-E-OPENOUT, error opening !AS as output

These messages are followed by:

%COPY-E-OPENOUT, error opening 9999""::SVA019841.D1; as output -RMS-E-CRE, ACP file create failed -SYSTEM-F-INVLOGIN, login information invalid at remote node %COPY-W-NOTCOPIED, SYS$COMMON:[SYSTEST]UETP.COM;2 not copied %UETP-E-TEXT, Remote file test data error

You can ignore these messages.

19.7.14 Bugchecks and Machine Checks

When the system aborts its run, a bugcheck message appears at the console.

Solution

Call your Compaq support representative. Often a hardware problem causes bugchecks and machine checks; solving bugchecks or machine checks is not easy. However, saving the SYS$SYSTEM:SYSDUMP.DMP and ERRLOG.SYS files is important so they are available for examination. Knowing whether the failure can be re-created is also important; you can run UETP again to verify the failure.

19.8 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 Section 19.4 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.

19.8.1 Initialization Phase

The following actions occur during the initialization phase:

• The image UETINIT00.EXE prompts you for information. (See Section 19.4.) Your information defines variables that affect the execution of UETP tests.
• The image UETINIT01.EXE gathers information about all the controllers in the system and on their associated devices. This image writes the information into a file called UETINIDEV.DAT.
• Using the information in UETSUPDEV.DAT, UETINIT01.EXE verifies which devices in the configuration are operable by running the appropriate device test. Each device test completes a simple read/write operation to each device. If a device fails this test, the device's entry in UETINIDEV.DAT specifies that the device cannot be tested. As a result, subsequent UETP tests ignore that device.
• For each testable controller, UETINIT01.EXE writes a line into a file called UETCONT00.DAT. The line associates a test file with the controller it tests.

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.

19.8.2 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 Section 19.4.1.

19.8.2.1 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.

19.8.2.2 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 Table 19-1 (for VAX systems) or Table 19-2 (for Alpha 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

19.8.2.3 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.

19.8.2.4 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-2000 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.

19.8.2.5 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 Ethernet adapter test does self-test diagnostics on the device. It also does read and write tasks with test data that uses various adapter modes (such as internal loopback and external loopback).

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.

Table 19-1 lists the device test images and the devices to be tested on VAX systems.

Table 19-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

Table 19-2 lists the device test images and the devices to be tested on Alpha systems.

Table 19-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

	privacy and legal statement
6017PRO_082.HTML