Document revision date: 19 July 1999

To set up your node as a LAT service node and start the LAT protocol software on your system each time the system boots, add the SYSTARTUP_VMS.COM:

$ @SYS$STARTUP:LAT$STARTUP.COM

When the procedure executes this command, it invokes LAT$STARTUP.COM, which in turn invokes the LAT$CONFIG and LAT$SYSTARTUP command procedures. For more information, see Section 24.5.

5.2.7.13 Starting a DECnet Network

Before starting the network, you must register your DECnet license and configure your network. See Chapter 21 for information about setting up DECnet network.

If your system participates in a DECnet network, you might need to start the DECnet software each time your system boots:

• If you are running DECnet for OpenVMS on your system, edit SYSTARTUP_VMS.COM to delete the exclamation point (!) at the beginning of the following command line:

  $ @SYS$MANAGER:STARTNET.COM

• If you are running DECnet-Plus on your system, DECnet is started automatically each time you boot your system.

Each node that will execute DIBOL programs must contain a line in SYS$STARTUP:SYSTARTUP_VMS.COM that executes the command procedure SYS$STARTUP:DBLSTRTUP.COM. This command procedure starts the DIBOL Message Manager, used by DIBOL programs as an intermediary in passing messages.

Example

SYSTARTUP_VMS.COM should contain a line as follows:

$ @SYS$STARTUP:DBLSTRTUP.COM

5.2.7.15 Defining the Number of Interactive Users

By default, when the system starts up, it limits to 64 the number of interactive users allowed to log in.

To change the default value for the number of interactive users that you permit to log in to your system at one time, define the symbol STARTUP$INTERACTIVE_LOGINS to be the maximum number of users in SYSTARTUP_VMS.COM as follows:

STARTUP$INTERACTIVE_LOGINS == n

where n specifies the maximum number of interactive users that can log in at one time.

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 about LAT software, see Section 24.1.

Example

$ STARTUP$INTERACTIVE_LOGINS == 200

5.3 Modifying Login Command Procedures to Customize User Environments

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.

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

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. Refer to the OpenVMS User's Manual for sample LOGIN.COM procedures.

5.4 Customizing Startup Databases with SYSMAN

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:

• Display information in any startup database.
• Create a site-specific startup database.
• Add, modify, or remove elements in the layered product database or site-specific database. (Compaq recommends that you do not modify the OpenVMS startup database.)

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.

5.4.1 Understanding Startup Databases

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.

5.4.2 Understanding the Layered Product 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:

• Name of the component file to be run. The file type must be either .EXE or .COM.
• Phase in which the component file is to run. Each phase describes a minimum environment that exists at that point in the startup process, as follows:
  1. BASEENVIRON---Startup tasks execute here. These must be performed before the site-specific startup command procedure, SYSTARTUP_VMS.COM, executes.
  2. LPBEGIN---SYSTARTUP_VMS.COM, the site-specific startup command procedure, executes here, as do any other files that prepare an environment necessary for layered products.
  3. LPMAIN---The majority of layered products execute here. This phase is the default.
  4. LPBETA---Layered products that have a dependency on previously installed products execute here.
  5. END---Products that are dependent on layered products execute here.
  
  Each phase must meet the prerequisites of the following phase; therefore, the order of the phases is extremely important. Components that occur in a phase cannot have dependencies on components that are in the same phase or in subsequent phases. When installing layered products using SYSMAN, be sure that all requisite components occur in a previous phase.
• Mode (or method) by which the component file is to run. Choose one of the following modes:
  • DIRECT (the default, where the command procedure or image is executed immediately)
  • BATCH (valid only for command procedures)
  • SPAWN
• Node restrictions for the component. This is either the node or nodes on which the component file should be run, or the node or nodes on which the component file should not be run.
• Parameters passed to the component file for execution. You can pass up to eight parameters, using the following format:

  (P1:args,P2:args,...)

  
  You can omit the parentheses if you pass only a single parameter.

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

5.4.4 Showing the Name of the Target Startup Database

To display which database is the target database, enter the STARTUP SHOW DATABASE command.

Example

$ RUN SYS$SYSTEM:SYSMAN SYSMAN> STARTUP SHOW DATABASE

5.4.5 Showing the Contents of a Startup 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, refer to the OpenVMS System Management Utilities Reference Manual.

Example

$ RUN SYS$SYSTEM:SYSMAN SYSMAN> STARTUP SHOW FILE/FULL

5.4.6 Adding Startup Files to a Startup Database

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 about 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 about the valid qualifiers, refer to 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

5.4.7 Changing Information Associated with a Startup File

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

You can specify any of the following qualifiers to specify the information that is to be changed:

• /MODE
• /NAME=filespec
• /PARAMETER=(P1:arg1, P2:arg2,...)
• /PHASE

For information about the qualifiers for this command, refer to 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

5.4.8 Deleting a Record from a Startup Database

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

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

5.4.9 Preventing a Startup File from Executing

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

5.4.10 Allowing a Previously Disabled Startup File to Execute

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

5.5 Registering Images that Have System Version Dependencies

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.

	privacy and legal statement
6017PRO_014.HTML