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] ALPMOUN05_062 Alpha V6.2 - V6.2-1H3 MOUNT ECO Summary

TITLE: *OpenVMS] ALPMOUN05_062 Alpha V6.2 - V6.2-1H3 MOUNT ECO Summary Modification Date: 29-JUN-1999 Modification Type: Updated Kit: Supersedes ALPMOUN04_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) Compaq Computer Corporation 1998, 1999. All rights reserved. PRODUCT: OpenVMS Alpha COMPONENT: MOUNT SOURCE: Compaq Computer Corporation ECO INFORMATION: ECO Kit Name: ALPMOUN05_062 ECO Kits Superseded by This ECO Kit: ALPMOUN04_062 ALPMOUN03_062 ALPMOUN02_062 (Not released) ALPMOUN01_062 ECO Kit Approximate Size: 882 Blocks Kit Applies To: OpenVMS Alpha V6.2, V6.2-1H1, V6.2-1H2, V6.2-1H3 System/Cluster Reboot Necessary: No Installation Rating: INSTALL_3 3 : To be installed by customers experiencing the problems corrected. KIT DEPENDENCIES: The following remedial kit(s) must be installed BEFORE installation of this, or any required kit: None In order to receive all the corrections listed in this kit, the following remedial kits should also be installed: ALPSYSA02_062 ALPBACK02_062 ALPDISM02_062 ALPINIT01_062 ALPMTAA02_062 ECO KIT SUMMARY: An ECO kit exists for MOUNT on OpenVMS Alpha V6.2 through V6.2-1H3. This kit addresses the following problems: Problems Addressed in ALPMOUN05_062: o The previous version of this kit contained a fix for a problem in which SWL disks do not come out of mount verification properly. The fix insured that the VCB$T_VOLOCKNAM matches the SCB$_VOLOCKNAME of the volume, even for privately mounted disks. However, if a member of a shadow set is removed from the set for BACKUPs, then both the still-mounted shadow set and the privately mounted former member will have the same VCB$T_VOLOCKNAMs. This causes a variety of symptoms, including access conflicts during BACKUPs of the former member and in at least one case, an XQPERR, Error detected by file system XQP bugcheck at F11BXQP_PRO+0BE48. In addition, reports of customers unable to MOUNT multiple CDROMS have been attributed to this problem. The original fix has been removed to fix these problems. As a result, the original problem may still occur. If a disk is write-locked, it will not successfully complete mount verification. The device will be marked as "wrong volume". Compaq OpenVMS Engineering continues to research solutions to this problem. Images Affected: [SYSLIB]MOUNTSHR.EXE, [SYSEXE]VMOUNT.EXE o /MEDIA_FORMAT and /DENSITY qualifiers are not always handled properly, resulting in tapes being written in different modes than intended. Images Affected: [SYSLIB]MOUNTSHR.EXE, [SYSEXE]VMOUNT.EXE o A new check is provided to determine if the disk that is being MOUNTed is initialized to a size that is larger than the number of blocks that are now available. This size discrepancy occurs when a disk is moved from one controller type to another (e.g., from a local SCSI connection to an HSJ), without the disk being initialized on the new controller. As a result, some data may be inaccessible through the new controller. It has been determined that a number of customers are running with disks which are in this condition. While data may be inaccessible on the disk, the usefulness of the disk should be left to the discretion of the System Manager. Therefore, if this condition is detected, a warning message is displayed: %MOUNT-W-INCONSIZE, inconsistent number of blocks reported, some data may not be accessible Note that the warning message text will be shipped in a separate kit, ALPMSGF04_062, which contains the SYSMSG.EXE image. If the ALPMSGF04_062 kit has not been installed, then the following message will be output: %MOUNT-W-NOMSG, Message number 007290D0 It is recommended that the BACKUP utility be used to move data from a disk on one controller type to a disk on another controller type, especially if those controllers report a different number of blocks available for the same disk type. Once the data has been moved, the physical disk can be moved and initialized on the new controller. Image(s) Affected: [SYSLIB]MOUNTSHR.EXE, [SYSEXE]VMOUNT.EXE Problems Addressed in ALPMOUN04_062: o MailBox Read synchronization problem in MME_MBX_COMM 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 may occur in several different code areas of the operating system. In order to eliminate all instances of this problem, the following remedial kits (or their supersedants) will also need to be installed: o ALPSYSA02_062 o ALPBACK02_062 o ALPDISM02_062 o ALPINIT01_062 o ALPMTAA02_062 Problems Addressed in ALPMOUN03_062: o If the target disk of a shadow copy has been initialized, such that the SCB is in a different location than that of the master node (i.e. INIT/INDEX=END), and the shadow copy has not yet started, then validation during a second MOUNT of this disk would fail with an ISAMBR error. However, this error message was incorrect; the actual error was a WRONGVU error. Problems Addressed in ALPMOUN02_062: o There have been a number of reports of "MOUNT-F-ISAMBR" error messages on MOUNT/SHADOW. Most of them were not reproducible and most of them were on shadow sets that were already mounted elsewhere in the cluster. This error message does not give the user any idea why the MOUNT failed. The failure message is now clearer. o A device could be mounted /NOSHARE on one system and as the member of a shadow system disk on another system. This could result in Disk Corruption. No "Alloc. lock ID" is setup on the booting system. o A MOUNT of a former shadow set member will fail on all nodes in a cluster, except the first mounting node, with a "%MOUNT-F-DIFVOLMNT" failure. o A MOUNT of multiple tape devices with one command will cause inconsistent "write lock" attributes. For example: $ mount/write mkb400,mkb500 MKB400,TZ000 %MOUNT-I-MOUNTED, MKB400 mounted on _N24005$MKB400: %MOUNT-I-MOUNTED, TZ000 mounted on _N24005$MKB500: $ sho dev mkb Device Device Error Volume Free Trans Mnt Name Status Count Label Blocks Count Cnt MKB400: Mounted alloc 0 MKB400 0 1 1 MKB500: Mounted alloc 0 TZ000 0 1 1 wrtlck MKB500 should not be "wrtlck". o MOUNT messages obtained through OPCOM with MOUNT/ASSIST are often less helpful than the error code returned when /NOASSIST is specified. For example: $ MOUNT/ASSIST /OVER=ID mua0: %MOUNT-I-OPRQST, device _SCSI3$MUA0: contains the wrong volume %MOUNT-I-OPRQST, Please mount device _SCSI3$MUA0: MOUNT/NOASSIST /OVER=ID mua0: %MOUNT-F-NOTLABELMT, tape is not labeled The "NOTLABELMT" is a more accurate message than "wrong volume". o MOUNT/FOREIGN/CLUSTER DUnxx will mount the disk locally, but fails to mount the device on other nodes in the cluster. The error message is: %MOUNT-W-RMTMNTFAIL, _$4$DUA216: failed to mount on node BEAR -MOUNT-F-CONFQUAL, conflicting qualifiers o Failure of a tape MOUNT would cause MOUNT to retry the MOUNT for 2 minutes before reporting the error to the user and OPCOM. This time is wasted under many circumstances as the drive status will not change without operator intervention. o If the /SYSTEM qualifier was not used when adding a member to an existing shadow set, that was mounted with /SYSTEM, the add appeared to be successful. It was not. The resulting behavior ranges from member copies that never happen ("0% copies") to system crashes. o Since the MOUNT96 rewrite some customers have had an issue with the extended period of time MOUNT attempts retries. When one or more members of a shadowset are offline/unavailable for mounting, a mount of that shadowset is observed to take approximately 2 minutes to complete. This leads to unacceptably long delays in system and application startup completion. o Attempting to MOUNT/SYSTEM two ISO-9660 volumes, whose volume labels are not unique in the first 12 characters, results in an "another volume of the same label already mounted" error. Problems Addressed in ALPMOUN01_062: o If per-disk licensing is used, MOUNT may end up in an infinite loop if this is the first mount of any shadow set and the system disk is unit 0. This problem is corrected in OpenVMS Alpha V7.0. INSTALLATION NOTES: The system does not need to be rebooted after this kit is installed. However, if you have other nodes in your OpenVMS VMScluster, they should be rebooted or you should install this kit on each system in order to make use of the new image(s).



This patch can be found at any of these sites:

Colorado Site
Georgia Site



Files on this server are as follows:

alpmoun05_062.README
alpmoun05_062.CHKSUM
alpmoun05_062.CVRLET_TXT
alpmoun05_062.a-dcx_axpexe
alpmoun05_062.CVRLET_TXT

privacy and legal statement