Document revision date: 30 March 2001

Several parts of UETP, such as some device tests, UETINIT00.EXE, UETCLIG00.EXE, and UETDNET00.COM, let you obtain additional information concerning the progress of the test run or the problems the test encounters. Because this information is usually insignificant, it is not displayed on the screen.

To view the information, enter the following command to define the logical name MODE and run the program:

$ DEFINE MODE DUMP

19.6.4 Example Screen Display (VAX Only)

The following example shows the output for UETINIT00.EXE on a VAX 6000 computer, and logical name MODE defined as DUMP:

$DEFINE MODE DUMP $RUN UETINIT00 Welcome to VAX/VMS UETP Version X7.3 %UETP-I-ABORTC, UETINIT00 to abort this test, type ^C You are running on a VAX 6000-430 CPU with 327680 pages of memory. The system was booted from _$11$DUA6:[SYS0.]. Run "ALL" UETP phases or a "SUBSET" [ALL]? How many passes of UETP do you wish to run [1]? The default number of loads is the minimum result of 1) CPU_SCALE * ((MEM_FREE + MEM_MODIFY) / (WS_SIZE * PER_WS_INUSE)) 7.32 * (( 232390 + 5048) / ( 1024 * 0.20)) = 8486 2) Free process slots = 296 3) Free page file pages / Typical use of page file pages per process 1099992 / 1000 = 1099 How many simulated user loads do you want [296]? Do you want Long or Short report format [Long]? UETP starting at 1-MAR-2001 16:00:43.86 with parameters: DEVICE LOAD DECNET CLUSTER phases, 1 pass, 296 loads, long report. $

This program does not initiate any phase; it displays the equation used by UETP to determine user load and the specific factors that are employed in the current run.

Respond to the questions by pressing Return. After you respond to the first prompt, the program displays the expressions that determine the default number of simultaneous processes. The following definitions apply:

• CPU_SCALE refers to the relative processing power of the CPU in relation to a VAX 11/780 computer. For example, a VAX 6000-430 computer has a CPU_SCALE of 7.32 because it has 7.32 times the processing power of a VAX 11/780 (1.0) computer.
• MEM_FREE represents memory in pages available to users.
• MEM_MODIFY represents memory pages on the modified page list.
• WS_SIZE represents working set size.
• PER_WS_INUSE represents typical percentage of the working set in active use for each process.

UETINIT00 also displays the specific values represented by the expressions. In this example, UETP selects 296 as the default for simulated user loads, because 296 is the minimum result of the three expressions.

Deassign the logical name MODE before running UETP, unless you prefer to see the user load breakdown every time you run UETP.

19.6.5 Example Screen Display (Alpha Only)

The following example shows the output for UETINIT00.EXE on an Alpha system, with logical name MODE defined as DUMP:

$ DEFINE MODE DUMP $ RUN UETINIT00 Welcome to OpenVMS Alpha UETP Version 7.3 %UETP-I-ABORTC, UETINIT00 to abort this test, type ^C You are running on a AlphaServer 4100 5/533 4MB CPU. The system was booted from _$4$DKA300:[SYS0.]. Run "ALL" UETP phases or a "SUBSET" [ALL]? How many passes of UETP do you wish to run [1]? The default number of loads is the minimum result of 1) (MEM_FREE + MEM_MODIFY) / ( WS_SIZE ) ( 1807872 + 10496) / ( 16512) = 110 2) Free process slots = 488 3) Free page file pages / Typical use of blocks per process 650240 / 1000 = 650 How many simulated user loads do you want [110]? Do you want Long or Short report format [Long]? UETP starting at 1-MAR-2001 15:53:19.52 with parameters: DEVICE LOAD DECNET CLUSTER phases, 1 pass, 110 loads, long report.

This program does not initiate any phase; it displays the equation used by UETP to determine user load and the specific factors that are employed in the current run.

Respond to the questions by pressing the Return key. After you respond to the first prompt, the program displays the expressions that determine the default number of simultaneous processes. The following definitions apply:

• MEM_FREE represents memory in pagelets available to users.
• MEM_MODIFY represents memory pagelets on the modified page list.
• WS_SIZE represents working set size in pagelets.

UETINIT00 also displays the specific values represented by the expressions. In this example, UETP selects 110 as the default for simulated user loads, because 100 is the minimum result of the three expressions.

Deassign the logical name MODE before running UETP, unless you prefer to see the user load breakdown every time you run UETP.

19.6.6 Defining a Remote Node for UETP Ethernet Testing

Occasionally during the UETUNAS00 test, it is difficult to determine whether the problem reports concern the device under test or the remote device. The easiest way to ensure proper error reporting is to define a good turnaround. A good turnaround is a remote node that you know turns around Ethernet packets correctly and is up and waiting in the ready state.

You can make the UETUNAS00 test use a known good turnaround by performing the following actions. In the commands that follow, assume that the good device is on node BETA and that node BETA is already defined in the network database.

