![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
For more detailed information, see the OpenVMS Alpha System Dump Analyzer Utility Manual.
There are two new SDA unary operators. Table 4-25 shows the operators and their meanings.
| Unary Operator | Meaning |
|---|---|
| ^P | When used with the unary operator @, it specifies a physical address. |
| ^V | When used with the unary operator @, it specifies a virtual address. |
For more detailed information, see the OpenVMS Alpha System Dump Analyzer Utility Manual.
The new syntax for displaying the range of page table entries by using the SHOW PAGE_TABLE command or the SHOW PROCESS/PAGE command. Table 4-26 shows the command syntax and its meaning.
| Symbol | Meaning |
|---|---|
| m: n | Displays the page table entries that correspond to the range of virtual addresses from m to n. |
| m; n | Displays the page table entries that correspond to the range of n bytes starting at virtual address m. |
For more detailed information, see the OpenVMS Alpha System Dump Analyzer Utility Manual.
If no device or directory is given in the file specification, and the file specification is not found in SYS$DISK:[default_dir], then SDA attempts to open the file SDA$READ_DIR:filename.type. If no type has been given in filespec, SDA first tries .STB and then .EXE.
The SDA$READ_DIR logical name is defined in the system locial name table. You can use this logical name to redirect SDA to the SYS$SYSTEM area or private area.
For more detailed information, see the OpenVMS Alpha System Dump Analyzer Utility Manual.
OpenVMS Alpha allows you to write the system dump file to a device other than the system disk. This is useful in large-memory systems and in clusters with common system disks where sufficient disk space, on one disk, is not always available to support your dump file requirements. To perform this activity, the DUMPSTYLE system parameter must be correctly enabled to allow the bugcheck code to write the system dump file to an alternate device.
The requirements for writing the system dump file off the system disk (DOSD) are the following:
DUMPFILE_DEVICE = $nnn$ddcuuuu
>>> SET DUMP_DEV device-name[...]
For information on how to write the system dump file to an alternative device to the system disk, see the OpenVMS System Manager's Manual: Tuning, Monitoring, and Complex Systems.
The following sections describe the new system services features included in OpenVMS Version 7.1.
In OpenVMS Alpha Version 7.1, the following system services have been enhanced to support 64-bit addressing:
For complete information, see OpenVMS System Services Reference Manual.
The following sections describe system services that are new with OpenVMS Version 7.1. These services enable you to tailor OpenVMS scheduling to meet your local requirements. For more information about these new services, see the OpenVMS System Services Reference Manual.
The Avoid Process Preemption service requests that the scheduler avoid preempting a process or thread.
While the OpenVMS operating system provides many services for interlocking resources between processes, they are fairly heavyweight in that they require going into kernel mode to dispatch and operate. Some high-performance applications have implemented lightweight user-mode interlocks for some of their shareable resources. However, the performance advantage of avoiding the transition into kernel mode can be lost if the process that holds this interlock is scheduled off of the CPU, preventing other processes from executing until the preempted process or thread runs again and releases the interlock.
The $AVOID_PREEMPT system service provides a lightweight, caller's-mode method to request that the OpenVMS scheduler avoid preempting this process if at all possible.
The Setup for Process Preemption Avoidance service is a kernel-mode initialization routine that locks the necessary internal data structures in memory so scheduling routines can access them. A process or thread can then set or clear the indicator bit by calling $AVOID_PREEMPT.
The Release a Reserved User Capability service releases a user capability back to the global pool and indicates to other processes that the resource is available.
This service can be used along with the $GET_USER_CAPABILITY, $CPU_CAPABILITIES, and $PROCESS_CAPABILITIES system services to coordinate the sharing of global system resources by local processes.
The Reserve a User Capability service provides a way for discrete processes to communicate and synchronize their use of a user capability in the system. This service can indicate whether a particular user capability has been reserved and can return the current reservation state of all user capabilities in the system.
This chapter describes documentation features of interest to OpenVMS users.
For OpenVMS Version 7.1, documentation is offered in a variety of formats:
For OpenVMS Version 7.1, a selected group of manuals is offered in HTML format. These manuals are stored in the [HTML] directory on the OpenVMS Version 7.1 Documentation CD--ROM.
Use the INDEX.HTM Web page located in the [HTML] directory on the Documentation CD--ROM to browse the books. You can view these files with any Level 2 Internet browser, but Digital suggests using the Netscape Navigator Version 2.01 software. If needed, download the Netscape Navigator from the Internet Product Suite CD--ROM, which is part of your OpenVMS Version 7.1 package.
DECnet-Plus, formerly named DECnet/OSI, has replaced DECnet for OpenVMS Phase IV in the main operating system installation menu. To assist customers choosing to move from DECnet Phase IV to DECnet-Plus, OpenVMS is delivering a one-time complimentary offering that includes DECnet-Plus binaries and a DECnet Plus Starter Kit. Depending on the OpenVMS offering, the DECnet-Plus Starter Kit documentation is provided in printed or online format.
The DECnet-Plus Starter Kit for OpenVMS Version 7.1 customers includes the following documents:
Additional DECnet-Plus manuals are available on the OpenVMS Documentation Version 7.1 CD--ROM in Bookreader format or can be ordered in printed form through DECdirect (800-344-4825). Refer to the DECnet-Plus for OpenVMS Introduction and User's Guide for further information on DECnet-Plus for OpenVMS manuals. In future releases, DECnet-Plus manuals will not be part of the OpenVMS Documentation Sets and must be purchased separately.
DECnet for OpenVMS Phase IV binaries will ship on the OpenVMS Version 7.1 operating system media. The DECnet for OpenVMS manuals are no longer part of the OpenVMS Documentation Set but are included on the OpenVMS Documentation CD--ROM in DECW$BOOK and PostScript format. You can also order the printed books separately through DECdirect (800-344-4825). Table 5-1 lists the DECnet Phase IV manuals.
| Manual | Order Number |
|---|---|
| DECnet for OpenVMS Guide to Networking | AA--PV5ZA--TK |
| DECnet for OpenVMS Networking Manual | AA--PV60A--TK |
| DECnet for OpenVMS Network Management Utilities | AA--PV61A--TK |
OpenVMS device support documentation has been reorganized for OpenVMS Version 7.1. Two books about writing OpenVMS Alpha device drivers are now available, and several device support books from previous releases have been archived.
The OpenVMS Alpha device driver books available as of OpenVMS Version 7.1 are as follows:
Table 5-2 summarizes the Alpha and VAX device support documentation changes for OpenVMS Version 7.1. It lists the device support books that have been archived, and indicates whether the information they contain is available in other books.
| Title | New Location in Version 7.1 |
|---|---|
| Creating an OpenVMS AXP Step 2 Device Driver from a Step 1 Device Driver | Same |
| Creating an OpenVMS AXP Step 2 Device Driver from an OpenVMS VAX Device Driver | Creating an OpenVMS Alpha Device Driver from an OpenVMS VAX Device Driver (This book now includes reference information.) |
| OpenVMS Alpha Device Support: Developer's Guide | Writing OpenVMS Alpha Device Drivers in C |
| OpenVMS Alpha Device Support: Reference | C reference information is available in Writing OpenVMS Alpha Device Drivers in C. MACRO-32 reference information is included in the Creating an OpenVMS Alpha Device Driver from an OpenVMS VAX Device Driver book. |
| OpenVMS VAX Device Support Manual | Same |
| OpenVMS VAX Device Support Reference Manual | Same |
OpenVMS migration documentation is designed to help developers and system managers move computing environments and applications from an OpenVMS VAX to an OpenVMS Alpha system.
For Version 7.1, migration information is located in Migrating an Application from OpenVMS VAX to OpenVMS Alpha and Porting VAX MACRO Code to OpenVMS Alpha. The following documents have been archived. Table 5-3 lists the order numbers for these documents.
Several books have been archived for Version 7.1. Much of the information in these books has been incorporated in other manuals or updated in online Help. Archived books are available in PostScript and Bookreader format on the Documentation CD--ROM, or you can order a printed book through DECdirect at 800-344-4825. Table 5-3 lists the books archived for this release.
| Manual | Order Number |
|---|---|
| A Comparison of System Management on OpenVMS AXP and OpenVMS VAX | AA--PV71B--TE |
| Building Dependable Systems: The OpenVMS Approach | AA--PV5YB--TE |
| Creating an OpenVMS AXP Step 2 Device Driver from a Step 1 Device Driver | AA--Q28TA--TE |
| Creating an OpenVMS AXP Step 2 Device Driver from an OpenVMS VAX Device Driver | AA--Q28UA--TE |
| Guide to OpenVMS AXP Performance Management | AA--Q28WA--TE |
| Guide to OpenVMS Performance Management | AA--PV5XA--TE |
| Migrating an Environment from OpenVMS VAX to OpenVMS Alpha | AA--QSBLA--TE |
| Migrating to an OpenVMS AXP System: Planning for Migration | AA--PV62A--TE |
| Migrating to an OpenVMS AXP System: Recompiling and Relinking Applications | AA--PV63A--TE |
| OpenVMS Alpha Device Support: Developer's Guide | AA--Q28SA--TE |
| OpenVMS Alpha Device Support: Reference | AA--Q28PA--TE |
| OpenVMS Compatibility Between VAX and Alpha | AA--PYQ4C--TE |
| OpenVMS Glossary | AA--PV5UA--TK |
| OpenVMS Programming Environment Manual | AA--PV66B--TK |
| OpenVMS Software Overview | AA--PVXHB--TE |
| OpenVMS VAX Device Support Manual | AA--PWC8A--TE |
| OpenVMS VAX Device Support Reference Manual | AA--PWC9A--TE |
For more detailed information on OpenVMS documentation including components and part numbers, see the Overview of OpenVMS Documentation.
File-based autoconfiguration is a new feature that enables OpenVMS Alpha to configure third-party hardware devices automatically. As of OpenVMS Alpha Version 7.1, device configuration tables are constructed from ASCII text files on the OpenVMS Alpha operating system disk. By adding simple descriptions of their devices in the appropriate ASCII text file, third parties and end users can configure non-Digital supported devices and load user-written device drivers.
This chapter briefly explains device configuration and describes how to use the new file-based autoconfiguration method to configure non-Digital supported devices.
A device is configured on OpenVMS when system code is able to locate it on a bus, give it a name, and load a device driver for it. When a device is autoconfigured, all these steps happen without any user intervention.
Autoconfiguration is the process of discovering the hardware devices on a system and loading the appropriate device drivers. OpenVMS discovers devices during the boot process in a bus-specific manner. The discovery process includes storing data about detected devices in bus-specific data structures. Later, these data structures are used to search configuration tables of known devices. The configuration table provides the information necessary to determine the driver name, device name, and other parameters for loading and connecting the appropriate driver.
Prior to OpenVMS Alpha Version 7.1, configuration tables were built into the OpenVMS kernel and could not be modified without replacing a system image. As of OpenVMS Alpha Version 7.1, the configuration tables are constructed from ASCII text files on the system disk. A system file (SYS$SYSTEM:SYS$CONFIG.DAT) is provided for all OpenVMS supported devices, and a user file (SYS$SYSTEM:SYS$USER_CONFIG.DAT) is provided for all third party, layered product, and user-written device drivers. These files are read by the system during the boot process and used to create a set of configuration tables. These tables are used for subsequent autoconfiguration of hardware devices. Although the tables are built from two files and collected by bus type, they may be considered one logical configuration table of known devices.
Section 6.2 describes how to use the SYS$SYSTEM:SYS$USER_CONFIG.DAT file to autoconfigure devices.
File-based autoconfiguration reads two files during system boot to build the configuration tables of known devices:
Both files use the same format, and the data from both files are combined to create the configuration tables for each bus on the system. The SYS$USER_CONFIG.DAT file is read first, and takes precedence over any duplicate device descriptions contained in both files. If multiple device descriptions exist in a single file, the first occurrence of the description is used.
The configuration files consist of device description blocks, each of which provides the information needed to configure the correct device driver for a device.
Each device description block consists of a series of statements starting with a DEVICE keyword, and ending with the END_DEVICE keyword. Between these two keywords, additional keywords define the hardware ID, the device name, the driver name, the bus type, and any other required or optional information.
The SYS$USER_CONFIG.DAT file is an ASCII text file, which can be processed with any utility that handles variable length record files (for example, a text editor or DCL commands).
Note
The SYS$CONFIG.DAT file is read-only and should NOT be modified by users or by third parties. It should only be modified by Digital, and it may be replaced by OpenVMS upgrades. Inappropriate edits to this file could result in the inability to boot the system.
Statements in the SYS$SYSTEM:SYS$USER_CONFIG.DAT take the general form:
KEYWORD = value
Where the value is a string, a quoted string, or a numeric value. The END_DEVICE keyword has no associated value. For example, a minimal description of a non-disk device might look like the following:
DEVICE = "My device" NAME = UU DRIVER = USER$UUDRIVER ID = 0x0005111 ADAPTER = PCI FLAGS = NOVECTOR END_DEVICE
In this example, the description indicates that when a device with the hardware ID of 5111 (hex) is found on a PCI bus, the device named UU should be configured, and the USER$UUDRIVER device driver should be loaded. This example also specifies that the driver does not want to be connected to an interrupt vector. (If the bus information had a vector, it would be ignored.)
In addition to the values shown in the previous example, the following implied values can also be specified:
UNITS = 1 NUM_VECTORS = 1
These values usually default to the correct values for a single unit controller.
The following syntax rules apply to the SYS$USER_CONFIG.DAT file.
A minimal device description consists of DEVICE, NAME, DRIVER, ADAPTER, and END_DEVICE statements. The following keywords are defined for file-based autoconfiguration device descriptions:
SDA> CLUE CONFIG
.
.
.
Adapter Configuration:
----------------------
TR Adapter ADP Hose Bus BusArrayEntry Node Device Name / HW-Id
-- ----------- -------- ---- -------------------- ---- -------------------
.
.
.
4 PCI 80949900 60 PCI
80949B50 1 MERCURY
80949BC0 GQA: 3 S3 Trio32/64
80949C30 EWA: 5 NI (Tulip)
| NOVECTOR | Device has no interrupt vector. |
| CASE_BLIND | Causes the ID to be treated as an ASCII string and converted to uppercase. In addition, the ID from the hardware will also be converted to uppercase before comparing. This flag is useful for ISA device strings, because the console ISACFG command will not convert the HANDLE to uppercase. If this flag is specified, the ID must be entered in the description as a string, and not as a number, or an error will be displayed and the description ignored. |
| EXTENDED_ID |
The flag is valid only for devices on the PCI bus. Normally, only
32-bit hardware IDs are used for PCI. If you have a PCI board that
supports the V2.1 PCI bus specification, set this flag. The upper
32-bits of the hardware ID should contain the subsystem ID and the
subsystem vendor ID. For example, in the following example, 1133 is the
subsystem ID, and 10DF is the subsystem vendor ID.
FLAGS = EXTENDED_ID
If the EXTENDED_ID flag will be used to load a special driver, but the same ID without the EXTENDED_ID bit will be defined to load a generic driver, the description with the EXTENDED_ID should be located before the generic description. |
| ISA_ON_EISA | This flag is valid only when the value EISA is given to the ADAPTER keyword, and the device is an ISA device. ISA devices should set this flag to insure that the value given to the ID keyword is interpreted correctly. For ISA devices, the system keeps the ID value as an ASCII string. When the system believes that this is an EISA device, the ID value is compressed into binary format. |
USER_PARAM = "some data"
BEGIN_PRIVATE "some data" END_PRIVATE
6480P007.HTM OSSG Documentation 5-DEC-1996 13:50:42.25
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.