HP OpenVMS Systems Documentation
OpenVMS System Manager's Manual
19.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 19.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.
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.
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:
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.
126.96.36.199 How the DECnet Phase Works
19.8.5 Cluster-Integration Test Phase
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.
|Using the Error Formatter (ERRFMT)||Section 20.3|
|Using ERROR LOG to produce reports||Section 20.4|
|Using DECevent to report system events||Section 20.5|
|Setting up, maintaining, and printing the operator log file||Section 20.6|
|Using security auditing||Section 20.7|
|Using the Monitor utility to monitor system performance||Section 20.8|
This chapter explains the following concepts:
|System log files||Section 20.1|
|Error logging||Section 20.2|
|Error Log utility (ERROR LOG)||Section 20.4.1|
|DECevent Event Management utility||Section 20.5.1|
|Operator log file||Section 20.6.1|
|OPCOM messages||Section 20.6.2|
|Security auditing||Section 20.7.1|
|Monitor utility (MONITOR)||Section 20.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 20-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 20.2|
|Operator log file||The operator communication manager (OPCOM) records system events in this file.||Chapter 2 and Section 20.6|
|Accounting file||The accounting file tracks the use of system resources.||Chapter 21|
|Security audit log file||The audit server process preallocates disk space to and writes security-relevant system events to this file.||Section 20.7|
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.
The error logging facility consists of the parts shown in Table 20-2.
|Executive routines||Detect errors and events, and write relevant information into error log buffers in memory.|
|Error Formatter (ERRFMT)||
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
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 20.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 20.4.2.)|
|DECevent||Selectively reports the contents of an event log file; you invoke DECevent by entering the DCL command DIAGNOSE. (See Section 20.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 20.3.1 explains how to restart the
20.3 Using the Error Formatter
The Error Formatter (ERRFMT) process is started automatically at boot time. The following sections explain how to perform these tasks:
|Restart the ERRFMT process, if necessary||Section 20.3.1|
|Maintain error log files||Section 20.3.2|
|Send mail if the ERRFMT process is deleted||Section 20.3.3|
$ @SYS$SYSTEM:STARTUP ERRFMT
If disk quotas are enabled on the system disk, ERRFMT starts only if UIC [1,4] has sufficient quotas.
Because the error log file, SYS$ERRORLOG:ERRLOG.SYS, is a shared file, ERRFMT can write new error log entries while the Error Log utility reads and reports on other entries in the same file.
ERRLOG.SYS increases in size and remains on the system disk until you explicitly rename or delete it. Therefore, devise a plan for regular maintenance of the error log file. One method is to rename ERRLOG.SYS on a daily basis. If you do this, the system creates a new error log file. You might, for example, rename the current copy of ERRLOG.SYS to ERRLOG.OLD every morning at 9:00. To free space on the system disk, you can then back up the renamed version of the error log file on a different volume and delete the file from the system disk.
Another method is to keep the error log file on a disk other than the system disk by defining the logical name SYS$ERRORLOG to be the device and directory where you want to keep error log files; for example:
$ DEFINE/SYSTEM/EXECUTIVE SYS$ERRORLOG DUA2:[ERRORLOG]
To define this logical name each time you start up the system, add the logical name definition to your SYLOGICALS.COM procedure. See Section 5.2.5 for details.
Be careful not to delete error log files inadvertently. You might also
want to adopt a file-naming convention that includes a beginning or
ending date for the data in the file name.
20.3.3 Using ERRFMT to Send Mail
You can define these logical names in one of two ways: