Document revision date: 19 July 1999

To run UETP on an RRD40 or RRD50 compact disc drive, you must first load the test disc that you received with your compact disc drive unit.

17.3.8 Optical Disk Drives

To run UETP on an RV60 drive, set up the RV64 optical disk-storage system, perform the following steps:

1. Use the Jukebox Control Software (JCS) to load an optical disk in each of the RV60 drives. JCS is a layered product on the OpenVMS operating system that comes with the RV64 and is responsible for controlling the robot arm that loads and unloads the disks.
2. Initialize the optical disks with the label UETP, but do not mount them.

UETP tests all the RV60s present in the RV64 simultaneously. Unlike the tape tests, UETP does not reinitialize the optical disks at the end of the test.

17.3.9 Terminals and Line Printers

Terminals and line printers must be turned on and on line to be tested by UETP. Check that line printers and hardcopy terminals have enough paper. The amount of paper required depends on the number of UETP passes that you plan to execute. Each pass requires two pages for each line printer and hardcopy terminal.

Check that all terminals are set to the correct baud rate and are assigned appropriate characteristics. (Refer to the user's guide for your terminal.)

Spooled devices and devices allocated to queues fail the initialization phase of UETP and are not tested.

17.3.10 Ethernet Adapters

Make sure that no other processes are sharing the Ethernet adapter device when you run UETP.

Because either DECnet for OpenVMS or the LAT terminal server can try to use the Ethernet adapter (a shareable device), you must shut down DECnet and the LAT terminal server before you run the device test phase, if you want to test the Ethernet adapter.

17.3.11 DR11--W Data Interface (VAX Only)

The DR11--W data interface uses an internal logical loopback mode that tests all features except that of module connectors, cables, and transceivers.

Because random external patterns are generated during this operation, the user device or other processor might need to be isolated from the DR11--W data interface being tested until the testing is completed.

To test the DR11--W data interface properly, the E105 switchpack must be set as follows:

Switch 1	Switch 2	Switch 3	Switch 4	Switch 5
Off	On	Off	Off	On

When UETP testing is completed, restore the DR11--W data interface to the proper operating configuration.

17.3.12 DRV11--WA Data Interface (VAX Only)

The DRV11--WA data interface is a general-purpose, 16-bit, parallel, direct memory access (DMA) data interface.

To prepare the DRV11--WA driver on a MicroVAX computer for UETP testing, be sure the following conditions exist:

• The jumpers on the DRV11--WA board are set to W2, W3, and W6.
• A loopback cable is connected to the DRV11--WA board.
• The DRV11--WA board occupies slots 8 to 12. If the DRV11--WA is in another location, timeout errors can occur.

When UETP testing is completed, restore the DRV11--WA to the proper operating configuration.

17.3.13 DR750 or DR780 (DR32 Interface) (VAX Only)

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.

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

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

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

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

17.3.19 Vector Processors and the VVIEF (VAX Only)

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

Multiply the value of x by 3. If the result is greater than the account PRCLM value, then you must increase the SYSTEST account PRCLM quota to match the returned result. For more information, see Chapter 26.

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

17.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 17.4.2 through Section 17.4.4. If you want to run all the test phases, skip the next section.

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

17.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 17.4.4.) Ensure that all line printers and hardcopy terminals have enough paper because each run requires two pages.

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

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

17.4.4.1 Long Report Format

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.

17.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 17.6 for troubleshooting information.

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

	privacy and legal statement
6017PRO_076.HTML