1. Find the address of the good Ethernet node by using the Network Control Program (NCP). To use NCP, the following conditions must apply:
   • DECnet for OpenVMS must be up and running on the system.
   • The account you are using must have TMPMBX and NETMBX privileges.
   
   Enter the following commands and press Return:

   $ RUN SYS$SYSTEM:NCP NCP> TELL BETA SHOW EXECUTOR STATUS

   
   If node BETA has not been defined in your network database, NCP displays an error message. In this event, specify another good node and retry the command. Otherwise, see your system or network manager.
   NCP displays information similar to the following messages:

   Node Volatile Status as of 22-JUN-2000 16:13:02 Executor node = 19.007 (BETA) State = on Physical address = AA-00-03-00-76-D3 Active links = 6 Delay = 1

2. Use the displayed physical address (in this case, AA00030076D3) to define the logical name TESTNIADR to point to the good turnaround. Note that you do not specify the hyphens (-).
   First, log in to the SYSTEST account. Then enter the following command:

   $ DEFINE/SYSTEM TESTNIADR AA00030076D3

3. Run UETP.
4. When UETP has completed, deassign the logical name TESTNIADR by entering the following command:

   $ DEASSIGN/SYSTEM TESTNIADR

UETP stores all information generated by all UETP tests and phases from its current run in one or more UETP.LOG files, and it stores the information from the previous run in one or more OLDUETP.LOG files. If a run of UETP involves multiple passes, there will be one UETP.LOG or one OLDUETP.LOG file for each pass.

At the beginning of a run, UETP deletes all OLDUETP.LOG files, and renames any UETP.LOG files to equivalent versions of OLDUETP.LOG. Then UETP creates a new UETP.LOG file and stores the information from the current pass in it. Subsequent passes of UETP create higher versions of UETP.LOG. Therefore, at the end of a run of UETP that involves multiple passes, there is one UETP.LOG file for each pass. In producing the files UETP.LOG and OLDUETP.LOG, UETP provides the output from the two most recent runs.

The cluster test creates a NETSERVER.LOG file in SYS$TEST for each pass on each system included in the run. If the test is unable to report errors (for example, if the connection to another node is lost), the NETSERVER.LOG file on that node contains the result of the test run on that node. UETP does not purge or delete NETSERVER.LOG files; therefore, you must delete them occasionally to recover disk space.

If a UETP run does not complete normally, SYS$TEST can contain other log files. Ordinarily these log files are concatenated and placed within UETP.LOG. You can use any log files that appear on the system disk for error checking, but you must delete these log files before you run any new tests. You can delete these log files yourself or rerun the entire UETP, which checks for old UETP.LOG files and deletes them.

19.7 Troubleshooting: Possible UETP Errors

This section is intended to help you identify and solve problems you can encounter running UETP. You should refer to this section if you need help understanding a system failure and isolating its cause. This section is not intended as a repair manual and is not expected to diagnose any flaws in your system. It should, however, help you to interpret and act upon the information in the error messages.

If you are unable to correct an error after following the steps in this section, you should contact a Compaq support representative. Any information you can supply about the measures you have taken to isolate the problem will help your a Compaq support representative diagnose the problem.

19.7.1 Summary of Common Failures

The following problems are the most common failures encountered while running UETP:

• Wrong quotas, privileges, or account
• UETINIT01 failure
• UETVECTOR failure (VAX computers only)
• Ethernet device allocated or in use by another application
• Insufficient disk space
• Incorrect cluster setup
• Problems during the load test
• DECnet for OpenVMS error
• Errors logged but not displayed
• No process control block (PCB) or swap slots
• System hangups
• Lack of default access for the file access listener (FAL) object
• Bugchecks and machine checks

The sections that follow describe these errors and offer the best course of action for dealing with each one.

19.7.2 Wrong Quotas, Privileges, or Account

If your assigned quotas or privileges do not match standard quotas and privileges for the SYSTEST account, UETP displays the following error message:

********************** * UETINIT00 * * Error count = 1 * ********************** -UETP-W-TEXT, The following: OPER privilege, BIOLM quota, ENQLM quota, FILLM quota, are nonstandard for the SYSTEST account and may result in UETP errors.

This message informs you that the OPER privilege and the BIOLM, ENQLM, and FILLM quotas either are not assigned correctly or are not assigned at all.

Solution

To correct the problem, use the following procedure:

