| Previous | Contents | Index |
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.
STARTUP SHOW DATABASE
FILE
OPTIONS
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.
/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.
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.
The SYS_LOADABLE ADD command is not intended for general use. Only advanced system programmers should use this command. |
SYS_LOADABLE ADD product image
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.
/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.
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.
The SYS_LOADABLE REMOVE command is not intended for general use. Only advanced system programmers should use this command. |
SYS_LOADABLE REMOVE product
image
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.
/LOG
/NOLOG (default)
Controls whether the SYS_LOADABLE REMOVE command displays a notification after the entry has been removed.
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.
SYSMAN> reserved_memory list %SYSMAN-I-NODERR, error returned from node PIPERI -RMS-E-FNF, file not found |
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 |
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 |
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 |
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 |
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 |
SYSMAN> reserved_memory modify ak_sec/gr=4711 /noalloc |
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 |
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 |
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
|
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:
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.
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
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 |
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.
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:
|
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].
Never delete USB$UCM_DEVICES.DAT. Deleting this file might result in the inability to use your USB attached devices. |
| Previous | Next | Contents | Index |