![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
The maximum number of interactive users influences the service rating that the LAT software assigns to a service node. The LAT software uses a ratio of current users to maximum users in calculating a rating. An artificially high user limit results in a high service rating, indicating---erroneously---that the service node is more able to provide services. For information on LAT software, see Section 24.1.
Example
$ STARTUP$INTERACTIVE_LOGINS == 200
In addition to modifying site-specific startup command procedures, you can add commands to login command procedures to perform operations each time a user logs in.
Note that although the examples in this section are for DCL (.COM) command procedures, you can substitute other file types to denote other interfaces such as POSIX.
| Command Procedure | Description |
|---|---|
| SYS$MANAGER:SYLOGIN.COM | A file to which you can add common commands to execute whenever any user logs in. If SYS$MANAGER:SYLOGIN.COM exists and the logical name SYS$SYLOGIN points to this file, SYLOGIN.COM automatically executes when any user logs in. |
| SYS$LOGIN:LOGIN.COM | A file to which you or users can add commands that are to be executed only when individual users log in to their accounts. If a file named LOGIN.COM exists in a user's SYS$LOGIN directory, it automatically executes when the user logs in. |
Caution
If you introduce an error in login procedures, you can accidentally lock yourself out of the system. Section 4.4.2 describes a boot procedure you can use in such an emergency.
SYLOGIN.COM Procedure
As system manager, you create and maintain SYLOGIN.COM. This file is supplied on your distribution kit as a template, and contains commands that you can modify and add to as the needs of your site dictate.
The template for SYSTARTUP_VMS.COM includes the following command line that assigns the logical name SYS$SYLOGIN to SYLOGIN.COM:
$ DEFINE/SYSTEM/EXEC/NOLOG SYS$SYLOGIN SYS$MANAGER:SYLOGIN.COM
Note
If SYLOGIN.COM exits with an error, the user's login command procedure is not executed. If this occurs while the user is logging in to a captive account, the process is terminated because the system environment might not have been set up properly.If you expect SYLOGIN.COM to cause an error, you must use either SET NOON or ON ERROR commands, and explicitly exit the command procedure with a successful status so that the user's login command procedure can be executed.
LOGIN.COM Procedures
Each user creates and maintains a personal copy of the login command procedure LOGIN.COM. This file must be in the top-level directory for the user's account. You might need to help users set up a personal copy of LOGIN.COM.
See Section 6.7.1 for a sample SYLOGIN command file and a sample LOGIN.COM procedure. See the OpenVMS User's Manual for sample LOGIN.COM procedures.
Startup databases contain information used to start up system software. For example, STARTUP.COM uses information in a startup database named STARTUP$STARTUP_VMS to start the OpenVMS operating system. It uses information in a startup database named STARTUP$STARTUP_LAYERED to start layered products. For more information about startup databases, see Section 5.4.1.
You can use the STARTUP command of the System Management utility (SYSMAN) to customize startup databases as follows:
The following sections describe these tasks.
Before performing these tasks, it helps to understand SYSMAN. For more information about SYSMAN, see Section 2.3.1. You should also understand startup databases, in particular, the layered product startup database. For information, see Section 5.4.1 and Section 5.4.2.
Three startup database files are provided with the operating system, in the location defined by the logical name SYS$STARTUP:
| File | Description |
|---|---|
| VMS$PHASES.DAT | Determines the order of the phases of startup in a sequential list. This file includes a series of four basic phases (INITIAL, CONFIGURE, DEVICE, and BASEENVIRON) needed to bring the operating system up to a basic working environment, followed by a series of phases for layered products. STARTUP.COM uses this list of phases for startup. Do not modify this file. |
| VMS$VMS.DAT |
Equivalent to the logical name STARTUP$STARTUP_VMS. This file contains
information about the files used to start the base operating system
environment during system startup.
Do not modify this file.
STARTUP$STARTUP_VMS is provided for your information only. Use SYSMAN to display information in this file. For more information, see Section 5.4.5. |
| VMS$LAYERED.DAT |
Equivalent to the logical name STARTUP$STARTUP_LAYERED. This file
contains information about files that start site-specific products and
layered products. The system uses the information in this file to start
layered products during system startup. Section 5.4.2 provides more
information about this file.
Use SYSMAN to modify this file so that it contains information about all the layered product startup files you want to execute on your system. |
If you have site-specific software that you want to manage separately from your layered products, you can use SYSMAN to create an additional startup database.
The layered product startup database file (referred to by the logical name STARTUP$STARTUP_LAYERED) lists the files and command procedures that start site-specific products and layered products. It contains the following characteristics of each startup file:
(P1:args,P2:args,...)
With SYSMAN, the current database is the one that will be the target for the SYSMAN commands.
You can display or modify STARTUP$STARTUP_LAYERED or database files that you create. You can display STARTUP$STARTUP_VMS, but you should not modify it.
By default, the layered product database is the current database. To perform commands on another database, specify it as the current database by entering the STARTUP SET DATABASE command in the following format:
STARTUP SET DATABASE database
where database specifies the name of the database.
Example
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> STARTUP SET DATABASE STARTUP$STARTUP_LOCAL %SYSMAN-I-NEWCOMPFIL, current component file is now STARTUP$STARTUP_LOCAL
To display which database is the target database, enter the STARTUP SHOW DATABASE command.
Example
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> STARTUP SHOW DATABASE
To display the contents of the current database, enter the STARTUP SHOW FILE command. You can specify various qualifiers for this command to control the amount of information displayed. For more information, see the OpenVMS System Management Utilities Reference Manual.
Example
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> STARTUP SHOW FILE/FULL
To add a file to the layered product startup database, use the STARTUP ADD command. The /MODE qualifier specifies the mode of execution for the file. The /PHASE qualifier specifies the phase within system startup when the file is to be executed. For information on the layered product startup phases, see Section 5.4.2.
Do not use this command to modify STARTUP$STARTUP_VMS; this command procedure starts the operating system. The STARTUP MODIFY command requires read and write access to the startup database.
When adding layered product startup files using SYSMAN, be sure that all requisite components occur in a previous phase.
Enter the STARTUP ADD command with appropriate qualifiers. For information on the valid qualifiers, see the SYSMAN section of the OpenVMS System Management Utilities Reference Manual.
Example
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> STARTUP SHOW DATABASE %SYSMAN-I-DATANAME, STARTUP database is STARTUP$STARTUP_LAYERED SYSMAN> STARTUP ADD FILE/MODE=DIRECT/PHASE=LPMAIN FOR$LPMAIN_043_STARTUP.COM
Once a file is included in the layered product startup database, you can modify the information associated with the file by entering the STARTUP MODIFY command. (The command requires read and write access to the startup database.)
Note
Do not use STARTUP MODIFY to modify STARTUP$STARTUP_VMS.
You can specify any of the following qualifiers to specify the information that is to be changed:
For information on the qualifiers for this command, see the OpenVMS System Management Utilities Reference Manual.
Example
$ RUN SYS$SYSTEM:SYSMAN SYSMAN> STARTUP ADD/MODE=DIRECT/PHASE=LPMAIN FOR$LPMAIN_043_STARTUP.COM SYSMAN> STARTUP SHOW FILE/NODE SYSMAN> STARTUP MODIFY FILE FOR$LPMAIN_043_STARTUP.COM/NODE=ZNODE
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.)
Note
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.
Example
$ 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.
Example
$ 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.
Example
$ 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.
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:
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.
Note
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:
- FILES_VOLUMES
- MEMORY_MANAGEMENT
- SECURITY
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.
Caution
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 filenamewhere:
| 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 dependenciesIn this message, n is the number of images examined and the number of images that have dependencies.
Example
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 Digital-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 Digital-supplied messages | Section 5.6.3 |
| Adding comments to Digital-supplied messages | Section 5.6.4 |
| Changing text in Digital-supplied messages | Section 5.6.5 |
| Adding messages to Digital-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, see the OpenVMS System Messages: Companion Guide for Help Message Users. Also see that manual for a description of the files that you must manipulate to customize the Help Message database.
Note
Currently, user-supplied comments or additions to Digital-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 Digital-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 Digital. 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.
How to Perform This Task
$ HELP/MESSAGE/SECTION_FILE=*
Note
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=disk:[directory]file-name.EXE
$ LIBRARY/LIST MSGHLP$MESSAGE_SECTIONS.OLB
$ LIBRARY/DELETE=NETWRKMSG SYS$LIBRARY:MSGHLP$MESSAGE_SECTIONS.OLB
6017P011.HTM OSSG Documentation 22-NOV-1996 14:21:31.99
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.