Document revision date: 19 July 1999
[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

5.2.4.2 Suppressing Autoconfiguration of Devices

You might want to suppress autoconfiguration for various reasons, including the following ones:

You can define a symbol in SYCONFIG.COM to suppress autoconfiguration. For more information, see Section 7.4.3.

5.2.5 Modifying SYLOGICALS.COM to Define Systemwide Logical Names

A systemwide logical name applies to the entire system. It is defined in the system logical name table and can be used by any process in the system. A clusterwide system logical name applies to every node in the cluster at a system level. It is defined in the clusterwide system logical name table of every node and can be used by any process in the system.

In general, system managers edit the SYLOGICALS.COM command procedure to define site-specific logical names that take effect at system startup. However, this is not the appropriate command procedure for defining clusterwide logical names, which is, rather, SYSTARTUP_VMS.COM. Refer to "Preparing a Shared Environment" in OpenVMS Cluster Systems for more information.

As supplied by Compaq, SYLOGICALS.COM contains commands that assign systemwide logical names on a MicroVAX system that is not in an OpenVMS Cluster environment. If your system is not a standalone MicroVAX system, you can ignore the procedure at the beginning of the template file and add systemwide logical name assignments to the end of the file.

You can add commands to create your own site-specific systemwide logical names. In addition, if you want to change default definitions for the following system logical names, you can include the definitions in SYLOGICALS.COM. Table 5-2 lists some commonly defined logical names.

Table 5-2 Commonly Defined System Logical Names
Logical Name For More Information
++CLUE$DOCD_DEVICE Section 15.8
LMF$LICENSE OpenVMS License Management Utility Manual
MAIL$SYSTEM_FLAGS Section 5.7
NETNODE_REMOTE DECnet for OpenVMS Networking Manual
NETPROXY OpenVMS Guide to System Security
+NET$PROXY OpenVMS Guide to System Security
QMAN$MASTER Section 12.3
RIGHTSLIST OpenVMS Guide to System Security
SYS$ERRORLOG Section 18.4.1
SYS$MONITOR Section 18.8.9
SYSUAF OpenVMS Guide to System Security
VMSMAIL_PROFILE OpenVMS User's Manual


+VAX specific
++Alpha specific

Compaq recommends that you define logical names for system components (for example, public disks and directories) in executive mode, using the /EXECUTIVE_MODE qualifier with the ASSIGN or DEFINE command. This type of logical name, known as a trusted logical name, is available during system operations such as the activation of privileged mode images (LOGINOUT, Mail, and so on).

For detailed information about logical name assignments and the privilege modes (executive, kernel, supervisor, and user), refer to the OpenVMS User's Manual.

How to Perform This Task

  1. Invoke any editor to edit the file SYS$MANAGER:SYLOGICALS.COM.
  2. Add logical name definitions in the following format to the end of the file, immediately preceding the EXIT command:

    DEFINE/SYSTEM/EXECUTIVE/NOLOG logical-name equivalence-name 
    


    For example:


    DEFINE/SYSTEM/EXECUTIVE/NOLOG FINANCE_DISK DRAC$DRA2: 
    

    For more information about the DEFINE command, refer to the OpenVMS DCL Dictionary.

  3. Exit the editor to create a new version of the file. The highest version will automatically be invoked by STARTUP.COM each time the system boots.

Example


$ DEFINE/SYSTEM/EXECUTIVE/NOLOG FINANCE_DISK DRAC$DRA2: 
$ DEFINE/SYSTEM/EXECUTIVE/NOLOG SYSDSK SYS$SYSDEVICE: 

In this example, any user on the system (and any program running on the system) could use the name FINANCE_DISK (the logical name) in place of DRAC$DRA2: (the physical device name). Similarly, you can refer to the system disk (SYS$SYSDEVICE:) as SYSDSK.

5.2.6 Modifying SYSECURITY.COM to Set Up Security Auditing

SYSECURITY.COM runs prior to starting the security audit server process. You can add commands to this file to mount or define any disks that you want to hold security auditing log files or local security archive files. For more information about security auditing, see Section 18.7.

Ordinarily, the system turns on auditing in VMS$LPBEGIN just before SYSTARTUP_VMS.COM executes. However, you can change this behavior by redefining the logical name SYS$AUDIT_SERVER_INHIBIT.

To inhibit the automatic startup of auditing, edit the SYS$MANAGER:SYLOGICALS.COM command procedure to add the following line:


$ DEFINE/SYSTEM/EXECUTIVE SYS$AUDIT_SERVER_INHIBIT YES 

Then you can initiate auditing during another phase of system startup, perhaps at the end of SYSTARTUP_VMS.COM, by editing the command file to add the following line:


$ SET AUDIT/SERVER=INITIATE 

For information about editing SYSTARTUP_VMS.COM, see Section 5.2.7.

5.2.7 Modifying SYSTARTUP_VMS.COM to Perform General Operations

To perform any site-specific command not performed by another startup command procedure, you can add or modify commands in the general-purpose, site-specific startup command procedure, SYSTARTUP_VMS.COM.

Compaq recommends that you edit this procedure to modify or add commands that perform tasks such as the following ones:
Task For More Information
Mounting public disks Section 5.2.7.1
Setting the characteristics of terminals and printer devices Section 5.2.7.3
Starting queues and enabling autostart for queues Section 5.2.7.4
Installing known images Section 5.2.7.5
++Installing resident images Section 5.2.7.6
Setting up the OpenVMS InfoServer Client software Section 5.2.7.7
Running the System Dump Analyzer Section 5.2.7.8
Purging the operator's log file Section 5.2.7.9
Submitting batch jobs that are run at system startup time Section 5.2.7.10
Creating systemwide announcements Section 5.2.7.11
Starting up the LAT protocol software Section 5.2.7.12
Starting a DECnet network Section 5.2.7.13
Starting up the DIBOL Message Manager Section 5.2.7.14
Defining the number of interactive users Section 5.2.7.15


++Alpha specific

How to Perform This Task

To modify SYSTARTUP_VMS.COM, perform the following steps:

  1. Invoke any editor to edit the file.
  2. To prevent the command procedure from exiting if it invokes an error, include the DCL command SET NOON at the beginning of the file. This command disables error checking after the execution of each command in the procedure. For more information about error checking, refer to the OpenVMS User's Manual.
  3. Add commands to perform site-specific operations. Sections 5.2.7.1 to 5.2.7.15 describe operations that are typically performed by this command procedure.
  4. Exit the editor to create a new version of the file. The highest version will automatically be invoked by STARTUP.COM each time the system boots.

5.2.7.1 Mounting Public Disks

A public volume is a disk that any process on the system can access. To make disks available for public use, you must perform the following tasks:

How to Perform This Task

Add MOUNT commands in the following format to the command procedure:

MOUNT/SYSTEM device-name: volume_label logical_name 

where:

The /SYSTEM qualifier makes the disk available for systemwide access.

Note that, by default, the system creates the following logical name when you use the MOUNT command:

DISK$volume_label 

In many cases, using the default logical name will meet your needs.

When mounting disks in a startup command procedure, do not specify the /CLUSTER qualifier, even in a VAXcluster or an OpenVMS Cluster environment. Each node executes its own startup command procedure, so each node mounts disks for itself.

Note

When SYSTARTUP_VMS.COM executes (and only then), the MOUNT command default includes the /NOASSIST qualifier. This qualifier means that operator-assisted mounts are disabled. To enable this feature during SYSTARTUP_VMS.COM, specify /ASSIST with each MOUNT command.

For a DSA disk, you must also insert a WAIT statement in the command procedure prior to the first MOUNT statement. The wait time is controller-dependent. If you omit a WAIT statement, the MOUNT request might fail with a "no such device" status. Refer to the OpenVMS I/O User's Reference Manual for more information.

For more information about public volumes, see Section 8.1.4 and Section 8.5. For more information about the MOUNT command, refer to the MOUNT section of the OpenVMS System Management Utilities Reference Manual.

5.2.7.2 Mounting Disks That Must Be Available Early in Startup

If you have any disks that must be mounted early in startup, you can add MOUNT commands to SYCONFIG.COM. For example, your site might require that certain files be available before SYSTARTUP_VMS.COM executes. For more information about SYCONFIG.COM, see Section 5.2.4.

5.2.7.3 Setting Terminal and Printer Characteristics

To establish the device characteristics of the terminals and printers on the system, use a series of SET commands in your startup command procedure. For more information about the commands you use to set up devices, see Section 7.6.1 and Section 7.8.1.

If your configuration is simple, you can add the commands to SYSTARTUP_VMS.COM. If your configuration requires a large number of commands, create a separate command procedure (for example, DEVICE_SETUP.COM) and execute it from SYSTARTUP_VMS.COM. When the device setup command procedure finishes executing, control returns to SYSTARTUP_VMS.COM.

5.2.7.4 Starting Queues and Enabling Autostart for Queues

You should add commands to SYSTARTUP_VMS.COM to perform the following tasks:

If your configuration is simple, you can add these commands to SYSTARTUP_VMS.COM. On systems with a large number of queues, you might want to include the commands in a separate file named, for example, STARTQ.COM, and include a command in SYSTARTUP_VMS.COM to invoke the queue startup command procedure. The autostart feature simplifies queue startup, and allows you to start queues with fewer commands. Compaq recommends you use autostart queues whenever possible to simplify queue startup. For more information about autostart queues, see Section 13.1.3.

For more information about starting queues and enabling autostart for queues in system startup, see Section 13.4.1.

5.2.7.5 Installing Known Images

You can install commonly used programs as known images to reduce the I/O overhead in activating those images and to assign attributes or privileges to the images. Use the Install utility (INSTALL) to install known images, which you must reinstall each time the system boots.

STARTUP.COM includes a series of INSTALL commands that install certain system programs as known images. You should include any site-specific INSTALL commands in SYSTARTUP_VMS.COM to install images each time the system boots.

For information about installing known images, see Section 16.9.

Example

The following example shows a command sequence you might include in SYSTARTUP_VMS.COM for installing additional known images:


$ INSTALL 
  ADD/OPEN/SHARED/HEADER_RESIDENT BASIC 
  ADD/OPEN/SHARED/HEADER_RESIDENT FORTRAN 
  EXIT 

5.2.7.6 Installing Resident Images (Alpha Only)

Resident images must be installed each time the system boots. You can add commands to SYSTARTUP_VMS.COM to automatically perform this task. Section 16.9.6 explains how you can use the Install utility (INSTALL) to install resident images on Alpha systems.

5.2.7.7 Setting Up the OpenVMS InfoServer Client Software

If you use the InfoServer system, you will probably perform some setup tasks in SYSTARTUP_VMS.COM. For example, you can add commands to SYSTARTUP_VMS.COM to:

Chapter 23 explains the InfoServer system and its uses.

5.2.7.8 Running the System Dump Analyzer

You run the System Dump Analyzer utility (SDA) each time the system boots to analyze the system crash dump in case the system failed the last time it was running. You can do this by adding command lines to SYSTARTUP_VMS.COM.

For details, see Section 15.10 and the OpenVMS VAX System Dump Analyzer Utility Manual and the OpenVMS Alpha System Dump Analyzer Utility Manual.

Caution

If you use the page file for the crash dump file, you must enter the SDA command COPY when the system reboots, to copy the dump from the page file to another file suitable for analysis.

If you fail to perform the copy operation, pages used to save the crash dump information are not released for paging, and your system might hang because it has insufficient paging space. For more information, see Section 15.12.

Example

The following commands, executed in SYSTARTUP_VMS.COM, invoke SDA, save and analyze the crash dump, and print a listing file:


$ ANALYZE/CRASH_DUMP SYS$SYSTEM:SYSDUMP.DMP 
    COPY SYS$SYSTEM:SAVEDUMP.DMP        ! Save dump file 
    SET OUTPUT DISK1:SYSDUMP.LIS        ! Create listing file 
    READ/EXECUTIVE                      ! Read in symbols for kernel 
    SHOW CRASH                          ! Display crash information 
    SHOW STACK                          ! Show current stack 
    SHOW SUMMARY                        ! List all active processes 
    SHOW PROCESS/PCB/PHD/REGISTERS      ! Display current process 
    EXIT 

5.2.7.9 Purging the Operator Log File

Each time you reboot the system, you create a new version of the operator log file, OPERATOR.LOG. You should devise a plan for regular maintenance of the versions of this file. Add the following command to SYSTARTUP_VMS.COM to purge all but the last two versions of the operator log file:


$ PURGE/KEEP=2 SYS$MANAGER:OPERATOR.LOG 

For more information about the operator log file, see Section 18.6.1.

5.2.7.10 Submitting Batch Jobs to Run at Startup Time

Your site might have batch jobs that you want to submit at system startup time. To submit such batch jobs, add SUBMIT commands in the following format to SYSTARTUP_VMS.COM:

$ SUBMIT [/qualifier,...] SYS$MANAGER:file-spec 

Example

The following example submits a batch job to run a command procedure each time the system boots. The job is submitted at a high priority to make sure the job is scheduled before any batch jobs users might submit. If possible, submit startup batch jobs at high priority in this way before you start the batch queue.


$ SUBMIT/PRIORITY=255 SYS$MANAGER:SYSDISK_REBUILD 

See Section 13.6.5.2 for information about scheduling of jobs. Refer to the OpenVMS DCL Dictionary for information about the SUBMIT command.

5.2.7.11 Creating Systemwide Announcements

Usually, the last command in SYSTARTUP_VMS.COM announces to all terminals that the system is up and running:


$ REPLY/ALL/BELL "OpenVMS Operating System at ANDROMEDA, INC. ready for use." 

Before the procedure exits, you can provide site-specific definitions for one or both of the logical names SYS$ANNOUNCE and SYS$WELCOME. Whenever a user logs in, the user's terminal screen displays the messages associated with SYS$ANNOUNCE and SYS$WELCOME.

Defining SYS$ANNOUNCE

You can define SYS$ANNOUNCE to print an announcement at the beginning of the login procedure for each user. The text prints immediately after a successful dial-in, Ctrl/Y, or carriage return is received. It also prints on LAT terminals when a user connects to a service using the CONNECT command. The text can contain up to 63 characters. For longer messages, precede the name of a text-containing file with an at sign (@) so that the login command procedure prints the entire file as an announcement.

For example, you could include the following command in SYSTARTUP_VMS.COM:


$ DEFINE/SYSTEM SYS$ANNOUNCE "SIRIUS OPENVMS CLUSTER AT ANDROMEDA, INC." 

Or you might prefer to print a file by including the following command:


$ DEFINE/SYSTEM SYS$ANNOUNCE "@SYS$MANAGER:ANNOUNCE.TXT" 

If you do not define SYS$ANNOUNCE, the system does not display an announcement.

Caution

Sites requiring moderate or high security should restrict the amount of information displayed in system announcements.

Defining SYS$WELCOME

You can define SYS$WELCOME to display a welcome message whenever a user logs in. The text prints immediately after the user enters the correct password. The text can contain up to 63 characters. For longer messages, precede the name of a text-containing file with an at sign (@) so that the login command procedure displays the entire file as a welcoming announcement.

For example, you could include a command like the following one in SYSTARTUP_VMS.COM:


$ DEFINE/SYSTEM SYS$WELCOME "Welcome to Node RANDOM" 

If you prefer to display the contents of a file containing a message, you could use the following line in the procedure:


$ DEFINE/SYSTEM SYS$WELCOME "@SYS$MANAGER:WELCOME.TXT" 

If you do not explicitly define SYS$WELCOME, the terminal displays a standard welcome message similar to the following one:


Welcome to OpenVMS Version n.n 

You can add the DECnet node name to this message by including a translation of the logical name SYS$NODE. When DECnet starts, it creates the logical name assignment for SYS$NODE.

SYSTARTUP_VMS.COM, supplied as a template with your distribution kit, includes additional command examples for SYS$ANNOUNCE and SYS$WELCOME.


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_013.HTML