Document revision date: 19 July 1999

If you want to put extra stress on a device, you can run the device test in loop mode, which causes the test to run indefinitely. For example:

$ DEFINE MODE LOOP $ RUN UETDISK00 Controller designation?: DRA %UETP-I-TEXT, End of pass 1 with 980 iterations at 22-JUN-1998 16:18:51:03 ^C

You must use Ctrl/C to terminate the test run. If you use Ctrl/Y, UETP does not complete cleanup procedures.

17.8.2.5 Functions of Individual Device Tests

For each disk in the system, the disk test allocates two files into which it randomly writes blocks of data. The test then checks the data, reports any errors to SYS$OUTPUT, and deletes the disk files.

When you run the disk test phase in a cluster environment, the test accesses all disks that are mounted by the system being tested, and users of the disk being tested might encounter an insufficient disk space problem. You should warn users on remote nodes (who share disks with users on the local system) that UETP might be testing a disk they are using.

The magnetic tape test exercises all the magnetic tape drives in the system. The test creates a large file on each mounted magnetic tape, into which it writes multiple sequential records of varying sizes. After writing the records, the test rewinds the magnetic tape, validates the written records, and reinitializes the magnetic tape.

The terminal and line printer test generates several pages or screens of output, in which each page or screen contains a header line and a test pattern of ASCII characters. A header line contains the test name, the device name, the date, and the time.

For the laboratory peripheral accelerator (LPA11--K), the test image determines the configuration on the LPA11--K's I/O bus. The image loads all types of microcode to the LPA11--K and reads or writes data for each device on the LPA11--K I/O bus.

The communications device tests fill the transmit message buffer with random data; then, using loopback mode, the tests transmit and receive the message several times. To check that the looped-back data is correct, an AST routine is associated with a $QIO read to compare the received message against the transmitted message. The procedure is repeated using messages of different lengths.

The interface device tests put the devices they are testing in maintenance mode, write random data, and then verify the data.

The Ethernet adapter test does self-test diagnostics on the device. It also does read and write tasks with test data that uses various adapter modes (such as internal loopback and external loopback).

The vector processor device test performs simple vector-scalar and vector-vector arithmetic operations and compares the results with expected values. The test also uses vector-related system service extensions and forces the system to generate arithmetic and memory management exceptions.

Table 17-1 lists the device test images and the devices to be tested on VAX systems.

Table 17-1 Device Tests (VAX Only)

Test Image Name	Devices Tested
UETDISK00.EXE	Disks
UETTAPE00.EXE	Magnetic tape drives and tape cartridge drives
UETTTYS00.EXE	Terminals and line printers
UETLPAK00.EXE	LPA11--K
UETCOMS00.EXE	DMC11, DMR11
UETDMPF00.EXE	DMF32, DMP11
UETDR1W00.EXE	DR11--W
UETDR7800.EXE	DR780, DR750
UETCDRO00.EXE	RRD40, RRD42, RRD50
UETUNAS00.EXE	Ethernet Adapters
UETVECTOR.EXE	Vector Processor, VVIEF

Table 17-2 lists the device test images and the devices to be tested on Alpha systems.

Table 17-2 Device Tests (Alpha Only)

Test Image Name	Devices Tested
UETDISK00.EXE	Disks
UETTAPE00.EXE	Magnetic tape drives and tape cartridge drives
UETTTYS00.EXE	Terminals and line printers
UETCDRO00.EXE	RRD42
UETUNAS00.EXE	Ethernet adapters

17.8.3 System Load Test Phase

The purpose of the system load test is to simulate a number of terminal users who are demanding system resources simultaneously. The system load tests, directed by the file UETLOAD00.DAT, create a number of detached processes that execute various command procedures. Each process simulates a user logged in at a terminal; the commands within each procedure are the same types of commands that a user enters from a terminal. The load test creates the detached processes in quick succession, and the processes generally execute their command procedures simultaneously. The effect on the system is analogous to an equal number of users concurrently issuing commands from terminals. In this way, the load test creates an environment that is similar to normal system use.

