V7.1-2

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:

• IOC$DEALLOC_CRCTX
• IOC$ALLOC_CNT_RES
• IOC$DEALLOC_CNT_RES
• IOC$LOAD_MAP

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.

6.25 Adapter Release Notes

V8.2-1

The following sections provide release notes for adapters supported with OpenVMS Version 8.2--1.

6.25.1 Fibre Channel EFI Driver and Firmware Requirements

OpenVMS Version 8.3 for Integrity servers requires that the HP A6826A 2 GB Fibre Channel host-based adapter and its variants have the following minimum version: EFI driver: 1.47 RISC firmware: 3.03.154; HP AB378A and AB379A 4 GB Fibre Channel host-based adapter have the following minimum version: EFI driver: 1.05 RISC firmware: 4.00.70.

To determine the latest, currently supported versions of the RISC firmware and EFI driver, see the README text file provided on the HP IPF Offline Diagnostics and Utilities CD. To locate this file, navigate to the (\efi\hp\tools\io_ cards\fc2) directory for the 2 GB Fibre Channel HBA or \efi\hp\tools\io_ cards\fc4 for the 4 GB HBA. To update the driver and firmware, execute the fcd_update2.nsh or the fcd_update4.nsh , depending on your HBA type. Instructions for obtaining the Offline Diagnostics and Utilities CD are included in the HP OpenVMS Version 8.3 Upgrade and Installation Manual.

6.25.2 Booting with Multiple Fibre Channel Boot Entries

On cell-based systems and newer entry-level systems, the first fibre channel boot entry list is the only valid boot entry. To boot from the other Fibre Channel I64 system disk, go to the EFI Shell and execute "search all", exit the EFI Shell, then select the specified boot entry. This is also required when booting multi-member shadowed system disk.

This appendix contains notifications about OpenVMS products that are no longer supported or that are slated for retirement. It also tells you how to find manuals that have been archived.

Freeware

Once a product is retired, HP does not accept or act on problem reports posted against the product. However, for those interested in doing their own development and support, and where contractual and other considerations permit, product installation kits or source code for many former products can be available as OpenVMS Freeware, which is available from the following sources:

• On the Freeware media that ships with the OpenVMS operating system.
• On the web site at the following address:

V8.2

For OpenVMS Version 8.2, the layered product Compaq Open3D for OpenVMS Alpha V4.9B and earlier versions is not supported. However, it will continue to be supported on OpenVMS Versions 6.2 and 7.3-2 under Mature Product Support (MPS). This product should not be confused with the Open3D product that is integrated into OpenVMS Version 8.2 and supports new cards such as the PowerStorm 300, PowerStorm 350, and ATI RADEON. The product that is no longer supported is 3D support for PixelVision, FFB, TGA, and TGA2-based graphics in releases following OpenVMS Version 7.3-2. See Section 6.19 for a related release note.

If the unsupported Open3D product is installed on your system, you might encounter problems. For example, the DECwindows display server might hang in a CPU-intensive loop. If Open3D is already installed on your current version of OpenVMS and you plan to upgrade to OpenVMS Version 8.2, you must first ensure that none of the following graphics controller boards are installed on your target system:

• ZLX-M Series (PixelVision): ZLX-M1 (PMAGC-AA), ZLX-M2 (PMAGC-BA)
• ZLX-L Series (PixelVision Lite): ZLX-L1 (PMAGC-DA), ZLX-L2 (PMAGC-EA)
• ZLXp-L Series (PixelVision PCI): ZLXp-L1 (PBXGC-A), ZLXp-L2 (PBXGC-B)

V8.2

Starting with OpenVMS Version 8.2, the 3D graphics display feature is licensed with the operating system for both AlphaServers and Integrity servers. Therefore, the Open3D license is not available for Version 8.2 of OpenVMS.

For details, refer to Section 6.14.

A.3 DECamds Not Supported on OpenVMS Version 8.2

V8.2

DECamds is not supported on OpenVMS Version 8.2. HP recommends that users transition to using the Availability Manager in place of DECamds. For information about the Availability Manager, refer to the following website:

A.4 DECevent Not Supported

V8.2

DECevent and the DIAGNOSE command are not supported on OpenVMS Version 8.2.

Replacements for DECevent include the following:

• System Event Analyzer (SEA)
  SEA is now the supported error log analysis tool for OpenVMS and for later hardware platforms (for example, all I64 platforms, and the Alpha DSnn, ESnn, and most GSnn platforms).
  Install the latest available version of WEBES to receive the latest hardware support, including SEA. At a minimum, WEBES Version 4.2 or higher is required on Alpha systems, and Version 4.4 or higher is required on I64 systems.
  For detailed information about operating system requirements and supported hardware for SEA, refer to the WEBES Installation Guide, which is with the other WEBES documentation at the following web site:
• Error Log Viewer (ELV)
  You can use ELV to quickly examine an error log file that was created on these later hardware platforms. ELV is integrated into the OpenVMS operating system and can be accessed by entering the DCL command ANALYZE/ERROR_LOG/ELV.
  For more information about ELV, refer to the ELV chapter in HP OpenVMS System Management Utilities Reference Manual.

V8.2

On December 31, 2004, DECwrite reached its End-of-Service life and has been removed from the Software Products Library.

A.6 Error Log Report Formatter (ERF) Unsupported

V8.2

The Error Log Report Formatter (ERF) is no longer supported. If you require this product for use with error logs written on older systems running OpenVMS versions prior to Version 7.2, you can access ERF documentation from the Freeware website:

The Error Log Viewer (ELV) replaces ERF. For more information, refer to online help for ANALYZE/ERROR_LOG/ELV or see the HP OpenVMS System Management Utilities Reference Manual.

Before using ERF, you must convert error log files using ELV's CONVERT command or the Binary Error Log Translation utility, which is part of DECevent. DECevent and the DIAGNOSE command are no longer supported, but users who need these tools can download the software and related documentation from the Freeware website:

Until you install the DECevent software, you will get an error if you try to use the DIAGNOSE command.

A.7 ISA_CONFIG.DAT Unsupported in Future Release

V7.1

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.8 POSIX 1003.4a Draft 4 Interface May Be Retired

V7.0

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.9 NetBeans Version 3.6 Support Ends with OpenVMS Version 8.3

V8.3

OpenVMS Alpha and I64 Version 8.3 are the last releases on which NetBeans Version 3.6 for OpenVMS is supported. NetBeans Version 3.6 will be supported over the support life of OpenVMS Version 8.3. Also, note that NetBeans Version 3.6 for OpenVMS Alpha and I64 is supported only on Java^tm Platform, Standard Edition, Development Kit (JDK) v 1.4.2-x.

For a GUI-based development environment on OpenVMS, please consider using Distributed NetBeans, which provides a cost-effective and flexible development environment solution. More information about Distributed NetBeans can be found at:

http://www.hp.com/products/openvms/distributednetbeans/

A.10 Last Ordering Dates for Alpha Systems

V8.2

The following deadlines apply for ordering Alpha systems:

Product	Final Order Date
Alpha systems	October 27, 2006
CPU upgrades	November 30, 2007

A.11 Archived Manuals

V8.3

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 following web site:

Click on "Archived documents" in the left sidebar to link to the archived manuals.

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

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:

SYS$SYSTEM:SRM_CHECK.EXE

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.

B.3 Noncompliant Code Characteristics

The areas of noncompliance detected by the SRM_CHECK tool can be grouped into the following four categories. Most of these can be fixed by recompiling with new compilers. In rare cases, the source code may need to be modified. See Section B.5 for information about compiler versions.

• Some versions of OpenVMS compilers introduce noncompliant code sequences during an optimization called "loop rotation." This problem can be triggered only in C or C++ programs that use LDx_L/STx_C instructions in assembly language code that is embedded in the C/C++ source using the ASM function, or in assembly language written in MACRO--32 or MACRO--64. In some cases, a branch was introduced between the LDx_L and STx_C instructions.
  This can be addressed by recompiling.
• Some code compiled with very old BLISS, MACRO--32, DEC Pascal, or DEC COBOL compilers may contain noncompliant sequences. Early versions of these compilers contained a code scheduling bug where a load was incorrectly scheduled after a load_locked.
  This can be addressed by recompiling.
• In rare cases, the MACRO--32 compiler may generate a noncompliant code sequence for a BBSSI or BBCCI instruction where there are too few free registers.
  This can be addressed by recompiling.
• Errors may be generated by incorrectly coded MACRO--64 or MACRO--32 and incorrectly coded assembly language embedded in C or C++ source using the ASM function.
  This requires source code changes. The new MACRO--32 compiler flags noncompliant code at compile time.

If the SRM_CHECK tool finds a violation in an image, you should recompile the image with the appropriate compiler (see Section B.5). After recompiling, you should analyze the image again. If violations remain after recompiling, examine the source code to determine why the code scheduling violation exists. Then make the appropriate changes to the source code.

B.4 Coding Requirements

The Alpha Architecture Reference Manual describes how an atomic update of data between processors must be formed. The Third Edition, in particular, has much more information on this topic. This edition details the conventions of the interlocked memory sequence.

Exceptions to the following two requirements are the source of all known noncompliant code:

• There cannot be a memory operation (load or store) between the LDx_L (load locked) and STx_C (store conditional) instructions in an interlocked sequence.
• There cannot be a branch taken between an LDx_L and an STx_C instruction. Rather, execution must "fall through" from the LDx_L to the STx_C without taking a branch.
  Any branch whose target is between an LDx_L and matching STx_C creates a noncompliant sequence. For instance, any branch to "label" in the following example would result in noncompliant code, regardless of whether the branch instruction itself was within or outside of the sequence:

  LDx_L Rx, n(Ry) ... label: ... STx_C Rx, n(Ry)

Therefore, the SRM_CHECK tool looks for the following:

• Any memory operation (LDx/STx) between an LDx_L and an STx_C
• Any branch that has a destination between an LDx_L and an STx_C
• STx_C instructions that do not have a preceding LDx_L instruction
  This typically indicates that a backward branch is taken from an LDx_L to the STx_C Note that hardware device drivers that do device mailbox writes are an exception. These drivers use the STx_C to write the mailbox. This condition is found only on early Alpha systems and not on PCI-based systems.
• Excessive instructions between an LDx_L and an STxC
  The AARM recommends that no more than 40 instructions appear between an LDx_l and an STx_C. In theory, more than 40 instructions can cause hardware interrupts to keep the sequence from completing. However, there are no known occurrences of this.

To illustrate, the following are examples of code flagged by SRM_CHECK.

** Found an unexpected ldq at 0008291C 00082914 AC300000 ldq_l R1, (R16) 00082918 2284FFEC lda R20, 0xFFEC(R4) 0008291C A6A20038 ldq R21, 0x38(R2)

In the above example, an LDQ instruction was found after an LDQ_L before the matching STQ_C. The LDQ must be moved out of the sequence, either by recompiling or by source code changes. (See Section B.3.)

** Backward branch from 000405B0 to a STx_C sequence at 0004059C 00040598 C3E00003 br R31, 000405A8 0004059C 47F20400 bis R31, R18, R0 000405A0 B8100000 stl_c R0, (R16) 000405A4 F4000003 bne R0, 000405B4 000405A8 A8300000 ldl_l R1, (R16) 000405AC 40310DA0 cmple R1, R17, R0 000405B0 F41FFFFA bne R0, 0004059C

In the above example, a branch was discovered between the LDL_L and STQ_C. In this case, there is no "fall through" path between the LDx_L and STx_C, which the architecture requires.

The following MACRO--32 source code demonstrates code where there is a "fall through" path, but this case is still noncompliant because of the potential branch and a memory reference in the lock sequence:

getlck: evax_ldql r0, lockdata(r8) ; Get the lock data movl index, r2 ; and the current index. tstl r0 ; If the lock is zero, beql is_clear ; skip ahead to store. movl r3, r2 ; Else, set special index. is_clear: incl r0 ; Increment lock count evax_stqc r0, lockdata(r8) ; and store it. tstl r0 ; Did store succeed? beql getlck ; Retry if not.

To correct this code, the memory access to read the value of INDEX must first be moved outside the LDQ_L/STQ_C sequence. Next, the branch between the LDQ_L and STQ_C, to the label IS_CLEAR, must be eliminated. In this case, it could be done using a CMOVEQ instruction. The CMOVxx instructions are frequently useful for eliminating branches around simple value moves. The following example shows the corrected code:

movl index, r2 ; Get the current index getlck: evax_ldql r0, lockdata(r8) ; and then the lock data. evax_cmoveq r0, r3, r2 ; If zero, use special index. incl r0 ; Increment lock count evax_stqc r0, lockdata(r8) ; and store it. tstl r0 ; Did write succeed? beql getlck ; Retry if not.