Document revision date: 15 July 2002 | |
Previous | Contents | Index |
Deleting a record from a startup database prevents a product from starting up. To delete a record, use the STARTUP REMOVE FILE command. This command leaves the startup file intact, but the file is not used in system startup. (The command requires read and write access to the startup database.)
Do not use STARTUP REMOVE FILE to modify STARTUP$STARTUP_VMS. |
To delete a record from a startup database, enter a STARTUP REMOVE FILE command in the following format:
STARTUP REMOVE FILE filespec |
where filespec specifies the name of the startup file to be removed.
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> STARTUP SHOW FILE/FULL SYSMAN> STARTUP REMOVE FILE FOR$LPMAIN_043_STARTUP.COM SYSMAN> STARTUP SHOW FILE/FULL SYSMAN> EXIT |
To temporarily prevent a startup file from executing, enter the STARTUP DISABLE command. You can specify the /NODE qualifier to disable the startup file on certain nodes.
This command requires read and write access to the startup database. Do not use this command to modify STARTUP$STARTUP_VMS.
To delete a record from a startup database, enter the STARTUP DISABLE command as follows:
STARTUP DISABLE FILE filespec |
where filespec specifies the name of the startup file to be disabled.
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> STARTUP SHOW FILE SYSMAN> STARTUP DISABLE FILE FOR$LPMAIN_043_STARTUP.COM/NODE=ZURICH |
If you have disabled a startup file from executing, you can enable it again by using the STARTUP ENABLE command. You can specify the /NODE qualifier to enable the startup file on certain nodes.
This command requires read and write access to the startup database. Do not use this command to modify STARTUP$STARTUP_VMS.
To enable a previously disabled file, enter the STARTUP ENABLE FILE command in the following format:
STARTUP ENABLE FILE filespec |
where filespec specifies the name of the file to be enabled.
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> STARTUP ENABLE FILE FOR$LPMAIN_043_STARTUP.COM/NODE=ZURICH |
Applications that run on the OpenVMS operating system sometimes depend on the internal interfaces of a previous version of the operating system. For example, an application might call system routines, reference system data cells, or system data structures. New versions of the operating system might include changes that can break applications depending on those interfaces.
Registering an image records information about the image in a file called the image registry. The image activator, INSTALL, and SYSGEN do not check the versions of images that are recorded in the image registry. Image registry allows you to continue to run application images (including main images, shared libraries, and device drivers) that depend on the internal interfaces of a previous version of the operating system.
The Image Registry facility allows you to register different versions
of an image independently. It also allows you to deregister, analyze,
and show images in the image registry.
5.5.1 Understanding System Version Dependency and the Image Registry
Applications that depend on internal interfaces are bound to a particular version of the operating system when the application is linked. Version-dependent images reference both of the following version numbers:
When you attempt to run an image, the system checks to determine if the image requires a certain version of the operating system or of system components. If the version of the running system does not match the version requirements of the image, the image fails.
The system also checks version numbers when you attempt to install an image using the Install utility (INSTALL) or connect a device driver using the System Generation utility (SYSGEN).
When you upgrade your system to a new version of the operating system, an image might fail because the new version no longer matches the image's version requirements. However, an image might continue to be compatible with the new operating system version, even if it fails the version check.
In OpenVMS VAX Version 6.0, the major version number was not changed; only the version numbers for the following components were increased to reflect changes in these areas:
As a result, many version-dependent images built in VMS VAX Version 5.x systems (that is, images that do not reference FILES_VOLUMES, MEMORY_MANAGEMENT, or SECURITY) will run on OpenVMS Version 6.0 without registering the images. However, version-dependent images that do reference these components must be registered with the image registry, as explained in this section. In OpenVMS VAX Version 6.1, no version numbers were changed. However, images built on VMS VAX Version 5.x systems needed to be registered if they referenced FILES_VOLUMES, MEMORY_MANAGEMENT, or SECURITY. |
To continue running a compatible image, you can register the image using the Image Registry facility. You do not need to register images that are linked as part of the installation because they match the current operating system version. However, linking an image during installation does not ensure that system version dependencies do not exist. For information about changes in the current operating system version that might require you to recompile an image or change source code, see the release notes.
You must inspect and test an image carefully to avoid system crashes and data corruption. Registering an image does not necessarily make it work; registering only bypasses the version checks. |
To register an image in the image registry, run the command procedure SYS$UPDATE:REGISTER_PRIVILEGED_IMAGE.COM. Enter a command in the following format:
$ @SYS$UPDATE:REGISTER_PRIVILEGED_IMAGE keyword filename |
where:
keyword | Specifies one or more of the keywords described in Table 5-3, separated by commas. |
filename | Specifies the name and location of the image you want to register. The filename parameter accepts wildcard characters. |
Keyword | Action |
---|---|
ANALYZE | Displays version-dependent image names and their subsystem dependencies. |
REGISTER | Registers images on the local system. |
DEREGISTER | Deletes images from the registry on the local system. |
SHOW | Lists the registry content. To display the complete registry content, specify a wildcard (*) for the file name. |
CONFIRM | Confirms that each specified image be added to or deleted from the registry (used only with REGISTER and DEREGISTER). |
TRACE | Lists each image file for verification purposes (used only with REGISTER and DEREGISTER). |
HELP | Describes the supported keywords and provides examples. |
If the image does not have a version dependency, the following message is displayed:
REGISTER-I-SUMMARY n images examined, n have dependencies |
The following example adds the V6USRAPP image to the registry:
$ @SYS$UPDATE:REGISTER_PRIVILEGED_IMAGE REGISTER SYS$LIBRARY:V6USRAPP %REGISTER-I-ADDED added V6USRAPP to registry |
The Help Message utility (MSGHLP) allows users to quickly access online descriptions of system messages from the DCL prompt. Users with write access to Compaq-supplied .MSGHLP$DATA files can customize the Help Message database in more radical ways than general users can. The following sections describe how to perform the following customization tasks:
Task | For More Information |
---|---|
Accessing $STATUS values for uninstalled messages | Section 5.6.1 |
Creating system-level Help Message database search paths | Section 5.6.2 |
Deleting Compaq supplied messages | Section 5.6.3 |
Adding comments to Compaq-supplied messages | Section 5.6.4 |
Changing text in Compaq supplied messages | Section 5.6.5 |
Adding messages to Compaq supplied database files | Section 5.6.6 |
Before performing these tasks, you should be familiar with the Help Message utility. For a complete description of Help Message features, basic tasks, and the HELP/MESSAGE command and qualifiers, refer to the OpenVMS System Messages: Companion Guide for Help Message Users. Also refer to that manual for a description of the files that you must manipulate to customize the Help Message database.
Currently, user-supplied comments or additions to Compaq supplied .MSGHLP$DATA files are not preserved through the next upgrade. However, your own .MSGHLP$DATA files are not affected by future releases. You can reuse .MSGHLP files to insert your own messages into future Compaq supplied database files. Depending on the data format in future databases, you might also be able to reuse some .MSGHLP files to insert comments. |
Any messages that are not installed as part of the OpenVMS operating system cannot be equated with a value stored in $STATUS until they are recognized by the system. When the Help Message utility attempts to translate the value stored in $STATUS or a value specified with the /STATUS qualifier, the search can fail if the value does not equate to an installed message or a message that was linked into the Help Message utility when it was created by Compaq. You can make your system recognize such uninstalled messages. These messages include user-supplied messages, third-party messages, and messages from layered products and certain other OpenVMS facilities.
$ HELP/MESSAGE/SECTION_FILE=* |
This HELP/MESSAGE command produces results similar to, but entirely separate from those effected by the SET MESSAGE filespec command. The Help Message utility does not interact with the Message utility. If you want both utilities to translate the same set of message sections, you must separately code each utility to do so. It is perfectly acceptable to have each utility point to different message section files. |
HELP/MESSAGE/SECTION_FILE=file-name.EXE |
The default file specification is SYS$MESSAGE:.EXE.
$ LIBRARY/LIST MSGHLP$MESSAGE_SECTIONS.OLB |
$ LIBRARY/DELETE=NETWRKMSG SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.OLB |
The following example demonstrates this sequence of events:
Note that the output from the LIBRARY/LIST commands is omitted from the example.
$ HELP/MESSAGE/SECTION_FILE=* $ LIBRARY/LIST SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.OLB $ LIBRARY/DELETE=VVIEFMSG SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.OLB $ HELP/MESSAGE/SECTION_FILE=NEW_MSGS.EXE $ LIBRARY/LIST SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.OLB $ COPY MSGHLP$MESSAGE_SECTIONS.EXE SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.EXE |
Help Message database files need not reside on the system disk. You can create system logical names to define one or more Help Message search paths to access multiple .MSGHLP$DATA files in different locations.
When Help Message is installed, the OpenVMS messages database file is installed by default at SYS$COMMON:[SYSHLP]MSGHLP$LIBRARY.MSGHLP$DATA. However, this file can optionally be installed on or moved to another disk. The alternate location must be pointed to by logical name MSGHLP$LIBRARY. Use this command to define the logical name:
DEFINE/SYSTEM MSGHLP$LIBRARY disk:[directory]MSGHLP$LIBRARY |
By default, Help Message attempts to look up messages in the default location unless the logical name MSGHLP$LIBRARY is defined. If you do not use the default database location, include the logical name definition command in SYS$MANAGER:SYLOGICALS.COM so that the database is defined each time the system is booted.
If you move MSGHLP$LIBRARY.MSGHLP$DATA to a new location after installation, be sure to set the proper protections on the file and directory so that the database cannot be accidentally deleted or modified. The protections at installation are (RWE, RWE, RE, RE) for the directory and (RWE, RWE, RWE, RE) for the file. |
You and other system users can create additional .MSGHLP$DATA files, as described in the OpenVMS System Messages: Companion Guide for Help Message Users. None of the .MSGHLP$DATA files need reside on the system disk. You can add new files to a systemwide default database search path defined by MSGHLP$LIBRARY, or you can create specialized search paths to include different configurations of .MSGHLP$DATA files.
A search path definition can include individual file names or can point to one or more directories. If you specify a directory with no file name, Help Message searches all .MSGHLP$DATA files currently found in that directory. Pointing to a directory instead of individual files can minimize your bookkeeping when .MSGHLP$DATA files are added or removed.
To use system resources more efficiently, you can create different search paths for different user groups, depending on which .MSGHLP$DATA files they need to access. You can also set up different directories for different types of messages or for different user groups. For example, you could use three unique logical names to define three different search paths tailored to different user groups:
DEFINE/SYSTEM logical-name-1 file-a,file-b,file-c |
DEFINE/SYSTEM logical-name-2 file-a,directory-z |
DEFINE/SYSTEM logical-name-3 file-x,file-a,directory-y |
The first file you list in a search path is the default database for /INSERT and /DELETE operations that operate on that search path. By default, all other operations access all files in a search path. Specifying a directory first in a search path risks setting up a default moving target for /INSERT and /DELETE operations if files are added to or deleted from the directory. |
Users can select an alternate to the system default database by specifying the /LIBRARY qualifier in the HELP/MESSAGE command. Individual users can also create their own logical name search paths at the process level.
The following example defines a Help Message search path that accesses .MSGHLP$DATA database files in three locations: the Compaq supplied OpenVMS messages at USERS:[TOOLS], the user-supplied file USERS:[NEW_PROJ]OUR_MESSAGES.MSGHLP$DATA, and all .MSGHLP$DATA files in directory TEST:[TRY_ME].
$ DEFINE/SYSTEM MSGHLP$LIBRARY USERS:[TOOLS]MSGHLP$LIBRARY,- _$ USERS:[NEW_PROJ]OUR_MESSAGES.MSGHLP$DATA,TEST:[TRY_ME] |
Previous | Next | Contents | Index |
privacy and legal statement | ||
6017PRO_015.HTML |