HP OpenVMS System Manager's Manual, Volume 2:... |
Testing the System with UETP |
|
|
| |
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 !%DWhen 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:
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.$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.$
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:
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.$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.
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.
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.$RUN SYS$SYSTEM:NCPNCP>TELL BETA SHOW EXECUTOR STATUS
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
$DEFINE/SYSTEM TESTNIADR AA00030076D3
$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.
1 This manual has been archived.
( Number takes you back )
|
|