[OpenVMS documentation]
[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
Updated: 11 December 1998

OpenVMS System Manager's Manual


Previous Contents Index

3.9.2 Recording a Change in Volume Label in the Product Database

To record a changed volume label in the product database, enter the PRODUCT REGISTER VOLUME command. You will be prompted for the old volume label and the name of the device where the volume is mounted.

This command replaces all occurrences of the old volume label with the new volume label. (The POLYCENTER Software Installation utility reads the new label from the disk.)

Note that PRODUCT REGISTER VOLUME changes the information in the product database only; it does not change the label on the volume. To rename a volume, use the DCL command SET VOLUME. Then use PRODUCT REGISTER VOLUME to record the new name.

You can also use the PRODUCT REGISTER VOLUME command to record a change in the physical or logical device name.

3.9.3 Copying a Software Kit to a New Location

You can use the POLYCENTER Software Installation utility to copy product distribution kits from one location to another. If you transfer a kit from tape to disk, you can change the format from a sequential copy to a reference copy.

To copy a software kit from one location to another, use the PRODUCT COPY command. Specify the current location with the /SOURCE qualifier and the new location with the /DESTINATION qualifier. For example:


$ PRODUCT COPY/SOURCE=WORK_DISK:[KITS]/DESTINATION=LOCAL_DISK:[KIT_INSTALL] CMS

3.9.4 Converting a Software Kit from One Format to Another

You can convert a software kit from reference format (on disk or CD-ROM) to sequential format or from sequential format to reference format by using the /FORMAT qualifier with PRODUCT COPY.

For example, to convert CMS from sequential format to reference format, enter the following command:


$ PRODUCT COPY/FORMAT=REFERENCE/SOURCE=MUA1:/DESTINATION=LOCAL_DISK:[KIT_INSTALL] CMS

3.9.5 Retrieving Product Information

All of the information stored by the product database (PDB) can be accessed by using the SHOW OBJECT, SHOW PRODUCT, and SHOW HISTORY commands. This section describes how to use these commands to retrieve information from the PDB.

3.9.5.1 Displaying Information About Objects

To display information about the managed objects (for example, files, accounts, and directories) associated with the products installed on your system, use the SHOW OBJECT command. Table 3-8 lists questions that can be answered with SHOW OBJECT.

Table 3-8 SHOW OBJECT Command: Displaying Managed Object Information
Question Command
What files or other objects did this product create? PRODUCT SHOW OBJECT * /PRODUCT= product-name
What product created this file or other object? PRODUCT SHOW OBJECT object-name/FULL

3.9.5.2 Displaying Information About the Products

You can obtain information about products installed on your system with the SHOW PRODUCT and SHOW HISTORY commands. Table 3-9 lists some of the questions that can be answered with these commands.

Table 3-9 SHOW PRODUCT and SHOW HISTORY Commands: Displaying Product Information
Question Command
Which products have been installed? PRODUCT SHOW HISTORY */OPERATION=INSTALL
PRODUCT SHOW PRODUCT *
Product interdependencies: Is product A referenced by product B? PRODUCT SHOW PRODUCT A/FULL
PRODUCT SHOW PRODUCT */REFERENCED_BY= B
Which user installed a product? PRODUCT SHOW HISTORY product-name /FULL
Which products were installed before March 31, 1998? PRODUCT SHOW HISTORY */BEFORE=31-MAR-1998
Were any software patches applied to a product? PRODUCT SHOW PRODUCT product-name/FULL

3.10 Removing Installed Software Products and Kits

When you use the POLYCENTER Software Installation utility to remove an installed product, all of the files, accounts, and other objects that were created for the product when it was installed are removed from your system and from the product database.

To remove an installed product, enter PRODUCT REMOVE. For example:


$ PRODUCT REMOVE CMS


Chapter 4
Starting Up and Shutting Down the System

This chapter describes various ways to start up and shut down your system.

To initiate startup of your system, you boot it. Many systems have unique booting commands. For detailed booting instructions for your system, refer to the following manuals:

Information Provided in This Chapter

This chapter describes the following tasks:
Task Section
Deferring memory testing on AlphaServer 4100 computers Section 4.1.2
Booting with modified system parameter values Section 4.2
Assigning port allocation classes with SYSBOOT Section 4.3
Booting in an emergency Section 4.4
Booting with controlled startup Section 4.5
Solving booting problems Section 4.6
Writing a new boot block on the system disk Section 4.7
Performing an orderly shutdown with SHUTDOWN.COM Section 4.8.1
Customizing SHUTDOWN.COM to perform site-specific operations Section 4.8.3
Performing an orderly shutdown with SYSMAN Section 4.8.4
Performing an emergency shutdown with the OPCCRASH.EXE program Section 4.8.5
Performing an emergency shutdown using console commands Section 4.8.6

This chapter explains the following concepts:
Concept Section
Booting and startup processes Section 4.1.1
Nonstop boot: the most common booting operation Section 4.1.3.1
Conversational boot: for special booting functions Section 4.1.3.2
System startup and STARTUP.COM Section 4.1.4
System shutdown procedures Section 4.8
The order of shutdown events Section 4.8.2

4.1 Understanding Booting and System Startup

Booting is the process of loading system software from the system disk into processor memory. When you boot your system, it automatically performs a series of tasks to start up your system. These tasks are collectively known as system startup.

You must have installed the operating system before you boot the system for the first time.

Booting procedures vary for different computers. For example, computers with console storage devices use a boot command procedure. You can copy and edit this command procedure to specify the location of the system disk. Other computers have an internal memory device that provides the name of the system disk.

On Alpha systems, you cannot boot from a magnetic tape device.

4.1.1 Booting and Startup Processes

Together, the booting and startup processes comprise the following steps:

  1. You enter the BOOT command. The boot block, a fixed location on disk, points to the primary bootstrap image, which is loaded from disk into main memory.
    On VAX systems, the primary bootstrap image is VMB.EXE.
    On Alpha systems, the primary bootstrap image is APB.EXE.
    The primary bootstrap image allows access to the system disk by finding the secondary bootstrap image, SYS$SYSTEM:SYSBOOT.EXE, and loading it into memory.
  2. SYSBOOT.EXE loads the system parameters stored in the default parameter file into memory. (For more information about the default parameter file and loading of system parameters at boot time, see Section 4.2.)
    If you are performing a conversational boot, the procedure stops and displays the SYSBOOT> prompt. (For information about conversational booting, see Section 4.1.3.2.) Otherwise, SYSBOOT.EXE loads the operating system executive into memory and transfers control to the executive.
  3. When the executive finishes, it executes the SWAPPER process.
  4. The SWAPPER creates the SYSINIT process.
  5. Among other actions it performs, SYSINIT creates the STARTUP process.
  6. STARTUP executes SYS$SYSTEM:STARTUP.COM (unless you indicated another file using SYSMAN, SYSGEN, or conversational boot). STARTUP.COM executes a series of other startup command procedures, including SYSTARTUP_VMS.COM. (For more information about STARTUP.COM, see Section 4.1.4. For more information about other startup procedures, see Section 5.2.1.)
    The current values of system parameters are written back to the default parameter file.
  7. The boot process finishes, and you can log in to the operating system.

4.1.2 Deferring Memory Testing on AlphaServer 4100 Computers

To speed up the time between system power-on and user login, you can now defer a portion of memory testing on AlphaServer 4100 computers. When you choose this option, the console tests a minimum amount of memory and leaves the rest for the operating system to test.

To use this new feature, you need to specify a value for the MEMORY_TEST environment variable at the console before booting. The values for MEMORY_TEST are the following:
Value Description
FULL (off) The console does all the testing.
NONE 32 MB of memory are tested before booting.
PARTIAL 256 MB of memory are tested before booting.

If you set MEMORY_TEST to NONE or PARTIAL, OpenVMS tests any remaining untested memory on an as-needed basis at either or both of the following times:

When you change the value of MEMORY_TEST, you must issue the INIT console command before the new value takes effect. Therefore, you need to follow these steps from the console before booting:

  1. Change the value of MEMORY_TEST (if desired).
  2. Issue the INIT command from the console.
  3. Boot the operating system.

OpenVMS also gives you more control over when memory is actually tested. Bit 2 in the system parameter MMG_CTLFLAGS controls deferred memory testing:

4.1.3 Types of Booting Operations

You can perform the following types of booting operations:
Type Purpose For More Information
Nonstop boot To boot without stopping to perform special operations. Use this kind of boot in most cases. Section 4.1.3.1
Conversational boot To perform special boot operations---for example, to change system parameters before booting. Section 4.1.3.2

4.1.3.1 Nonstop Boot: The Most Common Booting Operation

The most common boot operation is a nonstop boot from the system disk. You perform a nonstop boot after changing certain system parameters or installing certain layered products, or after a standalone backup.

Follow the instructions for a nonstop boot in either of the following manuals:

4.1.3.2 Conversational Boot: For Special Booting Functions

A conversational boot is used in programming research and development environments where you must alter operating conditions for experimentation, testing, and debugging. Use a conversational boot to perform the following operations:
Operation For More Information
Boot after showing or modifying individual system parameter values. 1 Section 4.2.1
Boot using system parameter values from an alternate parameter file. 1 Section 4.2.2
Boot with default values for system parameters; for example, when modified system parameter values have caused the system to become unbootable. 1 Section 4.4.1
Boot without running startup or login procedures; for example, when modified startup or login procedures have caused the system to become unbootable. Section 4.4.2
Boot without the user authorization file; for example, when the user authorization file has been modified so that you cannot log in. Section 4.4.3
Boot with an alternate site-independent startup procedure. Section 4.5.1
Boot with a minimum startup. Section 4.5.3
Display startup procedure commands while booting. Section 4.5.4


1In most cases, Compaq recommends that you use AUTOGEN to modify system parameters. In special cases, however, you can use a conversational boot to modify a parameter value temporarily. To change a parameter value permanently, you must edit MODPARAMS.DAT and run AUTOGEN. For instructions, see Section 14.5.

To boot your system conversationally, follow the instructions for a conversational boot in either of the following manuals:

4.1.4 System Startup and STARTUP.COM

Immediately after your system boots, it runs the site-independent command procedure SYS$SYSTEM:STARTUP.COM to start up the system and control the sequence of startup events. This section describes STARTUP.COM.

Caution

Do not modify SYS$SYSTEM:STARTUP.COM. This file is deleted and replaced each time you upgrade your system to the next version of the operating system. Leaving STARTUP.COM intact prevents you from inadvertently altering any commands in the file, which in turn could cause the startup procedure to fail.

Although you should not modify STARTUP.COM, sometimes you may want to control site-independent startup when booting your system. For information, see Section 4.5.

STARTUP.COM uses a series of command procedures, executable images, and database files to perform the following startup tasks:

STARTUP.COM executes the following site-specific startup command procedures in this order:

  1. SYS$MANAGER:SYCONFIG.COM
  2. SYS$MANAGER:SYLOGICALS.COM
  3. SYS$MANAGER:SYPAGSWPFILES.COM
  4. SYS$MANAGER:SYSECURITY.COM
  5. SYS$MANAGER:SYSTARTUP_VMS.COM

For information about site-specific startup command procedures, see Section 5.2.

4.1.5 Messages Indicating Booting and Startup Progress

When you successfully boot a system, it prints a banner, followed by messages similar to the following message:

  1. The following message indicates that the system is executing the command procedure SYS$SYSTEM:STARTUP.COM:


    The OpenVMS system is now executing the system startup procedure. 
    

    This procedure configures and initializes the system and executes several site-specific command procedures. For more information, see Section 4.1.4.

  2. A short time later (up to a few minutes), the system displays a message similar to the following message:


    The OpenVMS system is now executing the site-specific system startup commands. 
    

    This message indicates that the system is executing SYSTARTUP_VMS.COM. You can modify this file to perform various operations at startup time. For more information, see Section 5.2.7.

  3. Finally, the procedure displays informational messages and accounting information. For example:


     
    %SET-I-INTSET, login interactive limit=64, current interactive value = 0 
    19-APR-1998 15:00:00.00 
      SYSTEM       job terminated at 19-APR-1998 15:00:00.00 
                                                      
    Accounting information: 
     Buffered I/O count:       133     Peak working set size:        401 
     Direct I/O count:          12     Peak pagefile size:          2379 
     Page faults:              325     Mounted volumes:                0 
     Charged CPU time: 0 00:00:55.23   Elapsed time:       0 00:01:31.24 
    

    After the system displays this information, you can log in.

4.2 Booting with Modified System Parameter Values

Using a conversational boot, you can modify system parameter values as follows:
Task For More Information
Boot after showing or modifying individual system parameter values Section 4.2.1
Boot with an alternate system parameter file Section 4.2.2
Boot with default values for system parameters Section 4.4.1

Before using a conversational boot to show or modify system parameter values, you must be familiar with the following terms:
Term Definition
Active values System parameter values stored in memory and used by the active system.
Current values System parameter values stored in the default parameter file. When the system boots, it sets active values for system parameters using the current values.
  +On VAX systems, the default system parameter file is SYS$SYSTEM:VAXVMSSYS.PAR.
  ++On Alpha systems, the default system parameter file is SYS$SYSTEM:ALPHAVMSSYS.PAR.
Default values System parameter values stored in the default list and used by default.


+VAX specific
++Alpha specific

For more information about system parameters, see Section 14.1.


Previous Next Contents Index

[Site home] [Send comments] [Help with this site] [How to order documentation] [OpenVMS site] [Compaq site]
[OpenVMS documentation]

Copyright © Compaq Computer Corporation 1998. All rights reserved.

Legal
6017PRO_008.HTML