HP OpenVMS Systems Documentation

Displays the name of the current startup database or its components as well as the startup logging options selected with the STARTUP SET OPTIONS command.

Format

STARTUP SHOW DATABASE

FILE
OPTIONS

Parameters

DATABASE

Displays the name of the current startup database. The two startup databases are STARTUP$STARTUP_LAYERED and STARTUP$STARTUP_VMS. HP recommends that you do not modify the STARTUP$STARTUP_VMS database.

FILE

Displays the contents of the current startup database. The display includes the file name, phase, and mode of execution for each component in the database.

OPTIONS

Displays the options selected when using the STARTUP SET OPTIONS command.

Qualifiers

/FULL

Displays full information about each component in the database. In addition to the phase, file name, and mode of execution for each startup component, SYSMAN displays the nodes on which the file executes and the parameters passed to the file. This qualifier is relevant with the FILE parameter.

/NODE

Displays the nodes within the cluster on which the file executes. By default, a startup file executes on all nodes in an environment. This qualifier is relevant with the FILE parameter.

/OUTPUT=filespec

Redirects command output from SYS$OUTPUT to the file named with the qualifier. Without a filespec, SYSMAN writes the output to SYSMAN.LIS in the current directory.

/PARAMETERS

Lists the parameters with which the startup file executes. Parameters that are not specified receive the defaults defined by the system parameter STARTUP_Pn. If STARTUP_Pn is blank, "FULL" is used as parameter 1 (P1) and is passed by STARTUP.COM to each startup component file. If you want a blank P1 parameter given to a specific component file, see the /PARAMETER qualifier under STARTUP MODIFY command for instructions.

/PHASE=phase-name

Displays components that execute in a specific phase of system startup. Valid phases include LPBEGIN, LPMAIN, LPBETA, and END. LPMAIN is the default. This qualifier is relevant with the FILE parameter.

Example

SYSMAN> STARTUP SET DATABASE STARTUP$STARTUP_VMS 
SYSMAN> STARTUP SHOW FILE
%SYSMAN-I-COMPFIL, contents of component database on node LUCERN
Phase        Mode    File                            
-----        ----    --------------------------------
BASEENVIRON  DIRECT  VMS$BASEENVIRON_050_LIB.COM
BASEENVIRON  CALLED  VMS$BASEENVIRON_050_SMISERVER.COM
BASEENVIRON  DIRECT  VMS$BASEENVIRON_050_VMS.COM
. 
. 
. 
                                                      
      

The commands in this example display the contents of the startup database.

Adds an entry in the system images file SYS$UPDATE:VMS$SYSTEM_IMAGES.IDX.

Format

SYS_LOADABLE ADD product image

Parameters

product

A 1- to 8-character product mnemonic that uniquely identifies a loadable image. For user-written images, this should typically contain the string _LOCAL_.

image

The file name of the system loadable image you want to add. A file name is the only value you can specify for this parameter. Do not specify a device, directory, file type, or wildcard characters.

Qualifiers

/LOAD_STEP

Indicates the step of the booting process at which you want the image loaded. Valid load steps are INIT (which causes the system initialization code to load the image), and SYSINIT (which causes the SYSINIT process to load the image).

If you do not specify a value for the /LOAD_STEP qualifier, it defaults to SYSINIT.

/LOG

/NOLOG (default)

Controls whether the SYS_LOADABLE ADD command displays a notification after the entry has been added.

/MESSAGE

Enables you to specify the text of a message that is displayed when the appropriate condition is met (see the /SEVERITY qualifier). The default message is "system image load failed".

/SEVERITY

Determines how the image load status will affect console output and booting progress. You can specify the following values for this qualifier:

Value	Description
FATAL	If an error occurs loading the image, display the error message and BUGCHECK information.
INFORMATION	Display the message and continue processing.
SUCCESS	Continue even if loading the image produces an error. Does not display the message.
WARNING	If an error occurs loading the image, display the error message and continue processing.

If you do not specify a value for the /SEVERITY qualifier, it defaults to WARNING.

Description

