Document revision date: 19 July 1999

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

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:

• On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.
• On Alpha systems, refer to the most recent version of the OpenVMS Alpha Upgrade and Installation Manual.

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.

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:

• While the operating system is booting
• In the scheduler idle loop when no processes are available to run

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:

• If the bit is clear (the default), OpenVMS tests memory in the background and not necessarily before the bootstrap process has completed.
• If you set the bit, OpenVMS guarantees that all memory will be tested by the end of EXEC_INIT in the system bootstrap process; that is, before IPL is lowered from 31.

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:

• On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.
• On Alpha systems, refer to the most recent version of the OpenVMS Alpha Upgrade and Installation Manual.

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

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

• On VAX systems, refer to the most recent versions of the OpenVMS VAX Upgrade and Installation Manual and the upgrade and installation supplement for your VAX computer.
• On Alpha systems, refer to the most recent version of the OpenVMS Alpha Upgrade and Installation Manual.

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.

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:

• Define systemwide logical names required for the symbolic debugger, language processors, linker, image activator, and help processor.
• Start processes that control error logging, SMISERVER (the system management server), the job controller, the operator log file, and security auditing.
• Connect devices that are physically attached to the system by invoking the SYCONFIG.COM procedure. Configure devices and load their I/O drivers.
• Install known images to reduce I/O overhead in activating the most commonly run images or to identify images that must have special privileges.

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.

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.

For more information about system parameters, see Section 14.1.

	privacy and legal statement
6017PRO_008.HTML