Document revision date: 15 July 2002
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

OpenVMS System Manager's Manual


Previous Contents Index

17.9.2.2.2 Expanding (Decompressing) Libraries

The default action for LIBDECOMP.COM is the expand function. You can explicitly specify EXPAND as the first parameter on your command line, but this is not necessary. Unless the first parameter is LIST or REDUCE, the expand function is used by default.

If the expand function is used, the remaining parameters specify which of the libraries to expand. You can specify ALL to expand all libraries known to the utility, or you can specify up to eight library names (seven names if EXPAND is specified). Wildcard characters are not permitted. The specified libraries must be known to the utility. (To expand any other libraries, you must use the LIBRARY command, as described in Section 17.9.3.) If you do not specify ALL or a list of libraries, LIBDECOMP.COM prompts you for the libraries to expand. You can specify any number of libraries in response to the prompt.

Note

Expanding or reducing all of the libraries known to LIBDECOMP.COM will generally take about five to ten minutes. However, depending on the specific hardware and software configuration of your system, and on other activity, this can take longer, up to half an hour or more in some cases.

The expand function produces a display similar to the one shown in the following OpenVMS Alpha example. After the header lines are displayed, there is a pause while LIBDECOMP.COM checks the status of each library.


                 OpenVMS Library Decompression Utility 
                   Candidate Libraries to be expanded 
   (Libraries not present and libraries already expanded are not listed) 
 
     1  ACLEDT.HLB           13  NCPHELP.HLB          25  VAXCRTLD.OLB 
     2  BKM$HELP.HLB         14  SDA.HLB              26  VAXCRTLDX.OLB 
     3  DBG$HELP.HLB         15  SHWCLHELP.HLB        27  VAXCRTLT.OLB 
     4  DBG$UIHELP.HLB       16  SYSGEN.HLB           28  VAXCRTLTX.OLB 
     5  EDTHELP.HLB          17  SYSMANHELP.HLB       29  VAXCRTLX.OLB 
     6  EVE$HELP.HLB         18  TPUHELP.HLB          30  ERFLIB.TLB 
     7  EVE$KEYHELP.HLB      19  UAFHELP.HLB          31  LIB_ADA_SUBSET.TLB 
     8  EXCHNGHLP.HLB        20  LANIDEF.MLB          32  NTA.TLB 
     9  HELPLIB.HLB          21  LIB.MLB              33  STARLETSD.TLB 
    10  LANCP$HELP.HLB       22  STARLET.MLB          34  SYS$LIB_C.TLB 
    11  LATCP$HELP.HLB       23  STARLET.OLB          35  SYS$STARLET_C.TLB 
    12  MAILHELP.HLB         24  VAXCRTL.OLB 
 
         36  VMS$VOLATILE_PRIVATE_INTERFACES.OLB 
         37  STARLET_RECENT_ADA_SUBSET.TLB 
 
          A  ALL libraries to be expanded 
          H  Display HELP information for LIBDECOMP 
          E  EXIT this procedure 

If you specified ALL, the following message is displayed, and the utility then expands all listed libraries.


"ALL" specified; all libraries will be processed 

If you did not specify ALL, you are prompted as follows:


* Enter a letter or the number(s) of libraries to be expanded 
  (Separate multiple numbers with a comma) 

Enter A, H, E, or one or more numbers to indicate which libraries to expand. There is no limit to how many numbers you can specify.

If you enter parameters to identify specific libraries to expand, LIBDECOMP.COM does not display the list as shown in the example; rather, it lists each library as it is processed.

Examples

17.9.2.2.3 Reducing (Compressing) Libraries

When you specify REDUCE as the first parameter in your command line, LIBDECOMP.COM reduces libraries that have been expanded.

You can specify ALL after REDUCE to reduce all of the libraries known to the utility, or you can specify a list of up to seven libraries. Wildcard characters are not permitted.

If you do not specify ALL or the name of at least one library, LIBDECOMP.COM prompts you for the libraries to reduce. There is no limit to the number of libraries you can list in response to the prompt.

The reduce function produces a display similar to that of the expand function except that it displays only the libraries eligible to be reduced.

