HP OpenVMS Systems Documentation

The DR32 (DR750 or DR780) device is an interface adapter that connects the internal memory bus of a VAX processor to a user-accessible bus called the DR32 device interconnect (DDI).

To prepare the DR750 or the DR780 for UETP testing, use the following procedure:

1. Copy the DR780 microcode file, XF780.ULD, from the diagnostic medium to SYS$SYSTEM. Use the procedure described in the documentation provided with the DR780 Microcode Kit.
2. Turn off the power to the DR780.
3. Make the following DR780 backplane jumper changes:
   1. Remove the jumper from W7 and W8.
   2. Add a jumper from E04M1 to E04R1.
   3. Add a jumper from E04M2 to E04R2.
4. Disconnect the DDI cable from the DR780. This cable is either a BC06V--nn cable, which can be disconnected, or a BC06R--nn cable, which requires that you remove its paddle card from the backplane of the DR780.
5. Restore power to the DR780.

When UETP testing is completed, restore the DR750 or the DR780 to the proper operating configuration.

19.3.14 Second LPA11--K Device

If you have two LPA11--K devices, be sure that each is given a systemwide logical name in the SYS$MANAGER:LPA11STRT.COM file. The logical name for the first LPA11--K device should be LPA11$0, and the logical name for the second LPA11--K device should be LPA11$1.

19.3.15 Devices That Are Not Tested

UETP does not test the following devices; their status has no effect on UETP execution:

• Devices that require operator interaction (such as card readers)
• Software devices (such as the null device and local memory mailboxes)

UETP does not have specific tests for UDA, HSC, or CI devices; they are tested implicitly by the disk, magnetic tape, and DECnet for OpenVMS tests.

UETP also does not test the console terminal or console drives. If you boot the system, log in, and start UETP, you have shown that these devices can be used.

19.3.16 OpenVMS Cluster Testing

Before you run UETP in an OpenVMS Cluster environment, check the SYSTEST_CLIG account. The SYSTEST_CLIG account parallels SYSTEST except that it is dedicated to running the cluster-integration test. The requirements for the SYSTEST_CLIG account are as follows:

• The account should be present in the user authorization file, exactly as distributed by Compaq on each system in your OpenVMS Cluster.

  Note The SYSTEST_CLIG account could have been disabled during the OpenVMS upgrade procedure. If it was disabled, you must reenable the SYSTEST_CLIG account and give it a null password before you run UETP.

  
  To reenable the SYSTEST_CLIG account, enter the following commands:

  $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> MODIFY /FLAGS=NODISUSER /NOPASSWORD SYSTEST_CLIG UAF> EXIT

  Note Compaq recommends that you disable the SYSTEST_CLIG account after testing has completed.

  
  To disable the SYSTEST_CLIG account, enter the following commands:

  $ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> MODIFY /FLAGS=DISUSER SYSTEST_CLIG UAF> EXIT

• The privileges and quotas of the SYSTEST_CLIG account must match those of the SYSTEST account.

UETP requires little additional preparation for the cluster-integration test phase beyond the requirements for other UETP test phases. The additional requirements for cluster integration testing are as follows:

1. Your system must be a member of a cluster. If it is not, UETP displays a message and does not attempt to run the test.
2. Your system must use the same deadlock detection interval as the other systems in the cluster. (The deadlock detection interval is set by the system parameter DEADLOCK_WAIT. It is normally not changed from the default value, which is 10 seconds.)
3. The files UETCLIG00.COM and UETCLIG00.EXE, located in SYS$TEST, are necessary for each system included in the test.
4. DECnet for OpenVMS must be set up between the cluster nodes; UETP uses DECnet for OpenVMS to create a process on those nodes. All checks that the test makes depend on its ability to create the SYSTEST_CLIG processes and to communicate with them using DECnet for OpenVMS software.
5. All operator terminals (OPA0:) should accept broadcast messages. To set the BROADCAST characteristic, enter the following command:

   $ SET TERM/BROADCAST/PERM OPA0:

   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"

6. There must be a [SYSTEST] or [SYS0.SYSTEST] directory on some disk available to the cluster for each node (both OpenVMS and HSC) in the cluster. The test uses the same directory as the UETP disk test to create a file on each cluster node and to see if some other OpenVMS node in the cluster can share access to that file. There must be one such directory per node; the test continues with the next cluster node once it has finished with a file.
7. By default, the UETP cluster phase selects three nodes from the running cluster for deadlock, disk, and file access testing. However, if you want all cluster nodes tested, enter the following command before invoking UETP:

   $ DEFINE/GROUP UETP$CTMODE ALL

After you install the OpenVMS operating system on a small system disk (for example, an RZ23L), you might not have the 1200 blocks of free disk space required to run UETP successfully. If you do not have 1200 free blocks on your system disk, use VMSTAILOR to remove some files from the system disk before you run UETP. For instructions on using VMSTAILOR, refer to the OpenVMS upgrade and installation manual for your system.

19.3.18 DECnet for OpenVMS Phase

The DECnet for OpenVMS phase of UETP uses more system resources than other tests. You can, however, minimize disruptions to other users by running the test on the least busy node.

By default, the file UETDNET00.COM specifies the node from which the DECnet test will be run. To run the DECnet test on a different node, enter the following command before you invoke UETP:

$ DEFINE/GROUP UETP$NODE_ADDRESS node_address

This command equates the group logical name UETP$NODE_ADDRESS to the node address of the node in your area on which you want to run the DECnet phase of UETP.

For example:

$ DEFINE/GROUP UETP$NODE_ADDRESS 9.999

You can also run the DECnet for OpenVMS test on a different node by entering the following command before you invoke UETP:

$ DEFINE/GROUP UETP$NODE_NAME "node""username password""

When you run UETP, a router node attempts to establish a connection between your node and the node defined by UETP$NODE_ADDRESS or UETP$NODE_NAME. Occasionally, the connection between your node and the router node can be busy or nonexistent. When this happens, the system displays the following error messages:

 %NCP-F-CONNEC, Unable to connect to listener
 -SYSTEM-F-REMRSRC, resources at the remote node were insufficient

 %NCP-F-CONNEC, Unable to connect to listener
 -SYSTEM-F-NOSUCHNODE, remote node is unknown

UETP automatically loads all installed and enabled vector processors during the load phase, and automatically tests all installed and enabled vector processors during the device test phase.

If vector processors are available on the system, check for the VP number by entering the following commands:

$ x = F$GETSYI ("VP_NUMBER")
$ SHOW SYMBOL x

However, UETP cannot load the VAX Vector Instruction Emulation facility (VVIEF) during the load phase, and will not automatically test VVIEF. To test VVIEF, you must perform the following steps before running UETP:

1. Edit the file UETCONT00.DAT to add the following line:

   Y Y UETVECTOR.EXE "DEVICE_TEST"

2. Make sure VVIEF was activated when the system was booted. To determine if the VVIEF was activated, enter the following DCL commands:

   $ X = F$GETSYI("VECTOR_EMULATOR") $ SHOW SYMBOL X

   
   If the system displays a value of 1, VVIEF is loaded; if the system displays a value of 0, VVIEF is not loaded.

The VVIEF test can be executed as an individual test using the RUN command, as described in Section 19.8.2.

19.4 Starting UETP

When you have logged in and prepared the system and devices, you are ready to begin the test.

To start UETP, enter the following command and press Return:

$ @UETP

UETP displays the following prompt:

Run "ALL" UETP phases or a "SUBSET" [ALL]?

Throughout the startup dialog, brackets indicate the default value, which you can choose by pressing Return.

When running UETP for the first time, it is recommended that you choose the default value (ALL) and run all the phases. If you choose ALL, UETP displays three more questions, which are described in Section 19.4.2 through Section 19.4.4. If you want to run all the test phases, skip the next section.

19.4.1 Running a Subset of Phases

You can run a single phase by entering SUBSET or S in response to the following prompt:

Run "ALL" UETP phases or a "SUBSET" [ALL]?

