skip book previous and next navigation links
go up to top of book: HP OpenVMS System Manager's Manual, Volume 2:... HP OpenVMS System Manager's Manual, Volume 2:...
go to beginning of chapter: Testing the System with UETP Testing the System with UETP
go to previous page: Stopping a UETP Operation Stopping a UETP Operation
go to next page: Troubleshooting: Possible UETP ErrorsTroubleshooting: Possible UETP Errors
end of book navigation links

Troubleshooting: An Overview  



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

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:

Interpreting UETP Output  

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 Log Files.) 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:

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:

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 1 or to the manual that describes the individual system component.

Displaying Information on Your Screen  

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

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 (or @UETP)
 
      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 that UETP uses 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:

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.

Example Screen Display (Alpha and I64)  

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 (or @UETP)
    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:

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.

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: 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

Log Files  

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.


Footnotes
1

This manual has been archived.

( Number takes you back )


go to previous page: Stopping a UETP Operation Stopping a UETP Operation
go to next page: Troubleshooting: Possible UETP ErrorsTroubleshooting: Possible UETP Errors