The SYS_LOADABLE ADD command adds an entry to the system images file SYS$UPDATE:VMS$SYSTEM_IMAGES.IDX. You can then process this file using the command procedure SYS$UPDATE:VMS$SYSTEM_IMAGES.COM. Processing the file with VMS$SYSTEM_IMAGES.COM generates a new system images data file that the system uses when it boots.

If the file SYS$UPDATE:VMS$SYSTEM_IMAGES.IDX does not exist, the SYS_LOADABLE ADD command creates a new one.

Removes an entry in the system images file SYS$UPDATE:VMS$SYSTEM_IMAGES.IDX.

Format

SYS_LOADABLE REMOVE product

image

Parameters

product

A 1- to 8-character product mnemonic that uniquely identifies a loadable image. For user-written images this should typically contain the string _LOCAL_.

image

The file name of the system loadable image you want to remove. A file name is the only value you can specify for this parameter. Do not specify a device, directory, file type, or wildcard characters.

Qualifier

/LOG

/NOLOG (default)

Controls whether the SYS_LOADABLE REMOVE command displays a notification after the entry has been removed.

Description

The SYS_LOADABLE REMOVE command removes an entry from the system images file SYS$UPDATE:VMS$SYSTEM_IMAGES.IDX. You can then process this file using the command procedure SYS$UPDATE:VMS$SYSTEM_IMAGES.COM. Processing the file with VMS$SYSTEM_IMAGES.COM generates a new system images data file that the system uses when it boots.

If the file SYS$UPDATE:VMS$SYSTEM_IMAGES.IDX does not exist, the SYS_LOADABLE REMOVE command creates a new, empty one.

24.4 RAD Example

1. Show that no reserved memory registry exists:

   SYSMAN> reserved_memory list %SYSMAN-I-NODERR, error returned from node PIPERI -RMS-E-FNF, file not found

2. Add a reservation for a group global section and display the new reservation:

   SYSMAN> reserved_memory add ak_sec/gr=4711 /size=16 /zero /page_tables SYSMAN> reserved_memory list %SYSMAN-I-OUTPUT, command execution on node PIPERI Reservation Name Group RAD Size (MB) Pages Attributes AK_SEC 4711 ANY 16 2048 Allocated Zeroed AK_SEC 4711 2 PageTables Allocated

3. Modify the reservation to have memory assigned from each of four RADs; display the result:

   SYSMAN> reserved_memory modify ak_sec/gr=4711 /new_rad=0 /size=4 SYSMAN> reserved_memory extend ak_sec/gr=4711 /rad=1 /size=4 SYSMAN> reserved_memory extend ak_sec/gr=4711 /rad=2 /size=4 SYSMAN> reserved_memory extend ak_sec/gr=4711 /rad=3 /size=4 SYSMAN> reserved_memory list %SYSMAN-I-OUTPUT, command execution on node PIPERI Reservation Name Group RAD Size (MB) Pages Attributes AK_SEC 4711 0 4 512 Allocated Zeroed AK_SEC 4711 1 4 512 Allocated Zeroed AK_SEC 4711 2 4 512 Allocated Zeroed AK_SEC 4711 3 4 512 Allocated Zeroed AK_SEC 4711 2 PageTables Allocated

4. Modify the reservation to no longer zero allocated pages at boot time. Note that you can change properties such as /ZERO, /ALLOCATE, /PAGE_TABLES only for the reservation as a whole, not for a specific RAD.

   SYSMAN> reserved_memory modify ak_sec/gr=4711 /nozero SYSMAN> reserved_memory list %SYSMAN-I-OUTPUT, command execution on node PIPERI Reservation Name Group RAD Size (MB) Pages Attributes AK_SEC 4711 0 4 512 Allocated AK_SEC 4711 1 4 512 Allocated AK_SEC 4711 2 4 512 Allocated AK_SEC 4711 3 4 512 Allocated AK_SEC 4711 2 PageTables Allocated

5. Modify the reservation to no longer request memory from specific RADs. Note that the overall size remains unchanged.

   SYSMAN> reserved_memory modify ak_sec/gr=4711 /norad SYSMAN> reserved_memory list %SYSMAN-I-OUTPUT, command execution on node PIPERI Reservation Name Group RAD Size (MB) Pages Attributes AK_SEC 4711 ANY 16 2048 Allocated AK_SEC 4711 2 PageTables Allocated

6. Starting with a reservation allocated across multiple RADs, request that memory no longer be allocated at boot time. Note that this implies that memory is no longer allocated from specific RADs.
   Reservation prior to change:

   SYSMAN> reserved_memory list %SYSMAN-I-OUTPUT, command execution on node PIPERI Reservation Name Group RAD Size (MB) Pages Attributes AK_SEC 4711 0 4 512 Allocated AK_SEC 4711 1 4 512 Allocated AK_SEC 4711 2 4 512 Allocated AK_SEC 4711 3 4 512 Allocated AK_SEC 4711 2 PageTables Allocated

   
   Command to no longer allocate at boot time:

   SYSMAN> reserved_memory modify ak_sec/gr=4711 /noalloc

   
   New state of reservation:

   SYSMAN> reserved_memory list %SYSMAN-I-OUTPUT, command execution on node PIPERI Reservation Name Group RAD Size (MB) Pages Attributes AK_SEC 4711 ANY 16 2048 AK_SEC 4711 2 PageTables

7. To change the size of a reservation with an assigned RAD, or to change the reservation to use a different RAD, you must specify the current RAD.
   Reservation prior to change:

   SYSMAN> reserved_memory list %SYSMAN-I-OUTPUT, command execution on node PIPERI Reservation Name Group RAD Size (MB) Pages Attributes AK_SEC 4711 2 16 2048 Allocated AK_SEC 4711 2 PageTables Allocated

   
   Attempt to change reservation size:

   SYSMAN> reserved_memory mod ak_sec/gr=4711 /size=20 %SYSMAN-I-NODERR, error returned from node PIPERI -SMI-E-RMRNOMATCH, no records matched search criteria Correct command: SYSMAN> reserved_memory mod ak_sec/gr=4711 /rad=2 /size=20

   
   New state of reservation:

   SYSMAN> reserved_memory list %SYSMAN-I-OUTPUT, command execution on node PIPERI Reservation Name Group RAD Size (MB) Pages Attributes AK_SEC 4711 2 20 2560 Allocated AK_SEC 4711 3 PageTables Allocated

The USB (Universal Serial Bus) Configuration Manager (UCM) utility allows you to connect a computer to a variety of devices using a single four-wire cable. More specifically, UCM does the following:

• Records events such as plugging or unplugging devices and errors that occur on a USB bus. This is the USB event-logging function of UCM.
• Maps physical devices to persistent device names (based on either serial number or bus location).
• Automatically configures and loads OpenVMS device drivers for known device types.
• Manages additions, deletions, and modifications to devices configured on the system.

Types of UCM Configuration

Beginning in OpenVMS Version 8.3, UCM automatically configures any new (non-permanent) device, loads the OpenVMS device driver for it, and makes the device permanent. This means that adding a new device to the system is as simple as plugging it in. This is automatic configuration.

However, you might decide to disable automatic recognition and configuration of new devices, or restrict the automatic configuration only to specific devices. You do this by first using a UCM SET AUTO command. You can then follow a number of procedures required for manual configuration.

Organization of This Chapter

Following explanations of USB and UCM concepts are sections that tell how to use UCM to configure devices automatically and manually. A section providing information about viewing events related to device configuration follows. The final section in the chapter details UCM commands and contains examples of these commands.

25.2 USB and UCM Concepts

OpenVMS tests and supports specific HP provided USB devices on HP Integrity servers.

In some cases, specific third-party devices are tested and supported by OpenVMS. For these devices, OpenVMS will respond to bug reports and fix defects in driver support for them. These devices are listed in appendices of the HP OpenVMS Systems Management Utilities Reference Manual.

The functionality of USB is such that in many cases broad categories of devices can be supported by a single generic device driver. OpenVMS does not attempt to prevent such unknown third-party devices from configuring and operating. However, HP cannot guarantee correct operation of such untested devices. If a problem occurs with such a device, it can be reported through support channels but there is no guarantee that the problem can be corrected or provide an ECO patch kit.

