HP OpenVMS Systems Documentation
HP OpenVMS Alpha Version 7.3--2 Release Notes
6.16 RZnn Disk Drive Considerations
The following notes describe issues related to various RZ disk drives.
During the testing of HP supported SCSI disk drives on configurations with DWZZAs and long differential SCSI buses, two drives, RZ25M and RZ26N, were found to have bus phase problems. For this reason, do not use these drives in configurations where the differential bus length connecting DWZZAs equals or exceeds 20 meters.
This recommendation applies only to the RZ25M and RZ26N drives. All
other disk drives that are listed as supported in the OpenVMS SPD can
be used in configurations to the full bus lengths of the SCSI-2
The minimum firmware revision level recommended for RZ26N and RZ28M disks is Revision 0568.
If the latest firmware revision level is not used with these disks,
multiple problems can occur.
If you install RZ26L or RZ28 disks on a multihost SCSI bus in an OpenVMS Cluster, the disk's minimum firmware revision is 442.
The following sections describe a procedure that you can use to update the firmware on some RZ26L and RZ28 drives. This procedure can only be used with drives that are directly connected to a SCSI adapter on a host system. Drives that are attached through an intelligent controller (such as an HSZ40 or KZPSC) cannot be updated using this procedure. Refer to the intelligent controller's documentation to determine whether an alternative firmware update procedure exists.
188.8.131.52 Firmware Revision Level 442 Requirements
Only the combinations of disk drives and firmware revision levels listed in Table 6-4 are capable of being upgraded safely to firmware revision level 442. Performing the update procedure on any other combination can permanently damage the disk.
184.108.40.206 Firmware Revision Level 442 Installation Procedure
If you determine that your disk requires revision level 442 firmware and it is capable of being upgraded safely, use the following procedure to update the firmware. (See Table 6-4 for the file name of the disk you are upgrading.)
6.17 ZLX Graphics Boards Support
You must install Open3D for OpenVMS Alpha to support the following families of graphics boards:
The latest version of Open3D for OpenVMS Alpha is V4.9B. To access the latest versions of Open3D for OpenVMS Alpha, check the Software Products Library at the following URL:
Click on "SPL master index" in the left sidebar. Then click
on the date for OpenVMS Alpha under Current Software Products Library
and search for Compaq Open3D in the list.
The following sections contain release notes pertaining to recompiling
and relinking OpenVMS device drivers.
All OpenVMS Alpha SCSI device drivers from previous versions of OpenVMS must be recompiled and relinked to run correctly on OpenVMS Version 7.3-1 or higher.
If you have an OpenVMS Alpha SCSI driver that you are upgrading from a version prior to OpenVMS Alpha 7.0, see Section 6.18.2.
Note that for OpenVMS Version 7.1 all OpenVMS VAX SCSI device drivers
required recompiling and relinking. OpenVMS VAX device drivers that
were recompiled and relinked to run on OpenVMS Version 7.1 will run
correctly on OpenVMS Version 7.3 or higher.
Device drivers that were recompiled and relinked to run on OpenVMS Alpha Version 7.0 do not require source-code changes and do not have to be recompiled and relinked to run on OpenVMS Alpha Version 7.1 and higher. (Note that Alpha SCSI drivers, however, must be recompiled and relinked as described in Section 6.18.1.)
Device drivers from releases prior to OpenVMS Alpha Version 7.0 that were not recompiled and relinked for OpenVMS Alpha Version 7.0 must be recompiled and relinked to run on OpenVMS Alpha Version 7.1 and higher.
OpenVMS Alpha Version 7.0 included significant changes to OpenVMS Alpha
privileged interfaces and data structures. As a result of these
changes, device drivers from releases prior to OpenVMS Alpha Version
7.0 may also require source-code changes to run correctly on OpenVMS
Alpha Version 7.0 and higher. For more details about OpenVMS Alpha
Version 7.0 changes that may require source changes to customer-written
drivers, refer to the OpenVMS Alpha Guide to Upgrading Privileged-Code Applications.
As of OpenVMS Version 7.3, when SYSTEM_CHECK is enabled, device driver
images with names of the form SYS$nnDRIVER_MON.EXE will be
automatically loaded by the system loader. If a corresponding _MON
version does not exist, the system will use the default image name:
Alpha hardware platforms that support PCI, EISA, and ISA buses deliver I/O device interrupts at different IPLs, either 20 or 21. The IPL at which device interrupts are delivered can change if you move the device from one platform to another. This is a problem if the driver declares its device IPL to be 20, and then that driver is executed on a machine that delivers I/O device interrupts at IPL 21.
The simplest solution to this problem is for PCI, EISA, and ISA device drivers to use IPL 21. This works correctly on platforms that deliver I/O device interrupts at IPL 20 and on platforms that deliver I/O device interrupts at IPL 21.
A future release of OpenVMS Alpha may provide a platform-independent
mechanism for drivers to determine the device IPL dynamically.
The system routines that you can use to manage the Counted Resource Context Block (CRCTX) data structure have been improved. The following routines now set and check the status (CRCTX$V_ITEM_VALID) of the CRCTX data structure:
These routines have changed as follows:
If you call IOC$DEALLOC_CRCTX with a valid CRCTX status (CRCTX$V_ITEM_VALID set to 1), the service returns a bad status. If the SYSBOOT parameter SYSTEM_CHECK is set, the system will fail. This prevents users from deallocating a CRCTX when they have valid resources that have not been deallocated.
You must call IOC$ALLOC_CNT_RES with an invalid CRCTX status (CRCTX$V_ITEM_VALID set to 0). If you call this routine with a valid status, OpenVMS assumes that you will lose the resources mapped by this CRCTX. OpenVMS does not allocate new resources and returns a bad status. If SYSTEM_CHECK is set, the system will fail. IOC$ALLOC_CNT_RES sets the valid bit before it returns.
IOC$DEALLOC_CNT_RES must be called with a valid CRCTX (CRCTX$V_ITEM_VALID set to 1). If you call IOC$DEALLOC_CNT_RES with an invalid CRCTX, OpenVMS assumes that the other parameters are not valid, and returns a bad status. If SYSTEM_CHECK is set, the system will fail. IOC$DEALLOC_CNT_RES clears the valid bit before it returns.
IOC$LOAD_MAP must be called with a valid CRCTX. If it is called with an invalid CRCTX (CRCTX$V_ITEM_VALID set to 0), it assumes that the other parameters are also invalid, and returns a bad status. If the SYSBOOT parameter SYSTEM_CHECK is set, the system will fail.
These improvements indicate to device support and privileged-code application developers whether they need to deallocate scatter gather registers, which are treated by OpenVMS as generic resources. If the CRCTX$V_ITEM_VALID bit is set, IOC$DEALLOC_CNT_RES still needs to be called.
Support for using the SYS$MANAGER:ISA_CONFIG.DAT file to configure ISA
devices will be discontinued in a future release of OpenVMS Alpha. If
you use this file, you should convert to using the ISACFG utility from
the console, and the new file-based autoconfiguration method for
loading device drivers (as described in Writing OpenVMS Alpha
Device Drivers in C).
A.3 POSIX 1003.4a Draft 4 Interface May Be Retired
The POSIX 1003.4a, Draft 4 (or "d4") interface of the Compaq POSIX
Threads Library (formerly named DECthreads) is slated for retirement in
a future release. Applications that were written using the POSIX
1003.4a, Draft 4 interface should be migrated to the new POSIX 1003.1c
standard (or "pthread") interface provided by the POSIX Threads
Library. A compatibility mode for the Draft 4 POSIX 1003.4a interface
has been provided in this release to help ease migration. This
compatibility mode will be removed in a future release.
A.4 Archived Manuals
As products are retired and the operating system evolves, certain OpenVMS manuals are archived. Archived manuals are no longer maintained and are not part of the OpenVMS documentation set. However, they are available on the OpenVMS Documentation CD-ROM and the following web site:
Information previously contained in the OpenVMS Guide to Extended File Specifications has been moved into other manuals and this manual is now obsolete.
The following table provides pointers to the new locations of topics from the archived manual:
|Chapter 1 Overview of Extended File Specifications for OpenVMS|
|All||HP OpenVMS System Manager's Manual, Volume 1: Essentials||Chapter 9|
|Chapter 2 Managing Extended File Naming on OpenVMS Systems|
|All except Section 2.2.1, Using RMS Default EFS Features||HP OpenVMS System Manager's Manual, Volume 1: Essentials||Chapters 9 and 10|
|Section 2.2.1, Using RMS Default EFS Features||Guide to OpenVMS File Applications||Chapter 6|
|Chapter 3 Extended File Naming Characteristics|
|All except Section 3.5, DCL Commands and Utilities||OpenVMS User's Manual||Chapter 5|
|Section 3.5, DCL Commands and Utilities||HP OpenVMS DCL Dictionary||Alphabetically by command|
|Chapter 4 Extended File Naming Considerations for OpenVMS Application Developers|
|All||OpenVMS Programming Concepts Manual, Volume II||Chapter 29|
|Appendix A Setting Users' Expectations of Extended File Specifications|
|Section A.1, ACP Interface (ODS-5)||HP OpenVMS I/O User's Reference Manual||Chapter 1|
|Section A.4, Restrictions||Guide to OpenVMS File Applications||Chapter 5|
|All except Sections A.1, A.4||HP OpenVMS System Manager's Manual, Volume 1: Essentials||Chapter 10|
|Appendix B Technical Information|
|Section B.1, System Services Changes||HP OpenVMS System Services Reference Manual||Alphabetically by routine|
|Section B.2, Record Management Services (RMS) Changes||Guide to OpenVMS File Applications||See below|
|Section B.2.1, Record Management Services (RMS) Changes||Guide to OpenVMS File Applications||Chapter 5|
|Section B.2.2, Record Management Services (RMS) Changes (except Section B.2.2.7, DID Abbreviation and Section B.2.2.8, FID Abbreviation)||Guide to OpenVMS File Applications||Chapter 5|
|Section B.2.2.7 (DID Abbreviation)||Guide to OpenVMS File Applications||Chapter 6|
|Section B.2.2.8 (FID Abbreviation)||Guide to OpenVMS File Applications||Chapter 6|
|Section B.2.3, RMS Data Structure Changes (NAM Block)||OpenVMS Record Management Services Reference Manual||Chapter 5|
|Section B.2.3, RMS Data Structure Changes (NAML Block)||OpenVMS Record Management Services Reference Manual||Chapter 6|
|Section B.3, Files-11 XQP Changes||HP OpenVMS I/O User's Reference Manual||Chapter 1|
|Section B.4, Programming Utility Changes||OpenVMS Utility Routines Manual||Chapter 10|
|Section B.5, Run-Time Library Changes||OpenVMS RTL Library (LIB$) Manual||Alphabetically by routine|
|Appendix C Character Sets|
|All||OpenVMS User's Manual||Appendix A|
The Alpha Architecture Reference Manual, Third Edition (AARM) describes strict rules for using interlocked memory instructions. The Alpha 21264 (EV6) processor and all future Alpha processors are more stringent than their predecessors in their requirement that these rules be followed. As a result, code that has worked in the past, despite noncompliance, could fail when executed on systems featuring the 21264 processor and its successors. Occurrences of these noncompliant code sequences are believed to be rare. Note that the 21264 processor is not supported on versions prior to OpenVMS Alpha Version 7.1-2.
Noncompliant code can result in a loss of synchronization between processors when interprocessor locks are used, or can result in an infinite loop when an interlocked sequence always fails. Such behavior has occurred in some code sequences in programs compiled on old versions of the BLISS compiler, some versions of the MACRO--32 compiler and the MACRO--64 assembler, and in some HP C and C++ programs.
The affected code sequences use LDx_L/STx_C instructions, either
directly in assembly language sources or in code generated by a
compiler. Applications most likely to use interlocked instructions are
complex, multithreaded applications or device drivers using highly
optimized, hand-crafted locking and synchronization techniques.
B.1 Required Code Checks
OpenVMS recommends that code that will run on the 21264 processor be checked for these sequences. Particular attention should be paid to any code that does interprocess locking, multithreading, or interprocessor communication.
The SRM_CHECK tool has been developed to analyze Alpha executables for
noncompliant code sequences. The tool detects sequences that may fail,
reports any errors, and displays the machine code of the failing
B.2 Using the Code Analysis Tool (SRM_CHECK)
The SRM_CHECK tool can be found in the following location on the OpenVMS Alpha Version 7.3-2 Operating System CD-ROM:
To run the SRM_CHECK tool, define it as a foreign command (or use the DCL$PATH mechanism) and invoke it with the name of the image to check. If a problem is found, the machine code is displayed and some image information is printed. The following example illustrates how to use the tool to analyze an image called myimage.exe:
$ define DCL$PATH  $ srm_check myimage.exe
The tool supports wildcard searches. Use the following command line to initiate a wildcard search:
$ srm_check [*...]* -log
Use the -log qualifier to generate a list of images that have been checked. You can use the -output qualifier to write the output to a data file. For example, the following command directs output to a file named CHECK.DAT:
$ srm_check 'file' -output check.dat
You can use the output from the tool to find the module that generated the sequence by looking in the image's MAP file. The addresses shown correspond directly to the addresses that can be found in the MAP file.
The following example illustrates the output from using the analysis tool on an image named SYSTEM_SYNCHRONIZATION.EXE:
** Potential Alpha Architecture Violation(s) found in file... ** Found an unexpected ldq at 00003618 0000360C AD970130 ldq_l R12, 0x130(R23) 00003610 4596000A and R12, R22, R10 00003614 F5400006 bne R10, 00003630 00003618 A54B0000 ldq R10, (R11) Image Name: SYSTEM_SYNCHRONIZATION Image Ident: X-3 Link Time: 5-NOV-1998 22:55:58.10 Build Ident: X6P7-SSB-0000 Header Size: 584 Image Section: 0, vbn: 3, va: 0x0, flags: RESIDENT EXE (0x880)
The MAP file for system_synchronization.exe contains the following:
EXEC$NONPAGED_CODE 00000000 0000B317 0000B318 ( 45848.) 2 ** 5 SMPROUT 00000000 000047BB 000047BC ( 18364.) 2 ** 5 SMPINITIAL 000047C0 000061E7 00001A28 ( 6696.) 2 ** 5
The address 360C is in the SMPROUT module, which contains the addresses from 0-47BB. By looking at the machine code output from the module, you can locate the code and use the listing line number to identify the corresponding source code. If SMPROUT had a nonzero base, you would need to subtract the base from the address (360C in this case) to find the relative address in the listing file.
Note that the tool reports potential violations in its output. Although SRM_CHECK can normally identify a code section in an image by the section's attributes, it is possible for OpenVMS images to contain data sections with those same attributes. As a result, SRM_CHECK may scan data as if it were code, and occasionally, a block of data may look like a noncompliant code sequence. This circumstance is rare and can be detected by examining the MAP and listing files.