These messages are followed by:
%COPY-E-OPENOUT, error opening 9999""::SVA019841.D1; as output -RMS-E-CRE, ACP file create failed -SYSTEM-F-INVLOGIN, login information invalid at remote node %COPY-W-NOTCOPIED, SYS$COMMON:[SYSTEST]UETP.COM;2 not copied %UETP-E-TEXT, Remote file test data error
You can ignore these messages.
When the system aborts its run, a bugcheck message appears at the console.
Solution
Call Multivendor Customer Services. Often a hardware problem causes bugchecks and machine checks; solving bugchecks or machine checks is not easy. However, saving the SYS$SYSTEM:SYSDUMP.DMP and ERRLOG.SYS files is important so they are available for examination. Knowing whether the failure can be re-created is also important; you can run UETP again to verify the failure.
This section explains, in detail, the organization of UETP and the individual components within the test package. You run UETP by starting a master command procedure containing commands to start each test phase. The procedure begins by prompting you for information needed by the various test phases. (See Section 17.4 for a detailed description of starting UETP.)
The master command procedure, UETP.COM, contains commands that initiate each test phase. UETP.COM also contains commands that do such tasks as defining logical names and manipulating files generated by the tests.
The UETP.COM procedure also issues commands to start the test controlling program UETPHAS00.EXE, which, in turn, controls each test phase. The test controller starts up multiple detached processes. It also reports their completion status and other information the processes report to it.
The sections that follow describe the various UETP test phases.
The following occurs during the initialization phase:
A summary of UETINIDEV.DAT always exists in UETP.LOG, and UETINIT01.EXE sends that summary to the console if you have requested the long report format.
The device test phase includes separate tests for each type of device, such as disk, magnetic tape, line printer, and terminal. This section explains the device test phase and presents instructions for testing a single device. If you want to run the entire device test phase individually, refer to Section 17.4.1.
The UETP device test phase starts an executable image, the phase controller UETPHAS00, which creates a detached process for every device controller to be tested. For example, if a system includes three terminal controllers, one line printer controller, and two disk controllers, the image creates six detached processes. In parallel, the detached processes execute images that test the various types of devices.
The initialization phase of UETP creates a file called UETINIDEV.DAT and a file called UETCONT00.DAT. UETINIDEV.DAT contains data on the controllers in the system supported by OpenVMS and their associated devices; UETCONT00.DAT associates a device test image with each testable controller.
UETPHAS00 uses the information in UETCONT00.DAT to find a device controller name to pass to each detached process that it creates. UETPHAS00 passes the controller name by writing it to a mailbox that is SYS$INPUT to individual tests. Each detached process uses that data to determine which controller to test. The test image then searches UETINIDEV.DAT for the device controller and for all testable units on that controller. The phase controller terminates when all devices on all controllers have completed testing.
Because UETCONT00.DAT is deleted automatically at the end of a UETP run, you cannot run the device phase unless you start UETP.COM; you can run only individual test images. UETINIDEV.DAT exists in SYS$TEST unless you delete it.
You must be logged in to the SYSTEST account to run the individual tests as described in this section. Also, a copy of UETINIDEV.DAT must exist. If a copy of the file is not present from a previous run (a run of the entire UETP or a run of the device test phase creates UETINIDEV.DAT), you can create it. Note that when you run a single test, no log file is created; the test sends all its output to your terminal.
If you do not want to test all the device types, you can test a specific controller by choosing a test image name from Table 17-1 (for VAX systems) or Table 17-2 (for Alpha systems) and executing it as in the following example:
$ RUN UETTTYS00 Controller designation?: TTB
UETP prompts you for the controller designation and the device code. Unless you are testing your own terminal, you must explicitly designate a controller name. If you are running the terminal test, you can press Return to test your terminal only.
If you plan to repeat the run several times, you might find it more convenient to define the logical name CTRLNAME as follows:
$ DEFINE CTRLNAME TTB $ RUN UETTTYS00
When you define the controller name in this way, the logical name CTRLNAME remains assigned after the test completes. To deassign this logical name, use the DCL command DEASSIGN as follows:
$ DEASSIGN CTRLNAME
The UETINIDEV.DAT file is an ASCII sequential file that you can type or edit if necessary. The contents of this file are shown in the following command sequence:
$ TYPE UETINIDEV.DAT DDB x ddd UCB y uuuuu nnnnnnnnn.nnn END OF UETINIDEV.DAT
The symbols in this example are defined as follows:
Symbol | Value |
---|---|
x | T, if testable units exist for this controller; N, if this controller is not to be tested |
y | T, if this unit is testable; N, if this unit is not testable |
ddd | Device controller name, for example DUA |
uuuuu | Device unit number, for example 25 |
nnnnnnnnn.nnn | UETP device test name for the unit, for example, UETDISK00.EXE |
UETINIDEV.DAT contains a DDB (device data block) line for each controller connected or visible to your system. After the DDB line is a UCB (unit control block) line for each unit connected to that controller. A device test can test a particular device only if both the DDB line and the UCB line indicate that the device is testable.
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-1996 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.
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.
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.
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 |
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.)
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.
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:
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.
Note
UETP assumes your system has default access for the FAL object, even though the network configuration command procedure NETCONFIG.COM does not provide access for the FAL object by default. When you install DECnet software with the defaults presented by NETCONFIG.COM, the UETP DECnet phase can produce error messages. You can ignore these error messages. See Section 17.7.13 for more information.
UETP (under the control of UETPHAS00.EXE) reads the file UETDNET00.DAT and completes the following steps during the DECnet for OpenVMS phase:
Note
If you do not want the counters zeroed, do not test the DECnet for OpenVMS software.
%UETP-S-BEGIN, UETNETS00 beginning at 22-JUN-1996 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-1996 13:45:36.34
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:
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 |
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.
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 |
The error logging facility automatically writes error messages to the latest version of the error log file, SYS$ERRORLOG:ERRLOG.SYS. You can use the Error Log utility (ERROR LOG) to report selectively on error log files. You can also use the DECevent Event Management utility to produce reports derived from system event entries.
6017P056.HTM OSSG Documentation 22-NOV-1996 14:22:39.01
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.