Document revision date: 15 July 2002 | |
Previous | Contents | Index |
SHOW MEMORY/CACHE indicates whether VIOC caching is on or off on a running system. (This is a lot easier than using SYSGEN.)
SYSGEN can be used to examine parameters before a system is booted. For example, you can check the system parameter VCC_FLAGS (on Alpha) or VBN_CACHE_S (on VAX) to see if virtual I/O caching is enabled by using SYSGEN, as shown in the following Alpha example:
$ RUN SYS$SYSTEM:SYSGEN SYSGEN> SHOW VCC_FLAGS |
A value of 0 indicates that caching is disabled; the value 1 indicates
caching is enabled.
18.6.7 Memory Allocation and VIOC
The memory allocated to caching is determined by the size of the free-page list. The size of the virtual I/O cache can grow if one of the following conditions is true:
The cache size is also limited by the following:
How is memory reclaimed from the cache? The swapper can reclaim memory
allocated to the virtual I/O cache by using first-level trimming. In
addition, a heuristic primitive shrinks the cache returning memory in
small increments.
18.6.8 Adjusting VIOC Size
The size of the virtual I/O cache is controlled by the system parameter VCC_MAXSIZE. The amount of memory specified by this parameter is statically allocated at system initialization and remains owned by the virtual I/O cache.
To increase or decrease the size of the cache, modify VCC_MAXSIZE and
reboot the system.
18.6.9 VIOC and OpenVMS Cluster Configurations
The cache works on all supported configurations from single-node systems to large mixed-interconnect OpenVMS Cluster systems. The virtual I/O cache is nodal; that is, the cache is local to each OpenVMS Cluster member. Any base system can support virtual I/O caching; an OpenVMS Cluster license is not required to use the caching feature.
If any member of an OpenVMS Cluster does not have caching enabled, then no caching can occur on any node in the OpenVMS Cluster (including the nodes that have caching enabled). This condition remains in effect until the node or nodes that have caching disabled either enable caching or leave the cluster. |
The lock manager controls cache coherency. The cache is flushed when a node leaves the OpenVMS Cluster. Files opened on two or more nodes with write access on one or more nodes are not cached.
This chapter explains how to use UETP (user environment test package)
to test whether the OpenVMS operating system is installed correctly.
19.1 Overview
This overview summarizes what UETP does and how you use it. The rest of the chapter provides detailed instructions for setting up your system for testing, running the tests, and troubleshooting errors.
Information Provided in This Chapter
This chapter describes the following tasks:
Task | Section |
---|---|
Running UETP (a summary) | Section 19.1.2 |
Preparing to use UETP | Section 19.2 |
Setting up the devices to be tested | Section 19.3 |
Starting UETP | Section 19.4 |
Stopping a UETP operation | Section 19.5 |
Troubleshooting: identifying and solving problems | Section 19.7 |
This chapter explains the following concepts:
Concept | Section |
---|---|
Understanding UETP | Section 19.1.1 |
Troubleshooting (an overview) | Section 19.6 |
UETP Tests and Phases | Section 19.8 |
UETP is a software package designed to test whether the OpenVMS operating system is installed correctly. UETP puts the system through a series of tests that simulate a typical user environment by making demands on the system that are similar to demands that can occur in everyday use.
UETP is not a diagnostic program; it does not attempt to test every feature exhaustively. When UETP runs to completion without encountering nonrecoverable errors, the system being tested is ready for use.
UETP exercises devices and functions that are common to all OpenVMS systems, with the exception of optional features such as high-level language compilers. The system components tested include the following ones:
This section summarizes the procedure for running all phases of UETP with default values. If you are familiar with the test package, refer to this section. If you want additional information, refer to Section 19.2.
If you are using UETP on an OpenVMS Alpha system, you must execute the CREATE_SPECIAL_ACCOUNTS.COM command procedure to create the SYSTEST and SYSTEST_CLIG accounts before you begin the following procedure. For complete information about the CREATE_SPECIAL_ACCOUNTS.COM command procedure, see Section 7.4. |
Username: SYSTEST Password: |
Because the SYSTEST and SYSTEST_CLIG accounts have privileges, unauthorized use of these accounts can compromise the security of your system. |
By design, UETP assumes and requests the exclusive use of system resources. If you ignore this restriction, UETP can interfere with applications that depend on these resources. |
$ @UETP |
Run "ALL" UETP phases or a "SUBSET" [ALL]? |
How many passes of UETP do you wish to run [1]? How many simulated user loads do you want [4]? Do you want Long or Short report format [Long]? |
***************************************************** * * END OF UETP PASS 1 AT 22-JUN-1998 16:30:09.38 * * ***************************************************** |
If you want to run UETP without using the default responses, refer to Section 19.4, which explains your options. |
After a run of UETP, you should run the Error Log utility to check for hardware problems that can occur during a run of UETP. For information about running the Error Log utility, refer to the OpenVMS System Management Utilities Reference Manual. |
19.2 Preparing to Use UETP
This section contains detailed instructions for running UETP, including:
Obtain the SYSTEST password from your system manager. Log in to the SYSTEST account from the console terminal as follows:
Username: SYSTEST Password: |
Because SYSTEST has privileges, unauthorized use of this account can compromise the security of your system. |
UETP will fail if you do not run the test from the SYSTEST account. Also, if you try to run UETP from a terminal other than the console terminal, the device test phase displays an error message stating that the terminal you are using is unavailable for testing. You can ignore this message.
After you log in to the SYSTEST account, enter the command SHOW USERS to make sure no user programs are running and no user volumes are mounted. UETP requires exclusive use of system resources. If you ignore this restriction, UETP can interfere with applications that depend on these resources.
The information contained in Section 19.7.2 can help you identify and solve problems, including wrong quotas, privileges, or accounts, that could occur when you are running UETP. Refer to this section before you run UETP. |
If you logged in successfully, your default directory is [SYSTEST] on the system disk. UETP uses this directory to hold all the files used by UETP command procedure (UETP.COM) and temporary files used by UETP during testing.
On a typical system, the DCL command SHOW LOGICAL displays the translation of the logical name SYS$TEST:
$ SHOW LOGICAL SYS$TEST "SYS$TEST" = "SYS$SYSROOT:[SYSTEST]" (LNM$SYSTEM_TABLE) |
To use UETP to test a particular disk, such as a scratch disk, create
either a [SYSTEST] directory or a [SYS0.SYSTEST] directory on that
disk. Section 19.3.3 discusses setting up scratch disks for testing.
19.3 Setting Up the Devices to Be Tested
After you log in, set up the devices on the system for UETP testing, as
described in the following sections. Note that your system might not
have all the devices described in this section.
19.3.1 Check Your Devices
Examine all devices that UETP will use to be sure that the following conditions exist:
Note that some communications devices discussed in this section must be
set up by a Compaq support representative.
19.3.2 System Disk Space Required
Before running UETP, be sure that the system disk has at least 1200 blocks available. Note that systems running more than 20 load test processes can require a minimum of 2000 available blocks. If you run multiple passes of UETP, log files will accumulate in the default directory and further reduce the amount of disk space available for subsequent passes.
If disk quotas are enabled on the system disk, disable them before you
run UETP.
19.3.3 How UETP Works on Disks
The disk test phase of UETP uses most of the available free space on each testable disk in the following manner:
By creating and extending fragmented files in this way, UETP exercises the disk. This allows the test to check for exceeded quotas or a full disk, and to adjust for the amount of available disk space.
As with other disks, shadow sets and volume sets can be tested with
UETP; the expectation is that the individual members will be listed as
untestable during UETINIDEV (initialization of UETP). UETINIDEV lists
errors when testing using a shadow set during the system disk
(UETDISK00) pass, however, the shadow set is listed as testable. When
testing using a volume set, errors will be noted against all but
relative volume number 1, and all but relative volume 1 will be listed
as untestable at the end of UETINIDEV.
19.3.4 Prepare Disk Drives
To prepare each disk drive in the system for UETP testing, use the following procedure:
$ INITIALIZE DUA1: TEST1 |
$ MOUNT/SYSTEM DUA1: TEST1 |
$ CREATE/DIRECTORY/OWNER_UIC=[1,7] DUA1:[SYSTEST] |
If the disk you have mounted contains a root directory structure, you
can create the [SYSTEST] directory in the [SYS0.] tree.
19.3.5 Magnetic Tape Drives
Set up magnetic tape drives that you want to test by performing the following steps:
$ INITIALIZE MUA1: UETP |
If you encounter a problem initializing the magnetic tape or if the
test has a problem accessing the magnetic tape, refer to the
description of the INITIALIZE command in the OpenVMS DCL Dictionary.
19.3.6 Tape Cartridge Drives
To set up tape cartridge drives you want to test, perform the following steps:
$ INITIALIZE MUA0: UETP |
If you encounter a problem initializing the tape cartridge, or if the test has a problem accessing the tape cartridge, refer to the description of the DCL INITIALIZE command in the OpenVMS DCL Dictionary.
During the initialization phase, UETP sets a time limit of 6 minutes for a TLZ04 unit to complete the UETTAPE00 test. If the device does not complete the UETTAPE00 test within the allotted time, UETP displays a message similar to the following one:
-UETP-E-TEXT, UETTAPE00.EXE testing controller MKA was stopped ($DELPRC) at 16:23:23.07 because the time out period (UETP$INIT_TIMEOUT) expired or because it seemed hung or because UETINIT01 was aborted. |
To increase the timeout value, enter a command similar to the following one before running UETP:
$ DEFINE/GROUP UETP$INIT_TIMEOUT "0000 00:08:00.00" |
This example defines the initialization timeout value to 8 minutes.
19.3.7 Compact Disc Drives
To run UETP on an RRD40 or RRD50 compact disc drive, you must first
load the test disc that you received with your compact disc drive unit.
19.3.8 Optical Disk Drives
To run UETP on an RV60 drive, set up the RV64 optical disk-storage system, perform the following steps:
UETP tests all the RV60s present in the RV64 simultaneously. Unlike the tape tests, UETP does not reinitialize the optical disks at the end of the test.
Previous | Next | Contents | Index |
privacy and legal statement | ||
6017PRO_082.HTML |