![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
A privileged shareable image is a shareable image with defined entry points that execute in inner (executive or kernel) mode. Inner-mode entry points in shareable images are referred to as user-written system services.
To create a privileged shareable image, you must:
Note
You cannot grant privileges to a shareable image using the /PRIVILEGED qualifier for the INSTALL commands ADD or CREATE. This qualifier works only for executable images.
For more information on creating privileged shareable images, see the OpenVMS Programming Concepts Manual.
When a process does one of the following, the image activator enters a restricted mode of operation similar to that entered when a privileged program is run:
In this mode of operation:
Note
The executable image that calls an execute-only shareable image must be installed with the /EXECUTE_ONLY qualifier, which enables the executable image to activate shareable images to which the process has execute but not read access.The /EXECUTE_ONLY qualifier has meaning only for executable images.
This restriction assures that shareable images running in a privileged context can be trusted to behave as expected.
When you use INSTALL commands, your file specifications must name existing executable or shareable images. OpenVMS RMS resolves each file specification using the following defaults:
You can specify a specific version of the file as the known version of the image with the CREATE or REPLACE command. Even if other versions of the file exist, the version that you specify will be the version that satisfies all known file lookups for the image.
Before performing this task, you should understand the following:
How to Perform This Task
$ SET PROCESS/PRIVILEGES=CMKRNL
$ INSTALL
CREATE file-spec [/qualifier...]
Specify one or more of the following qualifiers, depending on which
attributes you want to assign to the image:
Note
Installing the Install utility itself requires that a number of shareable images have been previously installed. If any of those required shareable images (such as SMG$SHR, LIBOTS, and so on) is unavailable, the execution of the Install utility fails. Since INSTALL will not work in this situation, you cannot simply install the missing images. To work around this problem, redefine the INSTALL command as follows:$ DEFINE INSTALL SYS$SYSTEM:INSTALL.EXE;0When you now enter the INSTALL command, the image activator does not check the known files list for INSTALL.EXE, and the INSTALL command will complete, allowing you to install the required shareable images.
Use the INSTALL command LIST to display information about known images.
The information displayed with the /FULL qualifier of the LIST command can help you determine if installing an image is worth the expense.
How to Perform This Task
$ INSTALL
LIST file-spec
INSTALL> LIST LOGINOUT
LIST/FULL file-spec
Example
The following example displays complete information about the installed image LOGINOUT.EXE, including the number of accesses, the number of concurrent accesses, and the number of global sections created:
$ INSTALL
INSTALL> LIST/FULL LOGINOUT
DISK$VMS551:<SYS2.SYSCOMMON.SYSEXE>.EXE
LOGINOUT;2 Open Hdr Shar Prv
Entry access count = 36366
Current / Maximum shared = 1 / 10
Global section count = 3
Privileges = CMKRNL SYSNAM LOG_IO ALTPRI TMPMBX SYSPRV
INSTALL>
If a shareable image is not located in SYS$SHARE, you must define a logical name for that image in order to run an executable image linked against it. For example, if the file specification for STATSHR is SYS$SHARE:STATSHR.EXE, no logical name is necessary. But if you put STATSHR in SYS$DEVICE:[TEST], you must define STATSHR as a logical name before running an executable image that calls it. The logical name must be the same one that was used as the input file specification for the shareable image when it was linked (this is the same name used in installation). For example:
$ DEFINE STATSHR SYS$SYSDEVICE:[TEST]STATSHR
By redefining the logical name of a shareable image, you can replace that shareable image with another without requiring the calling executable image to relink. For example, the following statement redefines the file name STATSHR. It becomes the logical name of the shareable image SYS$SYSDEVICE:[MAIN]STATSHR.EXE for executable images calling STATSHR.
$ DEFINE STATSHR SYS$SYSDEVICE:[MAIN]STATSHR
Note
Logical names defined in the process or group logical name table are ignored when you run a privileged executable image. Only logical names and table names defined in executive or kernel modes are used to find the image.
The INSTALL command REMOVE removes a known file entry for an image and deletes any global sections created when the image was installed. Note that a volume cannot be dismounted while any known file entries are associated with it. To dismount a volume, you must delete all known images associated with it. You must also wait for all processes using those images to exit. Use the DCL command SHOW DEVICES/FILES to determine the status of the files.
For more information on the INSTALL command DELETE, see the INSTALL section of the OpenVMS System Management Utilities Reference Manual.
This chapter explains how to use UETP (user environment test package) to test whether the OpenVMS operating system is installed correctly.
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 17.1.2 |
| Preparing to use UETP | Section 17.2 |
| Setting up the devices to be tested | Section 17.3 |
| Starting UETP | Section 17.4 |
| Stopping a UETP operation | Section 17.5 |
| Troubleshooting: identifying and solving problems | Section 17.7 |
This chapter explains the following concepts:
| Concept | Section |
|---|---|
| Understanding UETP | Section 17.1.1 |
| Troubleshooting (an overview) | Section 17.6 |
| UETP Tests and Phases | Section 17.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:
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 17.2.
Note
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 6.4.
Username: SYSTEST Password:
Caution
Because the SYSTEST and SYSTEST_CLIG accounts have privileges, unauthorized use of these accounts can compromise the security of your system.
Caution
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-1996 16:30:09.38 * * *****************************************************
Note
If you want to run UETP without using the default responses, refer to Section 17.4, which explains your options.
Note
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 on running the Error Log utility, refer to the OpenVMS System Management Utilities Reference Manual.
Obtain the SYSTEST password from your system manager. Log in to the SYSTEST account from the console terminal as follows:
Username: SYSTEST Password:
Note
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.
Note
The information contained in Section 17.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 17.3.3 discusses setting up scratch disks for testing.
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.
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 Multivendor Customer Services.
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.
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.
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.
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.
To set up tape cartridge drives you want to test, do the following:
$ 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:
-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 before running UETP:
$ DEFINE/GROUP UETP$INIT_TIMEOUT "0000 00:08:00.00"
This example defines the initialization timeout value to 8 minutes.
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.
To run UETP on an RV60 drive, set up the RV64 optical disk-storage system, by doing the following:
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.
Terminals and line printers must be turned on and on line to be tested by UETP. Check that line printers and hardcopy terminals have enough paper. The amount of paper required depends on the number of UETP passes that you plan to execute. Each pass requires two pages for each line printer and hardcopy terminal.
6017P053.HTM OSSG Documentation 22-NOV-1996 14:22:34.36
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.