|
HP OpenVMS Systems Documentation |
|
OpenVMS System Manager's Manual
19.7.8 Problems During the Load TestA 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:
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:
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:
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.
A DECnet error message can indicate that the network is unavailable. Solution
If you encounter other DECnet related errors, you should perform the following actions:
19.7.10 Errors Logged but Not Displayed
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.
The following error message indicates that no PCB or swap slots are available:
Solution To solve this problem, use the following procedure:
19.7.12 No Keyboard Response or System Disk ActivityIf 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:
19.7.13 Lack of Default Access for the FAL ObjectIf 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:
These messages are followed by:
You can ignore these messages.
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.
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.
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.
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.
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.
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:
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:
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:
19.8.2.3 Format of UETINIDEV.DATThe 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:
The symbols in this example are defined as follows:
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.
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:
You must use Ctrl/C to terminate the test run. If you use Ctrl/Y, UETP
does not complete cleanup procedures.
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-2 lists the device test images and the devices to be tested on Alpha systems.
|