____________________________________________________ OpenVMS Version 7.2 Release Notes Order Number: AA-QSBTC-TE January 1999 This manual describes changes to the software; installation, upgrade, and compatibility information; new and existing software problems and restrictions; and software and documentation corrections. Revision/Update Information: This is a new manual. Software Version: OpenVMS Alpha Version 7.2 OpenVMS VAX Version 7.2 Compaq Computer Corporation Houston, Texas ________________________________________________________________ January 1999 Compaq Computer Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description. Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Compaq or an authorized sublicensor. Compaq conducts its business in a manner that conserves the environment and protects the safety and health of its employees, customers, and the community. © Compaq Computer Corporation 1999. All rights reserved. The following are trademarks of Compaq Computer Corporation: Alpha, AlphaGeneration, AlphaServer, AlphaStation, Bookreader, CDA, CI, Compaq, DEC, DEC Ada, DEC BASIC, DEC Fortran, DEC Notes, DECdirect, DECdtm, DECevent, DECforms, DECmigrate, DECnet, DECpresent, DECthreads, DIGITAL, HSC, HSC40, HSC70, HSJ, HSZ, InfoServer, LAT, LinkWorks, MSCP, OpenVMS, PATHWORKS, POLYCENTER, RZ, StorageWorks, TMSCP, VAX, VMS, and the Compaq logo. The following are third-party trademarks: Adaptec is a trademark of Adaptec, Inc. Adobe, Display PostScript, and PostScript are registered trademarks of Adobe Systems Incorporated. IEEE and POSIX are registered trademarks of the Institute of Electrical and Electronics Engineers, Inc. Java is a registered trademark of Sun Microsystems, Inc. Microsoft, Windows, and Windows NT are registered trademarks and Windows 95 is a trademark of Microsoft Corporation. Mosaic is a trademark of the University of Illinois. Motif is a registered trademark of the Open Software Foundation, Inc. MultiNet is a registered trademark of Process Software Corporation. Netscape and the Netscape Navigator are registered trademarks of Netscape Communications Corporation. OSI is a registered trademark of CA Management, Inc. Spyglass is a registered trademark of Spyglass, Inc. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Limited. Wind/U is a registered trademark of Bristol Technology Inc. X/Open is a trademark of X/Open Company Limited. All other trademarks and registered trademarks are the property of their respective holders. ZK6534 The OpenVMS documentation set is available on CD-ROM. _________________________________________________________________ Contents Preface................................................... xxiii 1 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.1 Compaq's Support Policy....................... 1-1 1.2 Installation and Upgrade Information Common to VAX and Alpha ................................ 1-2 1.2.1 Changes and Enhancements.................. 1-2 1.2.1.1 Networking Options...................... 1-2 1.2.1.2 Installing Network Transport Products... 1-4 1.2.1.3 Upgrading Systems Running PATHWORKS V6.0/6.0A for OpenVMS (Advanced Server)................................. 1-5 1.2.1.4 DECevent Version 2.9 or Later Required to Analyze Errors....................... 1-6 1.2.1.5 OpenVMS Cluster Compatibility Kits for Version 6.2 Systems..................... 1-6 1.2.2 Problems and Restrictions................. 1-7 1.2.2.1 PCSI-I-RETAIN Messages During DECnet-Plus Installation ............... 1-7 1.3 Installation and Upgrade Information Specific to VAX........................................ 1-8 1.3.1 Changes and Enhancements.................. 1-8 1.3.1.1 Magnetic Tape Distribution.............. 1-8 1.3.2 Problems and Restrictions................. 1-9 1.3.2.1 Error at Shutdown After Booting CD-ROM for Full Environment Installation....... 1-9 1.3.2.2 Changing System Time Causes Write Lock Error................................... 1-9 1.4 Installation and Upgrade Information Specific to Alpha...................................... 1-10 v 1.4.1 Changes and Enhancements.................. 1-10 1.4.1.1 64 MB of Memory Required ............... 1-10 1.4.2 Problems and Restrictions................. 1-10 1.4.2.1 BAP System Parameter Tuning Required ... 1-10 1.4.2.2 DECwindows Motif V1.2-5 Provided in Reference Format ....................... 1-12 1.4.2.3 Remove Java Version A1.1 Before Upgrading .............................. 1-13 1.4.2.4 Spiralog File System Not Supported...... 1-14 1.4.2.5 Error When Upgrading DIGITAL TCP/IP Services for OpenVMS.................... 1-14 1.4.2.6 Error When Removing DIGITAL TCP/IP Services for OpenVMS (UCX) Version 4.2..................................... 1-15 1.4.2.7 Rolling Upgrades for MEMORY CHANNEL Configurations ......................... 1-16 1.4.2.8 X.25 Version 1.0-G and Earlier Not Supported .............................. 1-16 1.4.2.9 X.25 Version 1.1-B for OpenVMS Alpha Crashes OpenVMS Version 7.2............. 1-16 1.5 ALPHAbook 1 (Alpha Only)...................... 1-17 1.5.1 Using the SCSI_MODE Utility............... 1-17 1.5.2 Naming Serial Line Devices................ 1-18 1.5.3 Graphics Display Modes.................... 1-18 1.5.4 Customizing the Graphics Display.......... 1-18 1.5.5 PCMCIA Bus Support........................ 1-20 1.5.6 Audio Support............................. 1-22 1.5.7 Keyboard Mapping.......................... 1-22 1.5.8 OpenVMS Cluster Restrictions.............. 1-25 1.6 AlphaServer 1000A (Alpha Only)................ 1-25 1.6.1 Problems and Restrictions................. 1-25 1.6.1.1 Bus Probe Algorithm Default............. 1-25 1.6.1.2 Installation Failure with DEFPA Adapter................................. 1-25 1.7 AlphaServer 2100 (Alpha Only)................. 1-25 1.7.1 Console Display........................... 1-26 1.7.2 SCSI Controller Restriction............... 1-27 1.8 AlphaServer 4100 (Alpha Only)................. 1-27 1.8.1 Problems and Restrictions................. 1-27 1.8.1.1 EISA Configuration Utility (ECU)........ 1-27 1.8.2 FRU Table Error........................... 1-28 1.9 AlphaServer 8200 and AlphaServer 8400 (Alpha Only)......................................... 1-29 vi 1.9.1 Problems and Restrictions................. 1-29 1.9.1.1 Field Replaceable Units (FRU) Table Error .................................. 1-29 1.9.1.2 Environmental Data Restrictions......... 1-29 1.10 AlphaStation 255 (Alpha Only)................. 1-30 1.11 DEC 7000 (Alpha Only)......................... 1-30 1.11.1 Changes and Enhancements.................. 1-30 1.11.1.1 Ctrl/P Behavior Change During Boot ..... 1-30 1.12 DECwindows X11 Display Server (Alpha Only).... 1-30 1.12.1 Changes and Enhancements.................. 1-30 1.12.1.1 Ctrl/F2 Behavior Change................. 1-30 1.12.2 Problems and Restrictions................. 1-31 1.12.2.1 Graphics Boards Support ................ 1-31 1.12.2.2 PowerStorm Graphics Cards Can Hang System ................................. 1-31 1.12.2.3 S3 Multihead Graphics................... 1-32 1.13 DIGITAL Modular Computing Components (DMCC) (Alpha Only).................................. 1-32 1.13.1 Problems and Restrictions................. 1-32 1.13.1.1 CPUSPINWAIT Crash and Recovery on DMCC 21164A Systems ......................... 1-32 1.13.1.2 Alpha 5/366 and 5/433 PICMG SBC Restriction ............................ 1-32 1.13.1.3 Updating the SRM Console ............... 1-32 1.14 OSU HTTP Server............................... 1-33 1.14.1 Problems and Restrictions................. 1-33 1.14.1.1 Running on OpenVMS Version 7.2.......... 1-33 1.15 RF73 and Other RFnn DSSI Disk Devices ........ 1-33 1.15.1 Problems and Restrictions................. 1-34 1.15.1.1 RF73 and Other RFnn DSSI Disk Devices and Controller Memory Errors............ 1-34 2 OpenVMS Layered Products Release Notes 2.1 Layered Product Support....................... 2-1 2.2 Advanced Server V7.2 for OpenVMS (Alpha Only)......................................... 2-2 2.3 DEC BASIC..................................... 2-3 2.3.1 Problems and Restrictions................. 2-3 2.3.1.1 BASIC$STARLET.TLB Build Restriction (Alpha Only)............................ 2-3 2.4 DEC C and DEC C++............................. 2-4 vii 2.4.1 Changes and Enhancements.................. 2-4 2.4.1.1 STARLET Header Files Now Ship with OpenVMS VAX............................. 2-5 2.4.2 Problems and Restrictions................. 2-5 2.4.2.1 Pre-Version 5.2 Kits May Delete SYS$STARLET_C.TLB (VAX Only)............ 2-5 2.4.2.2 DEC C++ Version 5.3 Installation Fails (VAX Only).............................. 2-5 2.5 DEC Pascal.................................... 2-6 2.5.1 Problems and Restrictions................. 2-6 2.5.1.1 Installing DEC Pascal Version 5.5 After an Upgrade (Alpha Only)................. 2-6 2.6 DEC PL/I ..................................... 2-6 2.6.1 Problems and Restrictions................. 2-6 2.6.1.1 RTL Support for OpenVMS ................ 2-6 2.7 DECdfs for OpenVMS............................ 2-7 2.7.1 Problems and Restrictions................. 2-7 2.7.1.1 Version 2.3 Required for OpenVMS Alpha................................... 2-7 2.8 DECforms...................................... 2-7 2.8.1 Problems and Restrictions................. 2-7 2.8.1.1 Support on OpenVMS Version 7.0 and Later (Alpha Only)............................ 2-7 2.9 DECnet Layered Products ...................... 2-8 2.9.1 Problems and Restrictions................. 2-8 2.9.2 Documentation Changes and Corrections..... 2-8 2.9.2.1 DECnet-Plus for OpenVMS Network Management.............................. 2-8 2.10 DECpresent.................................... 2-8 2.10.1 Problems and Restrictions................. 2-8 2.10.1.1 Installation Dependency on OpenVMS VAX Version 6.1 or Later ................... 2-9 2.11 DECram........................................ 2-9 2.11.1 Problems and Restrictions................. 2-9 2.11.1.1 DECram Version 2.3 Is Required (Alpha Only) .................................. 2-9 2.12 DECwindows Motif for OpenVMS ................. 2-11 2.12.1 Changes and Enhancements.................. 2-11 2.12.1.1 Version 1.2-5 Ships with Year 2000 Enhancements............................ 2-11 2.12.1.2 Year 2000 Kits for Versions 1.2-3 and 1.2-4 .................................. 2-11 2.12.1.3 Adobe Display PostScript Support........ 2-12 viii 2.12.1.4 Spyglass Enhanced Mosaic Support........ 2-12 2.12.1.5 Installing Version 1.2-5 on Older OpenVMS Releases........................ 2-12 2.12.1.6 DECwindows Motif Version 1.2 for OpenVMS No Longer Supported .................... 2-13 2.12.2 Problems and Restrictions................. 2-13 2.12.2.1 System Parameter Values Required for Installation ........................... 2-14 2.12.2.2 Language Variants Not Available in Some Versions ............................... 2-14 2.12.2.3 Remedial Kits for DECwindows Motif Version 1.2-3........................... 2-14 2.12.2.4 Console Broadcasts Disabled............. 2-16 2.12.2.5 System Files Purged During Startup...... 2-18 2.12.3 Documentation Changes and Corrections..... 2-18 2.12.3.1 Getting Started With the New Desktop (Alpha Only)............................ 2-18 2.13 Digital Distributed Computing Environment (DCE) for OpenVMS............................. 2-19 2.13.1 Changes and Enhancements.................. 2-19 2.13.1.1 DCE System Management Command Procedure............................... 2-19 2.13.2 Problems and Restrictions................. 2-20 2.13.2.1 Authenticated RPC Functionality Not Available............................... 2-20 2.14 DIGITAL TCP/IP Services for OpenVMS........... 2-21 2.14.1 Changes and Enhancements.................. 2-21 2.14.1.1 Changes in Version 5.0 ................. 2-21 2.15 PATHWORKS for OpenVMS......................... 2-22 2.15.1 Changes and Enhancements.................. 2-23 2.15.1.1 PATHWORKS Advanced Server V6.0/6.0A Replacement ............................ 2-23 2.15.1.2 PATHWORKS V5 for OpenVMS (LAN Manager) Not Supported .......................... 2-23 2.16 POSIX for OpenVMS............................. 2-24 2.16.1 Problems and Restrictions................. 2-24 2.16.1.1 POSIX for OpenVMS Is Not Supported...... 2-24 2.17 Process MultiNet for OpenVMS ................. 2-24 2.17.1 Changes and Enhancements.................. 2-24 2.17.1.1 Update Required for OpenVMS Alpha Version 7.2............................. 2-24 2.18 Wind/U Products for OpenVMS................... 2-25 ix 3 General User Release Notes 3.1 COM for OpenVMS (Alpha Only).................. 3-1 3.1.1 Problems and Restrictions................. 3-1 3.1.1.1 Field Test Versions Incompatible with OpenVMS Version 7.2..................... 3-1 3.2 DCL Commands.................................. 3-2 3.2.1 Changes and Enhancements.................. 3-2 3.2.2 Problems and Restrictions................. 3-2 3.2.2.1 SET PROCESS/NOAUTO_UNSHELVE Command in Cluster Environment .................... 3-2 3.3 DECTPU ....................................... 3-2 3.3.1 Problems and Restrictions................. 3-2 3.3.1.1 Motif Widget Context Help Built-In...... 3-2 3.3.2 Documentation Changes and Corrections..... 3-3 3.3.2.1 DEC Text Processing Utility Reference Manual.................................. 3-3 3.4 High-Performance Sort/Merge Utility (Alpha Only)......................................... 3-3 3.4.1 Problems and Restrictions................. 3-3 3.4.1.1 Concurrent Sort Operations.............. 3-4 3.4.2 Corrections............................... 3-4 3.4.2.1 Error Messages Problem Fixed............ 3-4 3.4.2.2 Merging Stream Files Limitation Fixed... 3-4 4 System Management Release Notes 4.1 Alpha System Dump Analyzer (SDA) ............. 4-1 4.1.1 Changes and Enhancements.................. 4-1 4.1.1.1 Number of Nonpaged Pool Lookaside Lists Increased............................... 4-1 4.2 Backup Utility ............................... 4-1 4.2.1 Changes and Enhancements.................. 4-1 4.2.1.1 Writing a Save Set to a Files-11 Mounted Disk.................................... 4-2 4.2.2 Problems and Restrictions................. 4-2 4.2.2.1 /MEDIA_FORMAT=COMPACTION Qualifier Ineffective on TA90 Devices ............ 4-2 4.2.2.2 /OWNER and /BY_OWNER Qualifiers Require Numerical Identifiers................... 4-2 4.3 Compaq Galaxy Software Architecture on OpenVMS Alpha......................................... 4-3 4.4 DECamds....................................... 4-3 x 4.4.1 Changes and Enhancements.................. 4-3 4.4.1.1 Installation Procedure Change........... 4-4 4.4.1.2 Event Log File and Lock Log File Enhanced................................ 4-5 4.4.1.3 Handling of Unknown Adapter Types Improved................................ 4-5 4.4.1.4 Similar Groups Sorted Correctly......... 4-6 4.4.2 Problems and Restrictions................. 4-6 4.4.2.1 Kernel Threads Not Supported (Alpha Only)................................... 4-6 4.5 DECdtm Services .............................. 4-6 4.5.1 Problems and Restrictions................. 4-6 4.5.1.1 Kernel Threads Restriction (Alpha Only)................................... 4-6 4.6 DECevent Fault Management Support ............ 4-6 4.6.1 Changes and Enhancements.................. 4-7 4.6.1.1 DECevent Version 2.9 or Later Required to Analyze Errors....................... 4-7 4.7 Extended File Specifications ................. 4-8 4.7.1 Problems and Restrictions................. 4-8 4.7.1.1 Mixed UNIX Style and VMS Style File Names Not Supported (Alpha Only)........ 4-8 4.8 External Authentication....................... 4-9 4.8.1 Changes and Enhancements.................. 4-9 4.8.1.1 FTP Server Uses External Authentication ........................................ 4-9 4.8.1.2 DCL Command Interface to Control External Authentication................. 4-10 4.8.2 Problems and Restrictions................. 4-10 4.8.2.1 Failed Connection Attempts on POP Server ........................................ 4-10 4.8.2.2 SET PASSWORD Behavior Within a DECterm Terminal Session........................ 4-10 4.8.2.3 DECnet Phase IV Requirement............. 4-11 4.8.2.4 Impact on Layered Products and Applications............................ 4-12 4.8.2.5 Mixed-Version OpenVMS Cluster Systems... 4-13 4.8.2.6 LGI Callout Services Disable External Authentication.......................... 4-13 4.8.2.7 DECwindows Pause Screen Uses SYSUAF Password................................ 4-14 4.8.2.8 DECnet-Plus and NET_CALLOUTS Parameter............................... 4-14 xi 4.8.2.9 No Password Expiration Notification on Workstations ........................... 4-14 4.9 Fast Path (Alpha Only)........................ 4-14 4.9.1 Changes and Enhancements.................. 4-15 4.9.1.1 SYSGEN Parameter Changes................ 4-15 4.9.1.2 DCL Support............................. 4-15 4.9.1.3 STOP/CPU Command Is Allowed............. 4-15 4.10 Lock Manager.................................. 4-15 4.10.1 Changes and Enhancements.................. 4-15 4.10.1.1 Lock Manager and Nonpaged Pool (Alpha Only)................................... 4-16 4.11 Monitor Utility .............................. 4-16 4.11.1 Problems and Restrictions................. 4-16 4.11.1.1 Monitoring Pre-Version 7.2 Nodes from Version 7.2 Nodes ...................... 4-16 4.11.1.2 Changes to MONITOR Recording File....... 4-17 4.11.2 Documentation Changes and Corrections..... 4-17 4.12 Mount Utility ................................ 4-17 4.12.1 Problems and Restrictions................. 4-18 4.12.1.1 /MEDIA_FORMAT=COMPACTION Qualifier Ineffective on TA90 Devices ............ 4-18 4.12.1.2 Mounting Write-Protected Disks in a Mixed-Version Cluster................... 4-18 4.13 OPCOM......................................... 4-19 4.13.1 Corrections............................... 4-19 4.14 OpenVMS Cluster Systems....................... 4-19 4.14.1 Changes and Enhancements.................. 4-20 4.14.1.1 New HSZ Allocation Class (Alpha Only)... 4-20 4.14.1.2 OpenVMS Cluster Compatibility Kits for Version 6.2 Systems..................... 4-21 4.14.1.3 Cluster Client License Changes ......... 4-22 4.14.2 Problems and Restrictions................. 4-22 4.14.2.1 Mixed-Version Incompatibilities......... 4-23 4.14.2.2 DECnet-Plus Satellite Boot Restriction (Alpha Only)............................ 4-23 4.14.2.3 MSCP_SERVE_ALL and Mixed-Version Clusters................................ 4-24 4.14.2.4 SCSI Device-Naming Restrictions When Port Allocation Class Used ............. 4-24 4.14.2.5 Multipath Support for Parallel SCSI and Fibre Channel (Alpha Only).............. 4-25 4.14.2.6 Fibre Channel Support (Alpha Only) ..... 4-25 xii 4.14.2.7 SCSI Shared Interconnect Requires Same Node Allocation Class (Alpha Only) ..... 4-26 4.14.2.8 AlphaServer 4000/4100 Systems Problem in SCSI Clusters........................... 4-26 4.14.2.9 CI-to-PCI (CIPCA) Adapter (Alpha Only)................................... 4-26 4.14.2.9.1 HSJ50 Firmware Version Restriction for Use of 4K CI Packets .................. 4-27 4.14.2.9.2 Multiprocessor Systems with CIPCAs: CPUSPINWAIT Bugcheck Avoidance......... 4-27 4.14.2.10 MEMORY CHANNEL (Alpha Only)............. 4-28 4.14.2.10.1 Rolling Upgrades....................... 4-28 4.14.2.11 Booting Satellites with DECnet-Plus .... 4-29 4.14.2.12 System Startup in an OpenVMS Cluster Environment (Alpha Only)................ 4-29 4.14.3 Corrections .............................. 4-30 4.14.3.1 SCSI Device Naming and Quorum Disk Problem Corrected (Alpha Only).......... 4-30 4.14.3.2 SCSI Device-Naming Problem with PKA Device Corrected ....................... 4-30 4.14.3.3 SCSI Device-Naming Conflict That Prevented Satellite Booting Corrected... 4-31 4.14.3.4 MSCP_CMD_TMO System Parameter Corrections ............................ 4-32 4.15 OpenVMS File System........................... 4-32 4.15.1 Changes and Enhancements ................. 4-33 4.15.1.1 Performance and Configuration Requirements of Large Bitmaps........... 4-33 4.15.1.2 Changing Disk Cluster Factor Can Create Incompatibilities....................... 4-34 4.15.1.3 Storage Bitmap Might Be Smaller Than Volume Requires......................... 4-35 4.16 POLYCENTER Software Installation Utility ..... 4-36 4.16.1 Changes and Enhancements.................. 4-36 4.16.1.1 DECwindows Motif Interface Retired...... 4-36 4.16.2 Problems and Restrictions................. 4-36 4.16.2.1 PRODUCT Command Lacks Options to Control Output ................................. 4-37 4.16.2.2 Product Removal Restrictions............ 4-37 4.17 RMS Journaling................................ 4-37 4.17.1 Changes and Enhancements.................. 4-37 4.17.1.1 Modified Journal File Creation.......... 4-37 xiii 4.17.2 Problems and Restrictions................. 4-38 4.17.2.1 After-Image (AI) Journaling............. 4-38 4.17.2.2 Remote Access of Recovery Unit Journaled Files in an OSI Environment............. 4-39 4.17.2.3 VFC Format Sequential Files ............ 4-39 4.18 Security...................................... 4-39 4.18.1 Changes and Enhancements.................. 4-40 4.18.1.1 DETACH Privilege Renamed to IMPERSONATE............................. 4-40 4.18.1.2 DIRECTORY Command Now Summarizes Suppressed PATHWORKS ACEs............... 4-40 4.19 Show Cluster Utility.......................... 4-40 4.19.1 Documentation Changes and Corrections..... 4-41 4.19.1.1 OpenVMS System Management Utilities Reference Manual: M-Z................... 4-41 4.20 SYS$EXAMPLES ................................. 4-42 4.20.1 Changes and Enhancements.................. 4-42 4.20.1.1 SET PREFERRED_PATH Command Replaces PREFER.MAR and PREFER.CLD .............. 4-42 4.21 System Parameters............................. 4-42 4.21.1 Changes and Enhancements.................. 4-42 4.21.1.1 System Parameters Help.................. 4-42 4.21.1.2 CRD_CONTROL............................. 4-43 4.21.1.3 MAXBOBMEM (Alpha Only).................. 4-43 4.21.1.4 MMG_CTLFLAGS (Alpha Only)............... 4-44 4.21.1.5 MSCP_CMD_TMO............................ 4-44 4.21.1.6 MSCP_SERVE_ALL.......................... 4-45 4.21.1.7 NOCLUSTER............................... 4-45 4.21.1.8 PASTDGBUF .............................. 4-45 4.21.1.9 PIOPAGES ............................... 4-46 4.21.1.10 QDSKINTERVAL............................ 4-46 4.21.1.11 SCSCONNCNT Is Obsolete.................. 4-46 4.21.1.12 STARTUP_P3.............................. 4-46 4.21.1.13 TMSCP_SERVE_ALL......................... 4-46 4.21.1.14 VBN_CACHE_S (VAX Only).................. 4-47 4.21.1.15 VCC_MAXSIZE (Alpha Only)................ 4-47 4.21.2 Problems and Restrictions................. 4-48 4.21.2.1 ARB_SUPPORT (Alpha Only)................ 4-48 4.21.2.2 MSCP_SERVE_ALL.......................... 4-48 4.21.3 Corrections............................... 4-48 xiv 4.21.4 Documentation Changes and Corrections..... 4-49 4.21.4.1 ARB_SUPPORT Default Value Is 3 (Alpha Only)................................... 4-49 4.21.4.2 MPDEV_REMOTE Is Not Supported........... 4-49 4.22 Terminal Fallback Facility (TFF) (Alpha Only)......................................... 4-49 4.23 Volume Shadowing for OpenVMS.................. 4-51 4.23.1 Changes and Enhancements.................. 4-51 4.23.1.1 Shadow Set Member Support Raised to 500..................................... 4-51 4.23.2 Problems and Restrictions................. 4-51 4.23.2.1 HSD10 Virtual Disks .................... 4-51 4.23.2.2 Minimerge Capability for System Disk Requires DUMPSTYLE Parameter (Alpha Only) .................................. 4-51 4.23.2.3 Minimerge Version Incompatibility ...... 4-52 4.23.2.4 HSZ40 and Transportable SCSI Disk Shadow-Set Members...................... 4-53 4.23.3 Corrections............................... 4-54 4.23.3.1 Incompatibility with StorageWorks RAID Software Corrected...................... 4-54 4.23.3.2 Bad Block Repair (BBR) Logic Problem Corrected............................... 4-54 5 Programming Release Notes 5.1 Backup API.................................... 5-1 5.1.1 Changes and Enhancements.................. 5-1 5.1.1.1 New Flag BCK_OPTYP_IGNORE_K_STRUCTURE... 5-1 5.1.2 Problems and Restrictions................. 5-1 5.1.2.1 Unexpected Informational Message........ 5-2 5.1.2.2 Journaling Callback Events Restriction............................. 5-2 5.1.2.3 Repetitive Calls to BACKUP$START Can Cause an Error.......................... 5-3 5.2 Batch and Print Queues........................ 5-3 5.2.1 Problems and Restrictions................. 5-3 5.2.1.1 Terminating Executing Batch Jobs........ 5-3 5.3 COM for OpenVMS (Alpha Only).................. 5-4 5.4 Debugging Modes............................... 5-5 5.4.1 Problems and Restrictions................. 5-5 5.4.1.1 Avoiding CPUSPINWAIT Bugchecks.......... 5-5 5.5 DEC Ada Run-Time Library ..................... 5-5 xv 5.5.1 Changes and Enhancements.................. 5-6 5.5.1.1 OpenVMS Text Libraries Containing Ada Declarations............................ 5-6 5.5.2 Problems and Restrictions ................ 5-6 5.5.2.1 Unexpected Storage Errors (Alpha Only)................................... 5-6 5.5.3 Corrections............................... 5-7 5.5.3.1 AST Procedures No Longer Get Access Violations.............................. 5-7 5.6 DEC C Run-Time Library ....................... 5-7 5.6.1 Changes and Enhancements.................. 5-7 5.6.1.1 Internationalization Support ........... 5-7 5.6.1.2 Euro Support ........................... 5-8 5.6.1.3 New Functions .......................... 5-9 5.6.1.4 Cache of OpenVMS Environment ........... 5-9 5.6.1.5 mmap Function Allows Creation of Global and Permanent Sections.................. 5-10 5.6.1.6 wait Functions Can Return Completion Code of Child Process .................. 5-10 5.7 DECthreads.................................... 5-10 5.7.1 Changes and Enhancements.................. 5-10 5.7.1.1 Thread Stack Size....................... 5-11 5.7.1.2 Static Initialization Inappropriate for Stack-Based Synchronization Objects..... 5-12 5.7.1.3 POSIX 1003.4a Draft 4 Interface Retirement.............................. 5-13 5.7.2 Problems and Restrictions................. 5-13 5.7.2.1 Incorrect Success Exit Status Values Returned................................ 5-13 5.7.2.2 Language Support ....................... 5-14 5.7.2.3 DECthreads Debugger Metering Function... 5-14 5.7.2.4 C Run-Time Library errno Value ......... 5-14 5.7.2.5 SET TASK/ACTIVE Command................. 5-14 5.8 DECTPU for DECwindows Motif................... 5-15 5.8.1 Problems and Restrictions................. 5-15 5.8.1.1 Small Display Monitors and DECwindows Motif Applications...................... 5-15 5.9 High-Performance Sort/Merge Utility (Alpha Only)......................................... 5-16 5.10 Lexical Functions............................. 5-16 5.10.1 Changes and Enhancements.................. 5-16 5.10.1.1 F$GETSYI Lexical: Item NODE_HWTYPE Is Obsolete................................ 5-16 xvi 5.11 Librarian Utility ............................ 5-16 5.11.1 Problems and Restrictions................. 5-17 5.11.1.1 PGFLQUOTA Should Exceed 23000 (Alpha Only)................................... 5-17 5.12 Linker Utility................................ 5-17 5.12.1 Problems and Restrictions ................ 5-17 5.12.1.1 Limit of 25 Elements on Stack........... 5-17 5.12.2 Documentation Changes and Corrections..... 5-17 5.12.2.1 OpenVMS Linker Utility Manual........... 5-18 5.13 LTDRIVER...................................... 5-18 5.13.1 Problems and Restrictions................. 5-18 5.13.1.1 CANCEL SELECTIVE Cannot Cancel IO$_TTY_PORT Functions.................. 5-18 5.14 MACRO-32 Compiler for OpenVMS Alpha (Alpha Only)......................................... 5-18 5.15 Mail Utility ................................. 5-18 5.15.1 Problems and Restrictions................. 5-18 5.15.1.1 Threads Restriction for Callable Mail... 5-19 5.16 Mathematics (MTH$) Run-Time Library .......... 5-19 5.16.1 Problems and Restrictions................. 5-19 5.16.1.1 Linking Images to Run on Previous OpenVMS VAX Versions (VAX Only)......... 5-19 5.17 OpenVMS Registry (Alpha Only)................. 5-20 5.18 POLYCENTER Software Installation Utility ..... 5-20 5.18.1 Problems and Restrictions................. 5-21 5.18.1.1 Generation Option of File Statement..... 5-21 5.19 Privileged Interfaces and Data Structures (Alpha Only).................................. 5-21 5.19.1 Changes and Enhancements.................. 5-22 5.19.1.1 Per-Thread Security and Backward Compatibility........................... 5-22 5.19.1.2 Privileged Code Changes at Version 7.0..................................... 5-24 5.19.2 Problems and Restrictions................. 5-25 5.19.2.1 Per-Thread Security Impacts Privileged Code and Device Drivers................. 5-25 5.20 Record Management Services (RMS).............. 5-27 5.20.1 Changes and Enhancements.................. 5-27 5.20.1.1 Ellipsis Processing of [000000...] Now Finds All Files......................... 5-27 5.20.1.2 Circular Directory Path Detection (Alpha Only)................................... 5-27 5.20.1.3 Directory Cache Limits Removed ......... 5-28 xvii 5.21 Run-Time Library (LIB$)....................... 5-28 5.21.1 Problems and Restrictions................. 5-28 5.21.1.1 LIB$FIND_IMAGE_SYMBOL Signals Warning for Modules with Compilation Errors..... 5-28 5.21.2 Documentation Changes and Corrections..... 5-29 5.21.2.1 OpenVMS RTL Library (LIB$) Manual ...... 5-29 5.22 Screen Management (SMG$) Facility............. 5-29 5.22.1 Documentation Changes and Corrections..... 5-29 5.22.1.1 OpenVMS RTL Screen Management (SMG$) Manual.................................. 5-29 5.23 String Manipulation (STR$) Facility........... 5-31 5.23.1 Documentation Changes and Corrections..... 5-31 5.23.1.1 OpenVMS RTL String Manipulation (STR$) Manual.................................. 5-31 5.24 System Services .............................. 5-32 5.24.1 Changes and Enhancements.................. 5-32 5.24.1.1 $PERSONA System Services: Flags Ignored (Alpha Only)............................ 5-32 5.24.1.2 $PERSONA System Services: Default Privilege Change (Alpha Only)........... 5-33 5.24.1.3 $PERSONA System Services: Audit Record Change (Alpha Only)..................... 5-34 5.24.2 Problems and Restrictions................. 5-34 5.24.2.1 Linking SECURESHR Images to Run on Older Versions................................ 5-34 5.24.2.2 $SUSPND Behaves Incorrectly in a Cluster Environment ............................ 5-34 5.24.3 Corrections............................... 5-35 5.24.3.1 $PERSONA Restrictions Removed (Alpha Only)................................... 5-35 5.25 X/Open Transport Interface (XTI).............. 5-35 5.25.1 Changes and Enhancements.................. 5-35 5.25.2 Problems and Restrictions................. 5-38 6 Device Support on OpenVMS Systems 6.1 Recompiling and Relinking OpenVMS Device Drivers....................................... 6-1 6.1.1 Possible Per-Threads Security Impacts on Alpha Device Drivers...................... 6-1 6.1.2 Alpha and VAX SCSI Device Drivers......... 6-1 6.1.3 OpenVMS Alpha Device Drivers.............. 6-2 xviii 6.2 Restriction: Parallel SCSI Support for Logical Unit Numbers.................................. 6-2 6.3 Selective Autoconfiguration Unsupported in Some SCSI Configurations...................... 6-3 6.4 Changed Behavior of IO$_SKIPFILE Function..... 6-3 6.5 CRCTX Routines Enhanced (Alpha Only).......... 6-4 6.6 New Values for Length Parameter in System Routines (Alpha Only)......................... 6-5 6.7 Memory Barriers Required in Drivers for DMA (Alpha Only).................................. 6-7 6.8 ISA_CONFIG.DAT Unsupported in Future Release (Alpha Only).................................. 6-9 6.9 Required Change in ISA_CONFIG.DAT on AlphaStation 200/400.......................... 6-9 6.10 Naming Serial Line Devices on Alpha Systems... 6-10 6.11 Memory Holes on AlphaServer 4100 Systems...... 6-11 6.12 SYS$MSBDRIVER Removed from OpenVMS Alpha Distribution.................................. 6-13 6.13 Device IPL Setup for OpenVMS Alpha Drivers.... 6-13 6.14 AlphaStation 255: PCI Configuration Restriction................................... 6-14 6.15 Recommendation for RZ25M and RZ26N Disk Drives (Alpha)....................................... 6-14 6.16 SCSI Controller Restriction on AlphaServer 2100 Systems.................................. 6-15 6.17 OpenVMS Alpha SCSI Firmware Support .......... 6-15 6.17.1 Recommended Firmware Support for RZ26N and RZ28M Disks............................... 6-15 6.17.2 Required Firmware for Multihost Use of RZ26L and RZ28 Disks...................... 6-15 6.17.2.1 Firmware Revision Level 442 Requirements............................ 6-16 6.17.2.2 Firmware Revision Level 442 Installation Procedure............................... 6-16 6.18 OpenVMS Alpha SCSI Port and Class Drivers .... 6-16 6.18.1 Add-On SCSI Adapters...................... 6-17 6.18.2 SCSI Disk I/O Performance Degradation for KZMSA XMI and Adaptec 1742A Adapters...... 6-17 6.19 OpenVMS Alpha Device Support Documentation.... 6-18 xix 7 Using Interlocked Memory Instructions (Alpha Only) 7.1 Required Code Checks ......................... 7-1 7.2 Using the Code Analysis Tool.................. 7-2 7.3 Characteristics of Noncompliant Code.......... 7-4 7.4 Coding Requirements........................... 7-5 7.5 Compiler Versions............................. 7-7 7.6 Interlocked Memory Sequence Checking for the MACRO-32 Compiler............................. 7-8 7.7 Recompiling Code with ALONONPAGED_INLINE or LAL_REMOVE_FIRST Macros....................... 7-10 A Product Retirement Notices A.1 Adobe Display PostScript Not Supported in DECwindows Motif for OpenVMS.................. A-1 A.2 DECthreads: POSIX 1003.4a Draft 4 Interface To Be Retired.................................... A-2 A.3 ISA_CONFIG.DAT Unsupported in Future Release (Alpha Only).................................. A-2 A.4 PATHWORKS for OpenVMS (NetWare)............... A-2 A.5 POLYCENTER Software Installation Utility: DECwindows Motif Interface Retired ........... A-2 A.6 POSIX for OpenVMS Retirement.................. A-3 A.7 Spiralog File System Retired.................. A-3 A.8 Spyglass Enhanced Mosaic Not Supported on DECwindows Motif V1.2-5 ...................... A-3 A.9 X.25 Client for OpenVMS Alpha Retirement (Alpha Only).................................. A-4 A.10 Archived Manuals.............................. A-4 B Remedial Kits Included in OpenVMS Version 7.2 B.1 Remedial Kits Included in OpenVMS Alpha Version 7.2................................... B-1 B.2 Remedial Kits Included in OpenVMS VAX Version 7.2........................................... B-4 xx Index Tables 1-1 Documentation: Configuring and Managing Networks.................................. 1-4 1-2 Supported Microcode Revision Levels ...... 1-35 1-3 Commands for Updating Microcode in Certain DSSI Disk Devices......................... 1-36 2-1 DECram Support on OpenVMS ................ 2-10 4-1 TFF Character Fallback Tables............. 4-50 4-2 SHADOW_SYS_DISK System Parameter Settings.................................. 4-52 5-1 Obsolete Data Cells and New Location of Security Information...................... 5-23 5-2 Ignored $PERSONA_ASSUME Flags............. 5-32 5-3 Ignored $PERSONA_CREATE Flags............. 5-33 6-1 Values for Length Parameter............... 6-5 6-2 Revision Level 442 Firmware Compatibility............................. 6-16 7-1 OpenVMS Compilers......................... 7-8 A-1 Manuals Archived with OpenVMS Version 7.2....................................... A-5 xxi _________________________________________________________________ Preface Intended Audience This manual is intended for all OpenVMS operating system users. Read this manual before you install, upgrade, or use Version 7.2 of the operating system. Document Structure This manual contains the following chapters and appendixes: o Chapter 1 contains release notes that pertain to installing and upgrading the OpenVMS operating systems, as well as hardware-related information. o Chapter 2 contains installation and support information about OpenVMS layered products. o Chapter 3 contains release notes about the general use of the OpenVMS operating system. o Chapter 4 contains release notes specific to system management issues. o Chapter 5 contains release notes that relate to programming on an OpenVMS system, including notes for compilers, linkers, and run-time library routines. o Chapter 6 contains release notes pertaining to OpenVMS device support on Alpha and VAX systems. o Chapter 7 describes the proper use of interlocked memory instructions, which is crucial for the new Alpha 21264 (EV6) processor. o Appendix A contains information about OpenVMS products that are no longer supported, as of this release, or that are slated for retirement. xxiii o Appendix B lists remedial kits that are included in OpenVMS Version 7.2. In Chapters 2 through 5, notes are organized by facility or product name; facilities and products are listed alphabetically. Notes are further classified as changes, problems or restrictions, corrections, or documentation corrections. This manual contains release notes introduced in the current release and notes from previous OpenVMS versions that still apply to the new release. Margin notes for each release note indicate the version of origin (for example, V7.1). Notes from previous releases are published when: o The information in the release note has not been documented in hard copy in any other manual in the OpenVMS documentation set, and the note is still pertinent. o The release note may be pertinent in multiple-version OpenVMS Cluster systems. Related Documents For a list of additional documents that are available in support of this version of the OpenVMS operating system, refer to the Overview of OpenVMS Documentation. For additional information on the Open Systems Software Group (OSSG) products and services, access the following OpenVMS World Wide Web address: http://www.openvms.digital.com Reader's Comments Compaq welcomes your comments on this manual. Print or edit the online form SYS$HELP:OPENVMSDOC_ COMMENTS.TXT and send us your comments by: Internet openvmsdoc@zko.mts.dec.com xxiv Fax 603 884-0120, Attention: OSSG Documentation, ZKO3-4/U08 Mail Compaq Computer Corporation OSSG Documentation Group, ZKO3-4/U08 110 Spit Brook Rd. Nashua, NH 03062-2698 How To Order Additional Documentation Use the following World Wide Web address to order additional documentation: http://www.openvms.digital.com:81/ If you need help deciding which documentation best meets your needs, call 800-DIGITAL (800-344-4825). Conventions VMScluster systems are now referred to as OpenVMS Cluster systems. Unless otherwise specified, references to OpenVMS Clusters or clusters in this document are synonymous with VMSclusters. In this manual, every use of DECwindows and DECwindows Motif refers to DECwindows Motif for OpenVMS software. The following conventions are also used in this manual: Ctrl/x A sequence such as Ctrl/x indicates that you must hold down the key labeled Ctrl while you press another key or a pointing device button. PF1 x A sequence such as PF1 x indicates that you must first press and release the key labeled PF1 and then press and release another key or a pointing device button. In examples, a key name enclosed in a box indicates that you press a key on the keyboard. (In text, a key name is not enclosed in a box.) xxv . . . A horizontal ellipsis in examples indicates one of the following possibilities: o Additional optional arguments in a statement have been omitted. o The preceding item or items can be repeated one or more times. o Additional parameters, values, or other information can be entered. . A vertical ellipsis indicates the omission . of items from a code example or command . format; the items are omitted because they are not important to the topic being discussed. ( ) In command format descriptions, parentheses indicate that you must enclose the choices in parentheses if you choose more than one. [ ] In command format descriptions, brackets indicate optional elements. You can choose one, none, or all of the options. (Brackets are not optional, however, in the syntax of a directory name in an OpenVMS file specification or in the syntax of a substring specification in an assignment statement.) [|] In command format descriptions, vertical bars separating items inside brackets indicate that you choose one, none, or more than one of the options. { } In command format descriptions, braces indicate required elements; you must choose one of the options listed. bold text This text style represents the introduction of a new term or the name of an argument, an attribute, or a reason. xxvi italic text Italic text indicates important information, complete titles of manuals, or variables. Variables include information that varies in system output (Internal error number), in command lines (/PRODUCER=name), and in command parameters in text (where dd represents the predefined code for the device type). UPPERCASE TEXT Uppercase text indicates a command, the name of a routine, the name of a file, or the abbreviation for a system privilege. Monospace text Monospace type indicates code examples and interactive screen displays. In the C programming language, monospace type in text identifies the following elements: keywords, the names of independently compiled external functions and files, syntax summaries, and references to variables or identifiers introduced in an example. - A hyphen at the end of a command format description, command line, or code line indicates that the command or statement continues on the following line. numbers All numbers in text are assumed to be decimal unless otherwise noted. Nondecimal radixes-binary, octal, or hexadecimal-are explicitly indicated. xxvii 1 _________________________________________________________________ OpenVMS Installation, Upgrade, and Hardware Release Notes This chapter contains information that applies to installations and upgrades of the OpenVMS VAX and OpenVMS Alpha operating systems. It also provides information specific to certain hardware. The installation and upgrade notes in this chapter are organized into the following categories: o Installation and upgrade notes common to both VAX and Alpha systems (see Section 1.2) o Alpha specific installation and upgrade notes (see Section 1.4) Hardware and firmware notes follow the upgrade and installation sections. For information about layered product installation and support, see Chapter 2. 1.1 Compaq's Support Policy In November 1996, DIGITAL announced a revised support policy and a new Prior Version Support Service for customers concerned that software release cycles and the end of support may not be aligned with their ability to migrate systems to the new software releases. Compaq is continuing these support policies. In keeping with the November 1996 policy, support is available for the current version and the previous version (for up to 12 months) when a customer purchases a standard support contract. For versions of software older than the previous version, Prior Version Support service is available in two levels of support, including full, remedial support on selected products and versions. This year, extended Year 2000 OpenVMS Installation, Upgrade, and Hardware Release Notes 1-1 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.1 Compaq's Support Policy support was announced to provide regular remedial support through 30-JUN-2000 for OpenVMS VAX and Alpha Version 7.1 and OpenVMS Alpha Version 7.1-2. You can read the full extended support announcement on the World Wide Web at the following URL: http://www.openvms.digital.com/extsup.html For more information about all levels of support, contact your Compaq support representative or visit the Compaq Services web site: http://www.digital.com/services/mcs/mcs_support.htm . 1.2 Installation and Upgrade Information Common to VAX and Alpha The following release notes document installation and upgrade information common to both platforms. For additional Alpha specific notes, see Section 1.4. 1.2.1 Changes and Enhancements This section describes information related to installing or upgrading the OpenVMS VAX and OpenVMS Alpha Version 7.2 operating systems. 1.2.1.1 Networking Options V7.2 OpenVMS provides customers with the flexibility to choose the network protocol of their choice. Whether you require DECnet, TCP/IP, or OSI, OpenVMS allows you to choose the protocol or combination of protocols that works best for your network. OpenVMS supports both Compaq and third-party networking products. During the main installation procedure for OpenVMS Version 7.2, you have the option of installing the following Compaq networking software: o DIGITAL TCP/IP Services for OpenVMS Starting with OpenVMS Version 7.2, DIGITAL TCP/IP Services for OpenVMS Version 5.0 replaces DIGITAL TCP/IP Services for OpenVMS (UCX) Version 4.2. (See Section 2.14.1.1 for more information about Version 5.0.) Version 4.2 is not supported on OpenVMS Version 1-2 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.2 Installation and Upgrade Information Common to VAX and Alpha 7.2; that is, Version 4.2 has not been tested on OpenVMS Version 7.2 and Compaq does not commit to responding to problems running Version 4.2 on OpenVMS Version 7.2. If you have DIGITAL TCP/IP Services for OpenVMS (UCX) Version 4.2-21 or Version 4.1-12 installed when you upgrade to OpenVMS Version 7.2, you can choose either to retain UCX or to upgrade to DIGITAL TCP/IP Services for OpenVMS Version 5.0. Compaq recommends that you upgrade to DIGITAL TCP/IP Services for OpenVMS Version 5.0. TCP/IP Services and DECnet can run concurrently on your system. Once you have installed DECnet-Plus for OpenVMS and TCP/IP Services on your system, you can run DECnet applications over your TCP/IP network. Refer to the DECnet-Plus for OpenVMS Management Guide for more information about running DECnet over TCP/IP. o Either DECnet-Plus for OpenVMS (previously named DECnet/OSI) or DECnet for OpenVMS (Phase IV). (Note that both DECnet products cannot run concurrently on your system.) DECnet-Plus contains all the functionality of the DECnet Phase IV product, plus the ability to run DECnet over TCP/IP or OSI protocols. Support for DECnet Phase IV is provided to customers with a Prior Version Support Contract, which is available from Compaq's Multivendor Customer Services (MCS). For more information about the Prior Version Support service, see Section 1.1. Or, after you install OpenVMS, you can install a supported third-party networking product of your choice. For information about how to configure and manage your Compaq networking software after installation, see the manuals listed in Table 1-1. The manuals in online format are available on the OpenVMS Documentation CD-ROM and can be ordered in printed format through DECdirect (800-344- 4825). OpenVMS Installation, Upgrade, and Hardware Release Notes 1-3 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.2 Installation and Upgrade Information Common to VAX and Alpha Table_1-1_Documentation:_Configuring_and_Managing_Networks_ DIGITAL_TCP/IP_Services_for_OpenVMS________________________ DIGITAL TCP/IP Services for OpenVMS AA-LU49L-TE Installation and Configuration DIGITAL TCP/IP Services for OpenVMS AA-LU50K-TE Management ___________________________________________________________ DECnet-Plus_for_OpenVMS_(Phase_V)__________________________ DECnet-Plus for OpenVMS Installation and AA-QPSUB-TE Basic Configuration DECnet-Plus for OpenVMS Applications AA-QPSVB-TE Installation and Advanced Configuration DECnet-Plus for OpenVMS Network AA-R1UHA-TE Management ___________________________________________________________ DECnet_for_OpenVMS_(Phase_IV)______________________________ DECnet for OpenVMS Guide to Networking AA-PV5ZA-TK DECnet for OpenVMS Networking Manual AA-PV60A-TK DECnet for OpenVMS Network Management AA-PV61A-TK Utilities__________________________________________________ 1.2.1.2 Installing Network Transport Products V7.2 TCP/IP is the preferred network transport for OpenVMS Version 7.2. Customers can also install DECnet, with DECnet-Plus being the recommended DECnet product. If you choose to install the TCP/IP transport, DIGITAL TCP/IP Services for OpenVMS, Version 5.0, will be installed using the POLYCENTER Software Installation utility on both OpenVMS VAX and Alpha systems. The configuration from earlier versions of TCP/IP Services will be preserved and used as a basis for the TCP/IP Services for OpenVMS Version 5.0 configuration. If you do not choose this installation option and have TCP/IP Version 4.1 or 4.2 installed on your system, the earlier version will be left on your system and will still be available for use. 1-4 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.2 Installation and Upgrade Information Common to VAX and Alpha TCP/IP Services for OpenVMS, Version 4.2 and earlier are not supported on OpenVMS Version 7.2. Compaq strongly recommends that you run only supported versions of TCP/IP Services for OpenVMS. Unpredictable behavior can result if you run unsupported software. Although DECnet-Plus remains the recommended DECnet, both DECnet-Plus and DECnet Phase IV can be installed from the OpenVMS Version 7.2 installation procedure. To get support for any version of DECnet Phase IV, you need a Prior Version Support contract. 1.2.1.3 Upgrading Systems Running PATHWORKS V6.0/6.0A for OpenVMS (Advanced Server) V7.2 The following products ship with OpenVMS Version 7.2, providing file and print services: o PATHWORKS V6.0B for OpenVMS (Advanced Server) PATHWORKS V6.0B for OpenVMS (Advanced Server) runs on OpenVMS Version 7.2 on both VAX and Alpha. It supersedes the PATHWORKS V6.0A for OpenVMS (Advanced Server) product. o Advanced Server V7.2 for OpenVMS Advanced Server V7.2 for OpenVMS runs on OpenVMS Alpha Version 7.2 only. The Advanced Server for OpenVMS is based on and succeeds PATHWORKS V6 for OpenVMS (Advanced Server). Versions of PATHWORKS for OpenVMS prior to PATHWORKS V6.0B for OpenVMS (Advanced Server) are not supported on OpenVMS Version 7.2. To migrate systems currently running PATHWORKS V6.0/6.0A for OpenVMS (Advanced Server), follow these steps: 1. Upgrade PATHWORKS V6.0/V6.0A for OpenVMS (Advanced Server) on OpenVMS Version 7.1 to PATHWORKS V6.0B for OpenVMS (Advanced Server) on OpenVMS Version 7.1. 2. Upgrade from OpenVMS Version 7.1 to OpenVMS Version 7.2. 3. Upgrade PATHWORKS V6.0B for OpenVMS (Advanced Server) on OpenVMS Version 7.1 to PATHWORKS V6.0B for OpenVMS (Advanced Server) on OpenVMS Version 7.2. OpenVMS Installation, Upgrade, and Hardware Release Notes 1-5 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.2 Installation and Upgrade Information Common to VAX and Alpha 4. (Option on OpenVMS Alpha Version 7.2) Upgrade PATHWORKS V6.0B for OpenVMS (Advanced Server) on OpenVMS Alpha Version 7.2 to Advanced Server V7.2 for OpenVMS. Refer to Section 2.2 for more information about the Advanced Server for OpenVMS. Refer to Section 2.15 for information about restrictions pertaining to PATHWORKS for OpenVMS products on OpenVMS Version 7.2. 1.2.1.4 DECevent Version 2.9 or Later Required to Analyze Errors V7.2 Starting with OpenVMS Version 7.1-2, DECevent Version 2.9 or later is required to analyze error log files. In OpenVMS Version 7.0 and earlier releases of OpenVMS, the DECevent DCL command DIAGNOSE was defined during the operating system installation or upgrade. When you install OpenVMS Version 7.2, the DIAGNOSE command is disabled. To enable the DIAGNOSE command, you must install DECevent Version 2.9 (in the DECevent kit provided on the OpenVMS Version 7.2 CD-ROM) after you install OpenVMS Version 7.2. If the DECevent kit provided on the OpenVMS CD-ROM is not installed after the operating system, users attempting to use the DIAGNOSE command will receive the following system message: $ DIAGNOSE [parameters] %DIA-E-NOINSTAL, DIAGNOSE has not been installed on this system For more information about DECevent, see Section 4.6.1.1. 1.2.1.5 OpenVMS Cluster Compatibility Kits for Version 6.2 Systems V7.1-1H1 The OpenVMS Cluster Compatibility Kits that shipped with OpenVMS Version 7.1 have been superseded by remedial kits ALPCLUSIOnn_062 for Alpha systems and VAXCLUSIOnn_062 for VAX systems. These kits are required for OpenVMS Version 6.2 systems that are members of an OpenVMS Cluster system that includes systems running one or more of the following OpenVMS versions: o Version 7.1 1-6 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.2 Installation and Upgrade Information Common to VAX and Alpha o Versions 7.1-1H1, 7.1-1H2, or other Version 7.1-based releases o Version 7.2 The kits contain the OpenVMS Version 7.1 enhancements to Volume Shadowing, Mount, lock manager, and other quality improvements for OpenVMS Version 6.2 systems as well as additional enhancements to these subsystems made after the release of OpenVMS Version 7.1. The kits also contain limited support for SCSI device naming using port allocation classes. These remedial kits are included on the OpenVMS Version 7.2 CD-ROM. You can also obtain these kits from your Compaq support representative or from the following web site: http://www.service.digital.com/html/patch_public.html 1.2.2 Problems and Restrictions This section documents an upgrade and installation condition that is common to both VAX and Alpha operating systems. 1.2.2.1 PCSI-I-RETAIN Messages During DECnet-Plus Installation V7.2 If you upgrade to OpenVMS Version 7.2 and your old system has either DCE for OpenVMS or DECnet-Plus for OpenVMS installed on it, when you install DECnet-Plus, you will get PCSI-I-RETAIN informational messages for the following files: [SYSEXE]DTSS$SET_TIMEZONE.EXE [SYSLIB]DTSS$RUNDOWN.EXE [SYSUPD]DTSS$INSTALL_TIMEZONE_RULE.COM [SYSUPD]DTSS$TIMEZONE_RULES.DAT For example: %PCSI-I-RETAIN, file [SYSLIB]DTSS$RUNDOWN.EXE was not replaced because file from kit does not have higher generation number You can ignore these messages. The DECnet-Plus kit has been properly installed. OpenVMS Installation, Upgrade, and Hardware Release Notes 1-7 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.3 Installation and Upgrade Information Specific to VAX 1.3 Installation and Upgrade Information Specific to VAX The release notes in this section pertain only to installations or upgrades of OpenVMS VAX operating systems. See Section 1.2 for additional notes that pertain to both VAX and Alpha systems. For complete information about installing or upgrading to OpenVMS VAX Version 7.2, refer to the OpenVMS VAX Version 7.2 Upgrade and Installation Manual. 1.3.1 Changes and Enhancements The following note describes a change in magnetic tape distribution of the OpenVMS VAX operating system. 1.3.1.1 Magnetic Tape Distribution V7.2 The OpenVMS VAX Version 7.2 kit is available on two, 6250 BPI, open reel magnetic tapes. (Earlier versions of OpenVMS VAX shipped on four 1600 BPI magnetic tapes.) The first tape contains the VMS072.A, VMS072.B, and VMS072.C save sets. The second tape contains the VMS072.D, VMS072.E, and VMS072.F save sets, and the DECW072.C, DECW072.D, DECW072.E, and DECW072.F save sets. For more information about locating files on the distribution media, consult the OpenVMS VAX Version 7.2 Upgrade and Installation Manual. Distribution of the OpenVMS VAX operating system on magnetic tape is now available only to customers who subscribe to the OpenVMS VAX Media and Hardcopy Documentation Update Service. OpenVMS VAX CD-ROM and TK50 kits are available from all of the following sources: o DECdirect (800 344-4825) o OpenVMS VAX Media and Hardcopy Documentation Update Service o A Compaq sales representative o An authorized reseller 1-8 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.3 Installation and Upgrade Information Specific to VAX 1.3.2 Problems and Restrictions The following notes describe problems that can occur when installing OpenVMS VAX Version 7.2. 1.3.2.1 Error at Shutdown After Booting CD-ROM for Full Environment Installation V7.2 When you select to shut down the system (option 2) after booting a CD-ROM during a full OpenVMS VAX environment installation, you may encounter a problem on certain CPU types. However, these problems do not adversely affect the installation. The problems affect the following CPU types: o VAXstation 4000-96 After completing the shutdown on a VAXstation 4000-96, the keyboard no longer responds. To recover, power down your CPU, then power it back up. o VAX 3100 or a VAX 3100-M48 On either a VAX 3100 or a VAX 3100-M48, the system may crash with a fatal bugcheck. To continue the installation, boot the new system disk. 1.3.2.2 Changing System Time Causes Write Lock Error V7.2 When performing a full OpenVMS VAX environment installation from CD-ROM, do not attempt to change the displayed system time, even if it is incorrect. Attempting to change this value results in a write lock error that requires rebooting the CD-ROM to recover. This problem does not occur during a standalone BACKUP environment installation. You can change the system time once the installation has completed. OpenVMS Installation, Upgrade, and Hardware Release Notes 1-9 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.4 Installation and Upgrade Information Specific to Alpha 1.4 Installation and Upgrade Information Specific to Alpha The release notes in this section pertain only to installations or upgrades of OpenVMS Alpha operating systems. See Section 1.2 for additional notes that pertain to both Alpha and VAX systems. For complete information about installing or upgrading to OpenVMS Alpha Version 7.2, refer to the OpenVMS Alpha Version 7.2 Upgrade and Installation Manual. 1.4.1 Changes and Enhancements This section describes a change in the memory requirements for OpenVMS Alpha systems. 1.4.1.1 64 MB of Memory Required V7.2 Starting with OpenVMS Alpha Version 7.2, a minimum of 64 MB of memory is required. 1.4.2 Problems and Restrictions This section describes problems and restrictions that apply to installing or upgrading to OpenVMS Alpha Version 7.2. 1.4.2.1 BAP System Parameter Tuning Required V7.2 The CIPCA, CIXCD, KFMSB, and Qlogic 1020ISP adapters are the first among an expanding list of adapters to use bus-addressable pool (BAP). BAP is a non-paged dynamic, physical-address-filtered memory pool used to overcome I/O bus and 32-bit adapter physical addressing limits. Starting with OpenVMS Alpha Version 7.1, BAP allocation is controlled by system parameters. If one or more system adapters use BAP, you must adjust the following BAP system parameters after installing or upgrading the operating system: o NPAG_BAP_MIN o NPAG_BAP_MAX o NPAG_BAP_MIN_PA o NPAG_BAP_MAX_PA 1-10 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.4 Installation and Upgrade Information Specific to Alpha You can do this automatically using AUTOGEN with the FEEDBACK qualifier. The typical AUTOGEN with FEEDBACK command to set these parameters follows: $ @SYS$UPDATE:AUTOGEN SAVPARAMS REBOOT FEEDBACK If you prefer not to use this command because you want to adjust only the BAP parameters settings, you can use the following procedure: 1. Run SYS$SYSTEM:AGEN$FEEDBACK.EXE manually. 2. Search SYS$SYSTEM:AGEN$FEEDBACK.DAT for BAP_... values. 3. Run SYSGEN to set the following system parameters with the corresponding BAP_ values you obtained in Step 2: ________________________________________________________ AGEN$FEEDBACK System Data_____________Parameter________Units_________________ BAP_MIN NPAG_BAP_MIN bytes BAP_MAX NPAG_BAP_MAX bytes BAP_MIN_PA NPAG_BAP_MIN_PA Mb. PA[1] BAP_MAX_PA NPAG_BAP_MAX_PA Mb. PA[1] [1]PA_represents_the_memory_physical_address_value._____ ________________________________________________________ The BAP allocation amount depends on the adapter type, the number of adapters, and the version of the operating system. The size of physical memory and the I/O bus determine whether the BAP remains separate or is merged with normal nonpaged dynamic memory (NPAGEDYN). The general rule that determines whether BAP remains separate follows: o PCI adapters using BAP: separate if physical memory > 1 GB o XMI adapters using BAP: separate if physical memory > 4 GB For systems whose BAP is merged with nonpaged pool, the initial amount and maximum amount of nonpaged pool (as displayed by the DCL command SHOW MEMORY/POOL/FULL) do not match the value of the NPAGEDYN and NPAGEVIR system parameters. Instead, the value of the NPAG_BAP_MIN system OpenVMS Installation, Upgrade, and Hardware Release Notes 1-11 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.4 Installation and Upgrade Information Specific to Alpha parameter is added to NPAGEDYN to determine the initial size, and the value of NPAG_BAP_MAX is added to NPAGEVIR to determine the maximum size. On OpenVMS systems with merged BAP, the values of the NPAGEDYN... system parameters typically need to be increased. After your system has been running a few days, you can adjust these values by one of the following three methods: o Use AUTOGEN with the FEEDBACK qualifier which will automatically adjust the values of the NPAGEDYN... system parameters. o Use the DCL command SHOW MEM/POOL/FULL to analyze NPAGEDYN/BAP pool utilization. Then change the values of the NPAGEDYN... system parameters with SYSGEN, based on the results of this command. o Run SYS$SYSTEM:AGEN$FEEDBACK.EXE as previously described. Check the AGEN$FEEDBACK.DAT file for the feedback results for the NPAGEDYN... system parameters and adjust them accordingly, using SYSGEN. 1.4.2.2 DECwindows Motif V1.2-5 Provided in Reference Format V7.2 For OpenVMS Alpha Version 7.2, the DECwindows Motif V1.2-5 kit is provided in reference format. Usually the DECwindows kit is provided in sequential format; reference format is being used to work around a performance problem. In sequential format, the DECwindows kit appears in a single file on the OpenVMS operating system CD-ROM. In reference format, the kit is expanded. The individual files that make up the kit are in the [DWMOTIF_ALPHA125.KIT...] directory hierarchy. Do not mistake the Product Definition File (PDF) for the kit. The PDF (file DEC-AXPVMS-DWMOTIF-V0102-5- 1.PCSI$DESCRIPTION) is only part of the kit. The differences between reference and sequential format make no difference in the installation or upgrade procedure. Regardless of how PRODUCT command operations are executed, they work identically with either format. 1-12 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.4 Installation and Upgrade Information Specific to Alpha Copying the Reference Format Kit Do not attempt to copy the reference format kit by using a DCL COPY command. Instead, use the PRODUCT COPY command with the /FORMAT=SEQUENTIAL qualifier, so that the kit is copied to a single-file, sequential format kit. For example, if the OpenVMS Alpha operating system CD-ROM is located on DKA400 and you want to copy the DECwindows Motif V1.2-5 kit to the [KITS] directory on DKB100, you might use a command similar to the following: $ PRODUCT COPY DWMOTIF /VERSION=V1.2-5 /FORMAT=SEQUENTIAL - _$ /SOURCE=DKA400:[DWMOTIF_ALPHA125.KIT] - _$ /DESTINATION=DKB100:[KITS] This command creates file DKB100:[KITS]DEC-AXPVMS-DWMOTIF- V0102-5-1.PCSI, which is a sequential format DECwindows Motif kit. This file can be copied using the DCL COPY command. 1.4.2.3 Remove Java Version A1.1 Before Upgrading V7.2 If you have Java Version A1.1 installed, you must remove it before upgrading to OpenVMS Alpha Version 7.2. You can reinstall Java Version A1.1 after performing the upgrade, but you must remove it again before the next upgrade. ________________________ Note ________________________ If you have a later version of Java installed, you do not need to remove it before upgrading OpenVMS. For your convenience, Java Version 1.1 is included on the OpenVMS Version 7.2 media. ______________________________________________________ To remove Java from a running system before upgrading, use the following command: $ PRODUCT REMOVE JAVA You can also remove Java when you perform the Version 7.2 upgrade. Select Option 6, "Remove installed products." When prompted, enter the device for your target system; then select Java from the list of products. OpenVMS Installation, Upgrade, and Hardware Release Notes 1-13 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.4 Installation and Upgrade Information Specific to Alpha 1.4.2.4 Spiralog File System Not Supported V7.2 Spiralog has been retired and does not work with OpenVMS Version 7.2. _______________________ Warning _______________________ If Spiralog is installed on your system, you must deinstall it before upgrading to OpenVMS Version 7.2. ______________________________________________________ 1.4.2.5 Error When Upgrading DIGITAL TCP/IP Services for OpenVMS V7.2 When upgrading a version of DIGITAL TCP/IP Services for OpenVMS Alpha that is earlier than Version 5.0, you may encounter the following error: %PCSI-I-PRCOUTPUT, output from subprocess follows ... %LIBRAR-E-LOOKUPERR, error looking up UCX in $4$DKA300:[SYS0.SYSCOMMON.][SYSHLP]SDA.HLB;1 -LBR-E-KEYNOTFND, key not found %PCSI-E-EXERMVFAIL, product supplied EXECUTE REMOVE procedure failed %PCSI-E-OPFAILED, operation failed Terminating is strongly recommended. Do you want to terminate? [YES] This error can occur when you are upgrading DIGITAL TCP/IP Services as part of an OpenVMS upgrade, or during a separate TCP/IP Services upgrade. When the old version of TCP/IP Services is removed, it attempts to remove the module UCX from the SDA Help library. However, if OpenVMS has been upgraded since TCP/IP Services was installed, the SDA Help library has been replaced by a new library and the UCX module that TCP/IP Services inserted into the old SDA Help library is not found. This problem can also occur if you attempt to remove DIGITAL TCP/IP Services for OpenVMS. The workaround to upgrade or remove DIGITAL TCP/IP Services is to answer "NO" to the question "Do you want to terminate?" A NO response allows the operation to complete. 1-14 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.4 Installation and Upgrade Information Specific to Alpha ________________________ Note ________________________ Normally you should answer "YES" (the default) to the "Do you want to terminate?" question unless Compaq (or another software provider) specifically instructs you to answer otherwise under certain circumstances, such as this. ______________________________________________________ 1.4.2.6 Error When Removing DIGITAL TCP/IP Services for OpenVMS (UCX) Version 4.2 V7.2 The following error can occur when removing DIGITAL TCP/IP Services for OpenVMS (UCX) Version 4.2: %PCSI-I-PRCOUTPUT, output from subprocess follows ... %DCL-E-OPENIN, error opening PCSI$SOURCE:[000000]CLEAN_SDA_HELP.COM; as input -RMS-F-DEV, error in device name or inappropriate device type for operation Portion done: 10% %PCSI-E-EXERMVFAIL, product supplied EXECUTE REMOVE procedure failed -RMS-F-DEV, error in device name or inappropriate device type for operation %PCSI-E-OPFAILED, operation failed Terminating is strongly recommended. Do you want to terminate? [YES] The workaround to upgrade or remove DIGITAL TCP/IP Services is to answer "NO" to the question "Do you want to terminate?" A NO response allows the operation to complete. ________________________ Note ________________________ Normally you should answer "YES" (the default) to the "Do you want to terminate?" question unless Compaq (or another software provider) specifically instructs you to answer otherwise under certain circumstances, such as this. ______________________________________________________ OpenVMS Installation, Upgrade, and Hardware Release Notes 1-15 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.4 Installation and Upgrade Information Specific to Alpha 1.4.2.7 Rolling Upgrades for MEMORY CHANNEL Configurations V7.2 If you are performing a rolling upgrade from Version 6.2 or Version 6.2-x to Version 7.2, and are using MEMORY CHANNEL adapters (CCMAA-xx), see Section 4.14.2.10.1 for special instructions before you upgrade. 1.4.2.8 X.25 Version 1.0-G and Earlier Not Supported V7.2 X.25 Version 1.0-G and earlier will not operate on OpenVMS Version 7.2. If you upgrade to OpenVMS Version 7.2 from OpenVMS Version 6.2, you must remove X.25 Version 1.0-G before you upgrade. Compaq recommends that you install X.25 Version 1.2 and X25ALP_MUPA012 (the mandatory update kit for X.25 Version 1.2A) during the operating system upgrade. 1.4.2.9 X.25 Version 1.1-B for OpenVMS Alpha Crashes OpenVMS Version 7.2 V7.2 Customers using X.25 Version 1.1-B for OpenVMS Alpha should install X.25 Version 1.2 and X25ALP_MUPA012 (the mandatory update kit for X.25 Version 1.2A) before installing OpenVMS Alpha Version 7.2. Failure to do so will result in a system crash when X.25 starts up. If you install X.25 Version 1.2 over Version 1.1-B or Version 1.1-B ECO01, you will get a number of warning messages. If the X.25 Version 1.1-B ECO03 product, called X25ECO03, has been installed on your system, Compaq strongly recommends using the command PRODUCT REMOVE X25ECO03 to remove X25ECO03 before you install X.25 Version 1.2. If you do not remove X25ECO03 before installing the X.25 Version 1.2 kit, you must respond to PRODUCT error and warning messages to prevent the installation from terminating. Removing X25ECO03 after installing Version 1.2, can result in the uwanted removal of some files associated with Version 1.2. 1-16 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.5 ALPHAbook 1 (Alpha Only) 1.5 ALPHAbook 1 (Alpha Only) V7.1 The following sections contain release notes specific to the ALPHAbook 1 notebook computer. 1.5.1 Using the SCSI_MODE Utility The OpenVMS Alpha operating system includes a generic SCSI_MODE utility that allows privileged users to modify a SCSI device's mode pages. By using this utility to enable automatic disk spindown, users can save approximately 2 watts of power. Because mode pages are saved on the disk drive, the state is saved across power cycles. The following example shows how to enable automatic SCSI disk spindown after a 1-minute timeout period. (To select a spindown time other than 1 minute, replace the "01" following the offset f with the desired number of minutes expressed as a 2-digit hexadecimal value.) This procedure is recommended for use only on the internal drive of the ALPHAbook 1 notebook computer. Note that the parameter values shown in this example apply only to DVAS-2810 devices. To identify the SCSI disk devices on your system, use the SHOW DEVICE/FULL DK command. $ define dcl$path sys$etc $ scsi_mode -devnam dka0 -devtyp DVAS-2810 -offset f 01 -page 38 -mount -save $! $! Processing Page #38h $! $! Cur 00______ 04______ 08______ 0C______ 10______ 14______ 18______ 1C______ $! 0000 11000008 001829D0 00000200 B80400B4 0000 $! $! Chng 00______ 04______ 08______ 0C______ 10______ 14______ 18______ 1C______ $! 0000 11000008 001829D0 00000200 B80400FF 0000 $! $! Sel 00______ 04______ 08______ 0C______ 10______ 14______ 18______ 1C______ $! 0000 00000008 001829D0 00000200 38040001 0000 $! Perform MODE SELECT to page 38h [y/n] ? y OpenVMS Installation, Upgrade, and Hardware Release Notes 1-17 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.5 ALPHAbook 1 (Alpha Only) 1.5.2 Naming Serial Line Devices If an ALPHAbook 1 notebook computer is booted with the console environment variable set to graphics, the name of the serial line (COM1) will be different. On an ALPHAbook 1, the COM1 device is called TTA0. The COM1 device is controlled by SYS$YSDRIVER instead of SYS$OPDRIVER. If the console is set to serial, the device is called OPA0. 1.5.3 Graphics Display Modes The ALPHAbook 1 notebook computer contains a Western Digital 90C24A graphics controller displayed on a 10.4-inch active matrix Thin Film Transistor (TFT) display. Note that if a video monitor (CRT) is connected, the DECwindows display server software (which automatically detects the presence of an attached video monitor) will set the resolution to 1024 x 768 and disable the TFT display. If the server determines that no monitor is connected, it will force the size to match the LCD (800 x 600) and disable the CRT outputs (which saves power when the computer is running on battery). 1.5.4 Customizing the Graphics Display You can override the size selection by modifying the SYS$MANAGER:DECW$PRIVATE_SERVER_SETUP.COM file. You can also modify other parameters by using the DCL command DEFINE/SYSTEM for the following logical names: o DECW$SERVER_DYNAMIC_SIZE If defined as TRUE, you are prompted for the screen size when the system boots. The prompt times out in 10 seconds and the default is set (unless you have overridden the default in your private server setup). o DECW$SERVER_DISPLAY_SELECT You can specify one of the following values: 1-18 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.5 ALPHAbook 1 (Alpha Only) ________________________________________________________ Value__Result___________________________________________ 1 LCD-only operation 2 CRT-only operation 3______Simultaneous_operation___________________________ Note the following conventions: - The default is either 3 (if a monitor is available) or 1 (if no monitor is available. - If you have not explicitly selected the display or the resolution, then 1024 x 768 CRT-only is the default when a monitor is detected. If no monitor is detected, then 800 x 600 LCD-only is selected. - If you explicitly select the display, then that selection takes precedence over any other size requests. For example, if you select LCD, the 800 x 600 size supersedes any previous size specification. o DECW$SERVER_REFRESH_RATE This logical name selects an alternate vertical refresh rate in Hertz (for example, 60 Hz). The defaults are as follows: ________________________________________________________ Vertical Refresh Mode__________Resolution____Frequency_in_Hz_____________ LCD-only 800 x 600 56 CRT-only 640 x 480 72 800 x 600 72 1024 x 768 70 Other CRT 640 x 480 60 640 x 480 70 800 x 600 56 800 x 600 60[1] 1024 x 768 60 1024 x 768 75 [1]Actual_refresh_is_62_Hz._____________________________ ________________________________________________________ OpenVMS Installation, Upgrade, and Hardware Release Notes 1-19 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.5 ALPHAbook 1 (Alpha Only) o DECW$SERVER_VIRTUAL_MODE If this logical name is set to 1, note the following characteristics: - The server operates as a virtual frame buffer. - The resolution can be any of the previously listed sizes (or higher). - An 800 x 600 window is displayed for the internal (TFT) monitor and a 1024 x 768 window is displayed for an external monitor. Moving the pointer to the screen edges pans the display within the virtual frame. - Drawing can be slower (due to offscreen memory requirements). Changed areas are updated on a batch count or when the server has no more work. You can set the batch count with the logical DECW$SERVER_ BATCH_COUNT (the default is 10). 1.5.5 PCMCIA Bus Support The following notes apply to the PCMCIA bus. Supported PCMCIA Cards OpenVMS support for the PCMCIA bus on the ALPHAbook 1 system is limited to the following cards: o 3Com EtherLink III (3C589C) o Megahertz 28.8 FAX/Modem (XJ2288) o Apex Data ClipperCom V.34 International Data/FAX Modem (011-20811) The OpenVMS operating system can configure a maximum of one Ethernet card and one FAX/Modem card. Hot Swapping PCMCIA Cards Not Supported Hot swapping (removing and replacing cards while the computer is running) PCMCIA cards is not supported. If a PCMCIA card is inserted or removed while the OpenVMS operating system is running, it could result in a system hang (the system is unresponsive) or a system crash. A future release of the OpenVMS operating system is expected to include support for hot swapping PCMCIA cards. 1-20 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.5 ALPHAbook 1 (Alpha Only) PCMCIA Modem Setting The highest recommended baud rate for the Apex Data ClipperCom V.34 International Data/FAX Modem card is 9600. For access to the modem, Compaq recommends that you use the following DCL and modem commands: $ SET TERM/PERM/SPEED=9600/ALT/MODEM TTB0: $ SET HOST/DTE TTB0: at*ncxx at&k6 at&s1 at\g1 at\q1 at\x1) (Note that xx represents the country number; for example, the United States is 22. See the Apex Data ClipperCom V.34 documentation for a list of country numbers.) The highest recommended baud rate for the Megahertz 28.8 FAX/Modem card is 9600. For access to the modem, Compaq recommends that you use the following DCL and modem commands: $ SET TERM/PERM/SPEED=9600/ALT/MODEM TTB0: $ SET HOST/DTE TTB0: at&s1 at&r1 Audio Feedback Supported on PCMCIA Modem Audio feedback is available for the telephone call status. PCMCIA FAX Support The Apex Data ClipperCom V.34 International Data/FAX Modem works correctly with the PMDF FAX and Gold-FAX software to transmit data. The Megahertz 28.8 FAX/Modem works correctly with the PMDF FAX software to send and receive data with line speeds up to 19.2 baud. However, if you are using Gold- FAX software to send a Fax, the maximum baud rate allowed with a Megahertz 28.8 FAX/Modem card is 9600 baud. OpenVMS Installation, Upgrade, and Hardware Release Notes 1-21 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.5 ALPHAbook 1 (Alpha Only) 1.5.6 Audio Support The DECsound utility included with DECwindows Motif Version 1.2-3 does not support the sound processor on the ALPHAbook 1 system. Audio support is available on the OpenVMS Multimedia services kit, a separately licensed layered product available from Compaq. 1.5.7 Keyboard Mapping The ALPHAbook 1 keyboard is an 88-key, PC layout keyboard. The following notes describe how to set up the keyboard and enable particular key functions. Keyboard Setup You can set up the keyboard either to follow the engravings or to map the keys in a manner that makes it easier for you as an OpenVMS user. To set up your keyboard either way, do the following: 1. Click on Options in the Session Manager box. 2. Select Keyboard from the list of options. 3. Select one of the following LK443 or LK444 keyboard types: o A keyboard type with the suffix _PC maps the keyboard to follow the engravings. For example, US_LK443AA_PC. o A keyboard type with the suffix _LK sets the keyboard to follow the LK-style mapping common to OpenVMS systems. For example, US_LK443AA_LK. The procedure for setting up your keyboard is the same as that required for all current AlphaServer and AlphaStation systems. The only difference is that the ALPHAbook 1 keyboard does not have all of the keys directly on it. (The next section describes how to generate those missing keys.) You can also attach an LK411 (LK401 layout) compatible keyboard or a PCXAL (PS2 layout) keyboard directly to the AlphaBOOK 1 computer using the mini-docking station. 1-22 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.5 ALPHAbook 1 (Alpha Only) Key Functions When mapping to an LK-style keyboard, note the following: o The right ALT key does not transmit any code. Instead, the keyboard controller generates missing LK-style keys when pressed in combination with this key. These alternate keys are engraved in grey on the keyboard. For example, pressing RIGHT-ALT-U ([grey 4]) provides the function of KP4. ________________________ Note ________________________ By default, the right ALT key is set for the special functions described in the ALPHAbook 1 User Guide (such as increasing or decreasing display brightness). To set the right ALT key to perform different functions so you can emulate a LK-style keyboard, you must change this setting at the console level by entering the following command at the console prompt: >>> SET HOTKEY OFF After you enter this command, either enter the INIT command or powercycle the system. You can then use the right ALT key to perform the LK-style keyboard actions described in this section. ______________________________________________________ o Two keys are mislabeled. The KP_Subtract and KP_Add are engraved in grey on the minus (-) and plus (+) keys. However, the 0 (zero) and P keys actually provide the function for KP- and KP+ respectively. o NUMLOCK is generated by SHIFT-NUMLOCK, and KP_ENTER is generated by RIGHT-ALT-ENTER. o There is no way to generate directly RIGHT-ALT, RIGHT- COMPOSE, or LEFT-COMPOSE. You can provide the function of the compose key by pressing LEFT ALT-SPACE. o You can generate missing function keys by pressing CAPS LOCK-Fn. Pressing CAPS LOCK adds a value of 10 to the function key (Fn) that you also press. For example, pressing CAPS LOCK-F1 generates the F11 key; pressing CAPS LOCK-F2 generates the F12 key. OpenVMS Installation, Upgrade, and Hardware Release Notes 1-23 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.5 ALPHAbook 1 (Alpha Only) o Use the following table to help you determine which keys to press to provide the function of the corresponding LK-style key. ________________________________________________________ LK-Style_Key____ALPHAbook_Key_Combination_______________ PF1 [SHIFT] [grey Numlock] PF2 [RIGHT ALT] [grey /] PF3 [RIGHT ALT] [grey *] PF4 [RIGHT ALT] [0] KP, [RIGHT ALT] [P] KP- [LOCK] [RIGHT ALT] [P] KP_ENTER [RIGHT ALT] [ENTER] KP. [RIGHT ALT] [grey .] KP0 [RIGHT ALT] [grey 0] KP1 [RIGHT ALT] [grey 1] KP2 [RIGHT ALT] [grey 2] KP3 [RIGHT ALT] [grey 3] KP4 [RIGHT ALT] [grey 4] KP5 [RIGHT ALT] [grey 5] KP6 [RIGHT ALT] [grey 6] KP7 [RIGHT ALT] [grey 7] KP8 [RIGHT ALT] [grey 8] KP9 [RIGHT ALT] [grey 9] FIND INS INS HOME REMOVE PAGE UP SELECT DEL PREV END NEXT PAGE DOWN HELP PRINT SCREEN DO______________SCROLL_LOCK_____________________________ 1-24 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.5 ALPHAbook 1 (Alpha Only) 1.5.8 OpenVMS Cluster Restrictions Due to controller limitations of the PCMCIA Ethernet card, Compaq recommends that you use the ALPHAbook 1 computer only as a satellite node in a cluster environment rather than as a cluster boot node. 1.6 AlphaServer 1000A (Alpha Only) The following sections contain release notes pertaining to the AlphaServer 1000A computer. 1.6.1 Problems and Restrictions The following notes describe problems or restrictions with the AlphaServer 1000A computer. 1.6.1.1 Bus Probe Algorithm Default V7.1 You cannot set the console variable BUS_PROBE_ALGORITHM to OLD on AlphaServer 1000A computers. The default setting is NEW. If you reset the bus probe algorithm to OLD, your OpenVMS system will not boot correctly. 1.6.1.2 Installation Failure with DEFPA Adapter V7.1 When you attempt to install the OpenVMS operating system on an AlphaServer 1000A computer that uses a DEFPA adapter, the installation might fail, resulting in a KERNEL STACK NOT VALID HALT error message. If this failure occurs, powercycle your system and restart the installation. 1.7 AlphaServer 2100 (Alpha Only) V7.2 The following sections contain information specific to the AlphaServer 2100 series computer. OpenVMS Installation, Upgrade, and Hardware Release Notes 1-25 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.7 AlphaServer 2100 (Alpha Only) 1.7.1 Console Display On AlphaServer 2100 and 2100A systems, a console display similar to the following is normal and does not represent system errors: P00>>>SET CONSOLE SERIAL P00>>>INIT VMS PALcode X5.48-112, OSF PALcode X1.35-81 starting console on CPU 0 initialized idle PCB initializing semaphores initializing heap initial heap 1c0c0 memory low limit = 132000 heap = 1c0c0, 13fc0 . . . probing hose 0, PCI probing PCI-to-EISA bridge, bus 1 probing PCI-to-PCI bridge, bus 2 *** unable to assign PCI base address *** bus 2, slot 7, function 0, size 00001000 (16 bit I/O) bus 1, slot 1 -- fra -- DEFEA bus 1, slot 2 -- vga -- Compaq Qvision bus 1, slot 3 -- pua -- KFESA bus 2, slot 1 -- pka -- NCR 53C810 bus 2, slot 6 -- pkb -- NCR 53C810 bus 2, slot 7 -- pkc -- DEC KZPSA bus 0, slot 7 -- ewa -- DECchip 21041-AA initializing keyboard Memory Testing and Configuration Status Module Size Base Addr Intlv Mode Intlv Unit Status ------ ----- --------- ---------- ---------- ------ 0 64MB 00000000 1-Way 0 Passed Total Bad Pages 0 Testing the System Testing the Disks (read only) Testing the Network econfig: 20041 99 econfig: 20042 04 econfig: 20043 00 1-26 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.7 AlphaServer 2100 (Alpha Only) AlphaServer 2100A Console V4.3-130, built on Oct 26 1996 at 19:44:57 P00>>>P Note that in the previous display, the KZPSA adapter is successfully installed despite the error message displayed in the following lines: *** unable to assign PCI base address *** bus 2, slot 7, function 0, size 00001000 (16 bit I/O) 1.7.2 SCSI Controller Restriction The Adaptec 1740/1742 SCSI controller (PB2HA-SA) is not supported on AlphaServer 2100 systems having more than 1 gigabyte (GB) of memory. If the controller is connected to such a system, the following message appears on the operator's console: %PKJDRVR-E- The direct DMA window does not map all of memory. Port is going OFF LINE. 1.8 AlphaServer 4100 (Alpha Only) The following sections contain release notes specific to the AlphaServer 4100 computer. 1.8.1 Problems and Restrictions The following notes describe restrictions related to the AlphaServer 4100. 1.8.1.1 EISA Configuration Utility (ECU) V7.1 AlphaServer 4100 systems do not support automatic startup of the ECU (EISA Configuration Utility). Instead, follow the procedure described in this section. 1. In the SRM console, enter the arc command. This starts the AlphaBIOS facility. 2. Press the F2 key after the following display: 3. Use the DownArrow key to select Utilities. Then use either the RightArrow or Enter key to highlight the first submenu entry, "Run ECU From Floppy..." The display is as follows: OpenVMS Installation, Upgrade, and Hardware Release Notes 1-27 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.8 AlphaServer 4100 (Alpha Only) 4. Insert the ECU diskette in the floppy drive (if it isn't there already). 5. Press the Enter key to run the ECU. 6. After the ECU has run and returns control to AlphaBIOS, press the reset button to restart the system. If you switch from another operating system to OpenVMS on AlphaServer 4100 systems, you may have to remove EISA boards that have not been qualified on OpenVMS and run the EISA Configuration Utility (ECU). To run the ECU on other platforms, use the ECU command. To run the ECU on the AlphaServer 4100, use the ALPHABIOS command; and then run the ECU from the ALPHABIOS utility menu. For more information about using the ECU, refer to the AlphaServer 4100 System Drawer User's Guide. 1.8.2 FRU Table Error V7.1 After you boot the OpenVMS operating system, the following message might display on the screen: *****Config packet buffer allocation failure: Continuing without writing Errorlog This message indicates that the Field Replaceable Units (FRU) table is too large for the default set by the SYSGEN parameter ERLBUFFERPAGES. It is a warning message only and indicates that the FRU table was not written in the Error Log on this reboot. If your system displays this message, Compaq recommends that you change the ERLBUFFERPAGES parameter from 4 (the default) to 6. The following example shows how to use the SYSGEN utility to accomplish this task: $ MCR SYSGEN SYSGEN>use current SYSGEN>set erlbufferpages 6 SYSGEN>write current SYSGEN>exit 1-28 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.8 AlphaServer 4100 (Alpha Only) If this warning appears again after you reboot the system, increase the ERLBUFFERPAGES parameter in increments of 2 (maximum value is 32) until the warning message is no longer displayed. The final size of ERLBUFFERPAGES (the value that resolves the problem) varies depending on the configuration of your system. Note that if the FRU table exceeds the limit set by the ERLBUFFERPAGES parameter, during a boot of the OpenVMS Alpha operating system, no entry will be written to the error log file. 1.9 AlphaServer 8200 and AlphaServer 8400 (Alpha Only) This section contains release notes pertaining to AlphaServer 8200/8400 systems. 1.9.1 Problems and Restrictions The following notes describe restrictions that apply to AlphaServer 8200/8400 systems. 1.9.1.1 Field Replaceable Units (FRU) Table Error V7.2 The error log buffer size is controlled by the SYSGEN parameter ERLBUFFERPAGES, which has a maximum value of 32 pagelets. If the Field Replaceable Unit (FRU) table exceeds this limit during a boot of the OpenVMS Alpha operating system on an AlphaServer 8200/8400 or 4100 system, an entry will not be written to the error log file. 1.9.1.2 Environmental Data Restrictions V7.1-1H1 On AlphaServer 8200 systems, the power regulators do not contain sensors for environmental conditions. Therefore, data cannot be reported in the thermal and power supply MIB groups of the DSM System subagent. On AlphaServer 8400 systems, the power regulators do contain environmental sensors, but some configurations might not report environmental information correctly to the DSM System subagent. This problem affects the thermal and power supply MIB groups and will be resolved in a future release of the software. OpenVMS Installation, Upgrade, and Hardware Release Notes 1-29 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.10 AlphaStation 255 (Alpha Only) 1.10 AlphaStation 255 (Alpha Only) See Section 1.12.2.2 for a release note about using PowerStorm graphics cards on an AlphaStation 255. 1.11 DEC 7000 (Alpha Only) This section contains release notes pertaining to DEC 7000 systems. 1.11.1 Changes and Enhancements The following note describes a change in the behavior of DEC 7000 systems. 1.11.1.1 Ctrl/P Behavior Change During Boot V7.1 Starting with OpenVMS Alpha Version 7.1, the remote halt command, issued by typing Ctrl/P at the system console, does not work during boot until the following copyright banner appears. $! Copyright (c) 1996 Digital Equipment Corporation. All rights reserved. In previous versions of OpenVMS, typing Ctrl/P at the system console always returned the system to the console prompt at any time during the boot. 1.12 DECwindows X11 Display Server (Alpha Only) This section contains release notes pertaining to the DECwindows X11 display server for OpenVMS Alpha systems. 1.12.1 Changes and Enhancements The following note describes a change in behavior on the DECwindows X11 display server. 1.12.1.1 Ctrl/F2 Behavior Change V7.1 Starting with OpenVMS Alpha Version 7.1, you can no longer press Ctrl/F2 to switch from windows mode to console mode if your workstation or server contains one of these Qvision graphics boards: o PB2GA-AA (Qvision 1024E) 1-30 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.12 DECwindows X11 Display Server (Alpha Only) o PB2GA-HA (Qvision 1280P) This behavior has always been true for the S3 Trio64 graphics board (PB2GA-JA/JB). _______________________ Caution _______________________ Directing any output directly to the operator console window (OPA0: device) might cause a system crash during a simultaneous graphics operation. ______________________________________________________ Support for the operator console is now provided using a Motif-based window option that is enabled during DECwindows startup. For details, refer to Section 2.12.2.4. Note that you can still use Ctrl/F2 to switch from console mode to windows mode. 1.12.2 Problems and Restrictions The following notes describe restrictions for the DECwindows X11 display server. 1.12.2.1 Graphics Boards Support V7.2 You must install DIGITAL Open3D Version 4.7 or later for OpenVMS Alpha to support the following types of graphics boards on Version 7.2: o ZLX-M o ZLX-L o ZLXp-L The DIGITAL Open3D product also provides the following 3D extensions: OpenGL, PEX, and PCM. 1.12.2.2 PowerStorm Graphics Cards Can Hang System V7.2 On AlphaStation 255 systems using PowerStorm 3D30 and 4D20 (TGA2) graphics cards, the system will hang if the user selects the InlayColor or InlayPlain backdrop in the Style Manager's Backdrop dialog box. If this happens, you must reboot the system to use it. OpenVMS Installation, Upgrade, and Hardware Release Notes 1-31 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.12 DECwindows X11 Display Server (Alpha Only) 1.12.2.3 S3 Multihead Graphics Alpha computers equipped with S3 Trio32 or Trio64 graphics cards support single-screen display only. Multihead graphics are not supported. 1.13 DIGITAL Modular Computing Components (DMCC) (Alpha Only) This section contains release notes pertaining to DMCC. 1.13.1 Problems and Restrictions The following notes describe restrictions for DMCC. 1.13.1.1 CPUSPINWAIT Crash and Recovery on DMCC 21164A Systems V7.2 DIGITAL Modular Computing Components 21164A systems may experience the following crash running OpenVMS Version 7.2: CPUSPINWAIT, CPU spinwait timer expired To avoid this problem, reboot the system with the SYSTEM_ CHECK parameter disabled. Use the following commands when you reboot to disable the SYSTEM_CHECK parameter: >>> boot -flags, 0,1 bootdevice SYSBOOT> SET SYSTEM_CHECK 0 SYSBOOT> CONTINUE 1.13.1.2 Alpha 5/366 and 5/433 PICMG SBC Restriction V7.2 The KZPDA SCSI Controller and the PBXGA Graphics Card cannot be placed in a slot behind the bridge on the DIGITAL Modular Computing Components (DMCC) Alpha 5/366 and 5/433 PICMG SBCs. 1.13.1.3 Updating the SRM Console V7.2 To update the SRM console on the Alpha 4/233 (21064a), 4/266 (21164a), 5/366, and 5/433 DMCC systems, you must choose either the SRM console or the AlphaBIOS setup. You can store only one console. o If you are running OpenVMS on these systems, update only the SRM console. 1-32 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.13 DIGITAL Modular Computing Components (DMCC) (Alpha Only) o If you are running Windows NT on these systems, update only the AlphaBIOS setup. If you accidentally update both the SRM and the AlphaBIOS consoles, you will enter the AlphaBIOS Setup menu, and you will not have the option to return to the SRM console. The only way to then exit the AlphaBIOS Setup menu and return to the SRM console is to use a Firmware Update Utility located at the following Internet site: ftp://ftp.digital.com/pub/Digital/Alpha/firmware/index.html 1.14 OSU HTTP Server This section contains a release note for the Ohio State University (OSU) HTTP server. 1.14.1 Problems and Restrictions The following note describes a potential problem with the OSU HTTP server. 1.14.1.1 Running on OpenVMS Version 7.2 V7.2 If you use the OSU HTTP server on OpenVMS Version 7.2, you should install Version 3.3A (or later) of the server. Earlier versions of the server can hang when you use the "privrequest shutdown" or "privrequest restart" commands. You can download Version 3.3A from the following web site: http://www.er6.eng.ohio-state.edu/www/doc/serverinfo.html If you do not want to install a new version of the server, there is a small source patch for earlier versions available in the server mailing list archives at: http://celia.kjsl.com/htbin/hypermail/..vms-web-daemon:[1998]/MAY?thread=patch/3 1.15 RF73 and Other RFnn DSSI Disk Devices Release notes in this section pertain to the RF31T, RF31T+, RF35, RF35+, RF73, and RF74 DSSI disk devices. OpenVMS Installation, Upgrade, and Hardware Release Notes 1-33 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.15 RF73 and Other RFnn DSSI Disk Devices 1.15.1 Problems and Restrictions This section describes a problem found in certain RF31T, RF31T+, RF35, RF35+, RF73, and RF74 DSSI disk devices. 1.15.1.1 RF73 and Other RFnn DSSI Disk Devices and Controller Memory Errors V6.2 A problem exists with the microcode for earlier versions of RF31T, RF31T+, RF35, RF35+, RF73, and RF74 DSSI disk devices that can cause data loss. The problem can occur when reading data from one of these devices if the device has had a controller memory error (also known as an error detection and correction (EDC) error). The error could have been induced by a virtual circuit closure or faulty hardware. Compaq advises customers with any of these devices to check their microcode revision levels. If the microcode revision levels are lower than the numbers shown in Table 1-2, Compaq recommends that you update the microcode. The microcode for all models, except RF31T, RF31T+, and RF35+, is provided on the latest OpenVMS binary distribution CD- ROM. The RF_VERS utility, a utility program that displays the microcode revision level of the DSSI disk devices, is also provided on the CD-ROM. Instructions for using the utility program and for updating the microcode are provided in this section. ________________________ Note ________________________ If you have an RF31T, RF31T+, or RF35+ disk drive with a version of microcode that is not supported (see Table 1-2), and if you have a support contract, contact your Compaq support representative. Otherwise, contact your authorized reseller. ______________________________________________________ The earliest supportable revision levels of the DSSI disk microcode are shown in Table 1-2. 1-34 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.15 RF73 and Other RFnn DSSI Disk Devices Table_1-2_Supported_Microcode_Revision_Levels______________ Device_Type______Minimum_Level_with_Supported_Microcode____ RF31T T387E RF31T+ T387E RF35 T392D RF35+ T392D RF36 V427P RF73 T392D RF74_____________V427P_____________________________________ To display the microcode version level of your DSSI disk devices, perform the following steps: 1. Log in to the SYSTEM account or another account that has the CMKRNL, DIAGNOSE, and SYSPRV privileges. 2. Enter the following commands: $ SET PROCESS /PRIVILEGE=(DIAGNOSE,CMKRNL,SYSPRV) $ SHOW DEVICE FYA0: On VAX systems, if the SHOW DEVICE command produces an error, enter the following commands: $ RUN SYS$SYSTEM:SYSGEN SYSGEN> CONN FYA0/NOADAP SYSGEN> ^Z On Alpha systems, if the SHOW DEVICE command produces an error, enter the following commands: $ RUN SYS$SYSTEM:SYSMAN SYSMAN> IO CONNECT FYA0: /NOADAP SYSGEN> ^Z The following is an example of the display produced by the RF_VERS utility: Program Name: RF_VERS Revision Level: V1.2s NOTICE: This program does not currently support the RF72 or any HSDxx controllers. See next version for support. DSSI disks currently on this system as seen by RF_VERS OpenVMS Installation, Upgrade, and Hardware Release Notes 1-35 OpenVMS Installation, Upgrade, and Hardware Release Notes 1.15 RF73 and Other RFnn DSSI Disk Devices Device Node Status Hardware Firmware Name Name Type Version _$22$DIA7: R4JL2I mounted RF73 T387A _$22$DIA6: R4I0BG mounted RF73 T387A _$22$DIA8: R4XLWE mounted RF73 T387A _$22$DIA2: R4FCZK mounted RF73 T387A _$22$DIA3: R4CKCG mounted RF73 T387A _$22$DIA4: R4ZKUE mounted RF73 T387A _$22$DIA9: R4GYYI mounted RF73 T387A _$22$DIA1: R4XRYI mounted RF73 T387A To update the microcode in your device, use the appropriate command for your device and platform from Table 1-3. _______________________ Caution _______________________ Back up the disk before updating the microcode. ______________________________________________________ Table 1-3 Commands for Updating Microcode in Certain DSSI __________Disk_Devices_____________________________________ Device Type______Platform__Command________________________________ RF35 Alpha $RUN SYS$ETC:RF35_T392F_DEC_ALPHA.EXE RF35 VAX $RUN SYS$ETC:RF35_T392F_DEC.EXE RF36 Alpha $RUN SYS$ETC:RF36_V427P_DEC_ALPHA.EXE RF36 VAX $RUN SYS$ETC:RF36_V427P_DEC.EXE RF73 Alpha $RUN SYS$ETC:RF73_T392F_DEC_ALPHA.EXE RF73 VAX $RUN SYS$ETC:RF73_T392F_DEC.EXE RF74 Alpha $RUN SYS$ETC:RF74_V427P_DEC_ALPHA.EXE RF74______VAX_______$RUN_SYS$ETC:RF74_V427P_DEC.EXE________ _______________________ Caution _______________________ Do not delete SCSI_INFO.EXE, RF_VERS.EXE, or any of the files listed in Table 1-3. If these files are deleted, VMSKITBLD.COM (on VAX) will not be able to find them. Similarly, on Alpha systems, the 1-36 OpenVMS Installation, Upgrade, and Hardware Release Notes OpenVMS Installation, Upgrade, and Hardware Release Notes 1.15 RF73 and Other RFnn DSSI Disk Devices PRODUCT INSTALL commands in AXPVMS$PCSI_INSTALL and AXPVMS$PCSI_INSTALL_MIN will fail. ______________________________________________________ OpenVMS Installation, Upgrade, and Hardware Release Notes 1-37 2 _________________________________________________________________ OpenVMS Layered Products Release Notes This chapter contains installation and support information about OpenVMS layered products. Notes about using compilers, linkers, and run-time library routines are included in Chapter 5. 2.1 Layered Product Support The Software Public Rollout Reports for OpenVMS list the availability of Compaq's software products shipping on the Software Products Library kits (CD-ROM consolidations) for OpenVMS Alpha and OpenVMS VAX. The reports contain the product name and version, the operating system version required to support the product, and the volume ship date for the product. The information in these tables is continually evolving and is subject to change. The reports are intended for public distribution and are updated monthly. The information is not provided in these release notes because of the changing nature of the information. These reports are available from the OpenVMS home page on the World Wide Web in the OpenVMS Products section. Use the following URL to access the OpenVMS Software Public Rollout Reports for OpenVMS: http://www.openvms.digital.com/openvms/os/swroll/index.html If you do not have Internet access, you can find the operating system support information on any of the quarterly Software Products Libraries, in the following directory: [README]SW_COMPAT_MATRIX.PS (.TXT) The Software Public Rollout Reports are also available from your Compaq support representative. OpenVMS Layered Products Release Notes 2-1 OpenVMS Layered Products Release Notes 2.2 Advanced Server V7.2 for OpenVMS (Alpha Only) 2.2 Advanced Server V7.2 for OpenVMS (Alpha Only) V7.2 Advanced Server V7.2 for OpenVMS and PATHWORKS V6.0B for OpenVMS are the only OpenVMS file server products supported on OpenVMS Version 7.2. These products supersede PATHWORKS for OpenVMS (Advanced Server) Version 6.0 and 6.0A, which are not supported on OpenVMS Version 7.2. PATHWORKS V6.0B for OpenVMS (Advanced Server) ships on both VAX and Alpha Version 7.2 systems. Advanced Server V7.2 for OpenVMS ships with the OpenVMS Alpha Version 7.2 kit. (It is not supported on OpenVMS VAX.) If you are upgrading to Advanced Server V7.2 for OpenVMS from an earlier version of PATHWORKS for OpenVMS, you must first upgrade to PATHWORKS V6.0B. For information about upgrading from PATHWORKS for OpenVMS and about installing Advanced Server for OpenVMS, refer to the Advanced Server for OpenVMS Server Installation and Configuration Guide provided with the kit documentation. Features Advanced Server for OpenVMS includes the following features: o OpenVMS Registry support The Advanced Server provides network users with access to the OpenVMS Registry. The Advanced Server also stores its own configuration data in the OpenVMS Registry. When you upgrade from PATHWORKS for OpenVMS to Advanced Server for OpenVMS, the server configuration parameters are automatically migrated from the LANMAN.INI file to the OpenVMS Registry. The Advanced Server provides the PWRK$REGUTL utility to manage server configuration parameters in the OpenVMS Registry. The server parameters in the OpenVMS Registry can also be viewed and managed from a Windows NT-based registry editor. See Section 5.17 for more information about the OpenVMS Registry. o Extended File Specifications support 2-2 OpenVMS Layered Products Release Notes OpenVMS Layered Products Release Notes 2.2 Advanced Server V7.2 for OpenVMS (Alpha Only) Advanced Server disk shares can be stored and managed on ODS-5 devices, providing better integration with Windows 98, Windows 95, and Windows NT file systems. Requirements To access Advanced Server for OpenVMS on OpenVMS Version 7.2, clients must be licensed using the new Advanced Server V7.2 license PAK: PWLMXXXCA07.02. Refer to the Advanced Server for OpenVMS Guide to Managing Advanced Server Licenses for more information. The Advanced Server requires that the OpenVMS Registry be available when the server is started. The server startup procedure starts the registry server if it is not available. Compaq recommends that the OpenVMS Registry be configured and started before you install and configure the Advanced Server for OpenVMS software. 2.3 DEC BASIC This section contains release notes pertaining to DEC BASIC. 2.3.1 Problems and Restrictions The following note describes a build restriction for DEC BASIC Version 1.2. 2.3.1.1 BASIC$STARLET.TLB Build Restriction (Alpha Only) V7.0 The restriction described in this release note applies to using DEC BASIC Version 1.2 on OpenVMS Alpha Version 7.0 or later. The restriction does not apply to DEC BASIC Version 1.3. The introduction of 64-bit support for system services prevents the proper construction and use of BASIC$STARLET.TLB on OpenVMS Alpha systems. If you do not need any of the system definitions from STARLET, take the default for the following question when installing DEC BASIC: Do you want to install the OpenVMS AXP system definitions (10 min.) [NO]? OpenVMS Layered Products Release Notes 2-3 OpenVMS Layered Products Release Notes 2.3 DEC BASIC If you do need system definitions from STARLET, there are two possible workarounds: o If you need only a few definitions, you can construct your own include library using the STARLET definitions as a guide. o If you require a number of system definitions, you must construct your own copy of BASIC$STARLET.TLB, as follows: 1. Before installing DEC BASIC, make a copy of STARLETSD.TLB in SYS$LIBRARY. Be sure no one uses STARLETSD.TLB until you have completed building BASIC$STARLET.TLB. 2. Edit your copy of SYS$LIBRARY:STARLETSD.TLB to remove any system definitions that refer to 64-bit integers by value. (DEC BASIC does not support these, so you will not need them.) 3. Install DEC BASIC and request that the system definitions be installed. 4. When the DEC BASIC installation is complete, delete your copy of SYS$LIBRARY:STARLETSD.TLB. A usable copy of BASIC$STARLET.TLB will be in SYS$LIBRARY. It is now safe for other users to access STARLETSD.TLB. 2.4 DEC C and DEC C++ This section contains release notes pertaining to DEC C and DEC C++. 2.4.1 Changes and Enhancements The following note describes a change in how STARLET header files now ship on OpenVMS VAX. 2-4 OpenVMS Layered Products Release Notes OpenVMS Layered Products Release Notes 2.4 DEC C and DEC C++ 2.4.1.1 STARLET Header Files Now Ship with OpenVMS VAX V7.1 Starting with Version 7.1, OpenVMS VAX directly supplies the STARLET header files for DEC C and DEC C++ in SYS$LIBRARY:SYS$STARLET_C.TLB, as has always been done on OpenVMS Alpha systems. DEC C and DEC C++ compiler Versions 5.2 or later are required to access the STARLET headers. See a warning about installing earlier DEC C and DEC C++ compiler versions on OpenVMS VAX Version 7.1 or later in Section 2.4.2.1. The content of the STARLET headers has also been edited to correct deficiencies in versions supplied by the DEC C and DEC C++ compilers in releases prior to Version 7.1. 2.4.2 Problems and Restrictions The following notes describe problems associated with DEC C and DEC C++. 2.4.2.1 Pre-Version 5.2 Kits May Delete SYS$STARLET_C.TLB (VAX Only) V7.1 Installing a version of the DEC C or DEC C++ compiler older than Version 5.2 on OpenVMS VAX Version 7.1 or later may damage or delete SYS$LIBRARY:SYS$STARLET_C.TLB. (See Section 2.4.2.2 for another warning about installing DEC C++ Version 5.3 on OpenVMS VAX Version 7.1 and later.) 2.4.2.2 DEC C++ Version 5.3 Installation Fails (VAX Only) V7.1 When you attempt to install DEC C++ Version 5.3 on VAX systems running OpenVMS Version 7.1 or later, the installation fails because the Version 5.3 kit fails to install the system headers on OpenVMS Version 7.1 and later. DEC C++ Version 5.4 fixes these problems. OpenVMS Layered Products Release Notes 2-5 OpenVMS Layered Products Release Notes 2.5 DEC Pascal 2.5 DEC Pascal This section contains release notes pertaining to DEC Pascal. 2.5.1 Problems and Restrictions The following note describes a potential problem with an older version of DEC Pascal. 2.5.1.1 Installing DEC Pascal Version 5.5 After an Upgrade (Alpha Only) V7.1 After upgrading to OpenVMS Alpha Version 7.1 or later, you should reinstall DEC Pascal to produce new versions of STARLET.PAS and other definition files to match the upgraded system. If you do not reinstall DEC Pascal after upgrading to OpenVMS Alpha Version 7.1 or later, the compiler on your system will still work correctly. However, STARLET.PAS and the other definition files will not contain any of the new definitions added in Version 7.1 and later. Note that because of changes in OpenVMS, the DEC Pascal Version 5.5 kit can sometimes go into an infinite loop when it is installed on OpenVMS Alpha Version 7.1 or later. This problem is solved in DEC Pascal Version 5.6. 2.6 DEC PL/I This section contains release notes pertaining to DEC PL/I for OpenVMS. 2.6.1 Problems and Restrictions The following note describes a DEC PL/I restriction. 2.6.1.1 RTL Support for OpenVMS V7.2 The RTL that ships with OpenVMS Version 7.2 has not been tested with OpenVMS Version 7.1 or 7.2, and therefore is not supported. However, the RTL that ships with DEC PL/I Version 4.2 and later is supported on OpenVMS Versions 7.1 and 7.2. 2-6 OpenVMS Layered Products Release Notes OpenVMS Layered Products Release Notes 2.7 DECdfs for OpenVMS 2.7 DECdfs for OpenVMS This section contains release notes pertaining to DECdfs. 2.7.1 Problems and Restrictions The following note cites the consequences of using an old version of DECdfs for OpenVMS. 2.7.1.1 Version 2.3 Required for OpenVMS Alpha V7.2 If you want to run DECdfs for OpenVMS on OpenVMS Alpha Version 7.2, you must install Version 2.3. Do not install earlier versions of DECdfs on OpenVMS Alpha Version 7.2; your system will crash. DECdfs for OpenVMS Version 2.3 ships with OpenVMS Version 7.2. DECdfs for OpenVMS Version 2.3 is also recommended for OpenVMS VAX Version 7.2 systems. Earlier versions of DECdfs for OpenVMS may not cause your OpenVMS VAX system to crash, but DECdfs will function with limited capacity. 2.8 DECforms This section contains release notes pertaining to DECforms. 2.8.1 Problems and Restrictions The following note describes a DECforms support issue. 2.8.1.1 Support on OpenVMS Version 7.0 and Later (Alpha Only) V7.0 Because of changes in DECthreads, DECforms Version 2.1 does not work with OpenVMS Alpha Version 7.0 and later. Installing OpenVMS Alpha Version 7.0 or later causes existing applications based on DECforms Version 2.1 to fail; installing DECforms Version 2.1 on OpenVMS Alpha Version 7.0 or later also fails. In both cases, you get the following error message: %CMA-F-USE_ERROR, requested operation is inappropriate for the specified object For DECforms based applications to operate correctly on OpenVMS Alpha Version 7.0 and later, you must run DECforms Version 2.1A or later. OpenVMS Layered Products Release Notes 2-7 OpenVMS Layered Products Release Notes 2.9 DECnet Layered Products 2.9 DECnet Layered Products This section contains release notes pertaining to the DECnet layered products. 2.9.1 Problems and Restrictions Several restrictions for DECnet layered products are covered elsewhere in this manual, as follows: o External authentication requirements: - For DECnet Phase IV (See Section 4.8.2.3.) - For DECnet Phase V (See Section 4.8.2.8.) o DECnet-Plus MOP satellite boot service restriction (See Section 4.14.2.2.) 2.9.2 Documentation Changes and Corrections The following release note documents a correction to the DECnet-Plus for OpenVMS Network Management manual. 2.9.2.1 DECnet-Plus for OpenVMS Network Management V7.2 Section 8.4.2.1 of the DECnet-Plus for OpenVMS Network Management manual incorrectly states that DECnet-Plus for OpenVMS supports up to 16 circuits. In fact, the maximum number of circuits that can be created really is 4, as stated in the Software Product Description. The configuration utility (NET$CONFIGURE.COM) now imposes a limit of 4 circuits. 2.10 DECpresent This section contains a release note pertaining to installing DECpresent. 2.10.1 Problems and Restrictions The following note describes a dependence for installing DECpresent. 2-8 OpenVMS Layered Products Release Notes OpenVMS Layered Products Release Notes 2.10 DECpresent 2.10.1.1 Installation Dependency on OpenVMS VAX Version 6.1 or Later V6.1 To run DECpresent Version 1.0A on OpenVMS VAX Version 6.1 or later, you must upgrade the CDA Converter Library from Version 1.1 to Version 2.0. When installing DECpresent Version 1.0A on OpenVMS VAX Version 6.1 or later, system managers can safely ignore the IVP failure for the CDA Converter Library Version 1.1 because that version of the product is bundled with DECpresent, but does not work on OpenVMS VAX Version 6.1 and later. After installing DECpresent Version 1.0A on OpenVMS VAX Version 6.1 or later, or upgrading from VMS Version 5.5- 2 to Version 6.1 or later with DECpresent Version 1.0A already installed on the system, system managers should install CDA Converter Library Version 2.0. 2.11 DECram This section contains a release note about DECram support. 2.11.1 Problems and Restrictions The following note describes a DECram support limitation. 2.11.1.1 DECram Version 2.3 Is Required (Alpha Only) V7.2 OpenVMS Alpha Version 7.2 requires DECram Version 2.3. Do not install earlier versions of DECram on OpenVMS Alpha Version 7.2. Table 2-1 summarizes DECram support on OpenVMS. OpenVMS Layered Products Release Notes 2-9 OpenVMS Layered Products Release Notes 2.11 DECram Table_2-1_DECram_Support_on_OpenVMS________________________ OpenVMS Platform Minimum /Version________________Version________Recommended_Version_ Alpha Version 7.2 Version 2.3 Same Alpha Version 6.2 Version 2.2F Version 2.3 through 7.1-1Hx VAX Version 6.2 Version 2.2C Version 2.2F through_7.2________________________________________________ Furthermore, do not try to upgrade from OpenVMS Alpha Version 6.2 to Version 7.0 or later if you have DECram Version 2.2C or earlier installed. Attempting to do so prevents the system from booting. To avoid this problem, follow these steps: 1. Rename the DECram executable image, using the DCL command RENAME, as shown in the following example: $ RENAME SYS$SPECIFIC:[SYS$LDR]DECRAM$EXECLET.EXE - _$ SYS$SPECIFIC:[SYS$LDR]OLD_DECRAM$EXECLET.EXE 2. Upgrade OpenVMS Alpha. 3. Install DECram Version 2.3. ________________________ Note ________________________ These restrictions do not apply to OpenVMS VAX. However, Compaq recommends using the latest version of DECram, regardless of your operating system version or the architecture (VAX or Alpha). In addition to providing support for OpenVMS Alpha Version 7.2, the latest version also contains bugfixes for both architectures. ______________________________________________________ DECram Version 2.3 and supporting documentation are included in the OpenVMS Version 7.2 kit, on an OpenVMS Version 7.2 CD-ROM, in the following directory: [.DECRAM_023] This version of DECram is not architecture-specific. It can be used on systems running either OpenVMS Alpha or OpenVMS VAX. 2-10 OpenVMS Layered Products Release Notes OpenVMS Layered Products Release Notes 2.11 DECram For more information about the contents of the DECram directory, refer to the Guide to OpenVMS Version 7.2 CD- ROMs. 2.12 DECwindows Motif for OpenVMS This section contains release notes pertaining to the DECwindows Motif for OpenVMS layered product. 2.12.1 Changes and Enhancements This section contains notes about support for the DECwindows Motif for OpenVMS layered product. 2.12.1.1 Version 1.2-5 Ships with Year 2000 Enhancements V7.2 The OpenVMS Version 7.2 installation script asks whether you would like to install DECwindows Motif for OpenVMS Version 1.2-5. This version contains several enhancements, including modifications for the Year 2000. DECwindows Motif for OpenVMS Versions 1.2-3 and 1.2-4 are still supported, but you must apply a kit to obtain the Year 2000 enhancements. (See Section 2.12.1.2 for more information.) 2.12.1.2 Year 2000 Kits for Versions 1.2-3 and 1.2-4 V7.2 A few modifications for the Year 2000, as well as other enhancements for DECwindows Motif, are included in the following kits: ___________________________________________________________ Version__________Platform____Kit_Name______________________ Version 1.2-4 VAX VAXMOTF02_U4012 Alpha ALPMOTF03_U4012 Version 1.2-3 VAX VAXMOTF08_U3012 Alpha ALPMOTF08_U3012 Version 1.2-3 VAX VAXDWMW02_U3012 (worldwide) _________________Alpha_______ALPDWMW02_U3012_______________ OpenVMS Layered Products Release Notes 2-11 OpenVMS Layered Products Release Notes 2.12 DECwindows Motif for OpenVMS These kits are available on the OpenVMS binary CD-ROMs in the DECwindows directories and through the normal service channels, including the Software Patch (ECO) Access web page: http://www.service.digital.com/html/patch_service.html Use the Search and Download Utility to search for keywords VAXMOTF and ALPMOTF. Customers with service contracts can access the Version 1.2-3 kits. All of the Year 2000 enhancements are included in Version 1.2-5, which ships on the OpenVMS Version 7.2 kit (see Section 2.12.1.1). 2.12.1.3 Adobe Display PostScript Support V7.2 As of August 1, 1998, Compaq Computer Corporation no longer supports the Adobe Display PostScript software on the DECwindows Motif for OpenVMS product. (See Section A.1 for details.) 2.12.1.4 Spyglass Enhanced Mosaic Support V7.2 Starting with DECwindows Motif Version 1.2-5 for OpenVMS, which ships with OpenVMS Version 7.2, Compaq Computer Corporation no longer supports Spyglass Enhanced Mosaic on the DECwindows Motif for OpenVMS product. Spyglass Enhanced Mosaic was included with DECwindows Motif Version 1.2-3 and 1.2-4. Compaq suggests that users replace Spyglass Enhanced Mosaic with Netscape Navigator (see Section A.8). 2.12.1.5 Installing Version 1.2-5 on Older OpenVMS Releases V7.2 Before you can install DECwindows for OpenVMS Version 1.2-5 on OpenVMS Version 6.2, 6.2-1H1, 6.2-1H2, 6.2-1H3, 7.1, 7.1-1H1, and 7.1-1H2 systems, you must first install the POLYCENTER Software Installation utility kit that is in the [PCSI] directory on CD-ROM 1 of the OpenVMS Version 7.2 kit. This step is required because DECwindows Motif for OpenVMS Version 1.2-5 uses new POLYCENTER Software Installation utility functionality. This new functionality is integrated into OpenVMS Versions 7.1-2 and 7.2, so you do not need to install the POLYCENTER kit on these 2-12 OpenVMS Layered Products Release Notes OpenVMS Layered Products Release Notes 2.12 DECwindows Motif for OpenVMS systems. When the POLYCENTER kit is installed on older systems, it updates the POLYCENTER Software Installation utility, associated command procedures, help text, and documentation. For more information about installing DECwindows for OpenVMS Version 1.2-5 on older OpenVMS systems, refer to the DECwindows Motif Version 1.2-5 for OpenVMS Installation Guide and the Guide to the DECwindows Motif Version 1.2-5 for OpenVMS CD-ROM. 2.12.1.6 DECwindows Motif Version 1.2 for OpenVMS No Longer Supported V7.1 Starting with OpenVMS Version 7.1, the OpenVMS operating system no longer supports DECwindows Motif Version 1.2 (or earlier) for OpenVMS. To use DECwindows with OpenVMS Version 7.1 or later, you must install DECwindows Motif Version 1.2-3 or later. If you use the English language version of DECwindows Motif, Compaq recommends that you install Version 1.2-5. If you want to install a language variant, see Section 2.12.2.2. DECwindows Motif Version 1.2-3 or later does provide run- time support for programs built on earlier versions of DECwindows and DECwindows Motif. For more information, refer to the DECwindows Motif for OpenVMS Release Notes for Version 1.2-3 or later. For OpenVMS Alpha systems, DECwindows Motif Version 1.2-3 is supported only if you install a remedial kit. Remedial kits are also available for OpenVMS VAX systems. For information about remedial kits for both platforms, see Section 2.12.2.3. 2.12.2 Problems and Restrictions This section describes problems and restrictions associated with the DECwindows Motif for OpenVMS layered product. OpenVMS Layered Products Release Notes 2-13 OpenVMS Layered Products Release Notes 2.12 DECwindows Motif for OpenVMS 2.12.2.1 System Parameter Values Required for Installation V7.2 The installation procedure for DECwindows Motif for OpenVMS Version 1.2-4 and 1.2-5 can fail if the values for the GBLPAGES, FREE_GBLPAGES, and CLISYMTBL system parameters are set too low. The installation fails with the following error: %SYSTEM-W-NOSUCHFILE, no such file \sys$library:decw$xlibshr.exe\ If the installation fails, set these parameters to the minimum values shown in the following table; then reinstall the product. ___________________________________________________________ _________GBLPAGES___FREE_GBLPAGES__CLISYMTBL_______________ Alpha 150000 92000 512 VAX______62000______47000__________265_____________________ 2.12.2.2 Language Variants Not Available in Some Versions V7.2 No language variants are yet available for DECwindows Motif Version 1.2-5. Only Japanese and Hebrew variants are currently available for DECwindows Motif Version 1.2- 4. Consult your Compaq support representative for more information. 2.12.2.3 Remedial Kits for DECwindows Motif Version 1.2-3 V7.1 Starting with OpenVMS Alpha Version 7.1, DECwindows Motif Version 1.2-3 is supported only if you install the appropriate remedial kit. OpenVMS VAX Version 7.1 or later supports DECwindows Motif Version 1.2-3, but it also has problems unless a remedial kit is installed. 2-14 OpenVMS Layered Products Release Notes OpenVMS Layered Products Release Notes 2.12 DECwindows Motif for OpenVMS Why You Should Install the Remedial Kit If you run DECwindows Motif Version 1.2-3 on an OpenVMS Version 7.1 or later system and do not install one of the remedial kits described later in this note, OpenVMS Alpha users will experience all of the following problems, and VAX users will experience all but the first three of these problems: o The DECwindows login program fails with an ACCVIO status, preventing users from logging in to DECwindows. o The DECwindows interface to DEC Notes fails to open remote notes conferences and displays the following error message: LinkWorks Reported Error: Unknown error o The following error message is displayed on nonworkstation systems during system startup: %SDA-E-NOTINPHYS, 00000024 : virtual data not in physical memory o Console broadcasts are disabled by default on nonworkstation systems (see Section 2.12.2.4). o DECwindows system files are purged during startup (see Section 2.12.2.5). o The locale support in Xlib is not compatible with the support in the DEC C Run-Time Library. The remedial kit you install depends on whether you are running the U.S. version of DECwindows Motif Version 1.2-3 or the worldwide version. Remedial Kit for U.S. Version If you want to use any of the following language variants, you must install the U.S. version of DECwindows Motif: French German Hebrew Italian Spanish Swedish OpenVMS Layered Products Release Notes 2-15 OpenVMS Layered Products Release Notes 2.12 DECwindows Motif for OpenVMS If you use the U.S. version of DECwindows Motif Version 1.2-3, install the following remedial kits: o For VAX systems: VAXMOTF08_U3012 o For Alpha systems: ALPMOTF08_U3012 These kits also include enhancements to make DECwindows Motif Version 1.2-3 ready for the Year 2000. These kits ship on the OpenVMS Version 7.2 operating system CD-ROM and are also available from your Compaq support representative. Remedial Kit for Worldwide Version The following language variants include the worldwide version of DECwindows Motif: Czech Hangul Hanyu Hanzi Hungarian Japanese Polish Russian Slovak Thai If you use the worldwide version of DECwindows Motif Version 1.2-3, install the following remedial kits: o For VAX systems: VAXDWMW02_U3012 o For Alpha systems: ALPDWMW02_U3012 These kits also include enhancements to make the worldwide version of DECwindows Motif Version 1.2-3 ready for the Year 2000. These kits ship on the OpenVMS Version 7.2 operating system CD-ROM and are also available from your Compaq support representative. 2.12.2.4 Console Broadcasts Disabled V7.1 In the U.S. version of DECwindows Motif Version 1.2- 3, console broadcasts are disabled by default by the DECwindows startup procedure on nonworkstation systems as well as on workstation systems. 2-16 OpenVMS Layered Products Release Notes OpenVMS Layered Products Release Notes 2.12 DECwindows Motif for OpenVMS To allow broadcasts to OPA0: in the U.S. version of DECwindows Motif Version 1.2-3, edit the file SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM (creating it if it does not exist) and add the following global symbol definition: $ DECW$CONSOLE_SELECTION == "ENABLE" Then, restart DECwindows by entering the following command: $ @SYS$MANAGER:DECW$STARTUP RESTART On workstation systems, Compaq recommends that you set DECW$CONSOLE_SELECTION to WINDOW instead of ENABLE. This setting directs console output to a Console Window application (which is new in DECwindows Motif Version 1.2-3) instead of to the operator window on the graphics screen. ________________________ Note ________________________ If your workstation uses a Qvision graphics board, you must set DECW$CONSOLE_SELECTION to WINDOW. (See Section 1.12.1.1 for another release note pertaining to Qvision graphics boards.) ______________________________________________________ If you prefer that console broadcasts not be disabled by default on nonworkstation systems, install the following remedial kits, which ship on the OpenVMS operating system CD-ROM and are also available from your Compaq support representative: o For VAX systems: VAXMOTF07_U3012 o For Alpha systems: ALPMOTF07_U3012 Note that console broadcasts will still be disabled by default on workstations. OpenVMS Layered Products Release Notes 2-17 OpenVMS Layered Products Release Notes 2.12 DECwindows Motif for OpenVMS 2.12.2.5 System Files Purged During Startup V7.1 In the U.S. version of DECwindows Motif Version 1.2-3, the following DECwindows files are purged each time DECwindows Motif starts: SYS$LIBRARY:DECW$*.EXE SYS$SYSTEM:DECW$SETSHODIS.EXE This problem is corrected in Version 1.2-4. If you are running the U.S. version of DECwindows Motif Version 1.2-3, you can correct this problem by installing the following remedial kits, which ship on the OpenVMS operating system CD-ROM and are also available from your Compaq support representative: o For VAX systems: VAXMOTF08_U3012 o For Alpha systems: ALPMOTF08_U3012 2.12.3 Documentation Changes and Corrections The following note corrects a file specification in the Getting Started With the New Desktop manual. 2.12.3.1 Getting Started With the New Desktop (Alpha Only) DECwindows Motif V1.2-4 A file specification for a command procedure in Getting Started With the New Desktop (part number AA-QUW1A-TE) is incorrect. The file specification appears in Section 3.4.9, paragraph 5, as follows: "Optional DECwindows applications, such as DECwindows Notes, may not provide any information and therefore are not restarted. For such cases, there is a command procedure called disk$:[user.DT]SESSIONETC.COM that you can use to start any applications that cannot be restarted automatically. This procedure is analogous to the DECW$LOGIN.COM procedure in the traditional DECwindows environment." The correct file specification is: disk$:[user.DT.SESSIONS]SESSIONETC.COM 2-18 OpenVMS Layered Products Release Notes OpenVMS Layered Products Release Notes 2.13 Digital Distributed Computing Environment (DCE) for OpenVMS 2.13 Digital Distributed Computing Environment (DCE) for OpenVMS This section contains important release notes for existing users of Digital Distributed Computing Environment (DCE) for OpenVMS VAX and OpenVMS Alpha. Beginning with OpenVMS Version 7.2, Remote Procedure Call (RPC) functionality is integrated into the operating system. For more information about RPC functionality, refer to the OpenVMS Version 7.2 New Features Manual. _______________________ Warning _______________________ Do not install Digital DCE for OpenVMS Version 1.4 with OpenVMS Version 7.2. Doing so will overwrite the new RPC files with those from Version 1.4. This problem does not occur with Digital DCE for OpenVMS Version 1.5. (See Section 2.13.2.1 for a related note.) ______________________________________________________ For more information about Digital DCE for OpenVMS, refer to the following documentation: o Digital DCE for OpenVMS VAX and OpenVMS Alpha Installation and Configuration Guide (Order number AA-Q70GB-RE) o Digital DCE for OpenVMS VAX and OpenVMS Alpha Product Guide (Order number AA-Q70FC-RE) o Digital DCE for OpenVMS VAX and OpenVMS Alpha Reference Guide (Order number AA-Q70JC-RE) 2.13.1 Changes and Enhancements The following section describes changes to DCE. 2.13.1.1 DCE System Management Command Procedure V7.2 With the integration of the RPC daemon in OpenVMS Version 7.2, the following enhancements have been made to the DCE system management command procedure (DCE$SETUP.COM): o RPC can be started with the new startup command procedure, DCE$RPC_STARTUP.COM. For information about OpenVMS Layered Products Release Notes 2-19 OpenVMS Layered Products Release Notes 2.13 Digital Distributed Computing Environment (DCE) for OpenVMS how to start the RPC daemon, see the OpenVMS Version 7.2 New Features Manual. o DCE$SETUP no longer directly starts the RPC daemon. It now calls DCE$RPC_STARTUP. o DCE$SETUP no longer performs UCX parameter checking. This is performed by DCE$RPC_STARTUP. o DCE$SETUP no longer stops the RPC daemon under any circumstances. The RPC daemon can be stopped only by calling DCE$RPC_SHUTDOWN. o DCE$RPC_SHUTDOWN checks to see if any DCE components are running before it stops the RPC daemon. o DCE components can be started, stopped, or configured without shutting down the RPC daemon. o Invoking DCE$SETUP with the CLEAN or CLOBBER option no longer deletes the RPC endpoint database (DCE$LOCAL:[VAR.RPC]RPCDEP.DAT). However, the endpoints for any DCE components will be removed. The only way to delete the entire RPC endpoint database is to invoke the DCE$RPC_SHUTDOWN procedure with the CLEAN option. o Small modifications to some informational messages have been made to remind the user of the above changes. 2.13.2 Problems and Restrictions The following section describes a restriction associated with DCE for OpenVMS Version 1.5. 2.13.2.1 Authenticated RPC Functionality Not Available V7.2 The new authenticated RPC functionality in DCE for OpenVMS Version 1.5, including impersonation and authentication with NT Lan Manager (NTLM) protocol, is not included in OpenVMS Version 7.2. You can install DCE for OpenVMS Version 1.5 and use the existing functionality, but all new functionality related to using NTLM and impersonation is not available. 2-20 OpenVMS Layered Products Release Notes OpenVMS Layered Products Release Notes 2.13 Digital Distributed Computing Environment (DCE) for OpenVMS Compaq intends to provide support for the new DCE for OpenVMS features after OpenVMS Version 7.2. Customers will be notified how to obtain the software when support is available. The Digital DCE for OpenVMS VAX and OpenVMS Alpha documentation that ships with OpenVMS Version 7.2 provides information on NTLM as a preview of functionality that will be available in a future version of Digital DCE for OpenVMS Alpha. This advanced documentation will help you plan for the future. 2.14 DIGITAL TCP/IP Services for OpenVMS This section contains release notes pertaining to DIGITAL TCP/IP Services for OpenVMS. 2.14.1 Changes and Enhancements The following note describes changes introduced with Version 5.0 of DIGITAL TCP/IP Services for OpenVMS. 2.14.1.1 Changes in Version 5.0 V7.2 Starting with OpenVMS Version 7.2, DIGITAL TCP/IP Services for OpenVMS Version 5.0 replaces Version 4.2 (also known as UCX). Version 5.0 completes the change initiated several releases ago when the product name changed from ULTRIX Connection (UCX) to DIGITAL TCP/IP Services for OpenVMS. The identifier UCX is replaced with TCPIP in the following items: o Registered product facility code o Management command prompt o All messages, examples, and banners o All product file names and databases o All logical names o All associated product documentation This release provides backward compatibility for all UCX logical names and support for UCX commands. OpenVMS Layered Products Release Notes 2-21 OpenVMS Layered Products Release Notes 2.14 DIGITAL TCP/IP Services for OpenVMS At this time, customers do not need to upgrade their applications or command procedures that rely on UCX names. UCX$DEVICE will continue to work as always. However, Compaq encourages customers to use the new naming convention as soon as possible. Support for the old naming is not guaranteed in subsequent releases. ________________________ Note ________________________ Undocumented logical names or file names are not guaranteed to be supported in future releases (as is the case of any undocumented features). ______________________________________________________ No changes to the LMF (License Management Facility) Product Authorization Keys are required. Changes in this release include the following: o Support for external authorization o File Transfer Protocol (FTP) enhancements, including support for Extended File Specifications o Enhanced socket-based application programming interface o Time zone configuration changes o NFS and SMTP changes o Obsolescence of some management commands Additional new features are outlined in the OpenVMS Version 7.2 New Features Manual and details are provided in the release notes that ship with the DIGITAL TCP/IP Services for OpenVMS Version 5.0 kit. For information about installing DIGITAL TCP/IP Services for OpenVMS, refer to the manual DIGITAL TCP/IP Services for OpenVMS Installation and Configuration. 2.15 PATHWORKS for OpenVMS This section contains release notes pertaining to PATHWORKS for OpenVMS. 2-22 OpenVMS Layered Products Release Notes OpenVMS Layered Products Release Notes 2.15 PATHWORKS for OpenVMS 2.15.1 Changes and Enhancements The following release note summarizes a change in support for PATHWORKS for OpenVMS products. 2.15.1.1 PATHWORKS Advanced Server V6.0/6.0A Replacement V7.2 PATHWORKS for OpenVMS (Advanced Server) Version 6.0 and Version 6.0A are not supported on OpenVMS Version 7.2. You can run either PATHWORKS V6.0B for OpenVMS (Advanced Server) or the Advanced Server V7.2 for OpenVMS. Both are supported on OpenVMS Version 7.2 systems. PATHWORKS V6.0B for OpenVMS (Advanced Server) runs on either OpenVMS Alpha Version 7.2 or OpenVMS VAX Version 7.2 systems. You will want to run PATHWORKS V6.0B if you want to provide file and print services from an OpenVMS VAX Version 7.2 system, either in a cluster or standalone. Advanced Server V7.2 for OpenVMS (see Section 2.2) runs only on OpenVMS Alpha Version 7.2 systems. You can run Advanced Server V7.2 for OpenVMS in a mixed-architecture cluster, using an external authentication VAX module included in the kit. 2.15.1.2 PATHWORKS V5 for OpenVMS (LAN Manager) Not Supported V7.2 PATHWORKS V5 for OpenVMS (LAN Manager) is not supported on OpenVMS Version 7.2. If you are running PATHWORKS V5 for OpenVMS (LAN Manager) and want to offer file and print services after you install OpenVMS Version 7.2, you must upgrade the file and print server to PATHWORKS V6.0B for OpenVMS (Advanced Server) before you install OpenVMS Version 7.2. For information about upgrading from PATHWORKS V5 for OpenVMS (LAN Manager) to PATHWORKS V6 for OpenVMS (Advanced Server), refer to the PATHWORKS for OpenVMS (Advanced Server) Server Migration Guide provided with the kit documentation. You cannot upgrade directly from PATHWORKS V5 for OpenVMS (LAN Manager) to the Advanced Server V7.2 for OpenVMS. OpenVMS Layered Products Release Notes 2-23 OpenVMS Layered Products Release Notes 2.16 POSIX for OpenVMS 2.16 POSIX for OpenVMS This section contains release notes about POSIX for OpenVMS. 2.16.1 Problems and Restrictions The following note describes a support restriction for POSIX for OpenVMS. 2.16.1.1 POSIX for OpenVMS Is Not Supported V7.2 POSIX for OpenVMS is not supported on OpenVMS Version 7.2. The POSIX for OpenVMS product has been retired. For more information, see Section A.6. _______________________ Caution _______________________ Do not try to start up POSIX for OpenVMS on an OpenVMS Version 7.2 system. Your system will crash. ______________________________________________________ 2.17 Process MultiNet for OpenVMS This section contains a release note pertaining to the Process MultiNet for OpenVMS product. 2.17.1 Changes and Enhancements The following note describes a version update requirement. 2.17.1.1 Update Required for OpenVMS Alpha Version 7.2 V7.2 If you want to use Process MultiNet for OpenVMS on OpenVMS Alpha Version 7.2, you must either upgrade to MultiNet Version 4.1B or install the Version 4.1A patch KERNEL- UPDATE-30_A041, which is accessible using anonymous FTP from the following location: ftp://ftp.multinet.process.com/patches/multinet041/kernel-update-30_a041.zip 2-24 OpenVMS Layered Products Release Notes OpenVMS Layered Products Release Notes 2.17 Process MultiNet for OpenVMS MultiNet and TCPware customers should contact Process Software for ECO kits that should be applied to systems running OpenVMS Alpha Version 7.2. Contact information is as follows: o Telephone: 1-800-394-8700 o E-mail: support@process.com o World Wide Web: http://www.process.com 2.18 Wind/U Products for OpenVMS V7.1 Bristol Technology's Wind/U products are used by independent software vendors (ISVs) and developers to create Windows based applications that can be deployed across multiple computing environments. Bristol Technology's Wind/U Run-Time Library for OpenVMS is distributed with the OpenVMS Version 7.2 kit. However, you must directly contact Bristol Technology for the Wind/U Developer's Kit as well as for licenses and support for both the Run-Time Library and the Developer's Kit. To obtain your product authorization key (PAK) to access Wind/U for OpenVMS, contact Bristol Technology as follows: Bristol Technology Inc. 241 Ethan Allen Highway, Ridgefield, CT 06877 USA (203) 438-6969 email: info@bristol.com For more information about Wind/U for OpenVMS, access the Bristol Technology web site: http://www.bristol.com. OpenVMS Layered Products Release Notes 2-25 3 _________________________________________________________________ General User Release Notes This chapter provides information for all users of the OpenVMS operating system. It includes information about commonly used commands and utilities. For information about new features included in this version of the software, refer to the OpenVMS Version 7.2 New Features Manual. 3.1 COM for OpenVMS (Alpha Only) This section contains a note of interest to COM for OpenVMS field test customers. 3.1.1 Problems and Restrictions The following note reports an incompatibility between COM for OpenVMS field test versions and OpenVMS Version 7.2. 3.1.1.1 Field Test Versions Incompatible with OpenVMS Version 7.2 V7.2 An incompatibility between field test versions of COM for OpenVMS and OpenVMS Version 7.2 prevents the COM for OpenVMS run time from starting. If you are running a COM for OpenVMS field test version (G1.0, H1.0, or I1.0) and you upgrade to OpenVMS Version 7.2, you must install COM Version 1.0 for OpenVMS before you can start COM or run any COM applications. For more information about installing and configuring COM for OpenVMS, see the OpenVMS Connectivity Developer's Guide, which is available from the OpenVMS website at the following location: http://www.openvms.digital.com/openvms/products/dcom/ General User Release Notes 3-1 General User Release Notes 3.2 DCL Commands 3.2 DCL Commands This section contains release notes related to the DIGITAL Command Language (DCL) for this release of the OpenVMS operating system. 3.2.1 Changes and Enhancements See Section 4.18.1.2 for a change in output displayed by the DIRECTORY/SECURITY and DIRECTORY/FULL commands. 3.2.2 Problems and Restrictions The note in this section describes a restriction pertaining to DCL commands. 3.2.2.1 SET PROCESS/NOAUTO_UNSHELVE Command in Cluster Environment V6.1 The DCL command SET PROCESS/NOAUTO_UNSHELVE does not support operations across the cluster. It can be issued only for a process on the same node, including as the default case, the process from which the command is issued. The /IDENTIFICATION=pid qualifier is supported, but only when the target process is on the same node as the process where the command is issued. 3.3 DECTPU This section contains release notes pertaining to the DEC Text Processing Utility (DECTPU). 3.3.1 Problems and Restrictions The note in this section describes a DECTPU problem. 3.3.1.1 Motif Widget Context Help Built-In V1.0 The following built-in, which should enter Motif context- sensitive help mode, is disabled because of a problem in the Motif toolkit: SET (WIDGET_CONTEXT_HELP, widget_variable, {on|1|off|0}) 3-2 General User Release Notes General User Release Notes 3.3 DECTPU The mouse pointer changes to a question mark, and DECTPU waits for you to select a widget by clicking MB1. DECTPU then executes the help callback of the selected widget (or of its parent if the selected widget has no help callback). The widget_variable is the widget within which the modal help interaction occurs, usually the top-level widget returned from the GET_INFO (SCREEN, "widget") built-in. The last parameter confines the question mark pointer to the specified widget if ON or 1, and does not confine the pointer if OFF or 0. 3.3.2 Documentation Changes and Corrections This section contains a correction to the DECTPU documentation. 3.3.2.1 DEC Text Processing Utility Reference Manual V7.2 For the CALL_USER procedure, the Example section does not distinguish between VAX and Alpha platforms for the link option. Under Step 3, "Create an option file...," the example contains only the VAX link option, UNIVERSAL=TPU$CALLUSER. For the Alpha platform, the correct link option is SYMBOL_VECTOR=(TPU$CALLUSER=PROCEDURE). 3.4 High-Performance Sort/Merge Utility (Alpha Only) This section contains release notes pertaining to the command line interface and the callable interface (SOR routines) of the OpenVMS Alpha high-performance Sort/Merge utility. This information is of interest to both general users and programmers. For more information about using the OpenVMS Alpha high- performance Sort/Merge utility, refer to the OpenVMS User's Manual and the OpenVMS Utility Routines Manual. 3.4.1 Problems and Restrictions This section describes problems associated with using the command line interface and the SOR routines of the high- performance Sort/Merge utility. General User Release Notes 3-3 General User Release Notes 3.4 High-Performance Sort/Merge Utility (Alpha Only) 3.4.1.1 Concurrent Sort Operations V7.0 Memory allocation differences may limit the high- performance Sort/Merge utility's ability to perform the same number of concurrent sort operations as the Sort/Merge utility can perform in the same amount of virtual memory. If this situation occurs, you can either increase the amount of virtual memory that is available to the process, or reduce the working set extent. 3.4.2 Corrections This section describes problems that have been fixed in the command line interface and in the SOR routines of the high-performance Sort/Merge utility. 3.4.2.1 Error Messages Problem Fixed V7.2 In previous versions of OpenVMS, error messages generated by the high-performance Sort/Merge utility did not include secondary error messages from RMS or other facilities. This problem has been corrected in OpenVMS Version 7.2. 3.4.2.2 Merging Stream Files Limitation Fixed V7.2 In previous versions of OpenVMS, when the high-performance Sort/Merge utility was used to merge stream files, the end- of-file was not written correctly for the output stream file. This problem has been corrected in OpenVMS Version 7.2. 3-4 General User Release Notes 4 _________________________________________________________________ System Management Release Notes This chapter contains information that applies to system maintenance and management, performance management, and networking. For information about new features included in this version of the software, refer to the OpenVMS Version 7.2 New Features Manual. 4.1 Alpha System Dump Analyzer (SDA) This section contains release notes pertaining to the Alpha System Dump Analyzer (SDA). 4.1.1 Changes and Enhancements The following note describes a change that is visible from the SDA utility. 4.1.1.1 Number of Nonpaged Pool Lookaside Lists Increased V7.2 In Version 7.2, 48 more nonpaged pool lookaside lists have been added to now accommodate a maximum packet size of 8192 bytes. The number of packets on each list can be viewed by entering the CLUE MEMORY /LOOKASIDE command from the SDA utility. 4.2 Backup Utility Release notes in this section pertain to the Backup utility (BACKUP). 4.2.1 Changes and Enhancements The note in this section provides a performance tip. System Management Release Notes 4-1 System Management Release Notes 4.2 Backup Utility 4.2.1.1 Writing a Save Set to a Files-11 Mounted Disk V7.2 Beginning with OpenVMS Version 7.2, performance is improved when you write a save set to a Files-11 mounted disk with high-water marking. This performance improvement is the result of avoiding high-water marking erase IOs when the save set is written to the disk. 4.2.2 Problems and Restrictions This section describes known problems and restrictions for the Backup utility. 4.2.2.1 /MEDIA_FORMAT=COMPACTION Qualifier Ineffective on TA90 Devices V7.2 The introduction of multiple tape density in OpenVMS Version 7.2 causes TA90 tape drives not to be properly placed in compaction mode when the standard DCL qualifier /MEDIA_FORMAT=COMPACTION is used in INITIALIZE, BACKUP, or MOUNT commands. The command and qualifier are accepted at the DCL level, but the device does not change modes. To work around this problem, use the new qualifier /MEDIA_FORMAT=(DENSITY=3480,COMPACTION) to correctly place the device in compaction mode. 4.2.2.2 /OWNER and /BY_OWNER Qualifiers Require Numerical Identifiers V7.2 Commands like the ones in the following sequence produce an error and error messages in BACKUP: $ CREATE X.X $ BACKUP X.X X.SAV/SAVE $ BACKUP X.SAV/SAVE *.*/OWNER=SYS$NODE_'F$GETSYI("NODENAME") %BACKUP-F-BADOPTVAL, invalid callable interface option value, argument position 7, option type = 59, option value = 2147549196 The qualifier /BY_OWNER can also result in an error and a message similar to the one in the preceding example. 4-2 System Management Release Notes System Management Release Notes 4.2 Backup Utility With both qualifiers, the error occurs when you enter a general identifier rather than a numerical one; for example, BACKUP accepts a command like the following one: $ BACKUP [.EXE]S.SAV/SAV *.*/OWNER=[100,100]/LOG %BACKUP-S-CREATED, created $4$DUA155:[BTE.VMSTEST.BACKUP_REG]X.X;2 %BACKUP-S-CREATED, created $4$DUA155:[BTE.VMSTEST.BACKUP_REG]X.X;1 $ You can work around this problem by entering a numerical identifier. 4.3 Compaq Galaxy Software Architecture on OpenVMS Alpha V7.2 OpenVMS Alpha Version 7.2 introduces the Galaxy Software Architecture on OpenVMS Alpha. By running multiple instances of OpenVMS in a single computer, an OpenVMS Galaxy computing environment provides extremely flexible operational computing capabilities. This computing environment can be dynamically adapted to changing application needs and workload demands. The Compaq Galaxy Software Architecture on OpenVMS Alpha is available as a separately licensed System Integrated Product (SIP). For more information about how to transform an AlphaServer 8400, 8200, or 4100 system into an initial OpenVMS Galaxy computing environment and how to use the OpenVMS Galaxy capabilities available in OpenVMS Version 7.2, refer to the OpenVMS Alpha Galaxy Guide. This manual also contains any release notes about the Galaxy Software Architecture on OpenVMS. 4.4 DECamds This section contains release notes pertaining to DECamds. 4.4.1 Changes and Enhancements The following sections describe important changes to DECamds beginning with OpenVMS Version 7.2. System Management Release Notes 4-3 System Management Release Notes 4.4 DECamds 4.4.1.1 Installation Procedure Change V7.2 DECamds consists of client and server software: o The client software provides the graphical user interface to display DECamds information to users. o The server software, the DECamds Data Collector (RMDRIVER), collects the data that DECamds analyzes and displays. In earlier versions of OpenVMS, you needed to install both client and server software on your system from the lastest DECamds kit. Server Software: No Installation Required Beginning with OpenVMS Version 7.2, the Data Collector ships as part of the OpenVMS installation. In other words, after you install or upgrade to OpenVMS Version 7.2, the Data Collector is on your system. To use the Data Collector, do either of the following: - Run the command procedure @SYS$STARTUP:AMDS$STARTUP START at the DCL $ prompt. - Add the @SYS$STARTUP:AMDS$STARTUP START command to the SYSTARTUP_VMS.COM command file in the SYS$MANAGER directory. Client Software: Installation Required In OpenVMS Version 7.2, you still need to reinstall the DECamds client software on the system where you run the client, or graphical user interface. You need to do this to obtain the new library for DECamds Version 7.2. Making RMDRIVER part of OpenVMS requires moving the following files: ___________________________________________________________ File_______________________New_Directory_Location__________ AMDS$DRIVER_ACCESS.DAT SYS$MANAGER AMDS$RMCP.EXE SYS$SYSTEM AMDS$LOGICALS.COM__________SYS$MANAGER_____________________ 4-4 System Management Release Notes System Management Release Notes 4.4 DECamds These new directory locations should not affect previous copies of AMDS$DRIVER_ACCESS.DAT that are in the AMDS$SYSTEM directory because the AMDS$SYSTEM logical is now a search list for SYS$COMMON:[AMDS] and SYS$COMMON:[SYSMGR]. Copies of the files listed above from previous versions of DECamds will still be valid; however, new copies of the files will be placed in the new locations. 4.4.1.2 Event Log File and Lock Log File Enhanced V7.2 Prior to Version 7.2, the Event Log File and Lock Log File were created with a default creation size of 1 block and a default extension size of 1 block. This sometimes resulted in a very fragmented log file (and disk) when DECamds was allowed to run for a long period of time. Two new logicals in the AMDS$LOGICALS.COM file allow users to define additional sizes in log files; these logicals and their default values are shown in the following table: ___________________________________________________________ Logical_______________Description___________Default_Value__ AMDS$EVTLOG_ALLOC_ Sets the initial 100 blocks SIZE size of the log files AMDS$EVTLOG_EXTNT_ Sets the extension 0 blocks SIZE size of a file when ______________________it_needs_to_grow_____________________ The default value for AMDS$EVTLOG_EXTNT_SIZE causes DECamds to use the system defaults for extent size. 4.4.1.3 Handling of Unknown Adapter Types Improved V7.2 Prior to Version 7.2, DECamds labeled an adapter that reported an unknown RPORT value "UNKNOWN", but provided no other information in the SCA Summary Window. Beginning with Version 7.2, DECamds displays the value that a remote system returns for RPORT as well as the "UNKNOWN" label. System Management Release Notes 4-5 System Management Release Notes 4.4 DECamds 4.4.1.4 Similar Groups Sorted Correctly V7.2 Prior to Version 7.2, if the first three characters of group names were similar, DECamds sometimes did not sort them correctly. In OpenVMS Version 7.2, the sorting algorithm has been corrected, and DECamds now sorts group names correctly. 4.4.2 Problems and Restrictions The following section describes DECamds restrictions. 4.4.2.1 Kernel Threads Not Supported (Alpha Only) V7.2 DECamds support for kernel threads has not been implemented on OpenVMS Alpha systems. If you use threaded processes, DECamds displays only the top thread. 4.5 DECdtm Services This section contains release notes pertaining to DECdtm services. 4.5.1 Problems and Restrictions This section describes known problems and restrictions associated with using DECdtm services. 4.5.1.1 Kernel Threads Restriction (Alpha Only) V7.1 On OpenVMS Alpha systems, unpredictable results can occur if DECdtm services are used in a multithreaded environment. Do not make calls to DECdtm services in kernel threads other than the initial thread because much of the work performed by DECdtm uses the context of the calling process. 4.6 DECevent Fault Management Support This section contains a release note about the changes included in the latest version of DECevent. For information about installing DECevent, see Section 1.2.1.4. 4-6 System Management Release Notes System Management Release Notes 4.6 DECevent Fault Management Support 4.6.1 Changes and Enhancements The following release note explains the requirement to use DECevent Version 2.9 with OpenVMS Version 7.2. 4.6.1.1 DECevent Version 2.9 or Later Required to Analyze Errors V7.2 Starting with OpenVMS Version 7.1-2, DECevent Version 2.9 or later is required to analyze error log files. The binary error log file format has changed and older versions of DECevent will not work. Additionally, there have been changes made for some device-specific error log entries. DECevent Version 2.9 provides a separate utility, the Binary Error Log Translation utility, in the DECevent kit. The Binary Error Log Translation utility is used to convert the new Common Event Header (CEH) binary error log file into a binary error log file whose header format and structure can be read by earlier versions of DECevent and by the Error Reporting Formatter (ERF), an older utility. For more information about the Binary Error Log Translation utility, refer to its documentation, which is included in the DECevent kit. Note that the DCL command ANALYZE/ERROR_LOG, which invokes ERF, does not support MEMORY CHANNEL and other new devices. Using that command will result in improperly formatted error log entries. Install the DECevent kit supplied on the OpenVMS CD-ROM. Then use the following commands to invoke DECevent to analyze dump files: o DIAGNOSE Analyzes the current system error log file o DIAGNOSE file-name Analyzes the error log file named file-name.SYS For information about the DIAGNOSE command, use the HELP DIAGNOSE command; for additional information, refer to the OpenVMS DCL Dictionary. For more information about DECevent, refer to the OpenVMS System Manager's Manual, the System Management Release Notes 4-7 System Management Release Notes 4.6 DECevent Fault Management Support OpenVMS System Management Utilities Reference Manual, and the DECevent documentation included in the DECevent kit. 4.7 Extended File Specifications This section contains a release note pertaining to Extended File Specifications. For more information about Extended File Specifications, see the OpenVMS Guide to Extended File Specifications. 4.7.1 Problems and Restrictions The following note describes a restriction to extended file names. 4.7.1.1 Mixed UNIX Style and VMS Style File Names Not Supported (Alpha Only) V7.2 The ODS-5 volume structure, introduced in OpenVMS Alpha Version 7.2, supports long file names, allows the use of a wider range of characters within file names, and preserves case within file names. However, the DEC C RTL shipped with OpenVMS Alpha Version 7.2 does not provide full support for extended file names on ODS-5 devices. This lack of full support imposes certain restrictions on users running Netscape FastTrack Server or using Java applications on ODS-5 devices. In general, users running Netscape FastTrack or using Java applications on OpenVMS can enter either UNIX style file names or VMS style file names. (FastTrack usually outputs UNIX style file names.) With both products, file names are often created by FastTrack or by the Java Virtual Machine. Because mixed UNIX style and VMS style extended file names are not yet supported by the DEC C RTL, you may be required to use UNIX style syntax when interacting with Java applications or FastTrack, for example, to modify a root to which you append additional directories or a file name. The following example shows samples of mixed UNIX style and VMS style file names that are not supported in OpenVMS Alpha Version 7.2: 4-8 System Management Release Notes System Management Release Notes 4.7 Extended File Specifications doc/foo.bar.bar ./tmp/foo.bar.b^_ar ~foo^.bar You can, however, modify the last example so that it works as an OpenVMS extended file name that has a tilde (~) as the first character. Precede the leading tilde (~) with the Extended File Specifications escape character (^). For example: ^~foo^.bar See the OpenVMS Guide to Extended File Specifications for more information about using the tilde (~) in OpenVMS extended file names. Mixed UNIX style and VMS style file names will be supported in a future release of the DEC C RTL for OpenVMS Alpha Version 7.2. 4.8 External Authentication This section contains release notes pertaining to external authentication. External authentication is an optional feature introduced in OpenVMS Version 7.1 that enables OpenVMS systems to authenticate designated users using their external user IDs and passwords. Starting with OpenVMS Version 7.2, if you are running DECwindows and you want a DECwindows user to be externally authenticated, you must be running DECwindows Version 1.2-4 or later and meet any requirements outlined in the Advanced Server for OpenVMS Server Installation and Configuration Guide. See this manual and the OpenVMS Guide to System Security for detailed information about using external authentication. 4.8.1 Changes and Enhancements The following note describes a change related to external authentication support. 4.8.1.1 FTP Server Uses External Authentication V7.2 With the release of DIGITAL TCP/IP Services for OpenVMS Version 5.0, the File Transfer Protocol (FTP) server uses external authentication to authenticate connections on the OpenVMS system. System Management Release Notes 4-9 System Management Release Notes 4.8 External Authentication 4.8.1.2 DCL Command Interface to Control External Authentication V7.2 Chapter 7 of the OpenVMS Guide to System Security describes the SYS$SINGLE_SIGNON and SYS$ACME_MODULE logical names currently used for external authentication. Note that in a future release, the current interface for enabling and controlling external authentication will be replaced by a DCL command interface. 4.8.2 Problems and Restrictions The following notes describe problems or restrictions related to external authentication. 4.8.2.1 Failed Connection Attempts on POP Server V7.2 The Post Office Protocol (POP) server does not use external authentication to authenticate connection attempts on the OpenVMS system. This causes connection attempts to fail if either of the following conditions exist: o The external user ID is different from the OpenVMS user name. o The OpenVMS password is not synchronized with the external user password. 4.8.2.2 SET PASSWORD Behavior Within a DECterm Terminal Session V7.2 A DECterm terminal session does not have access to the external user name used for login and must prompt for one during SET PASSWORD operations. The external user name defaults to the process's OpenVMS user name. If the default is not appropriate (that is, if the external user name and mapped OpenVMS user name are different), you must enter the correct external user name. The following example shows a SET PASSWORD operation initiated by a user with the external user name JOHN_ DOE. The mapped OpenVMS user name is JOHNDOE and is the default used by the SET PASSWORD operation. In this case, the default is incorrect and the actual external user name was specified by the user. 4-10 System Management Release Notes System Management Release Notes 4.8 External Authentication $ set password External user name not known; Specify one (Y/N)[Y]? Y External user name [JOHNDOE]: JOHN_DOE Old password: New password: Verification: %SET-I-SNDEXTAUTH, Sending password request to external authenticator %SET-I-TRYPWDSYNCH, Attempting password synchronization $ 4.8.2.3 DECnet Phase IV Requirement V7.2 Users with the EXTAUTH bit set in their SYSUAF account record cannot use explicit access control strings with systems running DECnet Phase IV unless their externally authenticated password is all uppercase characters. For example, if you enter the following command: $ DIRECTORY nodename"username password":: where "nodename" is running DECnet Phase IV and "username" is an EXTAUTH account, DECnet will uppercase the string "password" before it is passed to the external authentication agent (a PATHWORKS or NT domain controller). This does not happen if the node is running DECnet Phase V on OpenVMS Version 7.2 and if the system has the system parameter NET_CALLOUTS set to 255. (See Section 4.8.2.8.) There are two workarounds: o If you are using DECnet Phase IV and you want to use explicit access control strings, define an uppercase NT password. o Set up a proxy account on your DECnet Phase IV nodes so that you do not have to use explicit access control strings to perform functions. System Management Release Notes 4-11 System Management Release Notes 4.8 External Authentication 4.8.2.4 Impact on Layered Products and Applications V7.1 Certain layered products and applications that use an authentication mechanism based on the traditional SYSUAF- based user name and password (for example, software that calls $HASH_PASSWORD or $GETUAI/$SETUAI to alter, fetch, or verify OpenVMS passwords) will encounter problems in either of the following cases: o When external authentication is used in an environment where a given user's external user ID and OpenVMS user name are different o Where the user's SYSUAF password is different from the external user password In such cases, the problem symptom is a user authentication failure from the layered product or application. For externally authenticated users, the normal system authorization database (SYSUAF.DAT) is used to construct the OpenVMS process profile (UIC, privileges, quotas, and so on) and to apply specific login restrictions. However, there are two key differences between externally authenticated users and normal OpenVMS users. The following is true for externally authenticated users: o The password stored in the SYSUAF is not the password used to verify the user. o The user name stored in the SYSUAF and used to identify the OpenVMS process is not necessarily the same as the external user ID used to authenticate the user during login. OpenVMS attempts to keep a user's SYSUAF and external user password synchronized to minimize these problems. An up- to-date copy of the user's external password is kept in the SYSUAF, but this is not the case if, for example, the external password contains characters that are invalid in OpenVMS, or if SYSUAF password synchronization is disabled by the system manager. (Password synchronization is enabled by default.) 4-12 System Management Release Notes System Management Release Notes 4.8 External Authentication If you enable external authentication, Compaq recommends you do the following to minimize incompatibility with layered products or applications that use traditional SYSUAF-based authentication: o Do not disable password synchronization. o Limit external user passwords to those characters from the OpenVMS valid password character set (A-Z, 0-9, underscore (_), and dollar sign ($)). o Assign users the same user name in both the external authentication service and OpenVMS. o Do not assign the same user name or user ID to more than one user. The $GETUAI and $SETUAI system services do not support external passwords. These services operate only on passwords stored in the SYSUAF and updates are not sent to the external authentication service. Enabling external authentication is not recommended for sites using software that makes calls to these services for the purposes of password checking or updates. Compaq expects to provide a new programming interface for this purpose in a future release. 4.8.2.5 Mixed-Version OpenVMS Cluster Systems V7.1 Compaq recommends using external authentication on OpenVMS Cluster systems only if all systems are running OpenVMS Version 7.1 or later. LOGINOUT on earlier version systems continues to enforce normal OpenVMS password policy (password expiration, password history, and so on), on all users, including externally authenticated users. 4.8.2.6 LGI Callout Services Disable External Authentication V7.1 Starting with Version 7.1, the presence of LOGINOUT (LGI) callouts disables external authentication. This restriction is expected to be removed in a future release. System Management Release Notes 4-13 System Management Release Notes 4.8 External Authentication 4.8.2.7 DECwindows Pause Screen Uses SYSUAF Password V7.1 The DECwindows pause screen unlock mechanism does not use the external authentication service for password validation. It continues to use the password in the SYSUAF file, even if you have external authentication enabled on your system. Password synchronization is enabled by default. If you have disabled password synchronization, be sure to keep the LAN Manager and SYSUAF passwords synchronized manually. 4.8.2.8 DECnet-Plus and NET_CALLOUTS Parameter V7.1 To run DECnet-Plus for OpenVMS with external authentication enabled, set the system parameter NET_CALLOUTS to 255. This enables LAN Manager user ID mapping and authentication for network logins. 4.8.2.9 No Password Expiration Notification on Workstations V7.1 In the LAN Manager domain, a user cannot log in once a password expires. Users on personal computers (PCs) receive notification of impending external user password expiration and can change passwords before they expire. However, when a user logs in from an OpenVMS workstation using external authentication, the login process cannot determine if the external password is about to expire. Therefore, sites that enforce password expiration, and whose user population does not primarily use PCs, may elect not to use external authentication for workstation users. This problem will be fixed in a future release. 4.9 Fast Path (Alpha Only) This section contains release notes pertaining to Fast Path. Fast Path is a high-performance feature designed to improve I/O performance. For more information about Fast Path, refer to the OpenVMS I/O User's Reference Manual. 4-14 System Management Release Notes System Management Release Notes 4.9 Fast Path (Alpha Only) 4.9.1 Changes and Enhancements The following release notes describe recent changes in Fast Path support. 4.9.1.1 SYSGEN Parameter Changes V7.2 Fast Path is now enabled by default. To disable Fast Path, set the FAST_PATH SYSGEN parameter to 0. Also, the IO_PREFER_CPUS parameter is now a dynamic SYSGEN parameter. Changing IO_PREFER_CPUS results in Fast Path ports being rebalanced across the set of usable CPUs. 4.9.1.2 DCL Support V7.2 The following DCL commands now support Fast Path: SHOW DEVICE/FULL SHOW CPU/FULL SET DEVICE/PREFERRED_CPU For more information about these commands, refer to the OpenVMS DCL Dictionary. 4.9.1.3 STOP/CPU Command Is Allowed V7.2 Prior to Version 7.2, you could not use the DCL command STOP/CPU to stop the Fast Path preferred CPU. This restriction has been removed. 4.10 Lock Manager This section contains notes pertaining to the lock manager. 4.10.1 Changes and Enhancements The following note describes changes that have been made to the lock manager data structures. System Management Release Notes 4-15 System Management Release Notes 4.10 Lock Manager 4.10.1.1 Lock Manager and Nonpaged Pool (Alpha Only) V7.2 To improve application scalability on OpenVMS Alpha systems, most of the lock manager data structures have been moved from nonpaged pool to S2 space. On many systems, the lock manager data structures accounted for a large percentage of nonpaged pool usage. Because of this change to nonpaged pool, Compaq recommends the following steps: o Use AUTOGEN with feedback information to tune the size of nonpaged pool. o Inspect MODPARAMS.DAT to check for any NPAGEDYN or NPAGEVIR settings previously made to increase the size of nonpaged pool due to the lock manager's usage. You may find that these parameters can be either trimmed back or removed due to changes to the lock manager The SHOW MEMORY documentation in the OpenVMS DCL Dictionary: N-Z describes the memory associated with the lock manager. 4.11 Monitor Utility The following notes pertain to the Monitor utility (MONITOR). 4.11.1 Problems and Restrictions The following release note describes how to deal with version incompatibilities when monitoring a pre-Version 7.2 node from a Version 7.2 node. 4.11.1.1 Monitoring Pre-Version 7.2 Nodes from Version 7.2 Nodes V7.2 Changes made to the Monitor utility in OpenVMS Version 7.2 are incompatible with previous versions of OpenVMS. If you attempt to monitor a pre-Version 7.2 node from a Version 7.2 node, you will get an incompatible version error message, as follows: 4-16 System Management Release Notes System Management Release Notes 4.11 Monitor Utility MONITOR> MONITOR /NODE=ARTOS1 PROCESSES %MONITOR-I-ESTABCON, establishing connection to remote node(s)... %MONITOR-E-ERRSYSINFO, failed to collect system information on node ARTOS1 -MONITOR-E-SRVMISMATCH, MONITOR server on remote node is an incompatible version %MONITOR-I-CONT, continuing.... You must install a remedial kit on OpenVMS Version 7.1 and Version 6.2 systems to communicate with Version 7.2 systems. The kit names are as follows: o VAX Version 6.2: VAXMONT01_062 o VAX Version 7.1: VAXMONT02_071 o Alpha Version 6.2: ALPMONT01_062 o Alpha Version 7.1: ALPMONT02_071 4.11.1.2 Changes to MONITOR Recording File V7.2 The MNR_DSK$B_ALLOCLS field in the MONITOR DISK class record has been changed from a byte-length field to a word-length field. The change was necessary to accommodate the disk port allocation class feature. In addition, all fields following MNR_DSK$B_ALLOCLS in the MONITOR DISK class record have been moved forward by one byte. Because of this change, the Structure Level Identification field (MNR_HDR$T_IDENT) in the File Header Record has been changed from "MON30050" to "MON31050". These changes are not reflected in Appendix A of the OpenVMS System Management Utilities Reference Manual: M-Z. 4.11.2 Documentation Changes and Corrections See Section 4.11.1.2 for a change that is not reflected in the OpenVMS Version 7.2 OpenVMS System Management Utilities Reference Manual: M-Z. 4.12 Mount Utility The following release notes pertain to mounting disks. System Management Release Notes 4-17 System Management Release Notes 4.12 Mount Utility 4.12.1 Problems and Restrictions The following notes describe how to work around several MOUNT restrictions. 4.12.1.1 /MEDIA_FORMAT=COMPACTION Qualifier Ineffective on TA90 Devices V7.2 The introduction of multiple tape density in OpenVMS Version 7.2 causes TA90 tape drives not to be properly placed in compaction mode when the standard DCL qualifier /MEDIA_FORMAT=COMPACTION is used in INITIALIZE, BACKUP, or MOUNT commands. The command and qualifier are accepted at the DCL level, but the device does not change modes. To work around this problem, use the new qualifier /MEDIA_FORMAT=(DENSITY=3480,COMPACTION) to correctly place the device in compaction mode. 4.12.1.2 Mounting Write-Protected Disks in a Mixed-Version Cluster V7.1-2 A fix that was made to MOUNT in OpenVMS Version 7.1-2 causes a minor incompatibility with earlier versions of MOUNT. This incompatibility occurs when disks that are write-protected (by either hardware or software write protection) are mounted on earlier versions of OpenVMS. In such cases, MOUNT returns the following error: %MOUNT-F-DIFVOLMNT, different volume already mounted on this device To avoid this error, apply the appropriate one of the following MOUNT kits (or a superseding kit): ALPMOUN04_062 ALPMOUN06_071 VAXMOUN03_062 VAXMOUN04_071 You can also use the following workaround to mount writable disks in a mixed-version cluster: $ DISMOUNT ddcu: ! on any nodes that it can be mounted on $ MOUNT/WRITE ddcu: label ! on the V7.1-2 node $ DISMOUNT ddcu: ! on the V7.1-2 node $ MOUNT/CLUSTER/NOWRITE ddcu: label 4-18 System Management Release Notes System Management Release Notes 4.12 Mount Utility By performing a MOUNT/WRITE operation, you allow the storage control block (SCB) of the device to be updated to be compatible with the MOUNT change. Once the SCB contains the new information, any version of MOUNT can properly use the device. 4.13 OPCOM This section contains a release note pertaining to the Operator Communication Manager (OPCOM). 4.13.1 Corrections V7.2 OpenVMS Version 7.2 contains corrections for the following OPCOM problems: o While OPCOM was processing cluster messages in previous OpenVMS versions, ASTs sometimes interrupted OPCOM in a queue operation and then attempted to perform a similar queue operation. This interruption corrupted the queue and caused OPCOM calls to LIB$FREE_VM to return a BADBLOADR message. If this status was returned while OPCOM was in kernel mode, the system crashed. This problem has been corrected so that ASTs do not interrupt OPCOM. o In previous versions of OpenVMS, the logical OPC$OPCOM_ STARTED was defined the first time OPCOM was started. This logical prevented other OPC logicals from being read on subsequent starts and restarts. OPCOM now reads the OPC logicals every time it starts or restarts. As a result, OPC$OPCOM_STARTED is no longer needed and has been removed. o The buffer size for the REQUEST command has been increased from 128 to 256 bytes to accommodate longer messages. 4.14 OpenVMS Cluster Systems The following release notes pertain to OpenVMS Cluster systems. System Management Release Notes 4-19 System Management Release Notes 4.14 OpenVMS Cluster Systems 4.14.1 Changes and Enhancements This section contains notes about changes and enhancements to OpenVMS Cluster systems. 4.14.1.1 New HSZ Allocation Class (Alpha Only) V7.2 OpenVMS Alpha Version 7.2 includes a new device-naming option, the HSZ allocation class, for devices on HSZ70 and HSZ80 storage controllers. HSZ allocation classes are documented in the new chapter, Configuring Multiple Paths to SCSI and Fibre Channel Storage, in Guidelines for OpenVMS Cluster Configurations. The HSZ allocation class is required when an HSZ is used in a multipath configuration. It can optionally be used in non-multipath configurations provided that all the systems with a direct SCSI connection to the HSZ are running OpenVMS Version 7.2. The HSZ allocation class takes precedence over all other device-naming methods. That is, if an HSZ controller has a valid HSZ allocation class, then the HSZ allocation class is always used to form the device name; the port allocation class (PAC), node allocation class, port letter, and node name are not used to form the device name. As a result, the SCSI bus configuration algorithm has been modified. Some of the previous restrictions placed on a shared SCSI bus do not apply when an HSZ allocation class is used. Prior to OpenVMS Version 7.2, the SCSI bus configuration code could configure devices on a shared SCSI bus only if all nodes supplied either matching PACs or matching port letters and matching node allocation classes. Such matching values were required to name a device consistently across all nodes in the cluster. Not only did the configuration code refuse to configure devices that failed these checks, but if the system had been running for less than 20 minutes, a system halt occurred. The behavior of the configuration code in OpenVMS Version 7.2 is as follows: o If PACs are supplied, they must match the PAC values supplied by other nodes. If the PACs do not match, the 4-20 System Management Release Notes System Management Release Notes 4.14 OpenVMS Cluster Systems bus is not configured, and an error message goes to the operator's console. However, the system does not halt as it did in prior versions. o If a SCSI bus is configured with HSZ controllers only, and all the controllers have a valid HSZ allocation class, then: - PACs are not required. - Node allocation class values do not have to match. - The port letter in the device name of each adapter does not have to match. o If there are non-HSZ devices on the bus, or HSZ controllers without an HSZ allocation class, then the standard rules for matching PACs or node allocation classes and port letters must be followed. If the PAC or the node allocation class and port letter do not match the values supplied by other nodes on the bus, the device is not configured, and an error message goes to the operator's console. However, the system does not halt as it did in prior versions. Note that certain devices, including those whose names include an HSZ allocation class, cannot be selectively autoconfigured using the SYSMAN utility. For more information on selective autoconfiguration, see Section 6.3. 4.14.1.2 OpenVMS Cluster Compatibility Kits for Version 6.2 Systems V7.1-1H1 The OpenVMS Cluster Compatibility Kits that shipped with OpenVMS Version 7.1 have been superseded by remedial kits ALPCLUSIOnn_062 for Alpha systems and VAXCLUSIOnn_062 for VAX systems. These kits are required for OpenVMS Version 6.2 systems that are members of an OpenVMS Cluster system that includes systems running one or more of the following OpenVMS versions: o Version 7.1 o Version 7.1-1H1 o Version 7.2 System Management Release Notes 4-21 System Management Release Notes 4.14 OpenVMS Cluster Systems The kits contain the OpenVMS Version 7.1 enhancements to Volume Shadowing, Mount, lock manager, and other quality improvements for OpenVMS Version 6.2 systems, as well as additional enhancements to these subsystems made after the release of OpenVMS Version 7.1. The kits also contain limited support for SCSI device naming using port allocation classes. These remedial kits are included on the OpenVMS Version 7.2 CD-ROM. You can also obtain these kits from your Compaq support representative or from the following web site: http://www.service.digital.com/html/patch_public.html 4.14.1.3 Cluster Client License Changes V7.1 A change has been made to OpenVMS Cluster Client licensing. Prior to Version 7.1, the OpenVMS Cluster Client license enabled full OpenVMS Cluster functionality, with the following exceptions: o Client CPUs could not provide votes toward the operation of the OpenVMS Cluster system. o Client CPUs could not use MSCP to serve disks or TMSCP to serve tapes. Previously, the first exception regarding voting was not enforced. Starting with Version 7.1, this exception is enforced. 4.14.2 Problems and Restrictions This section describes problems and restrictions pertaining to OpenVMS Cluster systems. Note that most SCSI cluster restrictions are described in the SCSI OpenVMS Cluster appendix in Guidelines for OpenVMS Cluster Configurations, although some appear only in these release notes. 4-22 System Management Release Notes System Management Release Notes 4.14 OpenVMS Cluster Systems 4.14.2.1 Mixed-Version Incompatibilities V7.2 A change to the OpenVMS Cluster Version 7.2 software prevents systems running OpenVMS Version 7.2 from participating in a cluster in which one or more nodes are running any of the following software versions: o OpenVMS VAX Version 5.5-2 or earlier versions o OpenVMS Alpha Version 1.5 or OpenVMS Alpha Version 1.0 If you attempt to boot a Version 7.2 node into a cluster containing a node with any of these older versions, the Version 7.2 node cannot join the cluster, and it crashes with a CLUSWVER bugcheck. Similarly, if you attempt to boot a node running one of these older versions into a cluster in which one or more nodes are running Version 7.2, the older version node cannot join the cluster, and it crashes with the same CLUSWVER bugcheck. For information about supported software versions in mixed- version and mixed-architecture clusters, refer to the OpenVMS Version 7.2 New Features Manual. 4.14.2.2 DECnet-Plus Satellite Boot Restriction (Alpha Only) V7.2 The DECnet-Plus MOP satellite boot service cannot be used to successfully boot an OpenVMS Cluster satellite system from a system disk that has a positive SCSI Port Allocation Class (PAC) value or an HSZ70/80 controller allocation class. The failing satellite displays the following messages during boot: %VMScluster-I-MSCPCONN, Connected to a MSCP server for the system disk, node ALAN %VMScluster-E-NOT_SERVED, Configuration change, the system disk is no longer served by node ALAN These messages may repeat indefinitely, possibly with different boot server node names, as the satellite attempts to find a usable boot server. System Management Release Notes 4-23 System Management Release Notes 4.14 OpenVMS Cluster Systems This problem can be avoided by using the LAN MOP service on any boot server that is running DECnet-Plus and is serving a satellite system disk that has a SCSI PAC or HSZ70/80 controller allocation class. The LAN MOP service can be enabled by using the CLUSTER_CONFIG.COM procedure or the LANCP utility. Refer to the OpenVMS Cluster Systems manual for additional information about LAN MOP booting. Note that this restriction does not apply if the boot server is running DECnet for OpenVMS (Phase IV). 4.14.2.3 MSCP_SERVE_ALL and Mixed-Version Clusters V7.2 MSCP_SERVE_ALL is a system parameter that controls disk serving in an OpenVMS Cluster system. Starting with OpenVMS Version 7.2, in certain configurations, it is possible to serve disks connected to HSx controllers with a node allocation class different from the system's node allocation class. However, for that to happen, all systems must be running OpenVMS Version 7.2. In a mixed-version OpenVMS Cluster system, serving "all available disks" is restricted to its pre-Version 7.2 meaning, that is, serving locally attached disks and disks connected to HSx and DSSI controllers whose node allocation class matches that of the system's node allocation class. To serve "all available disks" in a mixed-version cluster, you must specify the value 9. For more information about changes to the MSCP_SERVE_ALL system parameter, see Section 4.21.1.6. 4.14.2.4 SCSI Device-Naming Restrictions When Port Allocation Class Used V7.2 For OpenVMS Alpha Version 7.2, the internal device-naming model for SCSI devices with a port allocation class greater than 0 has been modified. This modification is part of the solution described in Section 4.14.3.2. In the new model, the only valid device name that you can use to address a SCSI device with a port allocation class is the fully specified device name, such as $3$DKA500. You can no longer use names like DKA500 and FUZZY$DKA500 to address such devices. In addition, the $GETDVI system 4-24 System Management Release Notes System Management Release Notes 4.14 OpenVMS Cluster Systems service has been changed to return the fully specified device name, including the port allocation class, for SCSI devices with a port allocation class greater than 0. A second restriction concerns using the SYSMAN utility to selectively autoconfigure devices. Certain devices, including those whose names include a port allocation class, cannot be selectively autoconfigured using SYSMAN. For more information, see Section 6.3. 4.14.2.5 Multipath Support for Parallel SCSI and Fibre Channel (Alpha Only) V7.2 Multipath support for parallel SCSI and Fibre Channel is documented in a new chapter, Configuring Multiple Paths to SCSI and Fibre Channel Storage, in Guidelines for OpenVMS Cluster Configurations. The following three restrictions apply to the initial release of OpenVMS Version 7.2: o Fibre Channel configurations are not supported. o Devices with multiple SCSI paths cannot be members of host-based shadow sets. o Failover between a local path to a SCSI device and an MSCP served path to that same device is not supported. The default setting of the MPDEV_REMOTE system parameter (MPDEV_REMOTE = 0) in OpenVMS Version 7.2 turns off this type of failover. (Although failover to an MSCP path is not supported, multipath devices can be MSCP served to other systems in an OpenVMS Cluster system.) These restrictions are also documented in the chapter noted above. The restrictions will be removed by an update kit shortly after the release of OpenVMS Version 7.2. Contact your Compaq representative to obtain this kit. 4.14.2.6 Fibre Channel Support (Alpha Only) V7.2 Fibre Channel support is latent in OpenVMS Alpha Version 7.2. Fibre Channel support will be available shortly after the release of OpenVMS Alpha Version 7.2. System Management Release Notes 4-25 System Management Release Notes 4.14 OpenVMS Cluster Systems To help you plan for the use of Fibre Channel in your OpenVMS Cluster system, Fibre Channel support is documented in two new chapters, Configuring Fibre Channel as an OpenVMS Cluster Storage Interconnect and Configuring Multiple Paths to SCSI and Fibre Channel Storage, in Guidelines for OpenVMS Cluster Configurations. Contact your Compaq support representative for the availability of Fibre Channel support for OpenVMS Alpha Version 7.2. 4.14.2.7 SCSI Shared Interconnect Requires Same Node Allocation Class (Alpha Only) V7.1-1H1 Prior to the introduction of port allocation classes in OpenVMS Version 7.1, nodes sharing a SCSI interconnect were required to use the same nonzero node allocation class. This requirement is still in effect, whether or not you are also using port allocation classes. When port allocation classes were introduced in OpenVMS Version 7.1, this requirement was mistakenly removed from Guidelines for OpenVMS Cluster Configurations, Table A-1. 4.14.2.8 AlphaServer 4000/4100 Systems Problem in SCSI Clusters V7.1 An AlphaServer 4000/4100 system that accesses its system disk through a KZPSA adapter may not boot or write a crash dump file if another system on the SCSI bus is booting or shutting down at the same time. Subsequent attempts to boot should succeed. Compaq recommends that you not attempt to perform these operations simultaneously in this configuration until you have updated your firmware. 4.14.2.9 CI-to-PCI (CIPCA) Adapter (Alpha Only) The release notes in this section describe restrictions for using the CIPCA module on OpenVMS Alpha systems. For more information about the CIPCA adapter, including permanent restrictions, refer to Appendix C in Guidelines for OpenVMS Cluster Configurations. 4-26 System Management Release Notes System Management Release Notes 4.14 OpenVMS Cluster Systems 4.14.2.9.1 HSJ50 Firmware Version Restriction for Use of 4K CI Packets V7.2 Do not attempt to enable the use of 4K CI packets by the HSJ50 controller unless the HSJ50 firmware is Version 5.0J- 3 or higher. If the HSJ50 firmware version is less than Version 5.0J-3 and 4K CI packets are enabled, data can become corrupted. If your HSJ50 firmware does not meet this requirement, contact your Compaq support representative. For more information about the use of 4K CI packets by the HSJ50 controller, refer to OpenVMS Cluster Systems. 4.14.2.9.2 Multiprocessor Systems with CIPCAs: CPUSPINWAIT Bugcheck Avoidance V7.1-1H1 If your multiprocessor system uses a CIPCA adapter, you must reset the value of the SMP_SPINWAIT parameter to 300000 (3 seconds) instead of the default 100000 (1 second). If you do not change the value of SMP_SPINWAIT, a CIPCA adapter error could generate a CPUSPINWAIT system bugcheck similar to the following: **** OpenVMS (TM) Alpha Operating System V7.1-1H1 - BUGCHECK **** ** Code=0000078C: CPUSPINWAIT, CPU spinwait timer expired This restriction will be removed in a future OpenVMS release. ________________________ Note ________________________ This release note is a revision of a release note that was published in OpenVMS Version 7.1 Release Notes (note 4.15.2.4.5). The SYSTEM_CHECK parameter restriction in that note is incorrect. ______________________________________________________ System Management Release Notes 4-27 System Management Release Notes 4.14 OpenVMS Cluster Systems 4.14.2.10 MEMORY CHANNEL (Alpha Only) The following sections contain guidelines and restrictions that apply to MEMORY CHANNEL. For detailed information about setting up the MEMORY CHANNEL hardware, see the MEMORY CHANNEL User's Guide (order number EK-PCIMC-UG.A01). You can copy this manual from the OpenVMS Version 7.2 CD- ROM using the following file name: [DOCUMENTATION]HW_MEMORY_CHANNEL2_UG.PS 4.14.2.10.1 Rolling Upgrades V7.2 OpenVMS Version 7.2 supports rolling upgrades in an OpenVMS Cluster system from Version 6.2, Version 6.2-1Hx, Version 7.1, and 7.1-1Hx to Version 7.2. This note applies only to rolling upgrades from Version 6.2 and Version 6.2-1Hx to Version 7.2. If MEMORY CHANNEL adapters (CCMAA-xx) have been added to the cluster before upgrading OpenVMS to Version 7.2, an MC_FORCEDCRASH bugcheck occurs on the first system when the second and subsequent systems perform AUTOGEN and SHUTDOWN during their Version 7.2 installation. This problem is caused by conflicting system parameters. To avoid this problem when upgrading, use one of the following procedures: o Upgrade all systems to OpenVMS Version 7.2 before adding the CCMAA-xx MEMORY CHANNEL adapters. o If you have MEMORY CHANNEL hubs, power them off before upgrading each system to OpenVMS Version 7.2. After all systems have been upgraded to Version 7.2, power on the MEMORY CHANNEL hubs. o If the nodes are connected directly in a virtual hub configuration, disconnect the MEMORY CHANNEL cables before upgrading each system to OpenVMS Version 7.2. After all systems have been upgraded to Version 7.2, reconnect the MEMORY CHANNEL cables. 4-28 System Management Release Notes System Management Release Notes 4.14 OpenVMS Cluster Systems 4.14.2.11 Booting Satellites with DECnet-Plus V7.1 Compaq recommends the use of the LANCP utility for all MOP booting requirements. If you choose to use DECnet- Plus MOP booting instead of LANCP, note the following restriction when adding a satellite: CLUSTER_CONFIG.COM uses the first circuit configured for MOP in the NET$MOP_ CIRCUIT_STARTUP.NCL file. To use a different circuit, you must edit NET$MOP_CIRCUIT_ STARTUP.NCL before invoking CLUSTER_CONFIG.COM. Place your desired circuit at the beginning of the NET$MOP_CIRCUIT_ STARTUP.NCL file, then invoke CLUSTER_CONFIG.COM. 4.14.2.12 System Startup in an OpenVMS Cluster Environment (Alpha Only) V6.2 In an OpenVMS Cluster environment on Alpha systems, under some circumstances the system startup procedure may fail to write a new copy of the ALPHAVMSSYS.PAR file. If this occurs, the console output from the boot sequence reports the following messages: %SYSGEN-E-CREPARFIL, unable to create parameter file -RMS-E-FLK, file currently locked by another user This error creates an operational problem only when changing system parameters using a conversational boot. For a normal, nonconversational boot, this error message is purely cosmetic because the parameter file has not changed. If a conversational boot is used, and system parameters are changed at boot time, these changed parameters will be correctly used for the current boot of the system. However, since the boot procedure does not successfully write a new copy of the parameter file, these changed parameters will not be used in subsequent boots. To permanently change system parameters that have been changed by a conversational boot, run SYSGEN after the system has completed booting, and enter the following commands: SYSGEN> USE ACTIVE SYSGEN> WRITE CURRENT System Management Release Notes 4-29 System Management Release Notes 4.14 OpenVMS Cluster Systems 4.14.3 Corrections The following notes describe corrections to OpenVMS Cluster systems. 4.14.3.1 SCSI Device Naming and Quorum Disk Problem Corrected (Alpha Only) V7.2 Prior to OpenVMS Version 7.2, an OpenVMS system that was booting and attempting to form a new OpenVMS Cluster could not do so if the following conditions existed: o The node required the votes from a quorum disk to form a new cluster. o The node was using the SCSI port allocation class device-naming method and had a SCSI port with a positive port allocation class value. o The quorum disk was not the system disk. Under these conditions, the booting system hung shortly after displaying the following message on the system console terminal: %SYSINIT-I- waiting to form or join an OpenVMS Cluster DIGITAL recommended that you not use SCSI port allocation classes if you needed to rely on a quorum disk, unless you could designate the system disk as the quorum disk. Compaq has removed this restriction. A system booting under these conditions now boots successfully. 4.14.3.2 SCSI Device-Naming Problem with PKA Device Corrected V7.2 Port allocation classes, introduced in OpenVMS Version 7.1, provide a new method for naming SCSI devices attached to Alpha systems in an OpenVMS Cluster. A port allocation class is enabled on a port when its value is set to 0 or a positive integer. After OpenVMS Version 7.1 was released, a potential problem pertaining to the SCSI port with the OpenVMS device name PKA was discovered. Failure to enable a port allocation class on PKA could cause some I/O operations to be issued to the wrong SCSI device, causing data corruption or loss. 4-30 System Management Release Notes System Management Release Notes 4.14 OpenVMS Cluster Systems Immediately after this problem was detected, a SCSI device- naming advisory was issued. Customers using port allocation classes for shared SCSI devices were advised to enable a port allocation class on the SCSI port with the OpenVMS device name PKA. This was required in all cases, regardless of whether PKA was connected to a shared (multihost) bus or a private bus. Customers were also advised to use port allocation classes only on systems that were members of an OpenVMS Cluster system. Starting with OpenVMS Version 7.1-2, this problem has been eliminated. Provided that all systems in an OpenVMS Cluster system are running Version 7.1-2 or later, a port allocation class for the SCSI port with the OpenVMS device name of PKA is no longer required. OpenVMS Cluster systems with mixed operating system versions must continue to follow the OpenVMS Version 7.1 SCSI device-naming advisory until all systems have been upgraded to OpenVMS Version 7.1-2 or later, or until systems with earlier versions have installed compatibility kits for this change. These compatibility kits are not yet available. For more information about port allocation classes, see the OpenVMS Cluster Systems manual. 4.14.3.3 SCSI Device-Naming Conflict That Prevented Satellite Booting Corrected V7.2 Prior to OpenVMS Version 7.2, a satellite system that used SCSI port allocation classes for its directly attached SCSI ports could not successfully boot into an OpenVMS Cluster system under the following conditions: o The satellite system was booting from an MSCP served SCSI disk. o SCSI port allocation classes were enabled on the satellite system, that is, system parameter DEVICE_ NAMING=1. System Management Release Notes 4-31 System Management Release Notes 4.14 OpenVMS Cluster Systems o The SYS$DEVICES.DAT file on the satellite system defined a non-negative port allocation class for its PK port that had the same controller letter in its name as the MSCP served system disk for the satellite. For example, these conditions were met if a satellite system attempted to boot from an MSCP served system disk named $100$DKB100 and if its PKB port had a port allocation class of 20. When these conditions existed, the satellite system displayed the following message on the console and failed to make any further progress: %VMScluster-I-RETRY, Attempting to reconnect to a system disk server This problem has been corrected in OpenVMS Version 7.2. 4.14.3.4 MSCP_CMD_TMO System Parameter Corrections V7.2 In OpenVMS Version 7.1, the default value for the MSCP_CMD_TMO system parameter was inappropriately set at 600. This has been corrected. The default setting is now 0. Also, when you executed the SYSGEN command SHOW MSCP_CMD_TMO in OpenVMS Version 7.1, the parameter unit was incorrectly listed as CNTLRTMOs (controller timeouts) instead of seconds. This error has also been corrected. MSCP_CMD_TMO is the time in seconds that the OpenVMS MSCP server uses to detect MSCP command timeouts. The MSCP Server must complete the command within a built-in time of approximately 40 seconds plus the value of the MSCP_CMD_TMO parameter. For more information about this parameter, refer to the OpenVMS System Management Utilities Reference Manual: M-Z. 4.15 OpenVMS File System This section contains notes pertaining to the OpenVMS file system. 4-32 System Management Release Notes System Management Release Notes 4.15 OpenVMS File System 4.15.1 Changes and Enhancements OpenVMS Version 7.2 introduces significant changes in the way the file system handles the storage bitmap and index file bitmap. These files are in the OpenVMS master file directory (MFD). The following sections contain notes related to these changes. Also see the OpenVMS System Manager's Manual for information on increases in the limits of storage and index file bitmaps. 4.15.1.1 Performance and Configuration Requirements of Large Bitmaps V7.2 Although a small cluster factor and a large storage bitmap allow more efficient allocation of small files, they exact a price in potential performance and configuration requirements. To allocate space, the file system scans the storage bitmap sequentially. With a very large storage bitmap, file creation and extension can become very slow when a volume becomes nearly full and, as a result, the file system must work harder to find free space. Certain file utilities such as MOUNT, SET VOLUME/REBUILD, BACKUP, and ANALYZE/DISK_STRUCTURE allocate virtual memory to hold copies of the index file and storage bitmaps. With larger bitmaps, the virtual memory requirements of these utilities increase correspondingly. To use these utilities on volumes with large bitmaps, you might need to increase your page file quota. On OpenVMS VAX systems, you might also need to increase the system parameter VIRTUALPAGECNT. Virtual memory requirements for the bitmaps are shown in the following table. Sizes are shown as VAX pages (or Alpha 512-byte pagelets) per block of bitmap. Note that the size of the index file bitmap in blocks is the maximum number of files divided by 4096. System Management Release Notes 4-33 System Management Release Notes 4.15 OpenVMS File System ___________________________________________________________ Utility_______________Virtual_Memory_Requirement___________ MOUNT and Equal to the sum of the sizes of SET VOLUME /REBUILD all index file bitmaps and storage bitmaps on the volume set. This requirement applies to MOUNT only if you rebuild a volume. BACKUP Equal to the sum of the sizes of all index file bitmaps on the volume set. (Note that this memory requirement is in addition to the BACKUP utility's substantial buffer pool.) ANALYZE /DISK_ Sum of the following across the STRUCTURE entire volume set: o 3 times all the storage bitmaps plus the largest bitmap in the volume set. o 117 times the index file bitmaps. o An additional 96 times the index file bitmaps if /USAGE was requested. o Approximately 600 pages of additional fixed scratch space. ___________________________________________________________ 4.15.1.2 Changing Disk Cluster Factor Can Create Incompatibilities V7.2 Starting with OpenVMS Version 7.2, the limit on the size of a volume's storage bitmap has increased from 255 to 65535, allowing small cluster factors on all volumes. However, volumes with a storage bitmap larger than 255 blocks cannot be mounted on OpenVMS systems running versions prior to Version 7.2. Doing so results in the following error: %MOUNT-F-FILESTRUCT, unsupported file structure level The default behavior of the INITIALIZE command for ODS-2 disks is to limit the bitmap to 255 blocks. The default behavior for the BACKUP command is to limit an ODS-2 bitmap to 255 blocks if the bitmap on the input volume was 255 blocks or smaller. If you specify a cluster factor using 4-34 System Management Release Notes System Management Release Notes 4.15 OpenVMS File System INITIALIZE/CLUSTER_SIZE=n or specify BACKUP/NOINITIALIZE, you can create a volume with a bitmap larger than 255 blocks. You can compute the cluster factor that yields a 255-block bitmap by using the following formula: cluster factor = volume size / 1044480 Round up fractions to the next whole unit. For more information about increased bitmap limits, see the System Management chapter in the OpenVMS Version 7.2 New Features Manual. Also see online help or the OpenVMS DCL Dictionary for details about the INITIALIZE and BACKUP commands. 4.15.1.3 Storage Bitmap Might Be Smaller Than Volume Requires V7.2 The INITIALIZE and BACKUP/IMAGE/INITIALIZE commands have always sized the storage bitmap to correspond to the entire physical volume. This behavior has not changed in OpenVMS Version 7.2. However, beginning with OpenVMS Version 7.2, the file system correctly handles a volume whose storage bitmap is smaller than required. The space on the volume available for allocation is the space the bitmap describes; as a result, if the bitmap is smaller than the volume requires, not all the volume is available for file allocation. A SHOW DEVICE /FULL command continues to display the actual physical volume size; however, the free blocks displayed are the number of blocks actually available for allocation. The ANALYZE/DISK utility reports a short bitmap with this message: SHORTBITMAP, storage bitmap on RVN 'n' does not cover the entire device Do not expect to see this message on Version 7.2 systems. Including support for short bitmaps is done in anticipation of future file system development; no OpenVMS Version 7.2 software causes a disk to have a short storage bitmap. A volume with a short bitmap functions correctly on OpenVMS Version 7.2 systems. However, do not mount such volumes on OpenVMS Version 7.1 and earlier systems. Older versions of OpenVMS do not handle short bitmaps correctly and might System Management Release Notes 4-35 System Management Release Notes 4.15 OpenVMS File System crash if you mount such a volume and attempt to create files on it. Future enhancements to OpenVMS that create volumes with short bitmaps will be limited to Files-11 structure level 5 volumes, which you cannot mount on Version 7.1 and earlier systems. 4.16 POLYCENTER Software Installation Utility The release notes in this section pertain to the POLYCENTER Software Installation utility. Also see Section 5.18 for notes about this utility that are of interest to programmers. 4.16.1 Changes and Enhancements This section describes changes to the POLYCENTER Software Installation utility and the DCL interface for the PRODUCT command. 4.16.1.1 DECwindows Motif Interface Retired V7.2 Beginning with OpenVMS Version 7.2, you can no longer use the PRODUCT/INTERFACE=DECWINDOWS command to invoke the Motif interface for the POLYCENTER Software Installation utility. Although the Motif interface is no longer available, the default character cell interface for the PRODUCT command continues to be fully functional and has been enhanced for Version 7.2. 4.16.2 Problems and Restrictions Notes in this section pertain to problems and restrictions with using the POLYCENTER Software Installation utility to install, remove, and reconfigure software products. Problems and restrictions of interest to programmers are described in Section 5.18.1. 4-36 System Management Release Notes System Management Release Notes 4.16 POLYCENTER Software Installation Utility 4.16.2.1 PRODUCT Command Lacks Options to Control Output V6.2 Commands such as PRODUCT FIND and PRODUCT SHOW that can display more than a screen of text do not provide qualifiers such as /PAGE to control scrolling or /OUTPUT to redirect output to a file. As a result, information can scroll off the screen. Compaq expects to enhance these commands in a future release. 4.16.2.2 Product Removal Restrictions V6.1 Removing a product using the POLYCENTER Software Installation utility results in the removal of accounts created for that product. This happens regardless of whether the SYSUAF.DAT file is shared by another system disk. The same problem exists with rights identifiers and the file RIGHTSLIST.DAT. 4.17 RMS Journaling The following release notes pertain to RMS Journaling for OpenVMS. 4.17.1 Changes and Enhancements The following note describes a change to RMS Journaling for OpenVMS. 4.17.1.1 Modified Journal File Creation V7.2 Prior to Version 7.2, recovery unit (RU) journals were created temporarily in the [SYSJNL] directory on the same volume as the file that was being journaled. The file name for the recovery unit journal had the form RMS$process_id (where process_id is the hexadecimal representation of the process ID) and a file type of RMS$JOURNAL. The following changes have been introduced to RU journal file creation in OpenVMS Version 7.2: o The files are created in node-specific subdirectories of the [SYSJNL] directory. System Management Release Notes 4-37 System Management Release Notes 4.17 RMS Journaling o The file name for the recovery unit journal has been shortened to the form: YYYYYYYY, where YYYYYYYY is the hexadecimal representation of the process ID in reverse order. These changes reduce the directory overhead associated with journal file creation and deletion. The following example shows both the previous and current versions of journal file creation: Previous versions: [SYSJNL]RMS$214003BC.RMS$JOURNAL;1 Current version: [SYSJNL.NODE1]CB300412.;1 If RMS does not find either the [SYSJNL] directory or the node-specific directory, RMS creates them automatically. 4.17.2 Problems and Restrictions The following notes describe restrictions to RMS Journaling for OpenVMS. 4.17.2.1 After-Image (AI) Journaling V7.2 After-image (AI) journaling can be used to recover a data file that becomes unusable or inaccessible. AI recovery uses the AI journal file to roll forward a backup copy of the data file to produce a new copy of the data file at the point of failure. In the case of a process deletion or system crash, an update can be written to the AI journal file, but not make it to the data file. If only AI journaling is in use, the data file and journal are not automatically made consistent. If additional updates are made to the data file and are recorded in the AI journal, a subsequent roll forward operation could produce an inconsistent data file. If Recovery Unit (RU) journaling is used in combination with AI journaling, the automatic transaction recovery restores consistency between the AI journal and the data file. Under some circumstances, an application that uses only AI journaling can take proactive measures to guard against data inconsistencies after process deletions or system crashes. For example, a manual roll forward of AI-journaled 4-38 System Management Release Notes System Management Release Notes 4.17 RMS Journaling files ensures consistency after a system crash involving an unshared AI application (single accessor) or a shared AI application executing on a standalone system. However, in a shared AI application, there may be nothing to prevent further operations from being executed against a data file that is out of synchronization with the AI journal file after a process deletion or system crash in a cluster. Under these circumstances, consistency among the data files and the AI journal file can be provided by using a combination of AI and RU journaling. 4.17.2.2 Remote Access of Recovery Unit Journaled Files in an OSI Environment V6.1 OSI nodes that host recovery unit journaled files that are to be accessed remotely from other nodes in the network must define SYS$NODE to be a Phase IV-style node name. The node name specified by SYS$NODE must be known to any remote node attempting to access the recovery unit journaled files on the host node. It must also be sufficiently unique for the remote node to use this node name to establish a DECnet connection to the host node. This restriction applies only to recovery unit journaled files accessed across the network in an OSI or mixed OSI and non-OSI environment. 4.17.2.3 VFC Format Sequential Files VAX V5.0 Alpha V1.0 You cannot update variable fixed-length control (VFC) sequential files when using before-image or recovery unit journaling. The VFC sequential file format is indicated by the symbolic value FAB$C_VFC in the FAB$B_RFM field of the FAB. 4.18 Security This section contains release notes pertaining to system security. System Management Release Notes 4-39 System Management Release Notes 4.18 Security 4.18.1 Changes and Enhancements This section describes changes and enhancements to system security. 4.18.1.1 DETACH Privilege Renamed to IMPERSONATE V7.1 The DETACH privilege has been renamed IMPERSONATE. The power of this privilege has increased over time so that a user with this privilege can now perform a general impersonation of another user. Some ways that the IMPERSONATE privilege can be used are as follows: o You can use the DCL command RUN/DETACH/UIC to create a detached process running under another user's identity. (Refer to the OpenVMS DCL Dictionary for details.) o You can use the $PERSONA_CREATE system service to create a security profile that an application can use to impersonate another user's identity. (See the OpenVMS System Services Reference Manual for details.) 4.18.1.2 DIRECTORY Command Now Summarizes Suppressed PATHWORKS ACEs V7.1 In OpenVMS Version 7.1 and later, if you execute the DCL command DIRECTORY/SECURITY or DIRECTORY/FULL for files that contain PATHWORKS access control entries (ACEs), the hexadecimal representation for each PATHWORKS ACE is no longer displayed. Instead, the total number of PATHWORKS ACEs encountered for each file is summarized in this message: "Suppressed n PATHWORKS ACE." To display the suppressed PATHWORKS ACEs, use the DUMP/HEADER command. 4.19 Show Cluster Utility The notes in this section pertain to the Show Cluster (SHOW CLUSTER) utility. 4-40 System Management Release Notes System Management Release Notes 4.19 Show Cluster Utility 4.19.1 Documentation Changes and Corrections The following note describes a change to the SHOW CLUSTER documentation. 4.19.1.1 OpenVMS System Management Utilities Reference Manual: M-Z V7.2 In earlier releases, the descriptions were incomplete for the EXPECTED_VOTES and QUORUM fields in the MEMBERS class for the ADD (Field) command. The documentation has been updated for this release. The complete descriptions for these fields are as follows: ___________________________________________________________ Field_Name__Description____________________________________ EXPECTED_ Maximum number of votes that an individual VOTES node can encounter. Used as an initial estimate for computing CL_EXPECTED_VOTES. The cluster manager sets this number using the EXPECTED_ VOTES system parameter. It is possible for this field to display a number smaller than the EXPECTED_VOTES system parameter setting if the REMOVE_NODE option was used to shut down a cluster member or if the SET CLUSTER/EXPECTED_ VOTES DCL command was used since this node was last rebooted. The dynamic value for EXPECTED_ VOTES used clusterwide is the CL_EXPECTED_VOTES field, which is described in the CLUSTER class category of ADD (Field). QUORUM Derived from EXPECTED_VOTES and calculated by the connection manager. It represents an initial value for the minimum number of votes that must be present for this node to function. The dynamic QUORUM value is the CL_QUORUM field, which is described in the CLUSTER class ____________category_of_ADD_(Field)._______________________ System Management Release Notes 4-41 System Management Release Notes 4.20 SYS$EXAMPLES 4.20 SYS$EXAMPLES This section contains release notes pertaining to SYS$EXAMPLES. 4.20.1 Changes and Enhancements The following release note describes a change to SYS$EXAMPLES. 4.20.1.1 SET PREFERRED_PATH Command Replaces PREFER.MAR and PREFER.CLD V7.2 PREFER.MAR and PREFER.CLD have been removed from SYS$EXAMPLES. However, even though these files no longer ship on the operating system, they are not deleted from an existing system during an upgrade. You can delete them or save them. The new DCL command SET PREFERRED_PATH replaces the functionality formerly provided by PREFER.MAR and PREFER.CLD. Refer to online help or the OpenVMS DCL Dictionary for details about the SET PREFERRED_PATH command. 4.21 System Parameters This section contains release notes pertaining to OpenVMS system parameters. 4.21.1 Changes and Enhancements The following sections describe the changes made to system parameters and system parameter help in Version 7.2. For descriptions of new system parameters, refer to online help, the OpenVMS Version 7.2 New Features Manual, or the OpenVMS System Management Utilities Reference Manual. 4.21.1.1 System Parameters Help V7.2 Help for system parameters is now easier to access. Look for system parameter help in the following new locations: o In the top level of DCL help as topic Sys_Parameters. o In the top level of SYSGEN help as topic Sys_Parameters. 4-42 System Management Release Notes System Management Release Notes 4.21 System Parameters o In the top level of SYSMAN help as topic Sys_Parameters. Starting with Version 7.2, the special parameters are now alphabetically merged with the other system parameters to make them easier to find. This new organization is also used in the OpenVMS System Management Utilities Reference Manual. 4.21.1.2 CRD_CONTROL V7.2 The CRD_CONTROL system parameter is implemented on Alpha as well as VAX systems. On VAX systems, CRD_CONTROL serves the function performed by CRDENABLE in earlier releases. On Alpha systems, CRD_CONTROL can be used to expand the function defined by CRDENABLE. CRD_CONTROL is a bit mask for corrected read data (CRD) soft error control flags. These flags control the use of CRDERROR routines. With OpenVMS Version 7.2, several new bits have been defined to support extended functions for Alpha systems. Default values are different for VAX and Alpha. On VAX systems, the default CRD_CONTROL setting has changed from 7 to 6, which enables CRD processing, scrubbing, and page replacement. On Alpha systems, the default CRD_CONTROL setting is 22, which enables CRD processing, scrubbing, page replacement, and extended CRD handling. For detailed bit descriptions for VAX and Alpha systems, refer to the Sys_Parameters topic in online help or see the System Parameters appendix in the OpenVMS System Management Utilities Reference Manual: M-Z. 4.21.1.3 MAXBOBMEM (Alpha Only) V7.2 On Alpha systems, the MAXBOBMEM system parameter defines the maximum amount of physical memory, measured in pagelets, that can be associated with buffer objects. A page that is to be associated with a buffer object is counted against this parameter only once even if it is associated with more than one buffer object at the same time. System Management Release Notes 4-43 System Management Release Notes 4.21 System Parameters Beginning with OpenVMS Version 7.2, memory-resident pages are not counted against this parameter. (However, pages locked in memory through the $LCKPAG system service are counted.) MAXBOBMEM is a DYNAMIC parameter. 4.21.1.4 MMG_CTLFLAGS (Alpha Only) V7.2 Beginning with OpenVMS Version 7.2, you can control when memory is tested. This helps reduce the time between when you turn on the system and when you log in to an AlphaServer 4100 computer. Bit 2 in the MMG_CTLFLAGS parameter controls deferred memory testing: o If the bit is clear (the default), OpenVMS tests memory in the background and not necessarily before the bootstrap process has completed. o If you set the bit, all memory is tested by the end of EXEC_INIT in the system bootstrap process, that is, before IPL is lowered from 31. 4.21.1.5 MSCP_CMD_TMO V7.2 The MSCP_CMD_TMO system parameter specifies the time in seconds that the OpenVMS MSCP server uses to detect MSCP command timeouts. The MSCP server must complete the command within a built-in time of approximately 40 seconds plus the value of the MSCP_CMD_TMO parameter. The default value of this parameter, which is 0, is normally adequate. A value of 0 provides the same behavior as in earlier releases of OpenVMS that did not have an MSCP_CMD_TMO system parameter. A nonzero setting increases the amount of time before an MSCP command times out. If command timeout errors are logged on client nodes, setting the parameter to a nonzero value on OpenVMS servers reduces the number of errors logged. Increasing the value of this parameter reduces the number of client MSCP command timeouts and increases the time it takes to detect faulty devices. 4-44 System Management Release Notes System Management Release Notes 4.21 System Parameters If you need to decrease the number of command timeout errors, Compaq recommends that you set an initial value of 60. If timeout errors continue to be logged, you can raise this value in increments of 20 seconds. 4.21.1.6 MSCP_SERVE_ALL V7.2 The MSCP_SERVE_ALL system parameter has been enhanced to accommodate the serving of disks connected to HSx controllers whose allocation class differs from the system's node allocation class. In addition, the default setting for MSCP_SERVE_ALL has changed from 0 (off) to 4 (serve only the system disk) to prevent a problem that can occur in unusual circumstances. Starting with OpenVMS Version 7.2, the serving types are implemented as a bit mask. For a complete description of the serving types controlled by each bit, see the System Parameters appendix in the OpenVMS System Management Utilities Reference Manual: M-Z. See Section 4.21.1.13 for a similar change to the TMSCP_ SERVE_ALL parameter. For more information about MSCP and TMSCP serving, see the OpenVMS Cluster Systems manual. 4.21.1.7 NOCLUSTER V7.2 The NOCLUSTER system parameter is now supported on both VAX and Alpha systems. This parameter controls whether page read clustering is inhibited when the system boots. The NOCLUSTER parameter should be set to 1 (inhibit page read clustering) only for debugging purposes. 4.21.1.8 PASTDGBUF V7.2 The definition of the PASTDGBUF system parameter has changed: PASTDGBUF The number of datagram receive buffers to queue initially for the cluster port driver's configuration poller; the initial value is expanded during system operation, if needed. System Management Release Notes 4-45 System Management Release Notes 4.21 System Parameters Memory Channel devices ignore this parameter. PASTDGBUF is an AUTOGEN parameter. 4.21.1.9 PIOPAGES V7.2 The default value for the PIOPAGES system parameter has been increased to 575. This new setting should accommodate the increased demands for process-permanent memory that result from changes made to RMS file-name parsing in Version 7.2. 4.21.1.10 QDSKINTERVAL V7.2 Beginning with OpenVMS Version 7.2, the default value of QDSKINTERVAL has been changed from 10 to 3. 4.21.1.11 SCSCONNCNT Is Obsolete V7.2 Beginning with OpenVMS Version 7.2, the SCSCONNCNT system parameter is obsolete. SCS connections are now allocated and expanded only as needed, up to a limit of 65,000. 4.21.1.12 STARTUP_P3 V7.2 Beginning in OpenVMS Version 7.2, if STARTUP_P3 is set to AGEN, the system executes AUTOGEN at the end of the startup sequence. 4.21.1.13 TMSCP_SERVE_ALL V7.2 The TMSCP_SERVE_ALL system parameter has been enhanced to accommodate the serving of tapes connected to HSx controllers whose allocation class differs from the system's node allocation class. Beginning in OpenVMS Version 7.2, the TMSCP_SERVE_ALL parameter is a bit mask that controls the serving of tapes during a system boot. Also beginning in Version 7.2, a tape is served regardless of its allocation class unless bit 3 has a value of 1. 4-46 System Management Release Notes System Management Release Notes 4.21 System Parameters For a complete description of the serving types controlled by each bit, see the Sys_Parameters help topic or the System Parameters appendix in the OpenVMS System Management Utilities Reference Manual: M-Z. See Section 4.21.1.6 for a similar change to the MSCP_ SERVE_ALL parameter. For more information about TMSCP and MSCP serving, see the OpenVMS Cluster Systems manual. 4.21.1.14 VBN_CACHE_S (VAX Only) V7.2 As of OpenVMS VAX Version 7.2, the default value and behavior of this system parameter have changed. The new default and current behavior are described in the following paragraphs. On VAX systems, the static system parameter VBN_CACHE_S enables or disables file system data caching. By default its value is 1, which means that caching is enabled and the virtual I/O cache is loaded during system startup. To disable file system data caching on the local node and throughout the OpenVMS Cluster, set the value to 1. In an OpenVMS Cluster, none of the other nodes in the cluster can cache any file data until this node either leaves the cluster or reboots with the VBN_CACHE_S parameter set to 1. 4.21.1.15 VCC_MAXSIZE (Alpha Only) V7.2 The description of this system parameter has changed, as follows: On Alpha systems, the static system parameter VCC_MAXSIZE controls the size of the virtual I/O cache. This parameter, which specifies the size in blocks, is 6,400 by default. On Alpha systems, the virtual I/O cache cannot shrink or grow. Its size is fixed at system startup. VCC_MAXSIZE is an AUTOGEN parameter. System Management Release Notes 4-47 System Management Release Notes 4.21 System Parameters 4.21.2 Problems and Restrictions This section contains release notes describing problems and restrictions related to system parameters. 4.21.2.1 ARB_SUPPORT (Alpha Only) V7.2 The new Access Rights Block (ARB) compatibility option, the ARB_SUPPORT system parameter, is provided specifically to support products that have not yet been updated with the new per-thread security Persona Security Block (PSB) data structures. ________________________ Note ________________________ Compaq recommends that all OpenVMS Alpha Version 7.2 systems have the ARB_SUPPORT parameter set to 2 or to 3 (the default). (Note that Version 7.2 online help incorrectly identifies the default value as 2 in the table.) Do not change the ARB_SUPPORT parameter to any other value until all products dependent on the ARB and associated structures have been modified for the new environment. ______________________________________________________ For additional information on the ARB compatibility option, look up ARB_SUPPORT in online Help under the Sys_Parameters topic or refer to the system parameters appendix in the OpenVMS System Management Utilities Reference Manual. 4.21.2.2 MSCP_SERVE_ALL V7.2 If an OpenVMS node is a boot server, the OpenVMS allocation class should be set to the allocation class of the satellite boot device. If this requirement is not met, satellite boot failures can result. 4.21.3 Corrections See Section 4.14.3.4 for a description of corrections made to the MSCP_CMD_TMO system parameter. 4-48 System Management Release Notes System Management Release Notes 4.21 System Parameters 4.21.4 Documentation Changes and Corrections This section contains notes with corrections to system parameter documentation. See Section 4.21.1.1 for a description of improvements made to system parameter help. 4.21.4.1 ARB_SUPPORT Default Value Is 3 (Alpha Only) V7.2 In the Sys_Parameters help topic on OpenVMS Version 7.2 systems, the default for ARB_SUPPORT is incorrectly documented as 2 in the table. The actual default setting is 3, as noted in the first paragraph of ARB_SUPPORT help. 4.21.4.2 MPDEV_REMOTE Is Not Supported V7.2 The MPDEV_REMOTE system parameter that is documented in online help and in the OpenVMS System Management Utilities Reference Manual is unsupported in OpenVMS Version 7.2. OpenVMS VAX online help incorrectly lists the default value as ON. 4.22 Terminal Fallback Facility (TFF) (Alpha Only) On OpenVMS Alpha systems, the Terminal Fallback facility (TFF) includes a fallback driver (SYS$FBDRIVER.EXE), a shareable image (TFFSHR.EXE), a terminal fallback utility (TFU.EXE), and a fallback table library (TFF$MASTER.DAT). ________________________ Note ________________________ TFFSHR has been removed from IMAGELIB because it is not a documented, user-callable interface. The image is still available in the SYS$LIBRARY: directory. ______________________________________________________ To start TFF, invoke the TFF startup command procedure located in SYS$MANAGER, as follows: $ @SYS$MANAGER:TFF$SYSTARTUP.COM To enable fallback or to change fallback characteristics, invoke the Terminal Fallback utility (TFU), as follows: $ RUN SYS$SYSTEM:TFU TFU> System Management Release Notes 4-49 System Management Release Notes 4.22 Terminal Fallback Facility (TFF) (Alpha Only) To enable default fallback to the terminal, enter the following DCL command: $ SET TERMINAL/FALLBACK OpenVMS Alpha TFF differs from OpenVMS VAX TFF in the following ways: o On Alpha systems, the TFF fallback driver is named SYS$FBDRIVER.EXE. On VAX systems, the TFF fallback driver is named FBDRIVER.EXE. o On Alpha systems, TFF is capable of handling 16-bit character fallback. The OpenVMS Alpha fallback table library (TFF$MASTER.DAT) contains four more 16-bit character tables than the VAX library. Table 4-1 describes these additional tables. Table_4-1_TFF_Character_Fallback_Tables____________________ Table_Name_______Base___Description________________________ BIG5_HANYU BIG5 BIG5 for CNS 11643 (SICGCC) terminal/printer HANYU_BIG5 CNS CNS 11643 (SICGCC) for BIG5 terminal/printer HANYU_TELEX CNS CNS 11643 for MITAC TELEX-CODE terminal HANGUL_DS________KS_____KS_for_DOOSAN_200_terminal_________ These tables are used mainly by the Asian region. Also, the table format was changed due to the support of 16- bit character fallback. o On Alpha systems, the TFU command SHOW STATISTICS does not display the size of the fallback driver (SYS$FBDRIVER.EXE). RT terminals are not supported by TFF. For more information about the Terminal Fallback facility, refer to the OpenVMS Terminal Fallback Utility Manual[1]. ____________________ [1] This manual has been archived but is available in PostScript and DECW$BOOK (Bookreader) formats on the OpenVMS Documentation CD-ROM. A printed book can be 4-50 System Management Release Notes System Management Release Notes 4.23 Volume Shadowing for OpenVMS 4.23 Volume Shadowing for OpenVMS The following release notes pertain to Volume Shadowing for OpenVMS. 4.23.1 Changes and Enhancements This section describes changes to volume shadowing software. 4.23.1.1 Shadow Set Member Support Raised to 500 V7.1 As of OpenVMS Version 7.1, the limit on the number of supported shadow set members has been raised from 390 to 500. 4.23.2 Problems and Restrictions The following sections describe known problems and other considerations pertaining to volume shadowing. 4.23.2.1 HSD10 Virtual Disks V7.1 The HSD10 controller supports a virtual disk capability by partitioning physical disks. To prevent data corruption, do not use OpenVMS Volume Shadowing to create shadow sets using HSD10 virtual disks. 4.23.2.2 Minimerge Capability for System Disk Requires DUMPSTYLE Parameter (Alpha Only) V7.1 Do not enable system disk minimerge without using the DUMPSTYLE parameter to dump off system disk, which is described in the System Parameters appendix in the OpenVMS System Management Utilities Reference Manual. If you do not set the DUMPSTYLE parameter to DOSD (for dump off system disk) and proceed to enable minimerge for system disks, minimerge will be activated, to the detriment of crash dump analysis. ____________________ ordered through DECdirect (800-344-4825); the order number for this manual is AA-PS6BA-TE. System Management Release Notes 4-51 System Management Release Notes 4.23 Volume Shadowing for OpenVMS With the introduction of a new setting (4097) in the SHADOW_SYS_DISK system parameter in OpenVMS Alpha Version 7.1 and the use of the DUMPSTYLE parameter, you can now enable minimerge on shadowed system disks on OpenVMS Alpha systems as well as on OpenVMS VAX systems. The DUMPSTYLE parameter lets you specify that the system write a dump to a nonshadowed, nonsystem disk of your choice. This results in a considerable performance improvement. Control the shadowing of a system disk by setting the SHADOW_SYS_DISK system parameter as shown in Table 4-2. Table_4-2_SHADOW_SYS_DISK_System_Parameter_Settings________ Setting_____Description____________________________________ 0 Do not shadow the system disk. 1 Shadow the system disk; disable system disk minimerge (if enabled). 4097 Shadow the system disk; enable system disk ____________minimerge._____________________________________ If you accidentally enable minimerge to a system disk that receives a crash dump and you have not set up dump off system disk, you may be able to recover if you know which disk contains the valid dump. Remove that member, remount it, and remove the dump from that member. 4.23.2.3 Minimerge Version Incompatibility V7.1 With OpenVMS Version 7.1, the Volume Shadowing software has been revised with substantial quality improvements. However, this creates an incompatibility in the minimerge function between Version 7.1 or later nodes and Version 6.2 nodes within the same cluster. In such configurations, the Volume Shadowing software detects this incompatibility during the installation of Version 7.1 or later systems and disables the minimerge capability for the entire cluster. This problem is resolved by installing the Cluster Compatibility Kit (see Section 4.14.1.2). This kit makes the Version 6.2 minimerge function compatible with that of nodes running Version 7.1 or later software. 4-52 System Management Release Notes System Management Release Notes 4.23 Volume Shadowing for OpenVMS 4.23.2.4 HSZ40 and Transportable SCSI Disk Shadow-Set Members V6.2 If you are using an HSZ40 Raid-Array Controller and OpenVMS Volume Shadowing, Compaq strongly recommends that you use HSZ40 nontransportable SCSI disks. This is because of a lack of functionality in transportable disks, which can result in data corruption. An HSZ40 Raid-Array Controller can support an OpenVMS initialized SCSI disk (that is, one with a Files-11 ODS-2 format on it) that is moved between an OpenVMS controlled SCSI bus and an HSZ40 controlled SCSI bus without reinitializing the disk and losing data. Disks that contain this functionality are called transportable disks. A SCSI disk initialized by the HSZ40 and then subsequently initialized by OpenVMS is called a nontransportable disk and cannot be moved to an OpenVMS controlled SCSI bus without losing data. Transportable SCSI disks, which support the READ_LONG /WRITE_LONG capability while connected to an OpenVMS controlled SCSI bus, lose this capability when they are moved to the SCSI bus controlled by an HSZ40 Raid-Array Controller. However, OpenVMS Volume Shadowing requires that a SCSI disk support the READ_LONG/WRITE_LONG SCSI commands to handle certain classes of errors as seen under normal volume shadowing operations. The lack of support for the READ_LONG/WRITE_LONG SCSI commands can cause data corruption. The lack of READ_LONG/WRITE_LONG capability is detected at shadow-set MOUNT time, by the following error: MOUN$_DEVNOFE, device does not support FORCED ERROR handling If you want to use OpenVMS Volume Shadowing with this limitation, a practice that Compaq strongly discourages, you can specify the MOUNT qualifier /OVERRIDE=NO_FORCED_ERROR at shadow-set MOUNT time. Note that specifying this MOUNT qualifier may cause shadow- set member SCSI disks to be removed from a shadow set if certain error conditions arise that cannot be corrected. System Management Release Notes 4-53 System Management Release Notes 4.23 Volume Shadowing for OpenVMS 4.23.3 Corrections The following notes describe corrections to former volume shadowing problems. 4.23.3.1 Incompatibility with StorageWorks RAID Software Corrected V7.2 An incompatibility existed between StorageWorks RAID Software and the enhanced volume shadowing provided in both OpenVMS Version 7.1 and in the Cluster Compatibility Kit. Because of this incompatibility, RAID software could no longer detect a shadow set state change. This problem has been corrected in the StorageWorks RAID Software Version 2.4. ________________________ Note ________________________ This incompatibility did not affect RAID 0 (without shadowing) arrays or RAID 5 arrays. ______________________________________________________ 4.23.3.2 Bad Block Repair (BBR) Logic Problem Corrected V7.2 The OpenVMS Version 7.1 Volume Shadowing driver's Bad Block Repair (BBR) logic did not perform correctly in some cases. This problem has been fixed in OpenVMS Version 7.2 and in the Cluster Compatibility Kits available for OpenVMS Version 6.2 systems (see Section 4.14.1.2). 4-54 System Management Release Notes 5 _________________________________________________________________ Programming Release Notes This chapter provides release notes about both application and system programming on OpenVMS systems. For information about new programming features included in OpenVMS Version 7.2, refer to the OpenVMS Version 7.2 New Features Manual. 5.1 Backup API This section contains release notes pertaining to the Backup application programming interface (API). See Section 4.2 for additional notes about the Backup utility. 5.1.1 Changes and Enhancements The following section describes a new flag to the BCK_OPT_K_IGNORE_TYPES option structure. 5.1.1.1 New Flag BCK_OPTYP_IGNORE_K_STRUCTURE V7.2 The BCK_OPT_K_IGNORE_TYPES option structure has a new flag: BCK_OPTYP_IGNORE_K_STRUCTURE. Setting this flag allows ODS-5 to ODS-2 structure-level file conversion. When this flag is not set, file conversion is not allowed. Refer to the OpenVMS Utility Routines Manual for more information about using the BACKUP option structure types. 5.1.2 Problems and Restrictions This section describes known problems and restrictions for the Backup API. Programming Release Notes 5-1 Programming Release Notes 5.1 Backup API 5.1.2.1 Unexpected Informational Message V7.2 The Backup API may return an incorrect exit status, BACKUP- I-INCONQUALS, and display an informational message after the backup completes. The backup will, however, proceed as normal. The following BCK_OPT_K_BEFORE_TYPE and BCK_OPT_K_SINCE_ TYPE flags have been removed. If one or more of these flags is used, the informational message may be displayed. BCK_OPTYP_BEFORE_K_CREATED BCK_OPTYP_BEFORE_K_EXPIRED BCK_OPTYP_BEFORE_K_MODIFIED BCK_OPTYP_BEFORE_K_SPECIFIED BCK_OPTYP_SINCE_K_CREATED BCK_OPTYP_SINCE_K_EXPIRED BCK_OPTYP_SINCE_K_MODIFIED BCK_OPTYP_SINCE_K_SPECIFIED 5.1.2.2 Journaling Callback Events Restriction V7.1 If an application registers a callback routine for any of the journaling events, it must register a callback routine for all the journaling callback events. The following is a list of the journaling callback events: BCK_EVENT_K_JOURNAL_OPEN BCK_EVENT_K_JOURNAL_WRITE BCK_EVENT_K_JOURNAL_CLOSE This is a permanent restriction. See the Backup API chapter in the OpenVMS Utility Routines Manual for more information on registering callback routines. 5-2 Programming Release Notes Programming Release Notes 5.1 Backup API 5.1.2.3 Repetitive Calls to BACKUP$START Can Cause an Error V7.1 Repetitive calls to BACKUP$START can cause the following error: %BACKUP-F-INSBUFSPACE, insufficient buffer space The number of repetitive calls completed before receiving this error varies, depending on the previous backup operations performed. The workaround for an application that receives this error is to exit the operation and restart. This problem will be corrected in a future release. 5.2 Batch and Print Queues This section contains release notes pertaining to batch and print queues. 5.2.1 Problems and Restrictions This section describes problems and restrictions pertaining to batch and print queues. 5.2.1.1 Terminating Executing Batch Jobs V6.2 Under the following conditions, the DELETE/ENTRY command might fail to stop an executing batch job: o The batch job is a DCL command procedure. o There is an ON ERROR CONTINUE command (or SET NOON command) within the command procedure. The DELETE/ENTRY command causes the job to terminate in phases. A delete_process AST routine is given in user mode, supervisor mode, and then executive mode. Because there is a small delay between each mode, it is possible that, in a batch job, a user-mode image might terminate, and the command procedure might continue to execute until the supervisor-mode delete_process AST routine is executed. Programming Release Notes 5-3 Programming Release Notes 5.2 Batch and Print Queues The return status of the SYNCHRONIZE command is assumed to contain the termination status of the target batch job. In addition, command procedures would normally execute a command such as $ON ERROR THEN CONTINUE or $SET NOON before issuing the SYNCHRONIZE command. If a DELETE/ENTRY command is issued to the job executing the SYNCHRONIZE command, the JBC$_JOBABORT is interpreted as being the termination status of the target batch job rather than a return status of the SYNCHRONIZE command. The command procedure then continues to execute for a short period with this incorrect assumption and performs an operation such as requeuing the target batch job or incorrectly reporting a failure of the target batch job. This problem has been fixed for the SYNCHRONIZE command by detecting this situation and waiting in an exit handler for longer than the delay between the user-mode and supervisor- mode termination delay. Any other images that would report the job completion status obtained by the SJC$_SYNCHRONIZE_JOB function code of the $SNDJBC system service as the return status of the program should implement logic similar to the following: 1. Declare an exit handler. 2. In the exit handler, implement the following logic: IF (exit status is JBC$_JOBABORT) THEN Wait 10 seconds ENDIF 5.3 COM for OpenVMS (Alpha Only) For release notes about COM for OpenVMS, see the OpenVMS Connectivity Developer's Guide, which is installed as part of the COM for OpenVMS installation process. That document is available in PostScript, HTML, and PDF formats. The OpenVMS Connectivity Developer's Guide is also available from the OpenVMS website at the following location: http://www.openvms.digital.com/openvms/products/dcom/ 5-4 Programming Release Notes Programming Release Notes 5.3 COM for OpenVMS (Alpha Only) COM for OpenVMS field test customers should also read the note in Section 3.1.1.1. 5.4 Debugging Modes This section contains a release note pertaining to special debugging modes. 5.4.1 Problems and Restrictions The following note explains how you can avoid getting a CPUSPINWAIT bugcheck. 5.4.1.1 Avoiding CPUSPINWAIT Bugchecks V7.1 The OpenVMS operating system has a number of special modes of operation designed to aid in debugging complex hardware and software problems. In general terms, these special modes enable an extra level of tracing, data recording, and consistency checking that is useful in identifying a failing hardware or software component. These modes of operation are controlled by several system parameters: MULTIPROCESSING, POOLCHECK, BUGCHECKFATAL, and SYSTEM_ CHECK. If you are using one of these special modes (for example, to debug a device driver or other complex application), under certain conditions, generally related to high I/O loads, it is possible to incur a CPUSPINWAIT bugcheck. To prevent a CPUSPINWAIT bugcheck, use the system default settings for these system parameters, or reduce the loading of the system. If you have reason to change the default settings, you can reduce the likelihood of encountering a problem by setting the SMP_LNGSPINWAIT system parameter to a value of 9000000. 5.5 DEC Ada Run-Time Library This section contains release notes pertaining to the DEC Ada Run-Time Library. Programming Release Notes 5-5 Programming Release Notes 5.5 DEC Ada Run-Time Library 5.5.1 Changes and Enhancements The following note describes some resources that are available to advanced Ada programmers. 5.5.1.1 OpenVMS Text Libraries Containing Ada Declarations V7.2 The following files are optional OpenVMS text libraries that contain Ada declarations: SYS$LIBRARY:STARLET_RECENT_ADA_SUBSET.TLB SYS$LIBRARY:LIB_ADA_SUBSET.TLB These files can be used by advanced Ada programmers who write programs that must interact explicitly with the OpenVMS operating system. These files provide the basis for such programs, in contrast to the seamless precompiled libraries that come with the DEC Ada compiler. The STARLET library contains declarations for recent components that may not yet have been incorporated into the kit for the latest DEC Ada compiler. As new versions of DEC Ada add declarations for these components, successive operating system releases remove them from this text library. Declarations in the LIB library are for special purposes and are subject to becoming incompatible with future operating system releases, as are corresponding files for other languages. 5.5.2 Problems and Restrictions This section describes a potential problem. 5.5.2.1 Unexpected Storage Errors (Alpha Only) V7.0 In OpenVMS Alpha Version 7.0 and later, binary compatibility fails for some DEC Ada programs that make incorrect assumptions about the amount of task space used by DEC Ada tasks. If a task gets a storage error that it did not previously get, you may need to add a length clause specifying the storage size for the task. If you already use a length clause, you might need to increase the amount of storage specified. This is necessary only in cases where 5-6 Programming Release Notes Programming Release Notes 5.5 DEC Ada Run-Time Library the specified size (or default size) is not large enough for the task's execution. 5.5.3 Corrections The following section notes the correction of a problem that required a workaround in past releases. 5.5.3.1 AST Procedures No Longer Get Access Violations V7.2 DEC Ada written AST procedures used to get access violations if the AST that invoked them occurred when the null thread or a non-DEC Ada thread was running. The workaround (rewrite the program to use a task entry point that has pragma AST_ENTRY on it) is no longer necessary. 5.6 DEC C Run-Time Library The following sections contain release notes pertaining to the DEC C Run-Time Library (RTL). 5.6.1 Changes and Enhancements This section describes changes and enhancements that are included in Version 6.0 or later of the DEC C RTL software. For more details, see the revision of the DEC C Run-Time Library Reference Manual for OpenVMS Systems that ships with DEC C Version 6.0 or later. 5.6.1.1 Internationalization Support V7.2 The DEC C RTL has added capabilities to allow application developers to create international software. The DEC C RTL obtains information about a language and a culture by reading this information from locale files. If you are using these DEC C RTL capabilities, you must install a separate kit to provide these files to your system. The save set, VMSI18N072, is provided on the same media as the OpenVMS operating system. Programming Release Notes 5-7 Programming Release Notes 5.6 DEC C Run-Time Library To install this save set, follow the standard OpenVMS installation procedures using this save set name as the name of the kit. There are several categories of locales that you can select to install. You can select as many locales as you need by answering the following prompts: Do you want European and US support? Do you want Chinese support? Do you want Japanese support? Do you want Korean support? Do you want Thai support? Do you want the Unicode converters? This kit also has an Installation Verification Procedure that Compaq recommends you run to verify the correct installation of the kit. In OpenVMS Version 7.2, the DEC C RTL has added a universal Unicode locale based on UTF-8 as a multibyte-character encoding and UCS-4 as wide-character encoding. The name of the locale is UTF8-20. The locale is based on Version 2.0 of the Unicode standard. Unlike other locales, the UTF8-20 locale is distributed with the operating system, not with the VMSI18N072 kit. In OpenVMS Version 7.2, the DEC C RTL has added Unicode codeset converters for Microsoft Code Page 437 (CP437). These codeset converters are also distributed with the operating system. 5.6.1.2 Euro Support V7.2 To facilitate the use of the Euro sign by applications that currently use the ISO8859-1 character set, DEC C RTL has added proprietary codeset ISO8859-1-EURO. This codeset is the same as the ISO8859-1 codeset except for the 0xa4 codepoint, which is defined as the international currency sign in ISO8859-1 and as a Euro sign in ISO8859-1-Euro (Unicode codepoint U+20AC). For every locale based on ISO8859-1, DEC C RTL added a "Euro" locale based on ISO8859-1-EURO. 5-8 Programming Release Notes Programming Release Notes 5.6 DEC C Run-Time Library The DEC C RTL has also added Unicode codeset converters for the ISO8859-1-EURO codeset and the ISO8859-15 codeset (also known as Latin-9). The Euro locales and new codeset converters are distributed with the VMSI18N072 kit. 5.6.1.3 New Functions V7.2 In OpenVMS Version 7.2, the DEC C RTL has added the following functions: asctime_r ctime_r gmtime_r localtime_r dlclose dlerror dlopen dlsym fcntl (a subset of commands) decc$set_child_standard_streams decc$write_eof_to_mbx decc$validate_wchar See the DEC C Run-Time Library Reference Manual for OpenVMS Systems for DEC C Version 6.0 for details. 5.6.1.4 Cache of OpenVMS Environment V7.2 In OpenVMS Version 7.2, a cache of OpenVMS environment variables (that is, logical names and DCL symbols) has been added to the getenv function to avoid the library making repeated calls to translate a logical name or to obtain the value of a DCL symbol. By default, the cache is disabled. If your application does not need to track changes in OpenVMS environment variables that can occur during the run of the application, the cache can be enabled by setting the DECC$ENABLE_GETENV_CACHE logical before invoking the application (any equivalence string). Programming Release Notes 5-9 Programming Release Notes 5.6 DEC C Run-Time Library 5.6.1.5 mmap Function Allows Creation of Global and Permanent Sections V7.2 In OpenVMS Version 7.2, the mmap function was enhanced to accept an additional argument, which is passed to the SYS$CRMPSC service when processing a MAP_SHARED request. Applications that use this additional argument must be compiled with DEC C Version 6.0 or higher. See the DEC C Run-Time Library Reference Manual for OpenVMS Systems for DEC C Version 6.0 for the details. 5.6.1.6 wait Functions Can Return Completion Code of Child Process V7.2 With OpenVMS Version 7.2, the waitpid, wait3, and wait4 functions, compiled with the _VMS_WAIT macro defined, put the OpenVMS completion code of the child process at the address specified in the status_location argument. When compiled without the _VMS_WAIT macro, these functions convert the OpenVMS completion code of the child process to a value consistent with macros for analysis of process status in the wait.h header, which is the standard behavior for the wait functions. Applications that use nonstandard wait functions must be compiled with DEC C Version 5.7 or higher. 5.7 DECthreads The following sections contain release notes pertaining to DECthreads. 5.7.1 Changes and Enhancements This section summarizes some significant changes and enhancements made to DECthreads. For detailed information about using DECthreads, refer to the Guide to DECthreads. 5-10 Programming Release Notes Programming Release Notes 5.7 DECthreads 5.7.1.1 Thread Stack Size V7.2 Prior to OpenVMS Version 7.2, when an application requested to allocate a thread stack of a specific, absolute size, DECthreads would increase the size by a certain quantity, then round up that sum to an integral number of pages. This process resulted in the actual stack size being considerably larger than the caller's request, possibly by more than one page. Starting with OpenVMS Version 7.2, when an application requests DECthreads to allocate a thread stack of a specific, absolute size, no additional space is added, but the allocation is still rounded up to an integral number of pages. Any application that uses default-sized stacks is unlikely to experience problems due to this change. Similarly, any application that sets its thread stack allocations in terms of either the DECthreads default or the allowable minimum stack size is unlikely to experience problems due to this change; however, depending on the allocation calculation used, the application might receive more memory for thread stacks. Starting with OpenVMS Version 7.2, any thread that is created with a stack allocation of a specific, absolute size might fail during execution because of insufficient stack space. This failure indicates an existing bug in the application that was exposed by the change in DECthreads. When the application requests to allocate a thread stack of a specific size, it must allow for not only the space that the application itself requires, but also sufficient stack space for context switches and other DECthreads activity. DECthreads only occasionally uses this additional stack space, such as during timeslice interruptions. A thread with inadequate stack space might encounter no problems during development and testing because of timing vagaries - for instance, a thread might not experience problems until a timeslice occurs while the thread is at its maximum stack utilization - and this situation might never arise during in-house testing. In a different system environment, such as in a production environment, the timing might be Programming Release Notes 5-11 Programming Release Notes 5.7 DECthreads different, possibly resulting in occasional failures when certain conditions are met. With OpenVMS Version 7.2, DECthreads has increased the default thread stack size for both OpenVMS Alpha and OpenVMS VAX. Applications that create threads using the default stack size (or a size calculated from the default) will be unaffected by this change. As of OpenVMS Version 7.2, DECthreads has increased the minimum thread stack size (based on the PTHREAD_STACK_ MIN constant) for OpenVMS VAX only. Applications that base their thread stack sizes on this minimum must be recompiled. 5.7.1.2 Static Initialization Inappropriate for Stack-Based Synchronization Objects V7.2 Although it is acceptable to the compiler, it is inappropriate to use the following macros to initialize DECthreads synchronization objects that are allocated on the stack: PTHREAD_MUTEX_INITIALIZER PTHREAD_COND_INITIALIZER PTHREAD_RWLOCK_INITIALIZER Each thread synchronization object is intended to be shared among the program's threads. If such an object is allocated on the stack, its address can asynchronously become invalid when the thread returns or otherwise terminates. For this reason, Compaq does not recommend allocating any thread synchronization object on the stack. As of OpenVMS Version 7.2, DECthreads detects some cases of misuse of static initialization of automatically allocated (stack-based) thread synchronization objects. For instance, if the thread on whose stack a statically initialized mutex is allocated attempts to access it, the operation fails and returns EINVAL. If the application does not check status returns from DECthreads routines, this failure can remain unidentified, and (if the operation was "lock mutex") the program can encounter a thread synchronization failure, which in turn can result in unexpected program behavior including memory corruption. (For performance reasons, 5-12 Programming Release Notes Programming Release Notes 5.7 DECthreads DECthreads does not currently detect this error when the mutex is accessed by a thread other than the one on whose stack the object was automatically allocated.) If your application must allocate a thread synchronization object on the stack, the application must initialize the object before it is used by calling one of the routines pthread_mutex_init(), pthread_cond_init(), or pthread_ rwlock_init(), as appropriate for the object. Your application must also destroy the thread synchronization object before it goes out of scope (for instance, due to the routine's returning control or raising an exception) by calling one of the routines pthread_mutex_destroy(), pthread_cond_destroy(), or pthread_rwlock_destroy(), as appropriate for the object. 5.7.1.3 POSIX 1003.4a Draft 4 Interface Retirement V7.0 The POSIX 1003.4a, Draft 4 (or "d4") interface of 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 DECthreads. A compatibility mode for the Draft 4 POSIX 1003.4a interface is provided in this release to help ease migration. This compatibility mode will be removed in a future release. 5.7.2 Problems and Restrictions This section describes known DECthreads problems and restrictions. 5.7.2.1 Incorrect Success Exit Status Values Returned V7.2 OpenVMS Version 7.2 contains a DECthreads regression that causes a process or image exit to incorrectly return a success exit status value under either of the following conditions: o A thread explicitly invokes the $EXIT system service or the C RTL exit() function. Programming Release Notes 5-13 Programming Release Notes 5.7 DECthreads o The initial thread terminates by returning an error status value from the program's main function. For example, this regression causes the DEC Ada Compilation System (ACS) to always return SS$_NORMAL, whether or not errors are encountered in the compilation or linking. This regression will be corrected in a remedial kit. 5.7.2.2 Language Support V7.0 This release does not include interface definitions for non-C languages for the POSIX 1003.1c standard-style interface to DECthreads. All DECthreads routines are usable from non-C languages; however, the application must provide the routine declarations. These self-defined declarations should be modeled after the C language declarations in pthread.h. 5.7.2.3 DECthreads Debugger Metering Function V7.0 The metering capability of the DECthreads debugger does not work in this release. 5.7.2.4 C Run-Time Library errno Value V7.0 When errno is accessed from the OpenVMS Debugger, the value of the global errno (not the per-thread errno) is returned. (This is not a new condition; it just has not been documented previously.) 5.7.2.5 SET TASK/ACTIVE Command V6.2 The OpenVMS Debugger command SET TASK/ACTIVE does not work for DECthreads (on both OpenVMS Alpha and VAX systems) or for DEC Ada for OpenVMS Alpha systems, the tasking for which is implemented using DECthreads. Instead, you can use the following effective substitutes on DECthreads: o For query-type actions, use the SET TASK/VISIBLE command. 5-14 Programming Release Notes Programming Release Notes 5.7 DECthreads o To gain control to step through a particular thread, use strategic placement of breakpoints. 5.8 DECTPU for DECwindows Motif The following sections contain release notes pertaining to DECTPU for DECwindows Motif. 5.8.1 Problems and Restrictions This section describes DECTPU for DECwindows Motif problems and restrictions. 5.8.1.1 Small Display Monitors and DECwindows Motif Applications V6.0 When running DECwindows Motif DECTPU on small display monitors, the main window can be less than fully visible. To correct this condition, follow these steps: 1. Add the following resources to your DECTPU X resource file: Tpu.Tpu$MainWindow.X: 0 Tpu.Tpu$MainWindow.Y: 0 Tpu.Tpu$Mainwindow.Rows: 21 Tpu*condensedFont: on Tpu*fontSetSelection: 1 2. Copy the resource file from SYS$LIBRARY:EVE.DAT and add the previous lines. 3. Use logical name TPU$DEFAULTS to point at the new resource file. The following example invokes the EVE DECwindows Motif user interface using the X resource file named eve_ small_window.dat in your login directory to edit the file LOGIN.COM. $ DEFINE TPU$DEFAULTS SYS$LOGIN:EVE_SMALL_WINDOW.DAT $ EDIT/TPU/INTER=DECWINDOWS LOGIN.COM Programming Release Notes 5-15 Programming Release Notes 5.9 High-Performance Sort/Merge Utility (Alpha Only) 5.9 High-Performance Sort/Merge Utility (Alpha Only) For programming release notes pertaining to the callable interface (SOR routines) of the OpenVMS Alpha high- performance Sort/Merge utility, see Section 3.4. For information about using the OpenVMS Alpha high- performance Sort/Merge utility, refer to the OpenVMS Utility Routines Manual and the OpenVMS User's Manual. 5.10 Lexical Functions This section contains a release note pertaining to a lexical function. 5.10.1 Changes and Enhancements The following note describes an obsolete item that has been replaced. 5.10.1.1 F$GETSYI Lexical: Item NODE_HWTYPE Is Obsolete V7.2 The NODE_HWTYPE item is obsolete. Please use the HW_NAME item instead. The NODE_HWTYPE item has not been removed; therefore, programs using this item will still work. However, Compaq recommends that you migrate such programs to use the HW_NAME item whenever possible to take advantage of new capabilities. On OpenVMS VAX systems, applications using NODE_HWTYPE receive cryptic, 4-character, system model names for all VAX systems and receive the string ALPH for all Alpha systems. In contrast, the HW_NAME item operates on both OpenVMS VAX and OpenVMS Alpha systems, and provides longer, more descriptive names to be returned. For example, HW_NAME returns "VAXstation II," whereas NODE_HWTYPE returns "VUV2" for the same system. 5.11 Librarian Utility The following sections contain release notes pertaining to the Librarian utility (LIBRARIAN). 5-16 Programming Release Notes Programming Release Notes 5.11 Librarian Utility 5.11.1 Problems and Restrictions This section describes known LIBRARIAN problems and restrictions. 5.11.1.1 PGFLQUOTA Should Exceed 23000 (Alpha Only) V1.5 The OpenVMS Alpha LIBRARIAN sometimes does not inform you of errors during compression, data reduction, or data expansion operations. This problem occurs if the account or process in which the LIBRARIAN is running has a low PGFLQUOTA process quota. Operation failure is not readily apparent because the $PUTMSG system service always returns a status of SS$_NORMAL, even when the system service fails. However, when a failure occurs, the LIBRARIAN returns a status other than Success. To work around this problem, run the compression, data reduction, or data expansion operation in an account with a PGFLQUOTA process quota greater than 23000. In addition, ensure that your command procedures check the return status from the LIBRARY command. 5.12 Linker Utility The following sections contain release notes pertaining to the OpenVMS Linker utility (linker). 5.12.1 Problems and Restrictions This section describes a linker restriction. 5.12.1.1 Limit of 25 Elements on Stack V7.2 Developers who are creating object files should be aware that the linker's internal stack is guaranteed for only 25 elements. Any calculations must be done within this constraint. 5.12.2 Documentation Changes and Corrections This section describes a correction to the linker documentation. Programming Release Notes 5-17 Programming Release Notes 5.12 Linker Utility 5.12.2.1 OpenVMS Linker Utility Manual V7.2 In Appendix A, the TRANSFER FLAGS field of the end-of- module record is incorrectly listed as EOM$L_TFRFLG. This field is a byte, not a longword; therefore, the correct name of the field is EOM$B_TFRFLG. 5.13 LTDRIVER The following sections contain release notes pertaining to the LTDRIVER. 5.13.1 Problems and Restrictions This section describes known LTDRIVER problems and restrictions. 5.13.1.1 CANCEL SELECTIVE Cannot Cancel IO$_TTY_PORT Functions V6.1 In releases prior to OpenVMS Version 6.1, LTDRIVER did not set the "extended DDT" bit; therefore, the POSIX function CANCEL SELECTIVE did not work with LTDRIVER. This has been fixed, but a restriction remains. Although this fix allows $QIO reads and writes to be selectively canceled, any $QIO done to the port driver (that is, with the IO$_TTY_PORT function modifier-like a LAT connect $QIO) cannot be canceled with CANCEL SELECTIVE. 5.14 MACRO-32 Compiler for OpenVMS Alpha (Alpha Only) See Chapter 7 for a number of notes that concern the MACRO- 32 compiler. 5.15 Mail Utility This section contains release notes about the Mail utility that are of interest to programmers. 5.15.1 Problems and Restrictions The following note describes a restriction for callable mail. 5-18 Programming Release Notes Programming Release Notes 5.15 Mail Utility 5.15.1.1 Threads Restriction for Callable Mail V7.1 OpenVMS callable mail routines are not thread-safe. Refer to the Guide to DECthreads for more information about calling nonthread-safe routines within a threaded application. Because callable mail context information is maintained on a per-process (rather than a per-thread) basis, multiple threads performing context-based processing must be synchronized so that only one mail context of a given type is active at once. Otherwise, one thread could corrupt another thread's mail operations. On OpenVMS Alpha systems, there is an additional restriction when kernel threads is enabled in a multithreaded environment. In this environment, callable mail should be used only in the initial thread. 5.16 Mathematics (MTH$) Run-Time Library The following sections contain release notes pertaining to the Run-Time Mathematics Library (MTH$). 5.16.1 Problems and Restrictions This section describes known MTH$ problems and restrictions. 5.16.1.1 Linking Images to Run on Previous OpenVMS VAX Versions (VAX Only) V6.1 This version of OpenVMS VAX provides updated versions of the Mathematics Run-Time Library (RTL) images MTHRTL.EXE, UVMTHRTL.EXE, and VMTHRTL.EXE that contain new entry points in support of DEC Fortran Version 6.0. (UVMTHRTL.EXE is an alternate form of MTHRTL.EXE; references to MTHRTL.EXE in the following paragraphs also apply to UVMTHRTL.EXE.) Due to the large number of entry points added to MTHRTL.EXE, that image's transfer vector was extended and its global section match identifier incremented. This means that images linked against the new version of MTHRTL.EXE will not run on a system running an earlier version of OpenVMS VAX, unless that system has also installed DEC Programming Release Notes 5-19 Programming Release Notes 5.16 Mathematics (MTH$) Run-Time Library Fortran Version 6.0. In addition, images linked against the new MTHRTL.EXE cannot be translated to run on OpenVMS Alpha using DECmigrate. To link an image so that it will run on an earlier version of OpenVMS VAX, create a directory that contains saved copies of the .EXE and .OLB files from the SYS$LIBRARY directory of the earliest version you want to support, and define the logical name SYS$LIBRARY to point to that directory before linking. Because OpenVMS VAX also defines a system logical name MTHRTL to refer to either MTHRTL.EXE or UVMTHRTL.EXE, you must also define MTHRTL as a logical name in the process or job table to point to the copy in the directory of older images. For example: $ DEFINE/USER SYS$LIBRARY disk:[OLD_SYSLIB] $ DEFINE/USER MTHRTL SYS$LIBRARY:MTHRTL.EXE $ LINK ... Images to be translated using DECmigrate should be linked against the SYS$LIBRARY files of OpenVMS VAX Version 5.5-2 or earlier. 5.17 OpenVMS Registry (Alpha Only) For release notes about the OpenVMS Registry, refer to the OpenVMS Connectivity Developer's Guide, which is installed as part of the COM for OpenVMS installation process. That document is available in PostScript, HTML, and PDF formats. OpenVMS Connectivity Developer's Guide is also available from the OpenVMS website at the following location: http://www.openvms.digital.com/openvms/products/dcom/ 5.18 POLYCENTER Software Installation Utility The release notes in this section pertain to the POLYCENTER Software Installation utility. Also see Section 4.16 for notes about this utility that are of interest to system managers. 5-20 Programming Release Notes Programming Release Notes 5.18 POLYCENTER Software Installation Utility 5.18.1 Problems and Restrictions This section describes a known problem with using the POLYCENTER Software Installation utility to create software kits. Problems and restrictions of interest to system managers are described in Section 4.16.2. 5.18.1.1 Generation Option of File Statement V7.1 The generation option of the file statement does not work correctly on product removal. For example, the product description files for products TEST1 and TEST2 are as follows: product DEC VAXVMS TEST1 V1.0 full ; file [SYSEXE]TEST.EXE generation 1 ; end product ; product DEC VAXVMS TEST2 V1.0 full ; file [SYSEXE]TEST.EXE generation 2 ; end product ; Installing product TEST1 followed by product TEST2 works correctly. Generation 2 of file TEST.EXE replaces generation 1 of file TEST.EXE. However, if you remove product TEST2, generation 1 of file TEST.EXE is not restored; generation 2 of the file is left on the system. One workaround is to use an execute install...remove statement sequence in product TEST2. The command procedure invoked during the execute install portion of the statement saves any previous version of the file. Later the execute remove portion of the statement restores the saved version of the file. Compaq expects to correct this problem in a future release. 5.19 Privileged Interfaces and Data Structures (Alpha Only) This section contains release notes concerning privileged code and data structures. Programming Release Notes 5-21 Programming Release Notes 5.19 Privileged Interfaces and Data Structures (Alpha Only) 5.19.1 Changes and Enhancements The following sections describe changes that affect privileged code. 5.19.1.1 Per-Thread Security and Backward Compatibility V7.2 The security information previously stored in several data structures has moved to a new Persona Security Block (PSB) data structure, making the relevant fields in those structures obsolete in OpenVMS Version 7.2. The affected structures include the Access Rights Block (ARB), Process Control Block (PCB), Process Header Descriptor (PHD), Job Information Block (JIB), and Process Control (CTL) region fields. Table 5-1 shows the obsolete data cells and where the information in those cells has moved. For single persona execution within a process, the obsolete data cells[1] are maintained for backward compatibility. The cells are not maintained while a process is executing with multiple user-level personae (because any code checking the old cells would likely make the wrong security decision). ________________________ Note ________________________ A process is created with a single user-mode security profile known as the natural persona. Backward compatibility based on the current value of the new SYSGEN parameter ARB_SUPPORT, which defines the level of backward compatibility between the obsolete cells and the new PSB data structure, is maintained while the process remains in this user-mode persona state. (See the OpenVMS System Management Utilities Reference Manual for information about the ARB_SUPPORT parameter.) ___________________ [1] Security information within the JIB (JIB$T_ACCOUNT, the account cell) is not backward compatible because the JIB is shared among all processes in a job tree. Modifying the JIB user-name cell (JIB$T_USERNAME) in a multiprocess job tree can adversely affect other processes in that job tree. 5-22 Programming Release Notes Programming Release Notes 5.19 Privileged Interfaces and Data Structures (Alpha Only) Backward compatibility is not supported when multiple user-mode persona exist. Multiple user-mode persona are created using the $PERSONA_CREATE system service. ______________________________________________________ Backward compatibility of the obsolete data cells might not be maintained in future releases of OpenVMS. Writers of privileged code are encouraged to search for the obsolete symbols in their code and make the necessary modifications to remove the code's dependence on the obsolete cells, and to get the information from the new locations. Table 5-1 Obsolete Data Cells and New Location of Security __________Information______________________________________ Obsolete_Data_Cell_________New_Location____________________ ARB$L_CLASS PSB$AR_CLASS (Not supported[1]) ARB$L_RIGHTSLIST PSB$AR_RIGHTS (array of rights chains pointers) - Persona, image, and system rights chains ARB$L_UIC PSB$L_UIC ARB$Q_PRIV (Working PSB$Q_WORKPRIV, PSB$Q_IMAGE_ privileges logically OR'd WORKPRIV with image privileges) CTL$GQ_PROCPRIV PSB$Q_PERMPRIV CTL$T_ACCOUNT PSB$T_ACCOUNT CTL$T_USERNAME PSB$T_USERNAME EXE$GL_RIGHTSLIST EXE$AR_SYSTEM_RIGHTS (Rights chain pointer) JIB$T_ACCOUNT[2] PSB$T_ACCOUNT JIB$T_USERNAME PSB$T_USERNAME [1]OpenVMS_Version_7.2_does_not_maintain_the_structures____ to support MAC (mandatory access checking) in a level B1 security environment. [2]Security information within this cell is not backward compatible because the JIB is shared among all processes in a job tree. (continued on next page) Programming Release Notes 5-23 Programming Release Notes 5.19 Privileged Interfaces and Data Structures (Alpha Only) Table 5-1 (Cont.) Obsolete Data Cells and New Location of __________________Security_Information_____________________ Obsolete_Data_Cell_________New_Location____________________ PCB$L_NOAUDIT PSB$L_NOAUDIT PCB$V_SECAUDIT PSB$L_SECAUDIT PHD$Q_AUTHPRIV PSB$Q_AUTHPRIV PHD$Q_IMAGPRIV PSB$Q_IMAGE_WORKPRIV PHD$Q_PRIVMSK PSB$Q_WORKPRIV, PSB$Q_IMAGE_ WORKPRIV - Working privileges logically OR'd with image privileges (PSB) PHD$R_MAX_CLASS PSB$AR_CLASS (Not supported[1]) PHD$R_MIN_CLASS PSB$AR_CLASS (Not supported[1]) [1]OpenVMS_Version_7.2_does_not_maintain_the_structures____ to support MAC (mandatory access checking) in a level B1 security environment. ___________________________________________________________ 5.19.1.2 Privileged Code Changes at Version 7.0 V7.0 Privileged-code applications 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 later. Privileged-code applications 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 later. OpenVMS Alpha Version 7.0 included significant changes to OpenVMS Alpha privileged interfaces and data structures. As a result of these changes, privileged-code applications from releases prior to OpenVMS Alpha Version 7.0 might require source-code changes to run correctly on OpenVMS Alpha Version 7.0 and later. For more details about OpenVMS Alpha Version 7.0 changes that may require source changes to privileged-code applications, refer to the OpenVMS Alpha Guide to Upgrading Privileged-Code Applications. 5-24 Programming Release Notes Programming Release Notes 5.19 Privileged Interfaces and Data Structures (Alpha Only) For information about recompiling and relinking device drivers, see Chapter 6. 5.19.2 Problems and Restrictions The following release note describes how per-thread security impacts privileged code and device drivers. 5.19.2.1 Per-Thread Security Impacts Privileged Code and Device Drivers V7.2 The method used for attaching a security profile to the I/O Request Packet (IRP) has changed. In previous versions of OpenVMS, the address of the processwide Access Rights Block (ARB) security structure was copied directly into the IRP. Beginning with OpenVMS Alpha Version 7.2, the address of the new security profile structure (Persona Security Block, or PSB) of the thread making the I/O request is moved into the IRP. The I/O subsystem maintains its access to the PSB through a reference counter. The I/O subsystem increments this reference counter at IRP creation and decrements the counter at I/O completion. When the counter reaches zero, the PSB is deleted from the system. Device drivers that created copies of IRPs to facilitate multiple I/O operations per request, and subsequently pass the copied IRPs to the I/O subsystem for postprocessing, must make code changes to account for the extra dereferences to the PSB that result. This is done by calling NSA_STD$REFERENCE_PSB and passing the PSB address located in the copied IRP before I/O postprocessing of the IRP copy. The include file and routine call for NSA_ STD$REFERENCE_PSB is as follows: #include /* Increment REFCNT of PSB that is now shared by both IRPs */ nsa_std$reference_psb( irp->irp$ar_psb ); Programming Release Notes 5-25 Programming Release Notes 5.19 Privileged Interfaces and Data Structures (Alpha Only) Device drivers need to make this change under the following conditions: o If a device driver: 1. Creates a new IRP by duplicating an existing IRP, and 2. Will submit both the original and the duplicate IRPs for I/O postprocessing by calling IOC_STD$SIMREQCOM or IOC_STD$DIRPOST1. Then the device driver must call NSA_STD$REFERENCE_ PSB sometime after duplicating the IRP, but before submitting it for I/O postprocessing. o If a device driver: 1. Creates a new IRP by duplicating an existing IRP, and 2. Does not put the address of some procedure descriptor into the IRP$L_PID cell in either the copy or the original IRP, and 3. Will submit both the original and the duplicate IRPs for I/O postprocessing by calling IOC_STD$REQCOM, COM_STD$POST, COM_STD$POST_NOCNT, or IOC_STD$POST_ IRP. Then the device driver must call NSA_STD$REFERENCE_ PSB sometime after duplicating the IRP, but before submitting it for I/O postprocessing. Device drivers that perform steps 1 and 3 are also likely to put the address of some procedure descriptor into IRP$L_PID. Therefore, most device drivers that duplicate IRPs should be able to function correctly on OpenVMS 7.2 without making source changes, relinking, or recompiling. Failure to call NSA_STD$REFERENCE_PSB in these circumstances will result in corrupt tracking information within the PSB, which can result in system crashes. If you make code changes in a device driver to call NSA_ STD$REFERENCE_PSB, you must recompile and relink the driver to run on OpenVMS Version 7.2. 5-26 Programming Release Notes Programming Release Notes 5.20 Record Management Services (RMS) 5.20 Record Management Services (RMS) This section contains release notes pertaining to RMS. 5.20.1 Changes and Enhancements The following notes describe enhancements to RMS. 5.20.1.1 Ellipsis Processing of [000000...] Now Finds All Files V7.2 Prior to OpenVMS Version 7.2, an ellipsis search specification starting with the master file directory (MFD) (that is, [000000...]) would cause RMS, after returning all files in the MFD, to begin ellipsis processing with the first subdirectory whose name sorts alphanumerically after 000000.DIR. Subdirectory trees beginning with directories whose names sort before 000000.DIR would be skipped. With the introduction of support for Extended File Specifications, which makes the creation of such directory names a more common event, RMS now begins its ellipsis processing of [000000...] with the first directory found, not the first directory that sorts before the MFD itself. Therefore, this search specification can now be used to return all files located on the specified device. 5.20.1.2 Circular Directory Path Detection (Alpha Only) V7.2 Circular directory paths result when a SET FILE/ENTER command enters the directory name of a higher-level directory into a lower directory in its subdirectory tree. Prior to Version 7.2, such a directory tree appeared circular to RMS during ellipsis processing (for example, when processing a specification such as [A...]) because RMS did not detect that a directory's directory ID (DID) resulting from a SET FILE/ENTER command had already been encountered higher up in the path. In earlier releases, an 8-deep directory limit inhibited RMS from looping while following a potentially infinite circle of DIDs. With the introduction of deep directories in OpenVMS Version 7.2, the 8-deep directory limit has been removed. In this release, RMS has been enhanced to detect when a node in the path initiates a circle. Instead Programming Release Notes 5-27 Programming Release Notes 5.20 Record Management Services (RMS) of looping, RMS now treats such a node as if it were the lowest element in the current branch of the path. 5.20.1.3 Directory Cache Limits Removed V7.2 During most wildcard searches, RMS caches the target directory file in memory to optimize calls to the file system. Prior to this release, the maximum size of a directory file that RMS would cache was 127 blocks; wildcard lookups to larger directories would go directly to the file system. Beginning with Version 7.2, RMS attempts to cache directories of any size. If memory or other resources are not available to cache the file, wildcard lookups are then directed to the file system. 5.21 Run-Time Library (LIB$) This section contains release notes pertaining to the Run-Time Library (LIB$). 5.21.1 Problems and Restrictions This section describes known LIB$ RTL problems and restrictions. 5.21.1.1 LIB$FIND_IMAGE_SYMBOL Signals Warning for Modules with Compilation Errors V7.1 LIB$FIND_IMAGE_SYMBOL may signal a warning (LIB$_EOMWARN) to indicate that the image being activated contains modules that had compilation warnings. A condition handler used with LIB$FIND_IMAGE_SYMBOL should probably handle this as a special case. To allow LIB$FIND_IMAGE_SYMBOL to continue execution after signaling LIB$_EOMWARN, the condition handler should exit with SS$_CONTINUE. For this reason, you may choose not to use LIB$SIG_TO_RET as a condition handler for LIB$FIND_IMAGE_SYMBOL. 5-28 Programming Release Notes Programming Release Notes 5.21 Run-Time Library (LIB$) 5.21.2 Documentation Changes and Corrections This section describes minor corrections to the LIB$ Run- Time Library documentation. 5.21.2.1 OpenVMS RTL Library (LIB$) Manual V7.2 The OpenVMS RTL Library (LIB$) Manual requires the following corrections: o In the description of the LIB$GETJPI routine, the description of the resultant-string argument should read: String representation of the information you requested. The resultant-string argument is the address of the descriptor for a character string into which LIB$GETJPI writes the string representation. o In the description of the LIB$GETQUI routine, the description of the resultant-string argument should read: String representation of the information you requested. The resultant-string argument is the address of the descriptor for a character string into which LIB$GETQUI writes the string representation. 5.22 Screen Management (SMG$) Facility The following sections contain release notes pertaining to the Screen Management (SMG$) Facility. 5.22.1 Documentation Changes and Corrections This section describes minor corrections to the SMG$ Run- Time Library documentation. 5.22.1.1 OpenVMS RTL Screen Management (SMG$) Manual Note the following information that should be added to topics in the reference section at the end of the OpenVMS RTL Screen Management (SMG$) Manual: V7.2 o The following statement should be added to the Condition Values Returned section of routine SMG$DELETE_VIRTUAL_ DISPLAY: Programming Release Notes 5-29 Programming Release Notes 5.22 Screen Management (SMG$) Facility "Any condition value returned by the $DELPRC system service." o The description of routine SMG$GET_TERM_DATA contains an error in the Arguments section for the capability-data argument. The correction is as follows: access: write-only mechanism: by reference, array reference o The description of routine SMG$READ_LOCATOR contains an error in the Arguments section for both the row-number and the column-number arguments. The "access:" for both arguments is write only. o The description of routine SMG$SET_OUT_OF_BAND_ASTS contains an error in the Arguments section for the AST-argument argument. The symbolic names in the Data Structure diagram are incorrect. The symbolic names in the paragraph under this diagram are correct. The correct and incorrect symbolic names are as follows: ________________________________________________________ Incorrect_____________Correct___________________________ SMG$L_PASTEBOARD_ID SMG$L_PBD_ID SMG$L_ARG SMG$L_USER_ARG SMG$B_CHARACTER_______SMG$B_CHAR________________________ V7.1 o In the documentation for the SMG$READ_COMPOSED_LINE routine, the following text should be appended to the description of the flags argument: "The terminal characteristic /LINE_EDITING should be set for your terminal for these flags to work as expected. /LINE_EDITING is the default." o The description of routine SMG$SET_KEYPAD_MODE should contain this note: ________________________ Note ________________________ Changing the keypad mode changes the physical terminal setting. This is a global change for all virtual 5-30 Programming Release Notes Programming Release Notes 5.22 Screen Management (SMG$) Facility keyboards, not just the virtual keyboard specified by the keyboard-id argument. ______________________________________________________ 5.23 String Manipulation (STR$) Facility The following sections contain release notes pertaining to the Screen Management (STR$) facility. 5.23.1 Documentation Changes and Corrections This section describes minor corrections to the STR$ Run- Time Library documentation. 5.23.1.1 OpenVMS RTL String Manipulation (STR$) Manual V7.2 The following errors will be corrected in the OpenVMS RTL String Manipulation (STR$) Manual the next time this manual is updated. o The description of routine STR$FIND_FIRST_IN_SET contains an error in the Arguments section for the set- of-characters argument. The correct description of the set-of-characters argument follows: "Set of characters that STR$FIND_FIRST_IN_SET is searching for in the string. The set-of-characters argument is the address of a descriptor pointing to the set of characters." o The description of routine STR$FREE1_DX has an error and an omission in the Condition Values Returned section. - Delete error STR$_FATINTERR. - Add error STR$_ERRFREDYN, with the following description: "Error freeing dynamic descriptor. LIB$FREE_VM or LIB$FREE_VM_64 failed to free the descriptor." Programming Release Notes 5-31 Programming Release Notes 5.24 System Services 5.24 System Services The following sections contain release notes pertaining to system services. All system services are documented in the OpenVMS System Services Reference Manual. 5.24.1 Changes and Enhancements The following section describes a change related to system services. 5.24.1.1 $PERSONA System Services: Flags Ignored (Alpha Only) V7.2 The $PERSONA_ASSUME and $PERSONA_CREATE system services were provided in previous versions of OpenVMS. These services contained a flags argument that specified which persona services options were employed when the persona was assumed or created. In OpenVMS Version 7.2, these flags are ignored. The flags are ignored in this version of OpenVMS because with per-thread security, the process of impersonation has changed from modifying processwide security structures to modifying individual security profiles within a process. As a result, all the security information within a profile can be modified without affecting jobwide security structures. This eliminates the need for the persona flags to specify selective modification of security structures. Table 5-2 and Table 5-3 show the values for the flags argument that are ignored in OpenVMS Version 7.2. Table_5-2_Ignored_$PERSONA_ASSUME_Flags____________________ Flags_________________Description__________________________ IMP$M_ASSUME_SECURITY Assume access rights, UIC, authorized privileges, user name, and security audit flag. IMP$M_ASSUME_ACCOUNT Assume OpenVMS account. IMP$M_ASSUME_JOB_WIDE Assume the new persona, even in a ______________________multiprocess_job.____________________ 5-32 Programming Release Notes Programming Release Notes 5.24 System Services Table_5-3_Ignored_$PERSONA_CREATE_Flags____________________ Flags_________________Description__________________________ IMP$M_ASSUME_DEFCLASS Create a persona with default ______________________classification.______________________ For more information about the $PERSONA system services, refer to the OpenVMS System Services Reference Manual: GETQUI-Z. 5.24.1.2 $PERSONA System Services: Default Privilege Change (Alpha Only) V7.2 The default behavior in assigning persona privileges has changed in OpenVMS Alpha Version 7.2. Prior to this release, a persona was created with the authorized privileges from the specified user's UAF record as the default privileges. The user's default privileges would be used only if the IMP$V_ASSUME_DEFPRIV flag was set in the call to $PERSONA_CREATE. This default behavour is inconsistent with OpenVMS security policy and has been changed for OpenVMS Alpha Version 7.2. The new default behavior builds the persona with privileges as specified in the user's UAF record. For existing programs to run correctly on OpenVMS Alpha Version 7.2, you may need to modify the user's UAF records so that the default privileges specified are equivilent to authorized privileges. Two new flags have been added to the $PERSONA_CREATE system service. ISS$V_CREATE_DEFPRIV is equivalent to the IMP$V_ ASSUME_DEFPRIV flag of earlier releases and is provided solely for backward compatibility. ISS$V_CREATE_AUTHPRIV is provided to allow the caller to implement the default behavior of earlier versions of OpenVMS; that is, to use the user's authorized privileges as default privileges. The behavior for $PERSONA_CREATE on OpenVMS VAX Version 7.2 remains unchanged. Programming Release Notes 5-33 Programming Release Notes 5.24 System Services 5.24.1.3 $PERSONA System Services: Audit Record Change (Alpha Only) V7.2 The audit record for persona creation has changed from type Server Login to type Persona Created. A persona is created by calling the $PERSONA_CREATE system service. 5.24.2 Problems and Restrictions This section describes problems and restrictions related to system services. 5.24.2.1 Linking SECURESHR Images to Run on Older Versions V7.0 Some additional entry points have been added to the shareable image dispatch vector. Because of this change, any applications linked against Version 7.0 or later of SECURESHR will not run on a pre-Version 7.0 system. System services that use SECURESHR are the following: $FORMAT_ACL $PARSE_ACL $FORMAT_AUDIT $DELETE_INTRUSION $SCAN_INTRUSION $SHOW_INTRUSION $ADD_PROXY $DELETE_PROXY $DISPLAY_PROXY $VERIFY_PROXY If your program uses any of these system services and you want to create a version that runs on systems prior to Version 7.0, you must link your program on a system running a version of OpenVMS prior to Version 7.0. 5.24.2.2 $SUSPND Behaves Incorrectly in a Cluster Environment VAX V6.0 Alpha V1.5 When the $SUSPND system service is called and the target process is on a different cluster node than that of the process calling the $SUSPND service, the kernel mode suspend flag (bit 0) is ignored. As a result, any suspend is treated as a supervisor-mode suspend. 5-34 Programming Release Notes Programming Release Notes 5.24 System Services 5.24.3 Corrections The following section describes a correction to several system services. 5.24.3.1 $PERSONA Restrictions Removed (Alpha Only) V7.2 Previous versions of OpenVMS contained restrictions on the use of the $PERSONA system services ($PERSONA_ASSUME, $PERSONA_CREATE, and $PERSONA_DELETE). With OpenVMS Version 7.2, these restrictions have been removed. o I/O can now be in progress when you switch personae (using $PERSONA_ASSUME). o You can now safely use personae in a multiprocess job tree. Previously the $PERSONA services modified the Job Information Block (JIB), which is shared by all processes in the job tree. In OpenVMS Version 7.2, the user name and account cells are moved from the JIB to the Persona Block (PSB). o Interaction between a thread manager (for example, the thread manager incorporated within DECthreads) and the security subsystem enables the automatic switching of profiles as threads are scheduled for execution. For more information about per-thread security, see the OpenVMS Guide to System Security; for details on the $PERSONA system services, refer to the OpenVMS System Services Reference Manual. 5.25 X/Open Transport Interface (XTI) The notes in this section describe the X/Open Transport Interface (XTI). 5.25.1 Changes and Enhancements OpenVMS Version 6.2 and later supports the X/Open Transport Interface (XTI) programming interface. The implementation conforms with the XPG4 X/Open CAE XO/CAE /91/600 (ISBN 1 872630 29 4) X/Open Transport Interface (XTI) specification. Programming Release Notes 5-35 Programming Release Notes 5.25 X/Open Transport Interface (XTI) Supported Transports OpenVMS Version 7.1 and later supports the DECnet for OpenVMS (Phase IV), DECnet-Plus for OpenVMS (Phase V), and TCP/IP Services transports. See Section 5.25.2 for support restrictions. The transport names used in the t_open routine are 'dnet' for DECnet and either 'ip/udp' or 'ip/tcp' for TCP/IP. Other transports are available with other networking layered products. Consult individual layered product documentation for information about OpenVMS XTI support. Architecture XTI is supported by frontend and backend code. Frontend code provides access to the standard interface routines. Backend code provides the interface from the frontend code to the selected networking transport. The supporting image files are as follows: XTI frontend code SYS$SHARE:XTI$XTILIB.EXE TCP/IP XTI backend code SYS$SHARE:XTI$IPSHR.EXE DECnet XTI backend code SYS$SHARE:XTI$DNETSHR.EXE XTI C programming include SYS$LIBRARY:XTI.H file Linking Requirements After compiling an XTI program, no additional qualifiers are required for linking with XTI. Documentation Documentation about XTI is not included in the OpenVMS documentation set. You can order documentation directly from X/Open Company Limited. If you have access to the Internet, you can get more information about X/Open Company Limited (including their publications) by browsing the following URL: http://www.xopen.co.uk/ You can also contact X/Open Company Limited at the following locations: o USA: East Coast 5-36 Programming Release Notes Programming Release Notes 5.25 X/Open Transport Interface (XTI) X/Open Company Limited 3141 Fairview Park Drive Falls Church VA 22042-4501 U.S.A. Tel: +1 (703) 876 0044 Fax: +1 (703) 876 0050 o USA: West Coast X/Open Company Limited 1010 El Camino Real Suite 380 Menlo Park, CA 94025 U.S.A. Tel: +1 (415) 323 7992 Fax: +1 (415) 323 8204 o United Kingdom: X/Open Company Limited Apex Plaza Forbury Road Reading Berks RG1 1AX U.K. Tel: +44 1734 508311 Fax: +44 1734 500110 o Japan: X/Open Company Limited Karufuru-Kanda Bldg, 9F 1-2-1 Kanda Suda-cho Chiyoda-Ku Tokyo 101 Japan Tel: +81 3 3251 8321 Fax: +81 3 3251 8376 Programming Release Notes 5-37 Programming Release Notes 5.25 X/Open Transport Interface (XTI) 5.25.2 Problems and Restrictions V6.2 The following restrictions apply to XTI on OpenVMS systems: o Nonblocking I/O is unsupported for DECnet for OpenVMS. DECnet for OpenVMS (Phase IV) does not fit the model for nonblocking I/O. Attempts to open or switch an XTI file descriptor to nonblocking I/O (O_NONBLOCK) will fail. o Connectionless I/O is unsupported for DECnet for OpenVMS. DECnet for OpenVMS (Phase IV) does not fit the model of connectionless I/O. Therefore, only connection-oriented connections are supported. o Disabled ASTs cause problems. The XTI backend code uses ASTs for asynchronous delivery of events from the transports. If ASTs are disabled (sys$setast(0)), the XTI backend code will not operate correctly until the ASTs are enabled again. o XTI file descriptors are not compatible with C Run-Time Library file descriptors. In addition, the 't_info' structure returned from the t_open function reports any additional implementation- specific restrictions for the given transport. (See the XTI documentation for information about the t_open command.) 5-38 Programming Release Notes 6 _________________________________________________________________ Device Support on OpenVMS Systems This chapter contains release notes pertaining to OpenVMS device support on Alpha and VAX systems. Where appropriate, section headings indicate whether specific notes contain Alpha-specific or VAX-specific information. 6.1 Recompiling and Relinking OpenVMS Device Drivers The following sections contain release notes pertaining to recompiling and relinking OpenVMS device drivers. 6.1.1 Possible Per-Threads Security Impacts on Alpha Device Drivers V7.2 Refer to Section 5.19.2.1 for information about possible per-thread security impacts on OpenVMS Alpha device drivers. 6.1.2 Alpha and VAX SCSI Device Drivers V7.2 All OpenVMS Alpha SCSI device drivers from previous versions of OpenVMS must be recompiled and relinked to run correctly on OpenVMS Version 7.2. You must recompile and relink these drivers because OpenVMS Version 7.2 includes significant changes to SCSI data structures. These changes are needed in preparation for support of Fibre Channel as a SCSI interconnect. No source changes are required by these data structure changes. If you have an OpenVMS Alpha SCSI driver that you are upgrading from a version prior to OpenVMS Alpha 7.0, see Section 6.1.3. Device Support on OpenVMS Systems 6-1 Device Support on OpenVMS Systems 6.1 Recompiling and Relinking OpenVMS Device Drivers Note that for OpenVMS Version 7.1 all OpenVMS Alpha and 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.2. 6.1.3 OpenVMS Alpha Device Drivers V7.1 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 later. (Note that Alpha SCSI drivers, however, must be recompiled and relinked as described in Section 6.1.2.) 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 later. 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 might also require source-code changes to run correctly on OpenVMS Alpha Version 7.0 and later. For more details about OpenVMS Alpha Version 7.0 changes that may require source changes to customer-written drivers, see the OpenVMS Alpha Guide to Upgrading Privileged-Code Applications. 6.2 Restriction: Parallel SCSI Support for Logical Unit Numbers V7.2 OpenVMS supports up to eight Logical Unit Numbers (LUNs) LUNs per target ID on a parallel SCSI bus. The SCSI-2 standard is limited to eight LUNs, but the SCSI- 3 standard recently increased to 64 LUNs. The HSZ80 is the only supported device that implements more than eight LUNs (it supports 32 LUNs per target ID). This feature cannot be used in the current release of OpenVMS. LUN values on OpenVMS must be in the range 0-7. 6-2 Device Support on OpenVMS Systems Device Support on OpenVMS Systems 6.2 Restriction: Parallel SCSI Support for Logical Unit Numbers This restriction may be removed in a future release of the operating system. This restriction does not apply to Fibre Channel. 6.3 Selective Autoconfiguration Unsupported in Some SCSI Configurations V7.2 OpenVMS Alpha provides SYSMAN commands that allow system managers to specify which devices will be autoconfigured. This can be specified permanently, so that it is applied at each system boot or for the duration of a manual autoconfiguration command, using the following qualifiers: SYSMAN> IO SET/EXCLUDE=(device_name) SYSMAN> IO AUTOCONFIGURE/EXCLUDE=(device_name) and/or /SELECT=(device_name) These commands cannot be used selectively to autoconfigure SCSI device names that include a port allocation class or device names that have an HSZ allocation class. The commands also cannot be used for Fibre Channel devices. This restriction applies to class-driver devices only (DK, MK, DG). Selective autoconfiguration can be used for all SCSI and Fibre Channel port-driver devices (PK, PG, and FG). This restriction also applies to OpenVMS Version 7.1 systems that use port allocation classes. 6.4 Changed Behavior of IO$_SKIPFILE Function V7.2 The performance of the IO$_SKIPFILE function was significantly improved in OpenVMS Version 7.1 for certain SCSI tape drives. The new IO$_SKIPFILE implementation functions correctly with all built-in OpenVMS tape functions such as INIT, MOUNT, BACKUP, and COPY when tapes are formatted according to the ANSI Standard X3.27-1987. This is the default tape standard for OpenVMS. Higher performance for the IO$_SKIPFILE function is requested with the modifier (IO$M_ALLOWFAST). When the IO$M_ALLOWFAST modifier is used, IO$_SKIPFILE stops at the end of data rather than at double filemarks. For more Device Support on OpenVMS Systems 6-3 Device Support on OpenVMS Systems 6.4 Changed Behavior of IO$_SKIPFILE Function information about the IO$M_ALLOWFAST modifier, refer to the OpenVMS I/O User's Reference Manual. In OpenVMS Version 7.2, SKIPFILE support is implemented through a standard DCL interface, making the old SYS$ETC:MKSET.TXT and SYS$ETC:MKSET.EXE files obsolete. Refer to the OpenVMS I/O User's Reference Manual for details about using the DCL interface. 6.5 CRCTX Routines Enhanced (Alpha Only) V7.1-2 The system routines that can be used 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: o IOC$DEALLOC_CRCTX o IOC$ALLOC_CNT_RES o IOC$DEALLOC_CNT_RES o 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 crash. 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 crash. 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 crash. IOC$DEALLOC_ CNT_RES clears the valid bit before it returns. 6-4 Device Support on OpenVMS Systems Device Support on OpenVMS Systems 6.5 CRCTX Routines Enhanced (Alpha Only) 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 crash. 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.6 New Values for Length Parameter in System Routines (Alpha Only) V7.1-2 The following system routines called by OpenVMS Alpha device drivers have new values for the length parameter: IOC$READ_PCI_CONFIG IOC$WRITE_PCI_CONFIG IOC$READ_IO IOC$WRITE_IO The two new length values (IOC$K_BYTE and IOC$K_WORD) allow byte and word data to be passed in right-aligned fashion. Table 6-1 shows the accepted values for the length parameter. Table_6-1_Values_for_Length_Parameter______________________ Value (hex)_______Keyword________________________________________ 1 IOC$K_BYTE_LANED 2 IOC$K_WORD_LANED 4 IOC$K_LONGWORD 8 IOC$K_QUADWORD 100 IOC$K_BYTE 200_________IOC$K_WORD_____________________________________ IOC$K_BYTE_LANED and IOC$K_WORD_LANED lane bytes in the following way: Device Support on OpenVMS Systems 6-5 Device Support on OpenVMS Systems 6.6 New Values for Length Parameter in System Routines (Alpha Only) IOC$K_BYTE_LANED (1) byte-laned byte Depending on bits <1:0> of the address, the byte resides in a longword in one of the following lanes: +---+---+---+---+ | | | | X | bits <1:0> = 0 +---+---+---+---+ +---+---+---+---+ | | | X | | bits <1:0> = 1 +---+---+---+---+ +---+---+---+---+ | | X | | | bits <1:0> = 2 +---+---+---+---+ +---+---+---+---+ | X | | | | bits <1:0> = 3 +---+---+---+---+ The driver must use the low 2 bits of the address to select the correct byte. IOC$K_WORD_LANED (2) byte-laned word Depending on bits <1:0> of the address, the word resides in a longword in one of the following locations. +---+---+---+---+ | | | XXXXX | bits <1:0> = 0 +---+---+---+---+ +---+---+---+---+ | | XXXXX | | bits <1:0> = 1 +---+---+---+---+ +---+---+---+---+ | XXXXX | | | bits <1:0> = 2 +---+---+---+---+ The driver must use the low 2 bits of the address to select the correct word. However, if IOC$K_BYTE and IOC$K_WORD are used, the data is always right-aligned: 6-6 Device Support on OpenVMS Systems Device Support on OpenVMS Systems 6.6 New Values for Length Parameter in System Routines (Alpha Only) IOC$K_BYTE (hex 100) right-aligned byte The byte is always in the right-most lane: +---+---+---+---+ | | | | X | bits <1:0> = 0,1,2,3 +---+---+---+---+ Note that the high-order byte contains unpredictable data and must be masked to operate correctly. IOC$K_WORD (hex 200) right-aligned word The word is always in the right-most lane: +---+---+---+---+ | | | XXXXX | bits <1:0> = 0,1,2 +---+---+---+---+ Note that the high-order word contains unpredictable data and must be masked to operate correctly. By using the new values for the length parameter, programmers who write device drivers no longer have to put data into the correct lanes before writes and after reads. 6.7 Memory Barriers Required in Drivers for DMA (Alpha Only) V7.1-2 The two ways that the architecture of 21264 processors improves performance is by executing instructions out of order and by executing code sequences ahead of the actual location of the code. This can affect any interprocess communications, including communications with DMA devices. Code that executed successfully on previous hardware implementations might fail on 21264 processors and on future Alpha processors. The Alpha Architecture Reference Manual, Third Edition describes rules for communicating using shared memory between CPUs and devices. The rules have not changed for 21264 processors, but the possibility for ordering problems has increased. Device Support on OpenVMS Systems 6-7 Device Support on OpenVMS Systems 6.7 Memory Barriers Required in Drivers for DMA (Alpha Only) The problem exists primarily in device drivers that perform DMA reads when both of the following conditions occur: o If the data for the read is seen as available when a flag from the device is set o If the driver loops when looking for more data For example: Device: Write DATA Logical MB (logical memory barrier) Write FLAG (perhaps memory queue pointer, memory location, or CSR bit) Driver: Read FLAG If FLAG, Read/Use DATA else exit Interrupt Service Routine Loop to Read flag In this example, the LOGICAL MB in the device may actually be a CSR read from the device. The problem in the driver is that a memory barrier instruction must exist in the code between the read of the flag and the use of the data. This has always been the case in interprocessor communications, but it may have been omitted by drivers that communicate with devices. In previous releases, the driver probably would not have seen old DATA after seeing the flag due to the ordering rules for PCI and cache coherency. With 21264 processors, speculative execution may have progressed past the Read FLAG and speculatively prefetched the DATA, while waiting for the FLAG to be loaded. If there was no explicit dependency between the DATA and the FLAG and if the FLAG was found to be set, then the potentially older DATA that was prefetched may be used. Decisions may have been already made based on the presumed contents. A memory barrier between the read of the FLAG and the Read /Use of the DATA places an explicit barrier to speculation. Such a barrier also forces the ordering of the FLAG and DATA. 6-8 Device Support on OpenVMS Systems Device Support on OpenVMS Systems 6.7 Memory Barriers Required in Drivers for DMA (Alpha Only) ________________________ Note ________________________ Using LOCK/DEVICELOCK will not ensure that a memory barrier is placed in the code. In addition, a memory barrier in a subroutine call between the Read FLAG and the Read/Use of the DATA will not prevent speculation. The memory barrier must be in line. The same issue can occur (but probably less frequently) in sending data to a device that uses shared memory. In this case, the code must place a memory barrier between the writing of the DATA and the writing of the FLAG. This rule is a requirement for correct ordering in device drivers that communicate with devices through shared memory. ______________________________________________________ 6.8 ISA_CONFIG.DAT Unsupported in Future Release (Alpha Only) 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 using the new file-based autoconfiguration method for loading device drivers (as described in Writing OpenVMS Alpha Device Drivers in C). 6.9 Required Change in ISA_CONFIG.DAT on AlphaStation 200/400 V7.1 Customers configuring ISA devices on AlphaStation 200/400 Family systems must change their SYS$MANAGER:ISA_CONFIG.DAT file, so that the node information for each device appears at the end of each device description block. _______________________ Warning _______________________ For upgrades from OpenVMS Version 6.2 or 7.0 systems, this change must be made before starting the upgrade procedure. ______________________________________________________ Device Support on OpenVMS Systems 6-9 Device Support on OpenVMS Systems 6.9 Required Change in ISA_CONFIG.DAT on AlphaStation 200/400 For example, prior to OpenVMS Version 7.1, the following device description block: [AUA0] NAME=AU NODE=3 DRIVER=SYS$MSBDRIVER IRQ=9 DMA=(0,1) PORT=(388:4,530:8) would be changed as follows: [AUA0] NAME=AU DRIVER=SYS$MSBDRIVER IRQ=9 DMA=(0,1) PORT=(388:4,530:8) NODE=3 Customers using SYS$MANAGER:ISA_CONFIG.DAT files should read Section 6.8. 6.10 Naming Serial Line Devices on Alpha Systems V7.1 OpenVMS has changed the way it handles the second serial port on the following Alpha systems: o AlphaStation 200, 400, 500, and 600 families o AlphaServer 1000, 2000, 2100, and 4100 families If one of these systems is booted with the console environment variable set to graphics, the name of the serial line (COM1) will be different from that in previous releases. The COM1 device is called TTB0 instead of OPA1. In this case, the COM1 device is controlled by SYS$YSDRIVER instead of SYS$OPDRIVER. If the console is set to serial, the COM1 device is called OPA0. 6-10 Device Support on OpenVMS Systems Device Support on OpenVMS Systems 6.11 Memory Holes on AlphaServer 4100 Systems 6.11 Memory Holes on AlphaServer 4100 Systems V7.1 Physical memory holes might exist on AlphaServer 4100 systems. As illustrated in Figure 6-1, there are three different sizes of memory daughter card pairs: 512 MB, 256 MB, and 128 MB. In accordance with AlphaServer 4100 systems configuration rules, memory card pairs must be arranged in descending order of size. The AlphaServer 4100 hardware reads the first set of memory daughter cards and assumes that any memory card pairs that follow are the same size. Memory holes occur because memory card pairs following the first set of cards read by the hardware might not be the same size. As shown in Figure 6-1, the hole at 3000.0000 must be dealt with by OpenVMS. The hole at 4800.0000 is at the top of the address space and can be ignored by OpenVMS. ________________________ Note ________________________ Previous versions of OpenVMS Alpha did not efficiently support systems with physical memory holes and ultimately led to an inefficient use of system memory. The memory management data structures in OpenVMS Alpha Version 7.1 and later have been slightly modified to recognize the memory holes. As a result, inefficiencies in previous versions of the OpenVMS Alpha operating system have been eliminated. ______________________________________________________ Note that this configuration impacts the algorithm used to determine whether a driver needs to use map registers. In releases prior to OpenVMS Alpha Version 7.1, device drivers do the following: 1. Call IOC$NODE_DATA with key IOC$K_DIRECT_DMA_SIZE to obtain the size of the direct DMA window (in megabytes). This is usually 1 GB. 2. Convert the size returned from IOC$NODE_DATA to pages and compare the size with mmg$gl_memsize, which contains the number of pages in physical memory. Device Support on OpenVMS Systems 6-11 Device Support on OpenVMS Systems 6.11 Memory Holes on AlphaServer 4100 Systems 3. If mmg$gl_memsize is greater than the size returned from IOC$NODE_DATA, use map registers; otherwise, use the direct DMA window. The mmg$gl_memsize global cell does not contain the memory hole. As a result, the system has only 7/8 GB of memory, but according to the algorithm in releases prior to OpenVMS Alpha Version 7.1, it appears that the device can use the direct DMA window. Yet there is 128 MB of memory beyond the 1 GB border, which requires that the drivers use map registers. To eliminate this problem, drivers using the algorithm in releases prior to OpenVMS Alpha Version 7.1 must substitute it with the following algorithm: 1. Call IOC$NODE_DATA with key IOC$K_DIRECT_DMA_SIZE to obtain the size of the direct DMA window (in megabytes). This is usually 1 GB. 2. Convert the size returned from IOC$NODE_DATA to pages by dividing the number of bytes by the contents of mmg$gl_ page_size. For example: int dma_size; int pages; status = IOC$NODE_DATA (crb, IOC$K_DIRECT_DMA_SIZE, &dma_size); /* dma_size contains the number of megabytes. * convert number of megabytes to bytes. */ dma_size = dma_size * (1024 * 1024); /* Convert number of bytes to number of pages by * dividing by number of bytes per page. */ pages = dma_size / MMG$GL_PAGE_SIZE; 3. Compare the resulting number of pages with mmg$gl_maxpfn + 1. 4. If mmg$gl_maxpfn + 1 is greater than the size returned from IOC$NODE_DATA, use map registers; otherwise use the direct DMA window. 6-12 Device Support on OpenVMS Systems Device Support on OpenVMS Systems 6.12 SYS$MSBDRIVER Removed from OpenVMS Alpha Distribution 6.12 SYS$MSBDRIVER Removed from OpenVMS Alpha Distribution V7.0 The driver for the Microsoft Windows Sound System ISA sound card (MSB), SYS$MSBDRIVER, has been removed from the OpenVMS Alpha distribution as of Version 7.0. The following files have been removed: o SYS$LOADABLE_IMAGES:SYS$MSBDRIVER.EXE o SYS$EXAMPLES:SOUND_SERVICES.C o SYS$EXAMPLES:SOUND_SAMPLE.C o SYS$EXAMPLES:SOUND_SAMPLE.SND o SYS$LIBRARY:SYS$STARLET_C.TLB module MSB.H An enhanced version of this driver, called MMOV$MSBDRIVER, is included in Multimedia Services Version 2.0 for OpenVMS Alpha. This layered product also includes support for video capture and playback, an enhanced version of DECsound, and other audio and video applications. MMOV$MSBDRIVER provides the same $QIO programming interface as SYS$MSBDRIVER. Compaq recommends that the WAVE Applications Programming Interface provided by Multimedia Services for OpenVMS be used instead because it is more flexible and is portable to other platforms. (Multimedia Services Version 2.0 for OpenVMS is described in SPD 64.24.00.) 6.13 Device IPL Setup for OpenVMS Alpha Drivers V6.2 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. Device Support on OpenVMS Systems 6-13 Device Support on OpenVMS Systems 6.13 Device IPL Setup for OpenVMS Alpha Drivers 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. 6.14 AlphaStation 255: PCI Configuration Restriction V7.1 The OpenVMS Alpha operating system does not support PCI option cards configured in PCI slot 0 on any AlphaStation 255 series systems. PCI slot 0 is the lowest physical PCI option slot on AlphaStation 255 series systems. The interrupt signal for this slot is shared with the built-in Ethernet port. Because the OpenVMS Alpha operating system does not currently permit PCI devices to share an interrupt line, a PCI device installed in slot 0 will not function correctly or might cause errors to occur with the built-in Ethernet port. As a result of this restriction, AlphaStation 255 series systems support a maximum of two PCI option cards, configured in slot 1 and slot 2. 6.15 Recommendation for RZ25M and RZ26N Disk Drives (Alpha) V7.1 During the testing of Compaq 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, these drives are not recommended for use 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, listed as supported in the OpenVMS SPD, may be used in configurations to the full bus lengths of the SCSI-2 specification. 6-14 Device Support on OpenVMS Systems Device Support on OpenVMS Systems 6.16 SCSI Controller Restriction on AlphaServer 2100 Systems 6.16 SCSI Controller Restriction on AlphaServer 2100 Systems V6.2 The Adaptec 1740/1742 SCSI controller (PB2HA-SA) is not supported on AlphaServer 2100 systems having more than 1 gigabyte (GB) of memory. If the controller is connected to such a system, the following message appears on the operator's console: %PKJDRVR-E- PKX0, Port is going OFFLINE. 6.17 OpenVMS Alpha SCSI Firmware Support The following sections relate to SCSI firmware support. 6.17.1 Recommended Firmware Support for RZ26N and RZ28M Disks V6.2-1H3 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 may occur. 6.17.2 Required Firmware for Multihost Use of RZ26L and RZ28 Disks V6.2 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 can be used 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. ___________________ Important Note ___________________ Only certain RZ26L and RZ28 firmware revisions can be safely upgraded to firmware revision level 442. Refer Device Support on OpenVMS Systems 6-15 Device Support on OpenVMS Systems 6.17 OpenVMS Alpha SCSI Firmware Support to Section 6.17.2.1 to determine if your disks are capable of being upgraded to firmware revision level 442. If your disk is capable of supporting firmware revision level 442, use the RZTOOLS Utility that is described in Section 6.17.2.2 to update the disk's firmware. ______________________________________________________ 6.17.2.1 Firmware Revision Level 442 Requirements Only the combinations of disk drives and firmware revision levels listed in Table 6-2 are capable of being upgraded safely to firmware revision level 442. Performing the update procedure on any other combination can permanently damage the disk. Table_6-2_Revision_Level_442_Firmware_Compatibility________ Disk Drive_____Firmware_Revision___Disk_File_Name_______________ RZ26L 440C RZ26L_442D_DEC.FUP RZ28 441C or D41C RZ28_442D_DEC2104.FUP __________435_or_436__________RZ28P4_442C_DEC.FUP__________ 6.17.2.2 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-2 for the file name of the disk you are upgrading.) $ MCR SYS$ETC:RZTOOLS_ALPHA DKB500 /LOAD=SYS$ETC:filename.FUP Read in 262144 bytes. Current FW version - X440C Upgrading to - DEC0 Loading code ...... New code has been sent to the drive. 6.18 OpenVMS Alpha SCSI Port and Class Drivers V6.2 The following sections describe OpenVMS Alpha SCSI class and port device driver restrictions. 6-16 Device Support on OpenVMS Systems Device Support on OpenVMS Systems 6.18 OpenVMS Alpha SCSI Port and Class Drivers 6.18.1 Add-On SCSI Adapters V6.2 Version 6.2 and later of OpenVMS Alpha supports various add-on SCSI adapters. Compaq's AlphaGeneration platforms typically support one or more integral SCSI adapters, with the option of installing additional add-on SCSI adapters. Due to differences in device-naming conventions used between the Alpha console and OpenVMS, the OpenVMS device name may not match the name displayed by the console. For example, the console designation for a SCSI device on the integral SCSI adapter may be DKA100. However, when two additional add-on SCSI adapters are added, the "A" designation becomes "C"; and DKA100 appears as DKC100 when OpenVMS is running. Note that although the console and OpenVMS device names may be different, the unique specification of a device name from the console to the device name under OpenVMS stays consistent, provided add-on SCSI adapters are not added or removed. 6.18.2 SCSI Disk I/O Performance Degradation for KZMSA XMI and Adaptec 1742A Adapters V6.2 As a result of the SCSI-2 Tagged Command Queuing (TCQ) support in OpenVMS Alpha Version 6.2, Compaq has determined that customers with KZMSA XMI to SCSI and Adaptec 1742A adapters might experience a 20% SCSI disk I/O performance degradation because TCQ is not implemented for these adapters. The performance degradation is in the area of increased CPU cost per I/O. Customers running at less than maximum CPU utilization under OpenVMS Alpha Version 6.1 might not experience any degradation under OpenVMS Alpha Version 6.2. Compaq does not expect this situation to significantly affect DEC 7000 customers planning to upgrade to DEC 8000 Family systems using KZMSA adapters because the speed of those processors should offset the performance degradation. However, DEC 7000 customers who upgrade to OpenVMS Alpha Version 6.2 will experience the SCSI I/O disk performance degradation. Device Support on OpenVMS Systems 6-17 Device Support on OpenVMS Systems 6.18 OpenVMS Alpha SCSI Port and Class Drivers Compaq expects that this will significantly affect existing DEC 2000 Model 300 systems customers that use the Adaptec 1742A SCSI adapter. 6.19 OpenVMS Alpha Device Support Documentation As of OpenVMS Version 7.2, the Writing OpenVMS Alpha Device Drivers in C manual no longer ships with the OpenVMS documentation set. 6-18 Device Support on OpenVMS Systems 7 _________________________________________________________________ Using Interlocked Memory Instructions (Alpha Only) The Alpha Architecture Reference Manual, Third Edition (AARM) describes strict rules for using interlocked memory instructions. The new 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 new 21264 processor. 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 DEC 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. 7.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. Using Interlocked Memory Instructions (Alpha Only) 7-1 Using Interlocked Memory Instructions (Alpha Only) 7.1 Required Code Checks The SRM_CHECK tool (named after the System Reference Manual, which defines the Alpha architecture) has been developed to analyze Alpha executables for noncompliant code sequences. The tool detects sequences that might fail, reports any errors, and displays the machine code of the failing sequence. 7.2 Using the Code Analysis Tool The SRM_CHECK tool can be found in the following location on the OpenVMS Alpha Version 7.2 Operating System CD-ROM: 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. The -output qualifier can be used 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 The output from the tool can be used 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: 7-2 Using Interlocked Memory Instructions (Alpha Only) Using Interlocked Memory Instructions (Alpha Only) 7.2 Using the Code Analysis Tool ** 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, it would be necessary 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. Using Interlocked Memory Instructions (Alpha Only) 7-3 Using Interlocked Memory Instructions (Alpha Only) 7.3 Characteristics of Noncompliant Code 7.3 Characteristics of Noncompliant Code 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 7.5 for information about compiler versions. o Some versions of OpenVMS compilers introduce noncompliant code sequences during an optimization called "loop rotation." This problem can only be triggered 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. o Some code compiled with very old BLISS, MACRO-32, or DEC Pascal 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. o 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. o 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, the image should be recompiled with the appropriate compiler (see Section 7.5). After recompiling, the image should be analyzed again. If violations remain after recompiling, the source code must be examined to determine why the code scheduling violation exists. Modifications should then be made to the source code. 7-4 Using Interlocked Memory Instructions (Alpha Only) Using Interlocked Memory Instructions (Alpha Only) 7.4 Coding Requirements 7.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. In this edition, Section 5.5, "Data Sharing", and Section 4.2.4, which describes the LDx_ L instructions, detail the conventions of the interlocked memory sequence. Exceptions to the following two requirements are the source of all known noncompliant code: o 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. o 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: o Any memory operation (LDx/STx) between an LDx_L and an STx_C. o Any branch that has a destination between an LDx_L and an STx_C. o 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 Using Interlocked Memory Instructions (Alpha Only) 7-5 Using Interlocked Memory Instructions (Alpha Only) 7.4 Coding Requirements condition is found only on early Alpha systems and not on PCI based systems. o 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 7.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. ________________________ Note ________________________ This branch backward from the LDx_L to the STx_C is characteristic of the noncompliant code introduced by the "loop rotation" optimization. ______________________________________________________ 7-6 Using Interlocked Memory Instructions (Alpha Only) Using Interlocked Memory Instructions (Alpha Only) 7.4 Coding Requirements 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. 7.5 Compiler Versions This section contains information about versions of compilers that may generate noncompliant code sequences and the recommended versions to use when recompiling. Table 7-1 contains information for OpenVMS compilers. Using Interlocked Memory Instructions (Alpha Only) 7-7 Using Interlocked Memory Instructions (Alpha Only) 7.5 Compiler Versions Table_7-1_OpenVMS_Compilers________________________________ Old_Version___________Recommended_Minimum_Version__________ BLISS V1.1 BLISS V1.3 DEC C V5.x DEC C V6.0 DEC C++ V5.x DEC C++ V6.0 DEC Pascal V5.0-2 DEC Pascal V5.1-11 MACRO-32 V3.0 V3.1 for OpenVMS Version 7.1-2 V4.1 for OpenVMS Version 7.2 MACRO-64_V1.2_________See_below.___________________________ Current versions of the MACRO-64 assembler may still encounter the loop rotation issue. However, MACRO-64 does not perform code optimization by default, and this problem occurs only when optimization is enabled. If SRM_CHECK indicates a noncompliant sequence in the MACRO-64 code, it should first be recompiled without optimization. If the sequence is still flagged when retested, the source code itself contains a noncompliant sequence that must be corrected. 7.6 Interlocked Memory Sequence Checking for the MACRO-32 Compiler The MACRO-32 Compiler for OpenVMS Alpha Version 4.1 now performs additional code checking and displays warning messages for noncompliant code sequences. The following warning messages can display under the circumstances described: BRNDIRLOC, branch directive ignored in locked memory sequence Explanation: The compiler found a .BRANCH_LIKELY directive within an LDx_L/STx_C sequence. User Action: None. The compiler will ignore the .BRANCH_ LIKELY directive and, unless other coding guidelines are violated, the code will work as written. 7-8 Using Interlocked Memory Instructions (Alpha Only) Using Interlocked Memory Instructions (Alpha Only) 7.6 Interlocked Memory Sequence Checking for the MACRO-32 Compiler BRNTRGLOC, branch target within locked memory sequence in routine 'routine_name' Explanation: A branch instruction has a target that is within an LDx_L/STx_C sequence. User Action: To avoid this warning, rewrite the source code to avoid branches within or into LDx_L/STx_C sequences. Branches out of interlocked sequences are valid and are not flagged. MEMACCLOC, memory access within locked memory sequence in routine 'routine_name' Explanation: A memory read or write occurs within an LDx_ L/STx_C sequence. This can be either an explicit reference in the source code, such as "MOVL data, R0", or an implicit reference to memory. For example, fetching the address of a data label (e.g., "MOVAB label, R0") is accomplished by a read from the linkage section, the data area that is used to resolve external references. User Action: To avoid this warning, move all memory accesses outside the LDx_L/STx_C sequence. RETFOLLOC, RET/RSB follows LDx_L instruction Explanation: The compiler found a RET or RSB instruction after an LDx_L instruction and before finding an STx_C instruction. This indicates an ill-formed lock sequence. User Action: Change the code so that the RET or RSB instruction does not fall between the LDx_L instruction and the STx_C instruction. RTNCALLOC, routine call within locked memory sequence in routine 'routine_name' Explanation: A routine call occurs within an LDx_L/STx_C sequence. This can be either an explicit CALL/JSB in the source code, such as "JSB subroutine", or an implicit call that occurs as a result of another instruction. For example, some instructions such as MOVC and EDIV generate calls to run-time libraries. User Action: To avoid this warning, move the routine call or the instruction that generates it, as indicated by the compiler, outside the LDx_L/STx_C sequence. Using Interlocked Memory Instructions (Alpha Only) 7-9 Using Interlocked Memory Instructions (Alpha Only) 7.6 Interlocked Memory Sequence Checking for the MACRO-32 Compiler STCMUSFOL, STx_C instruction must follow LDx_L instruction Explanation: The compiler found an STx_C instruction before finding an LDx_L instruction. This indicates an ill-formed lock sequence. User Action: Change the code so that the STx_C instruction follows the LDx_L instruction. 7.7 Recompiling Code with ALONONPAGED_INLINE or LAL_REMOVE_FIRST Macros Any MACRO-32 code on OpenVMS Alpha that invokes either the ALONONPAGED_INLINE or the LAL_REMOVE_FIRST macros from the SYS$LIBRARY:LIB.MLB macro library must be recompiled on OpenVMS Version 7.2 to obtain a correct version of these macros. The change to these macros corrects a potential synchronization problem that is more likely to be encountered on the new Alpha 21264 (EV6) processors. ________________________ Note ________________________ Source modules that call the EXE$ALONONPAGED routine (or any of its variants) do not need to be recompiled. These modules transparently use the correct version of the routine that is included in this release. ______________________________________________________ 7-10 Using Interlocked Memory Instructions (Alpha Only) A _________________________________________________________________ Product Retirement Notices This appendix contains notifications about OpenVMS products that are no longer supported as of this release or that are slated for retirement. It also lists manuals that have been archived with this release. Freeware Once a product is retired, Compaq does not accept or act on CLDs posted against the product. However, for those interested in doing their own development and support, the source code for many former products is available as freeware from the following sources: o On the freeware CD-ROM that ships with the OpenVMS operating system The freeware CD-ROM also includes internal tools such as SDL, NMAIL, MAILWATCH, and popular Internet programs. o On the World Wide Web at the following URL: http://www.openvms.digital.com/openvms/freeware/index.html A.1 Adobe Display PostScript Not Supported in DECwindows Motif for OpenVMS V7.2 As of August 1, 1998, Compaq Computer Corporation no longer supports the Adobe Display PostScript software. This change results from Adobe Systems Incorporated discontinuing support for Display PostScript. However, for customer convenience, Compaq will continue to ship Display PostScript software "as is" in the DECwindows Motif for OpenVMS kit. Compaq disclaims all warranties regarding this software, including all implied warranties of merchantability and fitness. Product Retirement Notices A-1 Product Retirement Notices A.1 Adobe Display PostScript Not Supported in DECwindows Motif for OpenVMS Compaq Computer Corporation remains committed to the quality and support of the DECwindows Motif for OpenVMS product and to the protection of its customers' investment in this product and technology. A.2 DECthreads: POSIX 1003.4a Draft 4 Interface To Be Retired V7.0 The POSIX 1003.4a, Draft 4 (or "d4") interface of 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 DECthreads. 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.3 ISA_CONFIG.DAT Unsupported in Future Release (Alpha Only) 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.4 PATHWORKS for OpenVMS (NetWare) PATHWORKS for OpenVMS (NetWare) was retired in July 1998. This product still ships with PATHWORKS for OpenVMS Version 6.0A, but it is not available on PATHWORKS for OpenVMS Version 6.0B or on OpenVMS Version 7.2. A.5 POLYCENTER Software Installation Utility: DECwindows Motif Interface Retired V7.2 The DECwindows Motif interface for the POLYCENTER Software Installation utility has been retired. All functions of the POLYCENTER Software Installation utility are still available from the DCL interface using the PRODUCT command. A-2 Product Retirement Notices Product Retirement Notices A.6 POSIX for OpenVMS Retirement A.6 POSIX for OpenVMS Retirement V7.2 POSIX for OpenVMS was retired in January 1998. However, service continues for the POSIX for OpenVMS product, and it will continue to ship on the Software Product Library distribution (CONDIST) through June 1999. A.7 Spiralog File System Retired V7.2 Spiralog has been retired and does not work with OpenVMS Version 7.2. _______________________ Warning _______________________ If Spiralog is installed on your system, you must deinstall it before upgrading to OpenVMS Version 7.2. ______________________________________________________ A.8 Spyglass Enhanced Mosaic Not Supported on DECwindows Motif V1.2-5 V7.2 Starting with DECwindows Motif Version 1.2-5 for OpenVMS, which ships withOpenVMS Version 7.2, Compaq Computer Corporation no longer supports Spyglass Enhanced Mosaic on the DECwindows Motif for OpenVMS product. Spyglass Enhanced Mosaic used to be included with DECwindows Motif Version 1.2-3 and 1.2-4. Compaq advises customers to replace Spyglass Enhanced Mosaic with the Netscape Navigator web browser. Netscape Navigator is a state-of-the-art web browser that you can download from the following location: http://www.openvms.digital.com/openvms/products/ips Compaq Computer Corporation remains committed to the quality and support of the DECwindows Motif for OpenVMS product and to the protection of its customers' investment in this product and technology. Product Retirement Notices A-3 Product Retirement Notices A.9 X.25 Client for OpenVMS Alpha Retirement (Alpha Only) A.9 X.25 Client for OpenVMS Alpha Retirement (Alpha Only) V7.2 The X.25 Client for OpenVMS Alpha product is being retired and is not supported on OpenVMS Alpha Version 7.2. However, the X.25 for OpenVMS Alpha product provides the functionality previously provided by the X.25 Client for OpenVMS Alpha product. Customers who need X.25 Client functionality for OpenVMS Alpha Version 7.2 can achieve it with the following: o X.25 Version 1.2 for OpenVMS Alpha systems o An X.25 Client or X.25 license Note: You can use your X.25 Client license on the X.25 for OpenVMS Alpha product to get the same functionality. o DECnet-Plus Version 7.2 for OpenVMS On OpenVMS VAX Version 7.2, X.25 functionality is included in DECnet-Plus and has not changed. A.10 Archived Manuals V7.2 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 Documentation CD-ROM. You can also order printed manuals through DECdirect (800-344-4825) if you know the order numbers for the manuals. Order numbers are published in the Overview of OpenVMS Documentation. Table A-1 lists the manuals that have been archived starting with OpenVMS Version 7.2. A-4 Product Retirement Notices Product Retirement Notices A.10 Archived Manuals Table_A-1_Manuals_Archived_with_OpenVMS_Version_7.2______________ Order Manual_Title____________________File_Name_on_CD-ROM___Number_____ Creating an OpenVMS Alpha ALPHA_DRIVER_FR_ AA-R0Y8A-TE Device Driver from an OpenVMS VAX.PS VAX Device Driver OpenVMS Alpha System Dump ALPHA_SDA.PS AA-PV6UC-TE Analyzer Utility Manual[1] [1]The_information_formerly_contained_in_this_book_has_been_moved into the new OpenVMS Alpha System Analysis Tools Manual. _________________________________________________________________ For a list of all archived manuals, refer to the Overview of OpenVMS Documentation. Product Retirement Notices A-5 B _________________________________________________________________ Remedial Kits Included in OpenVMS Version 7.2 This appendix lists remedial kits that are included in OpenVMS Version 7.2. Compaq updates existing kits and creates new kits as necessary. Contact your Compaq support representative for the latest information about new remedial kits. The following sections list the remedial kits included in Version 7.2 of the OpenVMS VAX and OpenVMS Alpha operating systems. If you have used any of the kits listed here, you do not need to use them again with Version 7.2. Kit names are constructed from the following information, in this order: o Platform name: VAX or ALP (for Alpha) o Facility name, abbreviated to 4 characters if necessary o Number of the kit for this facility for this version o Version number For example, ALPDEBU02_071 is the second remedial kit created to correct the Debugger that shipped in Version 7.1 of OpenVMS Alpha. B.1 Remedial Kits Included in OpenVMS Alpha Version 7.2 The following remedial kits are included in Version 7.2 of the OpenVMS Alpha operating system: ALPACRT06_071 ALPAUDS01_071 ALPBACK04_071 ALPBASE02_071 ALPBASR01_071 ALPCLD01_071 ALPCLIU02_071 Remedial Kits Included in OpenVMS Version 7.2 B-1 Remedial Kits Included in OpenVMS Version 7.2 B.1 Remedial Kits Included in OpenVMS Alpha Version 7.2 ALPCLIU03_071 ALPCLIU04_071 ALPCPU001_071 ALPCPU002_071 ALPCPU0C04_071 ALPCPU101_071 ALPCPU1602_071 ALPCPU1E02_071 ALPCPU1E03_071 ALPCPUC03_071 ALPDCL01_071 ALPDDTM01_071 ALPDEBU02_071 ALPDISM01_071 ALPDPML01_071 ALPDRIV03_071 ALPDRIV06_071 ALPDRIV07_071 ALPDRIV09_071 ALPDUP01_071 ALPF11X03_071 ALPHYPR01_071 ALPINIT01_071 ALPIPC01_071 ALPLAD01_071 ALPLAN01_071 ALPLAN03_071 ALPLAT02_071 ALPLBR01_071 ALPLIBR08_071 ALPLOGI07_071 ALPMAIL02_071 ALPMC01_071 ALPMOUN03_071 ALPMOUN04_071 ALPMSCP01_071 ALPMTAA01_071 ALPPORTS01_071 ALPPPPD01_071 ALPPTHR02_071 ALPQMAN01_071 ALPRMS03_071 ALPSCSI04_071 B-2 Remedial Kits Included in OpenVMS Version 7.2 Remedial Kits Included in OpenVMS Version 7.2 B.1 Remedial Kits Included in OpenVMS Alpha Version 7.2 ALPSCSI3_071 ALPSHAD04_071 ALPSYS19_071 ALPSYSA02_071 ALPSYSB02_071 ALPSYSI01_071 ALPTNT01_071 ALPTRAC01_071 Remedial Kits Included in OpenVMS Version 7.2 B-3 Remedial Kits Included in OpenVMS Version 7.2 B.2 Remedial Kits Included in OpenVMS VAX Version 7.2 B.2 Remedial Kits Included in OpenVMS VAX Version 7.2 The following remedial kits are included in Version 7.2 of the OpenVMS VAX operating system: VAXACRT07_071 VAXAUDS01_071 VAXBACK02_071 VAXCLD01_071 VAXCLIU02_071 VAXCLIU03_071 VAXCMAR01_071 VAXDEBU02_071 VAXDRIV03_071 VAXDRIV04_071 VAXF11X03_071 VAXIPC01_071 VAXLAD01_071 VAXLAT01_071 VAXLAT02_071 VAXLBR01_062 VAXLBR01_071 VAXLIBR02_071 VAXLOGI02_071 VAXLOGI06_071 VAXMAIL02_071 VAXMANA01_071 VAXMOUN03_071 VAXMSCP01_071 VAXQMAN01_071 VAXRMS01_071 VAXSCSI01_071 VAXSHAD04_071 VAXSYSA01_071 VAXSYSB01_071 VAXSYSL01_071 VAXVERI02_071 VAXY2K01_071 B-4 Remedial Kits Included in OpenVMS Version 7.2 _________________________________________________________________ Index A AlphaServer 4100 (cont'd) _______________________________ problem in SCSI clusters, Adobe Display PostScript 4-26 not supported for DECwindows AlphaServer 8200 systems Motif, A-1 FRU table restriction, 1-29 Advanced Server for OpenVMS, AlphaServer 8400 systems 2-2 FRU table restriction, 1-29 After-image journaling, 4-38 AlphaStation 255 Alpha System Dump Analyzer PCI configuration restriction utility (SDA), 4-1 , 6-14 number of nonpaged pool PowerStorm graphics cards, lookaside lists increased, 1-31 4-1 ALPHAVMSSYS.PAR file ALPHAbook 1, 1-17 to 1-25 OpenVMS Cluster system AlphaServer 1000A startup problem, 4-29 BUS_PROBE_ALGORITHM default, AMDS$EVTLOG_ALLOC_SIZE 1-25 DECamds logical, 4-5 installation failure with AMDS$EVTLOG_EXTNT_SIZE DEFPA adapter, 1-25 DECamds logical, 4-5 AlphaServer 2100 Applications support for console display, 1-26 current release, 2-1 SCSI controller restriction, ARB_SUPPORT system parameter, 1-27, 6-15 4-48 AlphaServer 4000 error in online help, 4-49 problem in SCSI clusters, Archived manuals, A-4 4-26 AlphaServer 4100, 1-27 to 1-29 B______________________________ EISA Configuration Utility Backup API (ECU), 1-27 changes and enhancements FRU table error, 1-28 BCK_OPTYP_IGNORE_K_ FRU table restriction, 1-29 STRUCTURE flag, 5-1 memory holes, 6-11 problems and restrictions BACKUP$START error, 5-3 Index-1 Backup API CIPCA adapter problems and restrictions problems and restrictions (cont'd) (cont'd) journaling events, 5-2 CPUSPINWAIT bugcheck, unexpected message, 5-2 4-27 Backup utility (BACKUP) HSJ50 firmware requirement changes and enhancements , 4-27 writing save set to MULTIPROCESSING parameter Files-11 mounted disk, settings, 4-27 4-2 system tuning, 1-10 problems and restrictions CIXCD adapter /MEDIA_FORMAT=COMPACTION system tuning, 1-10 qualifier ineffective CLISYMTBL system parameter, on TA90 devices, 4-2 2-14 numerical identifiers with Cluster Client license, 4-22 /OWNER and /BY_OWNER, Cluster Compatibility Kit, 4-2 4-21 BASIC$STARLET.TLB build Clusters restriction, 2-3 See OpenVMS Cluster systems Batch and print queues COM for OpenVMS, 3-1, 5-4 terminating batch jobs, 5-3 field test versions BBR (Bad Block Repair), 4-54 incompatible with OpenVMS Binary Error Log Translation Version 7.2, 3-1 utility, 4-7 Common Event Header (CEH) BITMAP.SYS file, 4-34 binary error log file, 4-7 Bitmaps, 4-33 to 4-36 CPUSPINWAIT bugcheck, 1-32, BLISS compiler 4-27, 5-5 consequences of noncompliant CRD_CONTROL system parameter, code, 7-1 4-43 BUGCHECKFATAL system parameter , 5-5 D BUS_PROBE_ALGORITHM settings, _______________________________ 1-25 3D extensions, 1-31 DCE C______________________________ See Digital DCE for OpenVMS CANCEL SELECTIVE function DCL commands improved use with LTDRIVER, changes and enhancements 5-18 DIRECTORY command, 4-40 CI-to-PCI adapter displaying suppressed See CIPCA adapter PATHWORKS ACEs, 4-40 CIPCA adapter SET PREFERRED_PATH command problems and restrictions , 4-42 problems and restrictions Index-2 DCL commands DEC C Run-Time Library problems and restrictions See DEC C RTL (cont'd) DEC C++ compiler SET PROCESS/NOAUTO_ changes and enhancements UNSHELVE command, 3-2 STARLET header files on DEC 7000 VAX, 2-5 change in behavior, 1-30 consequences of noncompliant DEC Ada Compilation System code, 7-1 (ACS) problems and restrictions incorrect SS$_NORMAL exit SYS$STARLET_C.TLB on VAX status, 5-13 deleted by pre-Version DEC Ada Run-Time Library 5.2 kits, 2-5 AST procedure workarounds no Version 5.3 installation longer needed, 5-7 fails (VAX Only), 2-5 text libraries with Ada DEC Fortran declarations, 5-6 See Fortran unexpected storage errors, DEC Pascal 5-6 problems and restrictions DEC BASIC reinstalling after an BASIC$STARLET.TLB build upgrade (Alpha), 2-6 restriction, 2-3 DEC PL/I DEC C compiler RTL support, 2-6 changes and enhancements DEC Text Processing Utility STARLET header files on (DECTPU) VAX, 2-5 correction to DEC Text consequences of noncompliant Processing Utility code, 7-1 Reference Manual, 3-3 problems and restrictions DECwindows Motif interface SYS$STARLET_C.TLB on VAX help built-in disabled, deleted by pre-Version 3-2 5.2 kits, 2-5 small display monitors, DEC C RTL 5-15 changes and enhancements DECamds cache of OpenVMS changes and enhancements environment, 5-9 defining log file sizes, Euro support, 5-8 4-5 internationalization handling unknown adapter support, 5-7 types, 4-5 mmap creation of global installation, 4-4 and permanent sections, location of client 5-10 software files, 4-4 new functions, 5-9 no installation of server, wait functions, 5-10 4-4 sorting group names, 4-6 Index-3 DECamds (cont'd) DECthreads problems and restrictions changes and enhancements kernel threads unsupported (cont'd) on Alpha, 4-6 static initialization DECdfs for OpenVMS inappropriate Version 2.3 required for for stack-based Alpha, 2-7 synchronization objects DECevent , 5-12 Binary Error Log Translation thread stack size, 5-11 utility, 4-7 problems and restrictions DIAGNOSE command, 4-7 DECthreads debugger enabling the DIAGNOSE command metering function, , 1-6 5-14 new binary error log file errno value, 5-14 format, 4-7 incorrect success exit Version 2.9 required, 4-7 status, 5-13 DECforms language support, 5-14 support on OpenVMS Alpha using OpenVMS Debugger SET Version 7.0 and later, 2-7 TASK/ACTIVE command, DECnet for OpenVMS, 1-2 5-14 external authentication DECTPU requirement, 4-11 See DEC Text Processing DECnet-Plus for OpenVMS, 1-2 documentation correction, Utility 2-8 DECTPU SET built-ins external authentication WIDGET_CONTEXT_HELP keyword, requirement, 4-14 3-2 limit of 4 circuits, 2-8 DECwindows Motif NET_CALLOUTS parameter, 4-14 changes and enhancements satellite booting, 4-23 Adobe Display PostScript DECnet/OSI not supported, A-1 See DECnet-Plus for OpenVMS Spyglass Enhanced Mosaic DECpresent not supported for installation dependencies Version 1.2-5, A-3 with OpenVMS VAX, 2-9 Version 1.2 for OpenVMS DECram not supported, 2-13 Version 2.3 required on Alpha Version 1.2-5, 2-11 , 2-9 Year 2000 support for DECthreads Versions 1.2-3 and changes and enhancements 1.2-4, 2-11 application coding errors, Year 2000 support in 5-13 Version 1.2-5, 2-11 POSIX 1003.4a Draft 4 documentation correction, interface, 5-13 2-18 Index-4 DECwindows Motif (cont'd) DIGITAL Modular Computing problems and restrictions Components (DMCC) Alpha kit in reference problems and restrictions format, 1-12 CPUSPINWAIT error, 1-32 console broadcasts KZPDA controller and PBXGA disabled, 2-16 Graphics Card, 1-32 installing V1.2-5 on older updating the SRM console, releases, 2-12 1-32 language variant DIGITAL Open3D product, 1-31 availability, 2-14 DIGITAL TCP/IP Services for remedial kits, 2-14 OpenVMS, 1-2 system files purged, 2-18 error when removing UCX on system parameter Alpha systems, 1-15 values required for installing, 1-4 installation, 2-14 upgrade problem on Alpha DECwindows pause screen systems, 1-14 unlock mechanism password Version 5.0 changes, 2-21 validation, 4-14 Disk cluster factor, 4-34 DECwindows X11 display server Disks behavior change, 1-30 mounting Version 7.2 disks on graphics boards support, earlier systems, 4-34 1-31 DMCC DEFPA adapter See DIGITAL Modular Computing on AlphaServer 1000A computer Components (DMCC) , 1-25 Documentation changes and DETACH privilege corrections renamed to IMPERSONATE, 4-40 archived manuals, A-4 Device support, 6-1 to 6-18 Creating an OpenVMS Alpha DIAGNOSE command Device Driver from enabling, 1-6 an OpenVMS VAX Device to invoke DECevent, 4-7 Driver, A-4 Digital DCE for OpenVMS OpenVMS Alpha System Dump enhancements to the DCE Analyzer Utility Manual system management command , A-4 procedure, 2-19 DEC Text Processing Utility notes for existing users, Reference Manual, 3-3 2-19 DECnet-Plus for OpenVMS RPC functionality not Network Management, 2-8 available, 2-20 Getting Started With the New Digital Fortran Desktop, 2-18 See Fortran online help for system parameters, 4-42 Index-5 Documentation changes and External authentication corrections (cont'd) problems and restrictions OpenVMS Linker Utility Manual (cont'd) , 5-18 impact on layered products OpenVMS RTL Library (LIB$) and applications, 4-12 Manual, 5-29 LGI callout services, OpenVMS RTL Screen Management 4-13 (SMG$) Manual, 5-29 on mixed-version OpenVMS OpenVMS RTL String Cluster systems, 4-13 Manipulation (STR$) Manual password expiration , 5-31 notification, 4-14 OpenVMS System Management SET PASSWORD command, Utilities Reference 4-10 Manual: M-Z, 4-17, 4-41 requirements, 4-9 DSSI disk devices microcode revision levels, F______________________________ 1-34 F$GETSYI lexical function NODE_HWTYPE is obsolete, E______________________________ 5-16 EISA Configuration Utility Fast Path (ECU) changes and enhancements no automatic startup on DCL support, 4-15 AlphaServer 4100 systems, enabled by default, 4-15 1-27 STOP/CPU command allowed, EV6 Alpha processor, 7-1 4-15 Extended DDT bit system parameter changes, problem corrected, 5-18 4-15 Extended File Specifications FAST_PATH system parameter, mixed UNIX style and VMS 4-15 style file names not Fibre Channel support, 4-25 supported, 4-8 File system External authentication changes, 4-33 changes and enhancements Fortran DCL command interface, Mathematics RTL 4-10 interoperability FTP server, 4-9 restrictions, 5-19 problems and restrictions Freeware, A-1 DECnet Phase IV, 4-11 FREE_GBLPAGES system parameter DECnet-Plus, 4-14 , 2-14 DECwindows pause screen, FRU table error on AlphaServer 4-14 4100, 1-28 failed connection attempts FTP server on POP server, 4-10 external authentication support, 4-9 Index-6 Installation and upgrade G______________________________ information Galaxy Software Architecture Alpha only (cont'd) on OpenVMS, 4-3 64 MB memory requirement, GBLPAGES system parameter, 1-10 2-14 problems and restrictions Graphics boards support, 1-31 DECwindows Motif kit in reference format, H______________________________ 1-12 High-performance Sort/Merge error when removing utility UCX, 1-15 See Sort/Merge utility (high- error when upgrading performance) TCP/IP Services, HSD10 virtual disks, 4-51 1-14 HSJ50 controller Java, 1-13 firmware requirement, 4-27 Spiralog file system HSZ allocation class, 4-20 unsupported, 1-14 HSZ40 Raid-Array Controller tuning BAP system Volume Shadowing for OpenVMS, parameters, 1-10 4-53 VAX only Hypersort changes and enhancements See Sort/Merge utility (high- magnetic tape performance) distribution, 1-8 changing system time causes error, 1-9 I______________________________ error on shutdown after IMPERSONATE privilege, 4-40 booting CD-ROM, 1-9 INITIALIZE command Interlocked memory /MEDIA_FORMAT=COMPACTION instructions, 7-1 qualifier ineffective on IO_PREFER_CPUS system TA90 devices, 4-18 parameter, 4-15 Installation and upgrade information J______________________________ Alpha and VAX Java changes and enhancements removing before Alpha upgrade enabling the DIAGNOSE , 1-13 command, 1-6 networking options, K 1-2 _______________________________ problems and restrictions KFMSB adapter PCSI-I-RETAIN messages, system tuning, 1-10 1-7 Alpha only Index-7 Mathematics (MTH$) Run-Time L______________________________ Library Layered products See MTH$ RTL impact of external MAXBOBMEM system parameter, authentication on, 4-12 4-43 Software Public Rollout /MEDIA_FORMAT=COMPACTION Reports, 2-1 qualifier versions supported for ineffective on TA90 devices, current release, 2-1 4-18 LGI callout services MEMORY CHANNEL external authentication problems and restrictions, disabled, 4-13 4-28 LIB$ Run-Time Library hardware guide, 4-28 documentation error rolling upgrades, 4-28 LIB$GETJPI, 5-29 Memory holes on AlphaServer LIB$GETQUI, 5-29 4100 systems, 6-11 LIB$FIND_IMAGE_SYMBOL routine Memory requirement for Alpha LIB$_EOMWARN warning, 5-28 systems, 1-10 LIB$GETJPI routine, 5-29 Merging files LIB$GETQUI routine, 5-29 See Sort/Merge utility (high- Librarian utility (LIBRARIAN) performance) error reporting problem and MFDs (master file directories) workaround, 5-17 index file bitmap, 4-33 Linker utility storage bitmap, 4-33 linking with MTHRTL, 5-19 Microcode revision levels Lock manager commands for updating, 1-36 nonpaged pool size, 4-16 on DSSI disk devices, 1-34 LTDRIVER restriction, 5-18 Minimerge function on system disks, 4-52 M______________________________ version compatibility problem MACRO-32 compiler , 4-52 consequences of noncompliant MMG_CTLFLAGS system parameter, code, 7-1 4-44 MACRO-64 assembler MMOV$MSBDRIVER, 6-13 consequences of noncompliant Monitor utility (MONITOR) code, 7-1 changes to MONITOR recording Magnetic tape distribution for file, 4-17 VAX, 1-8 version incompatibilities Mail utility (MAIL) when monitoring older problems and restrictions systems, 4-16 callable mail used with Mount utility kernel threads enabled, /MEDIA_FORMAT=COMPACTION 5-19 qualifier ineffective on TA90 devices, 4-18 Index-8 Mount utility (cont'd) NPAGEDYN system parameter, mounting write-protected 1-11 disks in mixed-version NPAGEVIR system parameter, cluster, 4-18 1-11 Mounting Version 7.2 disks on older systems, 4-34 O______________________________ MPDEV_REMOTE system parameter ODS-5 file system not supported, 4-49 mixed UNIX style and VMS MSCP_CMD_TMO system parameter, style file names not 4-32, 4-44 supported, 4-8 MSCP_SERVE_ALL system Online help parameter, 4-45 changes to system parameter and mixed-version clusters, help, 4-42 4-24 correction to ARB_SUPPORT restriction, 4-48 help, 4-49 MTH$ RTL OPCOM executable image restrictions corrections, 4-19 , 5-19 OpenVMS Alpha System Dump MultiNet for OpenVMS Analyzer Utility Manual update requirement, 2-24 replaced by OpenVMS Alpha Multipath support for parallel System Analysis Tools SCSI and Fibre Channel, Manual, A-4 4-25 OpenVMS Cluster Compatibility MULTIPROCESSING system Kit, 4-21 parameter, 4-27, 5-5 OpenVMS Cluster systems, 4-19 Multiprocessor systems See also CIPCA adapter, setting SMP_SPINWAIT MEMORY CHANNEL, and SCSI parameter, 4-27 OpenVMS Cluster systems N changes and enhancements _______________________________ client license changes, Network options, 1-2 4-22 Network transport products Cluster Compatibility Kit, installing, 1-4 4-21 NOCLUSTER system parameter, problems and restrictions 4-45 booting satellites with Node allocation class, 4-20 DECnet-Plus, 4-29 shared SCSI interconnect, DECnet-Plus satellite 4-26 booting, 4-23 Nonpaged pool external authentication on lock manager changes, 4-16 mixed version, 4-13 Nonpaged pool lookaside lists mixed-version new lists added, 4-1 incompatibilities, 4-23 Index-9 OpenVMS Cluster systems PATHWORKS for OpenVMS problems and restrictions replaced by Advanced Server (cont'd) for OpenVMS on Alpha, 2-2 mounting write-protected upgrade path, 1-5 disks in mixed-version V6.0/V6.0A not supported on cluster, 4-18 OpenVMS V7.2, 2-23 MSCP_SERVE_ALL system PATHWORKS for OpenVMS parameter and mixed- (NetWare) version clusters, 4-24 retired, A-2 system startup using PATHWORKS V5 for OpenVMS ALPHAVMSSYS.PAR file, not supported on OpenVMS 4-29 V7.2, 2-23 OpenVMS Cluster Systems PCSI-I-RETAIN message, 1-7 changes and enhancements Per-thread security, 5-22, new HSZ allocation class, 5-32, 5-35 4-20 impact on device drivers, problems and restrictions 5-25 Fibre Channel support, impact on privileged code, 4-25 5-25 multipath support for Persona parallel SCSI and Fibre restrictions lifted, 5-35 Channel, 4-25 $PERSONA system services tuning BAP system audit record change, 5-34 parameters, 1-10 default privilege change, OpenVMS Debugger 5-33 problems and restrictions flags ignored, 5-32 errno value in threaded PGFLQUOTA applications, 5-14 problems, 5-17 OpenVMS VAX PIOPAGES system parameter, magnetic tape distribution, 4-46 1-8 POLYCENTER Software OSU HTTP server Installation utility restriction, 1-33 DECwindows Motif interface retired, 4-36 P problems and restrictions _______________________________ file generations, 5-21 PAC removing products, 4-37 See Port allocation class POOLCHECK system parameter, See Port allocation classes 5-5 PASTDGBUF system parameter, POP server 4-45 failed connection attempts, PATHWORKS ACEs 4-10 displaying, 4-40 Index-10 Port allocation class, 4-20 RF73 and RFnn disks Port allocation classes controller memory errors, nodes on a shared SCSI 1-34 interconnect, 4-26 RMS PKA device name correction, directory cache limits 4-30 removed, 5-28 SCSI device name restriction, ellipsis processing 4-24 circular directory paths, Port driver $QIO 5-27 restriction, 5-18 improvements, 5-27 POSIX for OpenVMS RMS Journaling 1003.4a Draft 4 interface after-image journaling, 4-38 retirement, 5-13 journal file creation retirement, A-3 modification, 4-37 support, 2-24 remote access of recovery PowerStorm graphics cards, unit journal files, 4-39 1-31 Rolling upgrades for MEMORY PREFER.CLD, 4-42 CHANNEL configurations, PREFER.MAR, 4-42 4-28 PRODUCT command Run-time library (LIB$), 5-28 no output control options, 4-37 S______________________________ Q SCSCONNCNT system parameter, _______________________________ 4-46 QDSKINTERVAL system parameter, SCSI controllers 4-46 restrictions on AlphaServer Qlogic 1020ISP adapter 2100 systems, 1-27, 6-15 system tuning, 1-10 SCSI device naming Qvision graphics boards conflict, 4-31 behavior changes, 1-30 PKA device name correction, 4-30 R______________________________ port allocation class Recovery unit journaling restriction, 4-24 file creation changes, 4-37 SCSI OpenVMS Cluster systems restriction, 4-39 AlphaServer 4000/4100 problem Remedial kits , 4-26 included in OpenVMS Alpha SECURESHR images, 5-34 Version 7.2, B-1 SET PASSWORD command, 4-10 included in OpenVMS VAX SET PREFERRED_PATH command, Version 7.2, B-4 4-42 Retired products information, SET PROCESS/NOAUTO_UNSHELVE A-1 command, 3-2 Index-11 Shadow sets Sort/Merge utility (high- support for more members, performance) 4-51 corrections (cont'd) Shadowing error messages, 3-4 See Volume shadowing limitation on merging Shared SCSI interconnect stream files, 3-4 node allocation class problems and restrictions requirement, 4-26 concurrent sort operations Show Cluster utility , 3-4 ADD (field) supplementary SOR callable interface, 3-3 documentation, 4-41 Spiralog file system SMG$DELETE_VIRTUAL_DISPLAY deinstalling, 1-14 documentation correction, retirement, A-3 5-29 Spyglass Enhanced Mosaic SMG$GET_TERM_DATA not supported for DECwindows documentation correction, Motif Version 1.2-5, A-3 5-30 SRM_CHECK tool SMG$READ_COMPOSED_LINE location on kit, 7-2 documentation correction, using to analyze code, 7-2 5-30 STARTUP_P3 system parameter, SMG$READ_LOCATOR 4-46 documentation correction, Static initialization 5-30 inappropriate for stack- SMG$SET_KEYPAD_MODE based synchronization documentation correction, objects, 5-12 5-30 StorageWorks RAID Software SMG$SET_OUT_OF_BAND_ASTS incompatibility with OpenVMS documentation correction, Volume Shadowing, 4-54 5-30 STR$FIND_FIRST_IN_SET SMP_SPINWAIT system parameter, documentation correction, 4-27 5-31 Software Public Rollout STR$FREE1_DX Reports, 2-1 documentation correction, SOR callable interface 5-31 See Sort/Merge utility (high- Support policy for software, performance) 1-1 SORT32 $SUSPND system service cluster problem, 5-34 See Sort/Merge utility (high- SYS$EXAMPLES performance) PREFER.CLD, 4-42 Sort/Merge utility (high- PREFER.MAR, 4-42 performance) SYS$MSBDRIVER command line interface, 3-3 removed from OpenVMS corrections distribution, 6-13 Index-12 SYS$STARLET_C.TLB on VAX System parameters (cont'd) deleted by pre-Version 5.2 VBN_CACHE_S, 4-47 kits, 2-5 VCC_MAXSIZE, 4-47 SYSMAN utility VIRTUALPAGECNT, 4-33 autoconfiguration, 4-21 System services System disks changes and enhancements minimerge capability, 4-52 $PERSONA audit record System Dump Analyzer utility change, 5-34 (SDA), 4-1 $PERSONA default privilege number of nonpaged pool change, 5-33 lookaside lists increased, $PERSONA flags ignored, 4-1 5-32 System parameters corrections ARB_SUPPORT $PERSONA, 5-35 default value, 4-49 problems and restrictions restriction, 4-48 calling $SUSPND in cluster BUGCHECKFATAL, 5-5 environment, 5-34 CLISYMTBL, 2-14 linking SECURESHR images, CRD_CONTROL, 4-43 5-34 FAST_PATH, 4-15 SYSTEM_CHECK system parameter, FREE_GBLPAGES, 2-14 5-5 GBLPAGES, 2-14 IO_PREFER_CPUS, 4-15 T MAXBOBMEM, 4-43 _______________________________ MMG_CTLFLAGS, 4-44 TCP/IP MPDEV_REMOTE See DIGITAL TCP/IP Services not supported, 4-49 for OpenVMS MSCP_CMD_TMO, 4-32, 4-44 Terminal Fallback facility MSCP_SERVE_ALL, 4-45 (TFF), 4-49 and mixed-version clusters restrictions, 4-50 , 4-24 TFF restriction, 4-48 See Terminal Fallback MULTIPROCESSING, 4-27, 5-5 facility NOCLUSTER, 4-45 Thread stack size, 5-11 NPAGEDYN, 1-11 TMSCP_SERVE_ALL system NPAGEVIR, 1-11 parameter, 4-46 PASTDGBUF, 4-45 PIOPAGES, 4-46 POOLCHECK, 5-5 V______________________________ QDSKINTERVAL, 4-46 VBN_CACHE_S system parameter, SCSCONNCNT, 4-46 4-47 SMP_SPINWAIT, 4-27 VCC_MAXSIZE system parameter, STARTUP_P3, 4-46 4-47 SYSTEM_CHECK, 5-5 TMSCP_SERVE_ALL, 4-46 Index-13 Version incompatibilities X/Open Transport Interface when monitoring older systems (XTI) (cont'd) , 4-16 problems and restrictions, when mounting disks on older 5-38 systems, 4-34 supported transports, 5-36 Virtual memory requirements for bitmaps, 4-33 VIRTUALPAGECNT system parameter, 4-33 Volume shadowing changes and enhancements shadow set member support, 4-51 corrections RAID software incompatibility, 4-54 problems and restrictions Bad Block Repair (BBR), 4-54 HSD10 virtual disks, 4-51 HSZ40 Raid-Array Controller, 4-53 minimerge requires dump off system disk, 4-52 minimerge version incompatibility, 4-52 X______________________________ X.25 Version 1.0-G unsupported, 1-16 X.25 Client for OpenVMS Alpha retirement, A-4 X.25 for OpenVMS Alpha provides X.25 Client functionality, A-4 Version 1.1-B crashes OpenVMS Version 7.2, 1-16 X/Open Transport Interface (XTI), 5-35 architecture, 5-36 documentation, 5-36 linking requirements, 5-36 Index-14