1. Display all privileges and quotas in effect for the SYSTEST account using the Authorize utility (AUTHORIZE) as follows:

   $ SET DEFAULT SYS$SYSTEM $ RUN SYS$SYSTEM:AUTHORIZE UAF> SHOW SYSTEST Username: SYSTEST Owner: SYSTEST-UETP Account: SYSTEST UIC: [1,7] ([SYSTEST]) CLI: DCL Tables: DCLTABLES Default: SYS$SYSROOT:[SYSTEST] LGICMD: LOGIN Login Flags: Primary days: Mon Tue Wed Thu Fri Sat Sun Secondary days: No access restrictions Expiration: (none) Pwdminimum: 8 Login Fails: 0 Pwdlifetime: 14 00:00 Pwdchange: 22-JUN-2000 10:12 Last Login: (none) (interactive), (none) (non-interactive) Maxjobs: 0 Fillm: 100 Bytlm: 65536 Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 12 JTquota: 1024 Prclm: 12 DIOlm: 55 WSdef: 256 Prio: 4 ASTlm: 100 WSquo: 512 Queprio: 0 TQElm: 20 WSextent: 2048 CPU: (none) Enqlm: 300 Pgflquo: 20480 Authorized Privileges: CMKRNL CMEXEC SYSNAM GRPNAM DETACH DIAGNOSE LOG_IO GROUP PRMCEB PRMMBX SETPRV TMPMBX NETMBX VOLPRO PHY_IO SYSPRV Default Privileges: CMKRNL CMEXEC SYSNAM GRPNAM DETACH DIAGNOSE LOG_IO GROUP PRMCEB PRMMBX SETPRV TMPMBX NETMBX VOLPRO PHY_IO SYSPRV UAF> SHOW SYSTEST_CLIG . . . UAF> EXIT

2. Make sure the default privileges and quotas assigned to the account match the following list:
   Privileges

   CMKRNL	CMEXEC	NETMBX	DIAGNOSE
   DETACH	PRMCEB	PRMMBX	PHY_IO
   GRPNAM	TMPMBX	VOLPRO	LOG_IO
   SYSNAM	SYSPRV	SETPRV	GROUP

   
   Quotas

   BIOLM: 18	PRCLM: 12
   DIOLM: 55	ASTLM: 100
   FILLM: 100	BYTLM: 65536
   TQELM: 20	CPU: no limit
   ENQLM: 300	PGFLQUOTA: 20480
   WSDEFAULT: 256	WSQUOTA: 512
   WSEXTENT: 2048

3. If any privileges or quotas are incorrect, run AUTHORIZE to correct them.

If you are logged in to the wrong account, the following error message asks you to log in to the SYSTEST account:

$ @UETP ********************** * UETINIT00 * * Error count = 1 * ********************** -UETP-E-ABORT, UETINIT00 aborted at 22-JUN-2000 14:24:10.13 -UETP-E-TEXT, You are logged in to the wrong account. Please log in to the SYSTEST account. $

You must run UETP from the SYSTEST account.

19.7.3 UETINIT01 Failure

UETINIT01 failures are related to peripheral devices; this type of error message can indicate any of the following problems:

• Device failure
• Device not supported or not mounted
• Device allocated to another user
• Device write locked
• Lost vacuum on a magnetic tape drive
• Drive off line

In some cases, the corrective action is specified explicitly in the error message. For example, you can receive a message from the operator communication manager (OPCOM) informing you of a problem and recommending a corrective measure:

%OPCOM, 22-JUN-2000 14:10:52.96, request 1, from user SYSTEST Please mount volume UETP in device _MTA0: %MOUNT-I-OPRQST, Please mount volume UETP in device _MTA0:

Other error messages can relate information in which the solution is specified implicitly:

%UETP-S-BEGIN, UETDISK00 beginning at 22-JUN-2000 13:34:46.03 ********************** * DISK_DRA * * Error count = 1 * ********************** -UETP-E-TEXT, RMS file error in file DRA0:DRA00.TST -RMS-E-DNR, device not ready or not mounted %UETP-S-ENDED, UETDISK00 ended at 22-JUN-2000 13:34:46.80

This message tells you that a disk drive is either not ready or not mounted. From this information, you know where to look for the cause of the failure (at the disk drive). If you cannot see the cause of the problem immediately, check the setup instructions in Section 19.3.

In other cases, the cause of a failure might not be obvious from the information in the message. The problem can be related to hardware rather than software. For example, the Ethernet adapter test may produce one of the following messages if UETP does not have exclusive access to the Ethernet adapter:

• Intermodule cable unplugged
• Self-test failure code 0000000

To run the self-test diagnostic on the Ethernet adapter successfully, UETP needs exclusive access to the adapter. As explained in Section 19.3.10, you must shut down DECnet and the LAT terminal server before running the UETP device test phase if you want to test the Ethernet adapter.

Solution

To determine where or when the failure occurs in the execution of UETP, use the following procedure:

• Run the device test individually. (See Section 19.4.1.) By doing this, you can determine if the failure can be re-created, and you can isolate the cause of the problem by reproducing it using the least amount of software possible.
  For example, if the failure occurs only when you run the entire device phase, and not when you run the affected device test individually, you can conclude the problem is related to device interaction. Conversely, if you can re-create the error by running the single device test, then you have proved that the error is not related to device interaction.
• Run the device test with different media. If your run of the single device test succeeded in reproducing the error, the magnetic tape or disk media could be defective. Running the same test with different media determines whether the original media caused the problem.
• Call a Compaq support representative. If you have tried all the previous steps without solving the problem, you should contact a Compaq support representative.

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-2000 07:37:00.59

Solution

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

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

19.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-2000 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-2000 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 19.2.2 and Section 19.3.3 for a further discussion of disk space.

19.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 19.3.16 and Section 19.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 19.3.16 for information about preparing for cluster testing.

	privacy and legal statement
6017PRO_081.HTML