Document revision date: 19 July 1999

UETP displays a message similar to the following one to signal a vector processor failure:

********************** * UETVECTOR * * Error count = 1 * ********************** %PPL-S-CREATED_SOME, created some of those requested - partial success -UETP-E-SUBSPNERR, Error spawning subordinate process. -UETP-E-SCHCTXERR, Error scheduling vector context test subprocess. -UETP-E-VECCTXERR, Error encountered during vector context testing. %UETP-I-ENDED, UETVECTOR_0000 ended at 22-JUN-1998 07:37:00.59

Solution

See Section 17.3.19 for the correct setup for vector processor testing.

17.7.5 Device Allocated or in Use by Another Application

If DECnet for OpenVMS software or the LAT software is running during the DEVICE phase, the UETUNAS00 test displays the following message:

-UETP-W-TEXT, Device is in use by DECnet or another application

Other UETP communication device tests display the following message:

SYSTEM-W-DEVALLOC, device already allocated to another user

Solution

If you want to run the device test on the Ethernet adapter, shut down DECnet and LAT software before beginning the test.

17.7.6 Insufficient Disk Space

When you run continuous passes of UETP, log files accumulate on the disk from which UETP was run. These files reduce the amount of free disk space available for each successive pass. If the amount of disk space available becomes too small for the current load, the following error message appears:

%UETP-S-BEGIN, UETDISK00 beginning at 22-JUN-1998 08:12:24.34 %UETP-I-ABORTC, DISK_DJA to abort this test, type ^C ********************** * DISK_DJA * * Error count = 1 * ********************** -UETP-F-TEXT, RMS file error in file DJA0:DJA00.TST -RMS-F-FUL, device full (insufficient space for allocation) ********************** * DISK_DJA * * Error count = 2 * ********************** -UETP-F-TEXT, RMS file error in file DJA0:DJA01.TST -RMS-F-FUL, device full (insufficient space for allocation) %UETP-E-DESTP, DISK_DJA stopped testing DJA unit 0 at 08:12:36.91 %UETP-S-ENDED, UETDISK00 ended at 22-JUN-1998 08:12:37.98

Solution

Make more space available on the disk. You can do this by using one or more of the following techniques:

• Delete unnecessary files to create more space.
• Purge files, if multiple versions exist.
• Mount a volume with sufficient space.
• Check for disk quotas that might be enabled on the disk. If disk quotas are enabled, either disable or increase them. (Refer to the OpenVMS System Management Utilities Reference Manual for a description of the Disk Quota utility.)
• Run VMSTAILOR if you have a small-disk system. Refer to the upgrade and installation manual for your operating system for more information.

See Section 17.2.2 and Section 17.3.3 for a further discussion of disk space.

17.7.7 Incorrect Setup of an OpenVMS Cluster System

Most problems that can occur during the cluster-integration test are related to improper setup of the OpenVMS Cluster system or of UETP on the cluster. These problems are most likely to occur at the following stages of the cluster test:

• Near the beginning, when processes on OpenVMS nodes are started
• Toward the end, when cluster file access is checked

The cluster test phase shows that various OpenVMS nodes in your cluster can simultaneously access files on selected nodes in the cluster. First, UETP tries to create a file on a disk drive that is accessible to the other selected nodes in the cluster. The following requirements are for creating a file in the cluster test phase:

• A [SYSTEST] directory must exist on the disk in either the master file directory (MFD) or in the root directory [SYS0.].
• The protection for [SYSTEST] directory must be set to allow the SYSTEST account to create a file in it.

If UETP is unable to find a suitable device on a certain node, the test displays a warning message and proceeds to the next cluster node.

Nodes on which the operator's terminal (OPA0) is set to the NO BROADCAST terminal characteristic will generate the following error message during the cluster test:

********************** * UETCLIG00master * * Error count = 1 * ********************** -UETP-E-TEXT, 0 operator consoles timed out on the cluster test warning and 1 operator console rejected it. -UETP-E-TEXT, Status returned was, "%SYSTEM-F-DEVOFFLINE, device is not in configuration or not available"

