HP OpenVMS System Management Utilities Reference Manual


Previous Contents Index

STARTUP SHOW

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.

SYS_LOADABLE ADD

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

Caution

The SYS_LOADABLE ADD command is not intended for general use. Only advanced system programmers should use this command.

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.

SYS_LOADABLE REMOVE

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

Caution

The SYS_LOADABLE REMOVE command is not intended for general use. Only advanced system programmers should use this command.

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

The following example procedure shows how to use SYSMAN resource affinity domain (RAD) qualifiers and options.
  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 
    


Chapter 25
USB Configuration Manager (UCM)

25.1 UCM Description

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:

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:

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:
Device Name Description
AGA n 1 Joystick
DNA n 1 Disk or other mass storage device (a pen drive, for example)
KBD n 1 Keyboard
MOU n 1 Mouse
TXA n 1 Modem
TXB n 1 Prolific driver
TXC n 1 Serial port (FTDI)
TXD n 1 Serial port (Edgeport/DIGI)
LPA n 1 Printer driver
HID0 Special-case driver that users cannot access
UCE0 Special-case driver that works with Edgeport/DIGI
UCM0 Hub driver (one per system)
UGA n 1 USG generic driver that can be used to support custom devices


1The value of n can be between 0 and 9999.

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:

The following table describes UCM lists in detail:
List Description
Generic This list contains descriptions of devices that UCM supports. The generic list is part of the file-based device configuration information that is maintained on the system. (See Chapter 8 of the HP OpenVMS System Manager's Manual.)

The installation process creates this list. A device that has no matching entry in the generic list is an unknown device type and cannot be configured.

Tentative This is is a list of devices that UCM has not yet configured. Usually, this list is empty because UCM automatically configures devices and makes them permanent. However, if automatic loading or automatic permanence is disabled, or if the device is excluded from loading with the SET AUTO command, the device is put on this list. The system manager can then display information about the device and manually add it as a permanent device. The tentative list, which is in memory, disappears when the server is restarted (when you enter the RELOAD command), or when the system reboots.
Permanent This list contains devices that UCM always configures if the device is connected to the bus. The permanent list supplies a persistent name for a USB device; that is, the name is maintained across reboots and server restarts.

Persistent names work somewhat differently on devices that have serial numbers from devices that do not have serial numbers:

  • On a device with a serial number, a persistent name always works.
  • On a device without a serial number, a name is persistent only if you attach the device in the same place on the hub each time you attach it.

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

Caution

Never delete USB$UCM_DEVICES.DAT. Deleting this file might result in the inability to use your USB attached devices.


Previous Next Contents Index