SEARCH CONTACT US SUPPORT SERVICES PRODUCTS STORE
United States    
COMPAQ STORE | PRODUCTS | SERVICES | SUPPORT | CONTACT US | SEARCH
gears
compaq support options
support home
software & drivers
ask Compaq
reference library
support forum
frequently asked questions
support tools
warranty information
service centers
contact support
product resources
parts for your system
give us feedback
associated links
.
} what's new
.
} contract access
.
} browse patch tree
.
} search patches
.
} join mailing list
.
} feedback
.
patches by topic
.
} DOS
.
} OpenVMS
.
} Security
.
} Tru64 Unix
.
} Ultrix 32
.
} Windows
.
} Windows NT
.
connection tools
.
} nameserver lookup
.
} traceroute
.
} ping
OpenVMS ALPY2K02_062 OpenVMS Alpha V6.2 Year 2000 ECO Summary

TITLE: OpenVMS ALPY2K02_062 OpenVMS Alpha V6.2 Year 2000 ECO Summary Modification Date: 29-JUN-98 Modification Type: Updated Kit: Supersedes ALPY2K01_062 NOTE: An OpenVMS saveset or PCSI installation file is stored on the Internet in a self-expanding compressed file. The name of the compressed file will be kit_name-dcx_vaxexe for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha. Once the file is copied to your system, it can be expanded by typing RUN compressed_file. The resultant file will be the OpenVMS saveset or PCSI installation file which can be used to install the ECO. Copyright (c) Digital Equipment Corporation 1997, 1998. All rights reserved. OP/SYS: DIGITAL OpenVMS Alpha and OpenVMS/Japanese Alpha COMPONENTS: CLUE$SDA DUMP EXCHANGE F11BXQP LBRSHR LIBRTL MESSAGE_ROUTINES MTAAACP TECOSHR_TV VERIFY VMS$REMEDIAL_ID STARLET.OLB SOURCE: Digital Equipment Corporation ECO INFORMATION: ECO Kit Name: ALPY2K02_062 ECO Kits Superseded by This ECO Kit: ALPY2K01_062 ALPVERI02_062 ALPF11X02_062 ALPLIBR06_062 ALPMTAA01_070 (V6.2 fixes *ONLY*) ECO Kit Approximate Size: 5850 Blocks Kit Applies To: OpenVMS Alpha and OpenVMS/Japanese Alpha V6.2, V6.2-1H1, V6.2-1H2, V6.2-1H3 System/Cluster Reboot Necessary: Yes Installation Rating: 1 - To be installed on all systems running the listed version(s) of OpenVMS. Kit Dependencies: The following remedial kit(s) must be installed BEFORE installation of this kit: ALPCLUSIO01_062 In order to receive all the corrections listed in this kit, the following remedial kits should also be installed: None ECO KIT SUMMARY: This kit provides Year 2000 enhancements for OpenVMS Alpha and OpenVMS Japanese/Alpha V6.2 through 6.2-1H3. This document contains information regarding both the VAX and Alpha Year 2000 enhancements that ship in kits VAXY2K02_062 and ALPY2K02_062, respectively. NOTE Kits VAXY2K02_062 and ALPY2K02_062 supersede kits VAXY2K01_062 and ALPY2K01_062. The new kits are identical to the superseded kits except that kits VAXY2K02_062 and ALPY2K02_062 also correctly replace image LBRSHR.EXE in SYS$COMMON:[SYSLIB]IMAGELIB.OLB. Kit VAXY2K02_062 also contains a fix that correctly installs F11BXQP.EXE in [SYSEXE]. Even though DIGITAL believes that few customer sites will need these enhancements, which affect only a few areas of the operating system, all customer sites running OpenVMS V6.2x should install the Year 2000 kit. The few Year 2000 enhancements in this kit result from a rigorous and comprehensive analysis of the entire OpenVMS operating system, including extensive OpenVMS testing. For more information on the OpenVMS Year 2000 Initiative, please visit the OpenVMS Year 2000 web page: http://www.openvms.digital.com/openvms/products/year-2000 NOTE DIGITAL expects that most year 2000-related problems will occur primarily in locally developed layered product applications. Therefore, it is important to start evaluating your applications and environments as soon as possible. Even if DIGITAL's products are ready for the year 2000, you must ensure that the environments in which these products operate are also ready. The OpenVMS Year 2000 web page includes a link to testing instructions, including how to set the system clock ahead to simulate the transition to the year 2000 or other future dates. If you need additional help, contact your DIGITAL support representative to learn what information and tools are available to get you started. The following release notes identify certain conditions you should be aware of when preparing your OpenVMS environment for the year 2000. This kit contains minor modifications to several older components of the operating system; other conditions are simply noted, but need no changes. o Crash Log Utility Extractor (CLUE) The CLUE history listing file contains a 2-digit year format in its file name, which has this format: CLUE$node_ddmmyy_hhmm.LIS This file format poses no year 2000 problem in itself, but the code that generates this date has been changed from using a subtract operation to using a modulo function so that the correct date will still be calculated in the year 2000. This change has no visible effect on the file name format. o EXCHANGE Utility When the EXCHANGE utility is used to transfer files between OpenVMS and RT-11 or DOS-11 systems, date problems could occur starting in the year 2004 for RT-11 and in the year 2036 for DOS-11. NOTE RT-11 volumes are also used as console storage media on certain older VAX systems. This kit contains an enhancement to EXCHANGE that makes the RT-11 date format continue to function correctly until the year 2099. NOTE DIGITAL transferred the RT-11 operating system, along with other PDP-11 software, to Mentec in 1994. o File System $QIO Interface The following sections describe conditions you should be aware of if you interoperate with RSX-11 or if you use RSX-11 software on your OpenVMS system. - The file system $QIO interface supports several attributes for RSX-11 compatibility. Of these, ATR$C_EXPDAT and ATR$C_ASCDATES return the file creation date, revision date, and expiration date using 2-digit years. These attributes are not normally used by native code and can be replaced with the following documented, compliant interfaces: ATR$C_CREDATE ATR$C_EXPDATE ATR$C_REVDATE The file system $QIO interface is provided by the following file systems: DIGITAL TCP/IP Network File System (NFS) client Distributed File System (DECdfs) Magnetic tape ACP OpenVMS ODS-1 file system OpenVMS ODS-2 file system o ODS-1 File Header Format and Utility Support For RSX-11 compatibility, OpenVMS VAX supports ODS-1 file format disk volumes. The ODS-1 file system uses a 2-digit year format internally, and current implementations have limitations for the year 2000. The magnetic tape ACP also returns an ODS-1 format file header in response to an application request for the ATR$C_HEADER attribute. This feature is supported on both VAX and Alpha. ODS-1 data structures use a 2-digit year (ddmmmyy) in the following items: - ODS-1 file header: FI1$T_CREDATE FI1$T_CRETIME FI1$T_EXPDATE FI1$T_REVDATE FI1$T_REVTIME - ODS-1 home block: HM1$T_CREDATE The OpenVMS VAX file system and the following OpenVMS utilities that support the ODS-1 file system format have been modified to correctly interpret these 2-digit years until the year 2057: Analyze/Disk_Structure Utility Backup Utility Dump Utility Librarian (LBR) routines NOTE Even though we are updating the ODS-1 code for the year 2000, DIGITAL strongly recommends that users of ODS-1 formatted media move to a newer file format by the year 2000. o LIB$ Run-Time Library In the run-time library, the LIB$CONVERT_DATE_STRING routine allows the user to select a 2-digit year format (as well as many others). This routine interprets 2-digit years as belonging to the century in which the system is currently running (according to the system clock). For example, in the 1900s, 61 is interpreted as 1961, and starting January 1, 2000, 61 will be interpreted as 2061. If this behavior could produce unexpected results on your system, select one of the alternatives to the 2-digit year format. NOTE This behavior has been documented in the OpenVMS RTL Library (LIB$) Manual since Version 6.0, so the code will not be changed. o TECO Editor This kit includes two minor changes to the TECO editor. - The date value in the TECO editor has been extended to a longword so that the year value returned by the Ctrl/B function will not overflow on 01-JAN-2028. - This kit also fixes a TECO problem that is unrelated to dates. The UIC value returned by the 2EJ function was incorrect if the process UIC had a group or member number greater than 377. For compatibility reasons, the 2EJ value cannot be changed. However, the problem has been fixed by the following changes: o All group and member numbers that exceed a byte are now mapped to 377 (octal). o A 3EJ function has been implemented to return the longword UIC. The following TECO example demonstrates the change. NOTE: The ESCAPE () sequence can be entered on most keyboards by typing Ctrl/[. $ SET UIC [1234,567] $ TECO *3EJ/65536== 1234 *3EJ&65535== 567 Problems Addressed in the ALPVERI02_062 Kit: o VERIFY does not flag files, which are directly back linked to themselves, as having invalid backlinks. o VERIFY hangs in an infinite loop during its scan of the directory structure. Problems Addressed in the ALPVERI01_071 Kit: o ANALYZE/DISK goes into an infinite loop. VERIFY has incorrectly 'fixed' the backlink of a lost directory to point to itself. The next time VERIFY is run, it encounters the lost directory and goes into a tight loop following the directory's backlink. Problems Addressed in the ALPVERI01_062 Kit: o Errors similar to these may occur during execution of the 'ANALYZE/DISK' DCL command: %ANALDISK-W-CHKALTHOME, invalid alternate home block, VBN 3, RVN 1 %ANALDISK-W-CHKALTHOME, invalid alternate home block, VBN 4, RVN 1 %ANALDISK-W-CHKALTHOME, invalid alternate home block, VBN 5, RVN 1 This problem has been corrected in OpenVMS Alpha V7.0. Problems Addressed in the ALPF11X02_062 Kit: o An XQPERR bugcheck occurs when trying to create a file. o A bad FID (File ID) bugcheck occurs when trying to mark a file header free in the index file bitmap. o There are multiply allocated blocks and file headers on the disk. o Processes hang in an RWAST state while trying to deaccess a file during channel deassignment. o The system hangs during cluster wide cache flushes. o The contents of a header or bitmap block could be corrupted within the block buffer cache. o Failure to take an allocation lock could be ignored. o If a DEACCESS request failed with a SS$_DEADLOCK error, a process could be left in an RWAST state indefinitely. o If a large file is created on a fragmented disk that has quotas enabled and the user needs to use EXQUOTA privilege to allocate the necessary disk space, an internal XQP table can become corrupted. This leads to the following bugcheck: SECAUDERR, Fatal error attempting to perform a security audit o Attempting to queue a maximal length (39.39;5) filename to the XQP for spooling to a symbiont would cause either an infinite CPU loop or the following bugcheck: FILCNTNONZ, Open file count nonzero after process rundown Problems Addressed in the ALPF11X01_071 Kit: o The problem occurs when a file is deleted while still being accessed by someone. This produces an XQPERR bugcheck when an attempt is made to access the deleted file. o The problem may result in an XQPERR bugcheck which claims that: "all the index buffers are active" during the processing of a directory file. The problem occurs when no free directory index BFRD's are found on the first pass through MAKE_DIRINDX. The thread then stalls to allow some of the BFRD's to be freed, but doesn't release the cache lock which would allow others to do this. This means that if no free BFRD was found on the first try then none will be found on subsequent tries either, and the bugcheck will occur. Problems Addressed in the ALPF11X03_070 Kit: o BACKUP and SLS can cause WCBFCBMNG bugchecks when operating on some files. These files are legal, uncorrupted files so they should not repeatedly cause a crash whenever BACKUP or SLS tries to back them up. o A system could crash with a SECAUD bugcheck whenever ANAL/DISK/etc is run on a corrupted disk with auditing turned on. o The XQP bugchecks when a file is accessed for the first time, with cathedral windows, and the accessing process runs out of BYTLM quota. o Window mapping code could incorrectly concatenate extents which ran from one volume to another in a volume set. o XQPERR bugcheck in [F11X]DIRSCNuPDATE_INDEX() when trying to insert index entry into directory index block with DIR$W_TOTALCELLS equal to zero. o Directory FCBs can become stale but invisible to the XQP. The File IDs can then be reused, and if the FCB in question was an extension FCB, the next time the new file is accessed on that node, the XQP bugchecks with the fatal XQPERR 'wrong lockbasis with FCB present'. o If a file is opened for exclusive access on one node in a cluster and a BACKUP/IGNORE=INTERLOCK command is issued to backup the file on that node, after the BACKUP completes the file can be successfully accessed from the other node(s) of the cluster. The BACKUP destroys the exclusive access. Problems Addressed in the ALPF11X02_070 Kit: o The ALPF11X01_070 remedial kit did not install on systems running OpenVMS Alpha V6.2-1H1, as it should have. Problems Addressed in the ALPF11X01_070 Kit: o The system crashes with a BADFID bugcheck. o File name appears twice in a directory block. o System crashes with a BADDALRQSZ bugcheck o Multiple allocated blocks being reported after the defragger has been run o UNXSIGNAL crash due to a corrupt Window Control Block o File Access Control Lists are corrupted after a failure to allocated an extension File Control Block due to disk quota being exceeded. o The system crashes with 'BADFID, ACP file number out of range for this volume" The system crashes with 'Failed to allocate FID when expected' This problem is fixed in OpenVMS Alpha V7.0 o On a disk with highwater marking enabled, a file is created with several extents, of which any extent, except the last one, exceeds 2 Gb in size. When a write operation is performed on a block in the last extent of the file, the user may see blocks of a different file erased incorrectly. This problem is fixed in OpenVMS Alpha V7.0 o Lock Ranking Violation when using EDIT/EDT. The problem is caused under the following circumstances: - User B does not have an entry in the quota file. - User A has CONTROL access to user B's files. CONTROL access grants the accessor all the privileges of the objects actual owner. User A can have this access by either: - being a member of the SYSTEM group - having the necessary entry in an ACL. - User A edits one of user B's files using edit/EDT. This problem is fixed in OpenVMS Alpha V7.0 o On a large, very fragmented disk with little free space and heavy usage, an XQP lock ranking violation can occur on a regular basis This problem is fixed in OpenVMS Alpha V7.0 Problems addressed in the ALPLIBR06_062 kit: o DEBUG links LIBRTL.OLB into its DEBUG.EXE image. The LIB$CALLING_STANDARD routines included can ACCVIO when trying to walk the call chain or write to a call's invocation context block on a corrupt stack. These ACCVIOs have now been observed from DEBUG CALL commands from certain register frames. In order to receive this full fix the ALPDEBU01_062 or its supersedant remedial kit must also be installed. Problems addressed in the ALPLIBR05_062 kit: o Because multi-version kits are no longer being issued, the ALPLIBR05_070 kit, which was for OpenVMS Alpha V6.1 through V7.0, has been broken down so that there is a kit for each version. This kit, ALPLIBR05_062, is the V6.2 portion of ALPLIBR05_070. Problems addressed in the ALPLIBR05_070 kit: o The OpenVMS operating system has a documented delta-time restriction that may cause an error in some applications and OpenVMS components beginning on or around 19-MAY-1997. This ECO corrects this potential problem by removing the delta-time limit. Applications and OpenVMS components most likely to experience errors are those that pass delta-time arguments with values exceeding 9999 days on system-supplied date routines. The most likely date that these errors will occur is 19-MAY-1997:00:00, which is 10,000 days after the common UNIX time origin of 1-JAN-1970. This problem is fixed in OpenVMS Alpha V7.1. Problems addressed in the ALPLIBR04_070 Kit: o Heaps that are removed from the heap pending list are only merged with the most recently returned heap. This can lead to heap fragmentation. Problems addressed in the ALPLIBR03_070 kit: o LIBRTL.EXE was not replaced in IMAGELIB.OLB. Problems addressed in the ALPLIBR02_070 kit: o The 10,000 day limit in LIB$CVT_TO_INTERNAL_TIME causes problems for DECthreads since it is using this routine to convert UNIX times to VAX time. It will fail to work on 19-May-1997. o LIB$STAT_TIMER produces incorrect results. Elapsed time jumps significantly from the initial value to the next returned value. o Problem noticed using OTS$DIV_PK_LONG or OTS$DIV_PK_SHORT LIBRTL routine. Packed value 11259 divided by 1, yielded 1125.90083841. Only a handful of numbers cause bad results. Problems addressed in the ALPLIBR01_070 kit: o The multiplication algorithm for delta time was faulty. This is a regression in V7.0. Problems addressed in the ALPLIBR03_062 kit: o When setting host into a DECnet PhaseV system, the logical name SYS$REM_NODE is incorrectly set. When the code was originally written, there was no support for node synonyms. The code does not get the right values from the system call. Problems addressed in the ALPMTAA01_070 kit for OpenVMS Alpha V6.2, V6.2-1H1, V6.2-1H2, and V6.2-1H3: o MTAACP can hang during multivolume copy operations. NOTE: According to OpenVMS Engineering, the fixes discussed below have been included in OpenVMS Alpha V7.0. There are some fixes that have been included in previous versions of OpenVMS and those versions are specified in text following the problem descriptions. Problems addressed in the ALPMTAA01_062 kit: o The system crashes with NOBVPVCB bugcheck when performing a test for an empty queue with a DO_CANCEL function in ACPCTR.B32. o The system crashes with an XQPERR bugcheck while dismounting a MAD drive. INSTALLATION NOTES: In order for the corrections in this kit to take effect, the system must be rebooted. If the system is a member of an OpenVMS cluster, the entire cluster should be rebooted. During the kit installation you will be prompted with options to print and/or display the release notes.



This patch can be found at any of these sites:

Colorado Site
Georgia Site



Files on this server are as follows:

alpy2k02_062.README
alpy2k02_062.CHKSUM
alpy2k02_062.CVRLET_TXT
alpy2k02_062.a-dcx_axpexe

privacy and legal statement