If you enter S or SUBSET, UETP prompts you for the phase you want to run as follows:

You can choose one or more of the following phases:

        DEVICE, LOAD, DECNET, CLUSTER

Phases(s):

There is no default; enter one or more phase names from the list. Separate two or more phases with spaces or commas.

If your choice includes the LOAD phase, UETP displays three prompts:

How many passes of UETP do you wish to run [1]?
How many simulated user loads do you want [n]?
Do you want Long or Short report format [Long]?

If you exclude the LOAD phase from your list of choices, UETP responds with only two prompts: the first and the third.

The next three sections discuss how you can respond to these questions. After you have answered the questions, the phase you have selected runs to completion.

19.4.2 Single Run Versus Multiple Passes

If you specified the default ALL or a subset of phases at the last prompt, UETP displays the following message:

How many passes of UETP do you wish to run [1]?

You can repeat the test run as many times as you want. If you enter 1 in response to the prompt (or press Return for the default), UETP stops after completing a single run. If you specify a number greater than 1, UETP restarts itself until it completes the specified number of passes.

You can run UETP once to check that the system is working, or many times to evaluate the system's response to continuous use. For example, a service technician who is interested only in verifying that a newly installed system works might run UETP once or twice. A manufacturing technician might let the system run for several hours as part of the system integration and test.

When you specify multiple UETP runs, you can request a short console log. (See Section 19.4.4.) Ensure that all line printers and hardcopy terminals have enough paper because each run requires two pages.

19.4.3 Defining User Load for Load Test

After you specify the number of passes, UETP prompts you as follows:

How many simulated user loads do you want [n]?

The load test simulates a situation in which a number of users (detached processes) are competing for system resources. In response to this prompt, enter the number of users you want to simulate for this test. The number in brackets is the default value that UETP computed for your system. The default value depends on the amount of memory and the paging and swapping space that your system has allocated.

Although the given default value is the best choice, you can increase or decrease the user load by entering your own response to the prompt. However, be aware that an increase can cause the test to fail because of insufficient resources.

If you want to see UETP display the user-load equation as it runs, see Section 19.6.2.

19.4.4 Report Formats

The following prompt allows you to choose between long or short report formats:

Do you want Long or Short report format [Long]?

If you choose the long report format (the default), UETP sends the following information to the console terminal:

• All error messages
• All output generated at the beginning of all phases and tests
• All output generated at the end of all phases and tests

In many cases, it might not be convenient to have UETP write the bulk of its output to the terminal. For example, if you run UETP from a hardcopy terminal, the output printing can slow the progress of the tests. This delay might not be a problem if you have requested only one run; however, you might prefer to use the short format if you intend to run multiple passes of UETP from a hardcopy terminal.

19.4.4.2 Short Report Format

If you request the short format, UETP displays status information at the console, such as error messages and notifications of the beginning and end of each phase. This information enables you to determine whether UETP is proceeding normally. If the short console log indicates a problem, you can look at the file UETP.LOG for further information. UETP.LOG contains all the output generated by the various phases, as well as the status information displayed at the console.

After you choose the report format, UETP initiates its sequence of tests and runs to completion. If UETP does not complete successfully, refer to Section 19.6 for troubleshooting information.

19.5 Stopping a UETP Operation

At the end of a UETP pass, the master command procedure UETP.COM displays the time at which the pass ended. In addition, UETP.COM determines whether UETP needs to be restarted. You can request multiple passes when you start up the test package. (See Section 19.4.2.)

At the end of an entire UETP run, UETP.COM deletes temporary files and does other cleanup activities.

Pressing Ctrl/Y or Ctrl/C lets you terminate a UETP run before it completes normally. Normal completion of a UETP run, however, includes the deletion of miscellaneous files that have been created by UETP for the purpose of testing. Using Ctrl/Y or Ctrl/C can interrupt or prevent these cleanup procedures.

The effect of these control characters depends on what part of UETP you are executing. For an explanation of the organization of UETP and its components, refer to Section 19.8.

19.5.1 Using Ctrl/Y