The load test uses the logical name LOADS to determine the number of detached processes to create. When you initiate the UETP command procedure, it prompts for the number of users to be simulated (see Section 17.4.3) and consequently the number of detached processes to be created. Your response, which depends on the amount of memory and the swapping and paging space in your system, defines the group logical name LOADS.

The UETP master command procedure deassigns all group logical names assigned by its tests as part of the termination phase. The group logical name LOADS remains assigned only if the UETP package does not complete normally.

The command procedures executed by the load test can generate a large amount of output, depending on the number of detached processes created. For each detached process (or user), the test creates a version of an output file called UETLOnnnn.LOG (nnnn represents a string of numeric characters). The console displays only status information as the load test progresses.

Whether the load test runs as part of the entire UETP or as an individual phase, UETP combines the UETLOnnnn.LOG files, writes the output to the file UETP.LOG, and deletes the individual output files.

You can run the system load test as a single phase by selecting LOAD from the choices offered in the startup dialog. (See Section 17.4.1.)

17.8.4 DECnet for OpenVMS Test Phase

If DECnet for OpenVMS software is included in your OpenVMS system, a run of the entire UETP automatically tests DECnet hardware and software. Because communications devices are allocated to DECnet and the DECnet devices cannot be tested by the UETP device test, UETP will not test the Ethernet adapter if DECnet for OpenVMS or another application has allocated the device. The DECnet node and circuit counters are zeroed at the beginning of the DECnet test to allow for failure monitoring during the run.

As with other UETP phases, you can run the DECnet for OpenVMS phase individually by following the procedure described in Section 17.4.1.

17.8.4.1 Environment

The DECnet for OpenVMS test will work successfully on OpenVMS systems connected to all DECnet supported node types, including routing and nonrouting nodes and several different types of operating systems (such as RSTS, RSX, TOPS, and RT). To copy files between systems, the remote systems must have some type of default access. The DECnet phase tests the following nodes and circuits:

• The node on which UETP is running.
• All circuits in sequence, unless you have defined the logical name UETP$NODE_ADDRESS to be the remote node that you want to run the test on. If you have defined a remote node, the DECnet phase tests only one circuit.
• All adjacent or first-hop nodes and all circuits in parallel.

No limit exists on the number of communication lines supported by the tests. A test on one adjacent node should last no more than two minutes at normal communications transfer rates.

UETP (under the control of UETPHAS00.EXE) reads the file UETDNET00.DAT and completes the following steps during the DECnet for OpenVMS phase:

1. Executes a set of Network Control Program (NCP) LOOP EXECUTOR commands to test the node on which UETP is running.
2. Uses NCP to execute the command SHOW ACTIVE CIRCUITS. The results are placed in UETININET.TMP, from which UETP creates the data file UETININET.DAT. The UETININET.TMP file contains the following information for any circuit in the ON state but not in transition:
   • Circuit name
   • Node address
   • Node name (if one exists)
   
   The UETININET.TMP file is used throughout the DECnet phase to determine which devices to test.
3. Uses the UETININET.TMP file to create an NCP command procedure for each testable circuit. Each command procedure contains a set of NCP commands to zero the circuit and node counters and to test the circuit and adjacent node by copying files back and forth.

   Note If you do not want the counters zeroed, do not test the DECnet for OpenVMS software.

4. Executes the command procedures from Step 3 in parallel to simulate a heavy user load. The simulated user load is the lesser of the following values:
   • The number of testable circuits, multiplied by two
   • The maximum number of user-detached processes that can be created on the system before it runs out of resources (determined by UETINIT00)
