HP OpenVMS System Manager's Manual, Volume 2:... |
Performance Considerations |
|
|
| |
Using INSTALL to Install Known Images
| Reason | For More Information |
|---|---|
|
To conserve
memory use for images that are used concurrently
|
Installing Images to Conserve Physical Memory
|
|
To improve
system performance
|
Installing Images to Improve Image Activation Performance
|
|
On Alpha and
I64 systems, to improve performance by using images with shared address
data1
|
Installing Images with Shared Address Data
|
|
To make executable
images that require enhanced privileges available for general use
|
Privileged Executable Images
|
|
To allow a
nonprivileged image to call the privileged functions of a shareable
image
|
Privileged Shareable Images
|
|
To mark a shareable image
as trusted so it can be invoked by privileged executable images
|
Activating Images in a Privileged Context
|
The site-independent startup command procedure, STARTUP.COM, uses INSTALL to install certain system images when the system boots. You use INSTALL to install other selected images, according to the needs of your site.
Installed images must be reinstalled each time the system reboots. To do so, include INSTALL commands in the site-specific startup command procedure SYSTARTUP_VMS.COM, as explained in the HP OpenVMS System Manager's Manual, Volume 1: Essentials.
The Install utility (INSTALL) only installs images that are linked with the /NOTRACEBACK qualifier.
Note that INSTALL commands perform a different function than System Generation utility (SYSGEN) INSTALL commands.
The following sections explain installed images and how to use the Install utility.
Understanding Images
and Known Images ![]()
An image is a collection of procedures
and data bound together by the Linker utility. Executable images
can be executed (or run) in a process, either by a command line
interpreter (CLI) or the $CREPRC system service. Usually, executable
programs have the file type .EXE.
There are three types of images:
When you install an image with INSTALL, the image is assigned attributes and becomes known to the system. For this reason, an installed image is also called a known image.
The image activator processes search lists in two passes, in order to favor known images. On its first pass through the search list, the image activator looks up images as known files. If needed, on a second pass through the search list, the image activator looks up images on disk.
Understanding Known
File Entries ![]()
The system defines
known images in internal data structures called known
file entries. Each entry identifies the file name of
the installed image and the attributes with which it was installed
(for information about attributes of installed images, see
Understanding Attributes You Can Assign to Known Images).
Known file entries last only while the system is operating. If the system is shut down or fails for any reason, you must reinstall all known images after the system is rebooted.
Understanding Attributes
You Can Assign to Known Images ![]()
By specifying appropriate qualifiers to INSTALL commands,
you can assign attributes to known images.
Attributes of Known Images describes these attributes and the qualifiers that
are used to assign them to known images.
| Attribute | Description | Qualifier |
|---|---|---|
|
Header resident
|
The header of the image file (native images
only) remains permanently resident, saving one disk I/O operation
per file access. For images with single-block file headers, the
cost is less than 512 bytes of paged dynamic memory per file; for images
with multiblock headers, the cost varies according to the header
block count. Images installed header resident are implicitly installed permanently
open.
|
/[NO]HEADER_RESIDENT
|
|
Permanently open
|
The image file
remains open, so access to the image does not require a call to
the file system.
|
/OPEN
|
|
Privileged
|
Amplified privileges are temporarily assigned
to any process running the image, permitting the process to exceed
its user authorization file (UAF) privilege restrictions during
execution of the image. In this way, users with normal privileges can
run programs that require higher-than-normal privileges. This attribute
(and the /PRIVILEGED qualifier that creates it) applies only to
executable images.
|
/PRIVILEGED[=(priv-name[,...])]
|
|
Protected
|
When the image is activated, the address
space for the image is protected against modification by user-mode
code. This is critical for shareable code that runs in kernel or
executive mode.
|
/PROTECTED
|
|
Resident2
|
On Alpha and I64 systems, code or read-only
data for an image is made permanently resident in a system region
of memory. This improves performance by using a special page mapping
to reduce translation buffer (TB) miss rates. The resident attribute
applies to shareable or executable images that have been linked
with the qualifier /SECTION_BINDING=(CODE,DATA).
|
/RESIDENT
|
|
Shared
|
More than one user can access the read-only
and non-copy-on-reference read/write sections of the image concurrently,
so that only one copy of those sections needs to be in physical
memory. (Copy-on-reference sections always require a separate copy
for each process.) The image is implicitly declared permanently
open.
|
/SHARED
|
|
Writable
|
When a shareable non-copy-on-reference
writable section is removed from physical memory (for paging reasons
or because no processes are referencing it), it is written back
to the image file. Any updates made by processes mapped to the section,
therefore, are preserved (while the initial values are lost). The
image must also be declared shareable.
|
/WRITABLE
|
Determining Which Images
to Install ![]()
You can install images for the following reasons:
Because an installed file requires system resources, such as paged dynamic memory, install those files that most improve system performance and site requirements. The INSTALL command LIST provides information about installed images to help you evaluate the merits of installing images. For example, the LIST command calculates the number of times each image is accessed, and shows the number of concurrent accesses, so you can determine if the installation of the images is worth the overhead.
Installing Images to
Improve Image Activation Performance ![]()
You can improve
image activation performance by installing images that run frequently.
Image activation performance improves when programs are installed
because the operating system opens installed files by file ID rather
than by file name, thus eliminating costly directory operations.
Installing images as header resident further enhances activation performance because the system avoids the overhead of I/O operations to read the image header into memory.
To install an image as header resident, specify the /HEADER_RESIDENT qualifier when you install the image. This makes the header of the image file remain permanently resident, saving disk I/O. Specifying the /HEADER_RESIDENT qualifier implicitly makes the images permanently open.
Image headers are stored in paged dynamic memory. The size of the image headers varies.
Frequently accessed images, critical to a site's operations, can be installed as open images. To install an image as permanently open, specify the /OPEN qualifier when you install the image. The image file remains open, so access to the image does not require a call to the file system. The cost of keeping an image file permanently open is approximately 512 bytes of nonpaged dynamic memory per file.
Installing Images with
Shared Address Data ![]()
Using
shared address data on OpenVMS Alpha and I64 systems improves performance
at the following times:
For details, refer to the INSTALL section of the HP OpenVMS System Management Utilities Reference Manual.
Explanations of terms related to shared address data follow.
| Instructions (code) |
| Read-only data (constants) |
| Read/write data |
When you enter this command, the Install utility creates global sections for read-only image sections, allowing the sections to be shared by all the processes that run the image.$INSTALL ADD image-name /SHARED
System-Provided Images ![]()
Many images that are part of the OpenVMS software product
are installed as shared known
images with shared address data. This provides the performance benefit
without requiring the system manager to take any explicit action.
Application Images ![]()
As system manager, you might choose to install additional
images with shared address data.
In considering this option, you need to investigate application
dependencies on shareable images.
Installing Images to
Conserve Physical Memory ![]()
You can conserve physical
memory by installing images that usually run concurrently from several
processes. When an image is not installed, or is installed without
the shared attribute, each process running the image requires private
sections in memory. Shared images conserve physical memory because
only one copy of the code needs to be in memory at any time, and
many users can access the code concurrently. Use the /SHARED qualifier
to install images as shared images.
When you install an image with the shared attribute, permanent system global sections are created. Execution of non-copy-on-reference global sections requires only one copy per section to be in physical memory, no matter how many processes are running the image to which the sections belong.
The number of images you can install with the shared attribute is restricted by the GBLPAGES and GBLSECTIONS system parameters. For more information about these system parameters, refer to the HP OpenVMS System Management Utilities Reference Manual.
Installing Images to
Enhance Privileges of Images ![]()
There are two ways to allow an image to execute in an enhanced
privilege environment:
| Installing an image with enhanced privilege can compromise system security. Make sure the image does not enable a user to regain control with extra privileges enabled. |
Privileged Executable
Images ![]()
A nonprivileged
process can perform the privileged functions of an executable image
when the image is installed with privileges. Install executable
images with enhanced privileges by using the /PRIVILEGED qualifier;
amplified privileges are temporarily assigned to any process running
the image (executable images only), permitting the process to exceed
its user authorization file (UAF) privilege restrictions during execution
of the image. In this way, users with normal privileges can run
programs that require higher-than-normal privileges.
For an image installed with privileges to activate another image, such as a shareable image, either by having it linked to the privileged image or by using LIB$FIND_IMAGE_SYMBOL, the following conditions hold:
Privileged Shareable
Images ![]()
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:
| 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. |
Activating Images in
a Privileged Context ![]()
When a process performs
one of the following actions, the image activator enters a restricted
mode of operation similar to that entered when a privileged program
is run:
In this mode of operation:
| 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. |
Specifying File Names
in INSTALL ![]()
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.
Installing Images with
INSTALL ![]()
Before performing this task, you should understand the following
points:
$SET PROCESS/PRIVILEGES=CMKRNL
$INSTALL
| /EXECUTE_ONLY |
| /HEADER_RESIDENT |
| /OPEN |
| /PRIVILEGED |
| /PROTECTED |
| /RESIDENT (Alpha and I64 systems only) |
| /SHARED |
| /WRITABLE |
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: When 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. |
Displaying Known Images
with INSTALL ![]()
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
INSTALL>LIST LOGINOUT
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:
$INSTALLINSTALL>LIST/FULL LOGINOUTDISK$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>
Defining Logical Names
for Shareable Image Files ![]()
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:
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:[TEST]STATSHR
$DEFINE STATSHR SYS$SYSDEVICE:[MAIN]STATSHR
| 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. |
Removing Known Images ![]()
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 about the INSTALL command DELETE, refer to the INSTALL section of the HP OpenVMS System Management Utilities Reference Manual.
1 Alpha or I64 specific
2 Alpha and I64 specific
( Number takes you back )
|
|