Should you require formal support for a third-party device a request for support can be made through your HP account team or HP distributor.

The following sections introduce and explain USB and UCM concepts.

25.2.1 Introduction to USB

Universal Serial Bus (USB) is a communications architecture that enables a computer to interconnect a variety of devices using a single four-wire cable. The purpose of USB is to provide a user-friendly way to connect low- and medium-speed devices to host computers.

The USB connects USB devices to the USB host, which, in turn, connects with a host computer system. Each USB has only one host, labeled USB Host in Section 25.2.1. (A host, however, can have many USB controllers.)

Figure 25-1 USB Configuration

The USB host is integrated with a root hub, which provides one or more attachment points for devices. The USB physical interconnections from each hub form a star, with a hub at the center of each star.

Point-to-point wire connections link the USB host to a hub or a function, or a hub to another hub or function. Hubs and functions are USB devices that do the following:

• Hubs provide additional attachment points to the USB.
• Functions provide capabilities to the system, such as a mouse or a keyboard.

Figure 25-2 shows that up to six hubs can be chained to create a tiered configuration. The path of a device is determined by its location in the structure; for example, the path to the printer LPA0: in Figure 25-2 is 1.1.2.3.1.4. (Note, however, that the numbers printed on the physical hub might not match the numbers that UCM displays.)

Figure 25-2 Hub Tiers

UCM works with the hub driver to configure USB-supported devices. The hub driver discovers devices and sends requests to the UCM server, which determines the action to be taken. By default, UCM configures and loads OpenVMS device drivers for the device and also logs activity. The UCM contains controls to inhibit or restrict device driver loading, and to allow manual intervention and modification of device driver loading and device naming.

25.2.2 UCM Concepts

UCM is made up of client and server layers. You, the user, interact with the client layer, and the client layer interacts with the server layer. It is the server layer that interacts with USB. Figure 25-3 shows the interaction of these layers.

Figure 25-3 UCM Architecture

As the figure indicates, the UCM server maintains the event-logging file and the generic and permanent list files. These files are passed to the UCM server, which can display list files. (The types of lists that the UCM server uses are explained in UCM Lists.) The UCM server is in contact with the UCM driver, SYS$HUBDRIVER, which maintains connections with other layers of the architecture.

25.2.3 The Discovery of Devices

The OpenVMS device names of USB devices are as follows:

Unlike most backplane buses, the discovery of devices on a USB bus is an asynchronous process that can take an indeterminate amount of time to complete. The discovery of devices also requires an additional layer of discovery beyond that provided by the OpenVMS auto-configuration in SYSMAN. UCM supplies this secondary layer for the discovery and loading of device drivers. The result is that although USB devices connected to the system are discovered during a boot, the actual timing of the discovery depends on the number and configuration of devices, as well as other system events that can affect the timing.

If you write code or DCL procedures that expect to find or use USB devices, you must write this code to handle cases in which the devices might not have been discovered or configured yet, and also to handle the case of a device that has been unplugged (which will be offline). The code or DCL procedures, therefore, must retry or wait for the device to appear. It must also check to ensure that the device is connected (online).

In addition, the hub driver discovers devices plugged into the system after the boot at runtime; UCM configures these devices. Devices that are unplugged after being configured are set offline and made unusable until the device is reconnected to the system.

The UCM client provides a command-line interface for you to interact with the UCM server and to display information about devices and USB events that have occurred.

UCM Lists

The UCM server manages a number of in-memory lists that are used to configure USB devices:

• Generic list - Contains the device types known to UCM; is built from the system configuration database.
• Tentative list - Contains devices that the HUB driver has seen, but that UCM has not yet configured or made permanent. This list is usually empty.
• Permanent list - Contains devices that UCM has made persistent. Whenever this device is seen, it is configured and given the same OpenVMS device name.

The following table describes UCM lists in detail:

A running system has only one permanent list, which UCM reads from SYS$SYSTEM:USB$UCM_DEVICES.DAT. For most customers, this is the minimal file that OpenVMS provides in SYS$COMMON:[SYSEXE].