Disregard this message if OPA0 is set to NO BROADCAST.

Solution

Whenever you suspect a problem, examine the SYS$TEST:NETSERVER.LOG file that was created when the SYSTEST_CLIG process was created. This file can contain additional error information that could not be transmitted to the node running the test. If it was not possible to create the SYSTEST_CLIG process on some node, the system accounting file for that node might contain a final process status in a process termination record.

The following problems can occur during a cluster test:

• Logging in at other nodes---This problem is due to incorrect setup for the cluster test at the remote OpenVMS node. For example, if you specified a password for the SYSTEST_CLIG account or if you disabled the SYSTEST_CLIG account, the test displays the following message:

  %SYSTEM-F-INVLOGIN, login information invalid at remote node

  
  Refer to Section 17.3.16 and Section 17.6.6 for information about preparing for cluster testing.

• Communicating with other nodes---A message indicates a DECnet problem. Check the NETSERVER.LOG file on the affected node to determine the cause.
• Taking out locks or detecting deadlocks---The most likely cause of this problem is that you are not logged in to the SYSTEST account. Another possibility is that your cluster is not configured properly.
• Creating files on cluster nodes---This problem is due to incorrect setup for the cluster test; refer to Section 17.3.16 for information about preparing for cluster testing.

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 17.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-1998 15:45:08.97 %UETP-I-BEGIN, UETLOAD02_0000 beginning at 22-JUN-1998 15:45:09.42 %UETP-I-BEGIN, UETLOAD03_0001 beginning at 22-JUN-1998 15:45:09.63 %UETP-I-BEGIN, UETLOAD04_0002 beginning at 22-JUN-1998 15:45:10.76 %UETP-I-BEGIN, UETLOAD05_0003 beginning at 22-JUN-1998 15:45:11.28 %UETP-I-BEGIN, UETLOAD06_0004 beginning at 22-JUN-1998 15:45:12.56 %UETP-I-BEGIN, UETLOAD07_0005 beginning at 22-JUN-1998 15:45:13.81 %UETP-I-BEGIN, UETLOAD08_0006 beginning at 22-JUN-1998 15:45:14.95 %UETP-I-BEGIN, UETLOAD09_0007 beginning at 22-JUN-1998 15:45:16.99 %UETP-I-BEGIN, UETLOAD10_0008 beginning at 22-JUN-1998 15:45:19.32 %UETP-I-BEGIN, UETLOAD11_0009 beginning at 22-JUN-1998 15:45:19.95 %UETP-I-BEGIN, UETLOAD02_0010 beginning at 22-JUN-1998 15:45:20.20 %UETP-I-BEGIN, UETLOAD03_0011 beginning at 22-JUN-1998 15:45:21.95 %UETP-I-BEGIN, UETLOAD04_0012 beginning at 22-JUN-1998 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.

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

17.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-1998 07:47:16.50 %UETP-I-BEGIN, UETLOAD02_0000 beginning at 22-JUN-1998 07:47:16.76 %UETP-I-BEGIN, UETLOAD03_0001 beginning at 22-JUN-1998 07:47:16.92 %UETP-I-BEGIN, UETLOAD04_0002 beginning at 22-JUN-1998 07:47:17.13 %UETP-I-BEGIN, UETLOAD05_0003 beginning at 22-JUN-1998 07:47:17.35 %UETP-I-BEGIN, UETLOAD06_0004 beginning at 22-JUN-1998 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-1998 07:47:54.10 -UETP-W-TEXT, Aborted via a user Ctrl/C. *************************************************** * * END OF UETP PASS 1 AT 22-JUN-1998 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 15) 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 Dump Analyzer Utility 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.

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

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

17.8.1 Initialization Phase

The following actions occur during the initialization phase:

• The image UETINIT00.EXE prompts you for information. (See Section 17.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.

17.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 17.4.1.

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

17.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 17-1 (for VAX systems) or Table 17-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

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

	privacy and legal statement
6017PRO_078.HTML