Press Ctrl/Y to abort a UETP run. Note, however, that cleanup of files and network processes in the [SYSTEST] directory might not be complete.

If you are running an individual test image, pressing Ctrl/Y interrupts the current UETP test and temporarily returns control to the command interpreter. While the test is interrupted, you can enter a subset of DCL commands that are executed within the command interpreter and do not cause the current image to exit.

19.5.2 Using DCL Commands

The OpenVMS User's Manual contains a table of commands that you can use within the command interpreter. In addition, you can enter any of the following commands:

• The CONTINUE command continues the test from the point of interruption (except during execution of the cluster test).
• The STOP command terminates the test; the test aborts and control returns to the command interpreter.

  Note Using the STOP command can prevent cleanup procedures from executing normally. You should use the EXIT command if you want the image to do cleanup procedures before terminating.

• The EXIT command executes cleanup procedures and terminates the test (except during execution of the cluster test); control returns to the command interpreter.

If you enter any DCL command other than those that execute within the command interpreter, the test does cleanup procedures and terminates, and the DCL command executes.

19.5.3 Using Ctrl/C

Press Ctrl/C to interrupt a UETP run. You cannot continue the same test phase after you press Ctrl/C. UETP automatically goes to the next phase in the master command procedure.

Some UETP phases react to Ctrl/C by cleaning up all activity and terminating immediately. These tests display the following message when they are started:

%UETP-I-ABORTC, 'testname' to abort this test, type ^C

The phases that do not display the previous message terminate all processes they have started. These processes might not have a chance to complete normal cleanup procedures.

If you are running an individual test image, however, you can use Ctrl/C to terminate the execution of the image and complete cleanup procedures.

Note that Ctrl/C does not complete cleanup procedures for the cluster test.

19.6 Troubleshooting: An Overview

This section explains the role of UETP in interpreting operational errors in an OpenVMS operating system. See Section 19.7 for a discussion of common errors that can appear in a UETP run and describes how to correct them.

19.6.1 Error Logging and Diagnostics

When UETP encounters an error, it reacts like a user program. It either returns an error message and continues, or it reports a fatal error and terminates the image or phase. In either case, UETP assumes the hardware is operating properly and it does not attempt to diagnose the error.

If the cause of an error is not readily apparent, use the following methods to diagnose the error:

• OpenVMS Error Log utility (ERROR LOG)---Run ERROR LOG to obtain a detailed report of hardware and system errors. ERROR LOG reports provide information about the state of the hardware device and I/O request at the time of each error. For information about running ERROR LOG refer to the OpenVMS System Management Utilities Reference Manual.
• Diagnostic facilities---Use the diagnostic facilities to test exhaustively a device or medium to isolate the source of the error.

You can monitor the progress of UETP tests at the terminal from which they were started. This terminal always displays status information, such as messages that announce the beginning and end of each phase and messages that signal an error.

The tests send other types of output to various log files, depending on how you started the tests. (See Section 19.6.7.) The log files contain output generated by the test procedures. Even if UETP completes successfully, with no errors displayed at the terminal, it is good practice to check these log files for errors. Furthermore, when errors are displayed at the terminal, check the log files for more information about their origin and nature.

Each test returns a final completion status to the test controller image, UETPHAS00, using a termination mailbox. This completion status is an unsigned longword integer denoting a condition value. As a troubleshooting aid, UETPHAS00 displays the test's final completion status using the $FAO and $GETMSG system services.

Sometimes, however, the $FAO service needs additional information that cannot be provided using the termination mailbox. When this happens, UETP displays an error message similar to the following one:

UETP-E-ABORT, !AS aborted at !%D

When UETP displays these types of error messages, check the log files for more information. You can also run the individual test to attempt to diagnose the problem.

The error messages that appear at the terminal and within the log files have two basic sources:

• UETP tests
• System components that are tested

If you need help interpreting the messages, use the OpenVMS Help Message utility (Help Message) or refer either to the OpenVMS System Messages and Recovery Procedures Reference Manual¹ or to the manual that describes the individual system component.