Examples

17.9.2.3 Using LIBDECOMP.COM in Batch Mode

You can submit the Library Decompression utility to a batch queue by using the DCL command SUBMIT with the /PARAMETERS qualifier, as follows:

SUBMIT SYS$UPDATE:LIBDECOMP /PARAMETERS=(p1[,p2,...])

The batch procedure produces the same results as the interactive procedure, but with the batch job you must specify HELP, LIST, ALL, or at least one library name, because the batch job cannot prompt you for input.

You can specify up to eight parameters. If you specify more than one parameter, the parameters must be enclosed in parentheses and must be separated by commas.

Examples

17.9.3 Using the LIBRARY Command with the /DATA Qualifier

An alternative to using the Library Decompression utility to expand or reduce an individual library is to use the DCL command LIBRARY with the /DATA qualifier. With this method, you can specify only one library per LIBRARY command.

Unlike LIBDECOMP.COM, which acts on only about 40 selected libraries that ship in data-reduced format, the LIBRARY command can be used to expand or reduce almost any library file, provided the library type (the file extension) is known to the OpenVMS Librarian utility. System libraries that you should not compress include the following:

To expand a specified library, use the following command format:

LIBRARY library-name.ext /DATA=EXPAND

To reduce a specified library, use the following command format:

LIBRARY library-name.ext /DATA=REDUCE

You must always specify the library extension (.HLB, .MLB, .OLB, or .TLB).

If the specified library is not located on your current default device and directory, you must also specify the device and directory in the library specification. Most system libraries are in either SYS$HELP ([SYSHLP]) or SYS$LIBRARY ([SYSLIB]). For example:


$ LIBRARY [SYSHLP]HELPLIB.HLB /DATA=EXPAND 

For information about other qualifiers for the LIBRARY command, see online help for LIBRARY or refer to the OpenVMS Command Definition, Librarian, and Message Utilities Manual.

17.10 Using INSTALL to Install Known Images

The Install utility (INSTALL) stores information about images in memory. Use INSTALL for the following reasons:
Reason For More Information
To conserve memory use for images that are used concurrently Section 17.10.7
To improve system performance Section 17.10.5
++On Alpha systems, to improve performance by using images with shared address data Section 17.10.6
To make executable images that require enhanced privileges available for general use Section 17.10.8.1
To allow a nonprivileged image to call the privileged functions of a shareable image Section 17.10.8.2
To mark a sharable image as trusted so it can be invoked by privileged executable images Section 17.10.9


++Alpha specific

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 Section 5.2.7.

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.

17.10.1 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:
Image Type Description
Executable An image linked with the /EXECUTABLE qualifier (or without the /SHAREABLE qualifier) of the Linker utility. For more information, refer to the OpenVMS Linker Utility Manual.
Shareable An image linked with the /SHAREABLE qualifier of the Linker utility. Shareable images are sometimes referred to as linkable images because they can be specified---implicitly or explicitly---as input files to the link of another file. A shareable image is not copied into the executable images that link with it. Thus, only one copy of the shareable image needs to be on disk, no matter how many executable images have linked with it. For more information, refer to the OpenVMS Linker Utility Manual.
System An image that does not run under the control of the operating system. It is intended for standalone operation only. The content and format of a system image differs from that of shareable images and executable images. For more information, refer to the OpenVMS Linker Utility Manual.

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.

17.10.2 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 Section 17.10.3).

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.

17.10.3 Understanding Attributes You Can Assign to Known Images

By specifying appropriate qualifiers to INSTALL commands, you can assign attributes to known images. Table 17-2 describes these attributes and the qualifiers that are used to assign them to known images.

Table 17-2 Attributes of 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
++ Resident On Alpha 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


++Alpha specific

17.10.4 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.

17.10.5 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.

17.10.6 Installing Images with Shared Address Data

Using shared address data on OpenVMS Alpha systems improves performance at the following times:

For details, refer to the INSTALL section of the OpenVMS System Management Utilities Reference Manual.

Related Terms

Explanations of terms related to shared address data follow.


Previous Next Contents Index

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement  
6017PRO_078.HTML