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 VAXODS1_01_062 VAX V6.2 ODS-1 ECO Summary

TITLE: OpenVMS VAXODS1_01_062 VAX V6.2 ODS-1 ECO Summary Modification Date: 14-DEC-1999 Modification Type: New Kit 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) Compaq Computer Corporation 1999. All rights reserved. OP/SYS: OpenVMS VAX COMPONENT: ODS1 BACKUP DUMP F11AACP F11BXQP F11CACP F11DACP INIT$SHR MTAAACP STABACKUP VERIFY SOURCE: Compaq Computer Corporation ECO INFORMATION: ECO Kit Name: VAXODS1_01_062 ECO Kits Superseded by This ECO Kit: None The VAXODS1_01_062 does not supersede any other kits. However, it does include problem corrections shipped in the VAXF11X05_062, VAXVERI02_062, VAXINIT01_062, VAXMTAA03_062, VAXBACK03_062 and VAXF11C01_062 remedial kits. If you install the VAXODS1_01_062 kit, you do not need to install any of these other remedial kits. ECO Kit Approximate Size: 1800 Blocks Kit Applies To: OpenVMS VAX V6.2 System/Cluster Reboot Necessary: Yes Rolling Re-boot Supported: Yes Installation Rating: INSTALL_2 2 - To be installed on all systems running the listed version(s) of OpenVMS and using the following feature(s): Users of ODS-1 Format Files Kit Dependencies: The following remedial kit(s) must be installed BEFORE installation of this kit: VAXCLUSIO01_062 VAXY2K02_062 In order to receive all the corrections listed in this kit, the following remedial kits should also be installed: VAXSYSA02_062 VAXDISM02_062 VAXMOUN04_062 VAXCLIU08_062 ECO KIT SUMMARY: An ECO kit exists for Y2K and other issues on ODS-1 on OpenVMS VAX V6.2. This kit addresses the following problems: Problems Addressed in this kit: o The 64 bit internal time is not formatted to an RSX-11 compatible ASCII string. An RSX date string contains only a 2-character year field (ASCII). In order to accommodate the year 2000, this ASCII encoding will now include the value of decades (since 1900) in the string. This means that for the years 1900 through 1999, the date string will appear as 00 to 99. For the years 2000 through the years 39xx, the string will show as ':0', ';0' and so forth. Images Affected: - [SYSEXE]F11AACP.EXE - [SYSLIB]INIT$SHR.EXE - [SYSEXE]VERIFY.EXE - [SYS$LDR]F11BXQP.EXE - [SYSEXE]MTAAACP.EXE - [SYSEXE]F11CACP.EXE - [SYSEXE]F11DACP.EXE - [SYSEXE]DUMP.EXE - [SYSEXE]BACKUP.EXE - [SYSLIB]BACKUPSHE.EXE - [SYSEXE]STABACKUP.EXE o Attempting to mount the second volume of a two-volume RMU backup results in %MOUNT-F-MEDOFL and %MOUNT-F-FILACCERR errors. Images Affected: [SYSEXE]MTAAACP.EXE o Verify does not flag files which are directly back linked to themselves as having invalid backlinks. Images Affected: [SYSEXE]VERIFY.EXE o VERIFY hangs in an infinite loop during its scan of the directory structure. Images Affected: [SYSEXE]VERIFY.EXE Problems Addressed in the VAXF11X05_062 Kit: o During the mounting of the system disk, the error message that the disk is mounted with a reduced cache is suppressed. Hence, the System Manager may be unaware that the performance of the system disk and all others attached to the same cache block is questionable. Image Affected: [SYSEXE]FILESERV.EXE o When deleting a large file (such as a system dump file), a UNXSIGNAL Bugcheck may occur. This particular bugcheck occurs because a variable in the code causes a reference to memory data that the file system does not own and an internal access violation occurs (ACCVIO). Image Affected: [SYS$LDR]F11BXQP.EXE o On some systems with higher rates of system paging or with WSDEC set to a non-standard value, a system can crash with a PGFLIPLHI (Page Fault IPL too High) bugcheck. This problem happened when the system returns from a SMP$ACQUIRE call. Image Affected: [SYS$LDR]F11BXQP.EXE o An XQPERR can occur in the RDBLOK module during disk cleanup using DCL. Image Affected: [SYS$LDR]F11BXQP.EXE o When storing the value of a directory index buffer, the system may crash with a PGFLIPLHI, SSRVEXCPTN error. Image Affected: [SYS$LDR]F11BXQP.EXE o A dismount on a shadowded device results in an unnecessary copy. Image Affected: [SYS$LDR]F11BXQP.EXE o If a process is created with a termination mailbox unit assigned, the files are not properly audited. Image Affected: [SYS$LDR]F11BXQP.EXE o An XQPERR bugcheck (crash) in the RETURN_CREDITS module can occur during DISMOUNT. Image Affected: [SYS$LDR]F11BXQP.EXE o An XQPERR Bugcheck (crash) in XQP can occur during a SET ACL (SET FILE/ACL) operation. Image Affected: [SYS$LDR]F11BXQP.EXE o When two processes are competing to dismount a volume, one process may be just a bit faster than the other and delete the VCB and other structures before the second process has time to finish up its processing. The result is a UNXSIGNAL/ACCVIO crash. Image Affected: [SYS$LDR]F11BXQP.EXE o A device reporting a read error (SS$_PARITY) during read/write processing in the XQP will attempt to record the bad blocks and FID in the BADLOG.SYS file. When the internal close operation occurs (on BADLOG), the system XQPERR bugchecks when it finds the process's dirty buffers have not been written out. Image Affected: [SYS$LDR]F11BXQP.EXE o A UNXSIGNAL/ACCVIO error can occur at module F11BXQP. This problem occurs during mount, when the primary volume is not yet mounted. Image Affected: [SYS$LDR]F11BXQP.EXE o Processes can hang (deadlock) when dismounting a device. Image Affected: [SYS$LDR]F11BXQP.EXE o A 'no such file' error can occur on directory extension FCBs. This problem can occur in at least two ways: 1. A file appears normal on one node but has an 'no such file' error from another node. 2. BACKUP or DUMP /HEADER encounters a read attributes error of NOSUCHFILE. This error occurs when an attempt is made to read a file header, for which the FCB for the old header is still in memory. Image Affected: [SYS$LDR]F11BXQP.EXE o Alternate file access checking does not provide the correct information for files on ODS-1 disks. That is, an ODS-1 disk access does not process the alternate file access checking parameters FIB$L_ALT_ACCESS and FIB$L_STATUS. Image Affected: [SYSEXE]F11AACP.EXE o The F11A routine ACPCONTROL only understands the control function REMAP_FILE. Hence, for illegal function codes, all other control functions return NORMAL, when ILLIOFUNC should be returned instead. Image Affected: [SYSEXE]F11AACP.EXE o Occasional false end-of-file (EOF) errors can occur on a read operation. Image Affected: [SYS$LDR]F11BXQP.EXE o The XQP fails after an IO$_DEACCESS call with an SS$_BADPARAM error. One cannot determine whether a file is still open or not due to the failed IO$_DEACCESS call. Image Affected: [SYS$LDR]F11BXQP.EXE o Non-privileged users can change the revision date (and count) of a file for which they should have only READ access. For example, if a non-privileged user with READ-only file access tries to set the file protection, a failure occurs with an SS$_NOPRIV error as expected. However, the revision date (and count) are modified. Image Affected: [SYS$LDR]F11BXQP.EXE Problems Addressed in the VAXF11X04_062 kit: o An XQPERR bugcheck error, "all the index buffers are active", occurs when running with a reduced cache or during a BACKUP. o An XQPERR bugcheck error, 'wrong lock basis with FCB present', occurred when creating files with ACLs on a full volume. o One can serialize on the wrong volume in a volume set. o Fix a reserved operand fault bugcheck on $QIO exit. The $QIO failed on return because the IPL was set to zero but was entered at IPL 2. o $GET_SECURITY was reading the ORB on a file without any synchronization with the file system. In the best case, this problem can lead to bad information being returned. In the worst case, if the file system was rebuilding the ORB's ACL chain at the time, a kernel mode ACCVIO can occur. *** Note: In order to get this fix, you must also install the kit VAXSYSA01_062. Problems Addressed in the VAXINIT01_062 Kit: o A possible system crash occurs during Host Based RAID Unbinds with MME code enabled. A mailbox read synchronization problem causes the crash. This problem only occurs when a host-based RAID UNBIND command is done while an MME-based application is running. This problem can occur in several different code areas of the operating system. In order to eliminate all known instances of this problem, the following remedial kits (or their supersedants) will also need to be installed: VAXSYSA02_062 VAXBACK03_062 VAXMOUN03_062 VAXINIT01_062 VAXMTAA03_062 o A process using MME could potentially "miss" the VOL1 label on a tape. Also, a process could "hang" trying to send a message to the MME process. Problems Addressed in the VAXVERI02_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 VAXVERI01_071 Kit for OpenVMS VAX V6.2, V6.2-0HF: 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 VAXVERI01_062 Kit for OpenVMS VAX V6.2: 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 NOTE: In order to receive this full fix, in addition to this kit, the VAXCLIU04_062 kit or any kits that supersede it, must also be installed. This problem is fixed in OpenVMS VAX V7.0. Problems Addressed in the VAXBACK03_062 Kit: o A possible system crash occurs during Host Based RAID Unbinds with MME code enabled. A mailbox read synchronization problem causes the crash. This problem only occurs when a host-based RAID UNBIND command is done while an MME-based application is running. The problem may occur in several different code areas of the operating system. In order get eliminate all known instances of this problem, the following remedial kits (or their supersedants) will also need to be installed: VAXSYSA02_062 VAXMOUN04_062 VAXDISM02_062 o A process using MME could potentially "miss" the VOL1 label on a tape. Also, a process could "hang" trying to send a message to the MME process. Problems Addressed in the VAXBACK02_062 Kit: o The VAXBACK01_062 remedial kit should have included the BACKUP.CLD file to update DCLTABLES.EXE. After installing the VAXBACK01_062 kit, users saw error messages due to a missing /NO_INCREMENTAL qualifier. If systems in the cluster utilize different DCLTABLES, even if booting from a common system disk, this kit must be installed on those systems to update the DCLTABLES.EXE. Problems Addressed in the VAXBACK01_062 Kit: o Incremental restores may get an INCDELERR error message and loop continuously when attempting to perform a directory tree delete on a specific DIR filespec. The following text is an example of the message syntax: %BACKUP-E-INCDELERR, error deleting $4$DUA153:[GHONEY.WINDATA.NETSCAPE.CACHE]CACHE.DIR;1 -SYSTEM-W-NOSUCHFILE, no such file o A possible ACCVIO (access violation) can occur when backing up volume sets, particularly individual relative volumes. o A possible loss of device cacheability when volume labels are overwritten could occur. Tape subsystems behave differently. Re-initializing a tape device cache value on volume switches may result in the loss of characteristic. The type of tape subsystem and its stickiness of characteristic aggravates the problem. o One cannot append to a non-expired tape on saveset appends when using the /EXACT_LABEL qualifier. Tape_expiration logic has a check specifically for the (/EXACT_LABEL) qualifier. o BACKUP may invoke a Restart operation during a network RESTORE operation when the link breaks. BACKUP was treating the network saveset read as if it were a tape device. o A new qualifier was added to invoke pre-OpenVMS V6.2 /SINCE behavior. After enhancements to INCREMENTAL restores was done, feedback from customers and Customer Support Centers (CSCs) indicated that not everyone was completely pleased with the new /SINCE behavior. Old style (pre-OpenVMS V6.2) /SINCE behavior can be invoked by adding the new /NO_INCREMENTAL qualifier to the BACKUP command line. Note that this change was implemented differently in OpenVMS V7.1. Check the OpenVMS V7.1 release notes for that implementation. o After installing VAXMOUN02_062, BACKUP/NOASSIST no longer works. However, BACKUP/ASSIST works fine. Problems addressed in the VAXMTAA03_062 kit: o A possible system crash occurs during Host Based RAID Unbinds with MME code enabled. A mailbox read synchronization problem causes the crash. This problem only occurs when a host-based RAID UNBIND command is done while an MME-based application is running. This problem can occur in several different code areas of the operating system. In order to eliminate all known instances of this problem, the following remedial kits (or their supersedants) will also need to be installed: VAXSYSA02_062 VAXBACK03_062 VAXMOUN03_062 VAXINIT01_062 VAXDISM02_062 o A process using MME could potentially "miss" the VOL1 label on a tape. Also, a process could "hang" trying to send a message to the MME process. Problems addressed in the VAXMTAA02_062 Kit: o This kit is a re-issue of the VAXMTAA01_062 kit with the OpenVMS VAX V6.2 portion only. The V6.1 section of the VAXMTAA01_062 kit will be superseded by a future Shadowing kit. Problems addressed in the VAXMTAA01_062 Kit: o The system crashes with a NOBVPVCB bugcheck. The crash occurs on the kernel stack with MTAAACP.EXE as the current image. o The system crashes with an XQPERR while dismounting a MAD drive. Problems Addressed in the VAXF11C01_062 Kit: o A Non-compliant ISO 9660 CD-ROM may have been incorrectly mastered such that the volume set fields in various ISO 9660 meta-data are left as '0'. ISO 9660 supports volume sets in the range of 1 to 32767, so there is no volume set '0'. The code which does volume switching, has a coding error which causes an INVEXCPTION crash. o The $QIO READ-ATTRUBUTES entry for ATR$C_BACKLINK fails to return the current file/directories backlink in all cases. This failure impacts Pathworks directory caching. INSTALLATION NOTES: The images in this kit will not take effect until the system is rebooted. If there are other nodes in the VMScluster, they must also be rebooted in order to make use of the new image(s). If it is not possible or convenient to reboot the entire cluster at this time, a rolling re-boot may be performed. All trademarks are the property of their respective owners.



This patch can be found at any of these sites:

Colorado Site
Georgia Site



Files on this server are as follows:

vaxods1_01_062.README
vaxods1_01_062.CHKSUM
vaxods1_01_062.CVRLET_TXT
vaxods1_01_062.a-dcx_vaxexe
vaxods1_01_062.CVRLET_TXT

privacy and legal statement