5. Executes a program, UETNETS00.EXE, that uses the UETININET.DAT file to check the circuit and node counters for each testable circuit. If a counter indicates possible degradation (by being nonzero), its name and value are reported to the console. All counters are reported in the log file, but only the counters that indicate degradation are reported to the console. An example of UETNETS00 output follows.

   %UETP-S-BEGIN, UETNETS00 beginning at 22-JUN-1998 13:45:33.18 %UETP-W-TEXT, Circuit DMC-0 to (NODENAME1) OK. %UETP-I-TEXT, Node (NODENAME2) over DMC-1 response timeouts = 1. %UETP-I-TEXT, Circuit DMC-1 to (NODENAME2) local buffer errors = 34. %UETP-I-TEXT, Node (NODENAME3) over DMP-0 response timeouts = 3. %UETP-S-ENDED, UETNETS00 ended at 22-JUN-1998 13:45:36.34

   
   Because degradation is not necessarily an error, the test's success is determined by you, not by the system. The following counters indicate possible degradation:
   For Circuits

   • Arriving congestion loss
   • Corruption loss
   • Transit congestion loss
   • Line down
   • Initialization failure
   • Data errors inbound
   • Data errors outbound
   • Remote reply timeouts
   • Local reply timeouts
   • Remote buffer errors
   • Local buffer errors
   • Selection timeouts
   • Remote process errors
   • Local process errors
   • Locally initiated resets
   • Network initiated resets
   
   For Nodes
   • Response timeouts
   • Received connect resource errors
   • Node unreachable packet loss
   • Node out of range packet loss
   • Oversized packet loss
   • Packet format error
   • Partial routing update loss
   • Verification reject

The cluster-integration test phase consists of a single program and a command file that depend heavily on DECnet for OpenVMS software. This phase uses DECnet for OpenVMS software to create SYSTEST_CLIG processes on each OpenVMS node in the cluster and to communicate with each node. SYSTEST_CLIG is an account that is parallel to SYSTEST, but limited so that it can only be used as part of the cluster-integration test. The following restrictions on the SYSTEST_CLIG account are necessary for a correct run of the cluster test phase:

• The account must be enabled and the password must be null. For more information, see Section 17.3.16.
• The UIC must be the same as that of the SYSTEST account.
• The account must have the same privileges and quotas as the SYSTEST account. For more information, see Section 17.7.2.
• The account can allow login only through DECnet for OpenVMS software.
• The account must be locked into running UETCLIG00.COM when it logs in.

These items are necessary to ensure the security and privacy of your system. If the test cannot create a SYSTEST_CLIG process on an OpenVMS node, it gives the reason for the failure and ignores that node for the lock tests and for sharing access during the file test. Also, the test does not copy log files from any node on which it cannot create the SYSTEST_CLIG process. If a communication problem occurs with a SYSTEST_CLIG process after the process has been created, the test excludes the process from further lock and file sharing tests. At the end of the cluster-integration test, an attempt is made to report any errors seen by that node.

UETCLIG00.EXE has two threads of execution: the primary and the secondary. The first, or primary thread, checks the cluster configuration (OpenVMS nodes, HSC nodes, and the attached disks that are available to the node running the test). For selected OpenVMS nodes, the primary thread attempts to start up a SYSTEST_CLIG process through DECnet software. If the primary thread was able to start a SYSTEST_CLIG process on a node, the node runs the command file UETCLIG00.COM, which starts up UETCLIG00.EXE and runs the secondary execution thread.

The process running the primary thread checks to see that it can communicate with the processes running the secondary threads. It then instructs them to take out locks so that a deadlock situation is created.

The primary thread tries to create a file on some disk on selected OpenVMS and HSC nodes in the cluster. It writes a block, reads it back, and verifies it. Next, it selects one OpenVMS node at random and asks that node to read the block and verify it. The primary thread then extends the file by writing another block and has the secondary thread read and verify the second block. The file is deleted.

The secondary processes exit. They copy the contents of their SYS$ERROR files to the primary process, so that the UETP log file and console report show all problems in a central place. DECnet for OpenVMS software automatically creates a NETSERVER.LOG in SYS$TEST as the test is run, so that if necessary, you can read that file later from the node in question.

During the test run, the primary process uses the system service SYS$BRKTHRU to announce the beginning and ending of the test to each OpenVMS node's console terminal.

You can define the group logical name MODE to the equivalence string DUMP to trace most events as they occur. Note that the logical name definitions apply only to the node on which they were defined. You must define MODE on each node in the cluster on which you want to trace events.

This chapter discusses setting up and maintaining system log files, maintaining error log files, and using system management utilities to monitor the system.

This chapter describes the following tasks:

Task	Section
Using the Error Formatter (ERRFMT)	Section 18.3
Using ERROR LOG to produce reports	Section 18.4
Using DECevent to report system events	Section 18.5
Setting up, maintaining, and printing the operator log file	Section 18.6
Using security auditing	Section 18.7
Using the Monitor utility to monitor system performance	Section 18.8

This chapter explains the following concepts:

Concept	Section
System log files	Section 18.1
Error logging	Section 18.2
Error Log utility (ERROR LOG)	Section 18.4.1
DECevent Event Management utility	Section 18.5.1
Operator log file	Section 18.6.1
OPCOM messages	Section 18.6.2
Security auditing	Section 18.7.1
Monitor utility (MONITOR)	Section 18.8.1

18.1 Understanding System Log Files

In maintaining your system, collect and review information about system events. The operating system provides several log files that record information about the use of system resources, error conditions, and other system events. Table 18-1 briefly describes each file and provides references to sections that discuss the files in more detail.

Table 18-1 System Log Files

Log File	Description	For More Information
Error log file	The system automatically records device and CPU error messages in this file.	Section 18.2
Operator log file	The operator communication manager (OPCOM) records system events in this file.	Chapter 2 and Section 18.6
Accounting file	The accounting file tracks the use of system resources.	Chapter 19
Security audit log file	The audit server process preallocates disk space to and writes security-relevant system events to this file.	Section 18.7

18.2 Understanding Error Logging

The error logging facility automatically writes error messages to the latest version of the error log file, SYS$ERRORLOG:ERRLOG.SYS. Error log reports are primarily intended for use by Compaq support representatives to identify hardware problems. System managers often find error log reports useful in identifying recurrent system failures that require outside attention.

Starting with OpenVMS Version 7.2, DECevent Version 2.9 or later is required for analyzing error log files. DECevent Version 2.9 provides a separate utility, the Binary Error Log Translation utility, in the DECevent kit. This utility converts the new Common Event Header (CEH) binary error log file into a binary error log file whose header format and structure can be read by earlier versions of DECevent and by the older Error Log utility.

For more information about the Binary Error Log Translation utility, refer to its documentation, which is included in the DECevent kit shipped with the OpenVMS kit.

Parts of the Error Logging Facility

The error logging facility consists of the parts shown in Table 18-2.

Table 18-2 Parts of the Error Logging Facility

Part	Description
Executive routines	Detect errors and events, and write relevant information into error log buffers in memory.
Error Formatter (ERRFMT)	The ERRFMT process, which starts when the system is booted, periodically empties error log buffers, transforms the descriptions of errors into standard formats, and stores formatted information in an error log file on the system disk. (See Section 18.3.2.) The Error Formatter allows you to send mail to the SYSTEM account or another user if the ERRFMT process encounters a fatal error and deletes itself. (See Section 18.3.3.)
Error Log utility (ERROR LOG)	Invokes the Error Log Report Formatter (ERF), which selectively reports the contents of an error log file. You invoke ERROR LOG by entering the DCL command ANALYZE/ERROR_LOG. (See Section 18.4.2.)
DECevent	Selectively reports the contents of an event log file; you invoke DECevent by entering the DCL command DIAGNOSE. (See Section 18.5.) DECevent Version 2.9 and higher includes the Binary Error Log Translation utility.

The executive routines and the Error Formatter (ERRFMT) process operate continuously without user intervention. The routines fill the error log buffers in memory with raw data on every detected error and event. When one of the available buffers becomes full, or when a time allotment expires, ERRFMT automatically writes the buffers to SYS$ERRORLOG:ERRLOG.SYS.

Sometimes a burst of errors can cause the buffer to fill up before ERRFMT can empty them. You can detect this condition by noting a skip in the error sequence number of the records reported in the error log reports. As soon as ERRFMT frees the buffer space, the executive routines resume preserving error information in the buffers.

The ERRFMT process displays an error message on the system console terminal and stops itself if it encounters excessive errors while writing the error log file. Section 18.3.1 explains how to restart the ERRFMT process.

	privacy and legal statement
6017PRO_079.HTML