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] ALPMOUN07_071 Alpha V7.1* MOUNT ECO Summary

TITLE: OpenVMS] ALPMOUN07_071 Alpha V7.1* MOUNT ECO Summary Modification Date: 16-JUN-1999 Modification Type: Updated Kit: Supersedes ALPMOUN06_071 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 MOUNTSHR VMOUNT DCLTABLES (updated with a new MOUNT.CLD)) SOURCE: Compaq Computer Corporation ECO INFORMATION: ECO Kit Name: ALPMOUN07_071 ECO Kits Superseded by This ECO Kit: ALPMOUN06_071 ALPMOUN05_071 ALPMOUN04_071 ALPMOUN03_071 ALPMOUN02_071 ALPMOUN01_071 ECO Kit Approximate Size: 882 Blocks Kit Applies To: OpenVMS Alpha V7.1, V7.1-1H1, V7.1-1H2 System/Cluster Reboot Necessary: No Installation Rating: INSTALL_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_071 ALPBACK04_071 ALPDISM01_071 ALPINIT01_071 ALPMTAA01_071 ECO KIT SUMMARY: An ECO kit exists for MOUNT on OpenVMS Alpha V7.1 through V7.1-1H2. This kit addresses the following problems: Problems Addressed in the ALPMOUN07_071 Kit: o A new check which was provided in the ALPMOUN06_071 kit, determines 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. If this condition is detected, then a fatal MOUNT-F-FILESTRUCT error is reported and the MOUNT is aborted. It has been determined that a number of systems 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, the change makes this condition a warning message only: %MOUNT-W-INCONSIZE, inconsistent number of blocks reported, some data may not be accessible NOTE: Since the warning message text, which is in SYSMSG.EXE, will be used by many facilities, SYSMSG.EXE will be issued in a separate kit named ALPMSGF01_071. If this MSGFIL 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 o A change was previously made to fix a problem where 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 Initializing a tape with the /MEDIA_FORMAT or /DENSITY qualifier is not always handled properly, resulting in a tape being written in a different mode than intended. Images Affected: [SYSLIB]MOUNTSHR.EXE, [SYSEXE]VMOUNT.EXE Problems Addressed in the ALPMOUN06_071 Kit: o SCB and VCB Volume Lock Name mismatch at mount time Mount Verification fails incorrectly with a "wrong volume" error if the device is mounted /NOWRITE. This failure also occurs when former shadow set members are MOUNTed without /OVERRIDE=SHADOW, which causes the device to be mounted write-locked. o MOUNT/SYSTEM CDROMs with long labels MOUNT/SYSTEM fails with an %MOUNT-F-IVBUFLEN error when an attempt is made to MOUNT an ISO 9660 CDROM with a volume label of more than 27 characters. The ISO 9660 specification allows volume labels of 32 characters. o Add REQUIRE_MEMBERS and VERIFY_LABELS switches to MOUNT command A MOUNT/POLICY=(REQUIRE_MEMBERS,VERIFY_LABELS) switch was added to the MOUNT command. This change is an enhancement, not a fix. The following switch and options were added to MOUNT: 1. /POLICY=REQUIRE_MEMBERS - force all specified members to be available for MOUNT to occur. The /POLICY=REQUIRE_MEMBERS option is used in disaster-tolerant configurations where another site may have a more recent disk that is not available. In effect, this option will force more human decision making. 2. /POLICY=VERIFY_LABELS - all copy targets must have label "SCRATCH_DISK" or they will not be added to the set The volume must be ODS2 and have a valid file structure. The new option will force users to use alternate volume labels. One of the biggest causes of "a wrong disk being added to a shadow set" is mistyped commands. If users are given a way to be sure that they only added "scratch" disks to shadow sets, then they will be less likely to lose data. This option is similar to /CONFIRM, except that it can be used in command procedures as well, without immediate operator intervention. It is also similar to the /NOCOPY command, except it allows copies to occur, as long as the label is "scratch". NOTE: Related to the above two qualifiers, the following new error messages were added to MOUNT. However, these messages will not display correctly until an updated SYSMSG.EXE has been installed on your system. Although MOUNT will still operate correctly, it will report these errors as: %NONAME-F-NOMSG, Message number 00728xxx The message numbers and their corresponding messages are as follows: 007283C4 is "NOTALLMEM, one or more specified members not available for mounting" 007283CC is "BADPOLICY, invalid syntax on /POLICY" A TIMA kit with a new SYSMSG.EXE will be available at a future date. o Synchronization problem in MME_ACTION and MME_ALLOC 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. o MME cannot mount shadow sets with media manager running $MOUNT DSAn/SHAD=$n$ddcu (shadow set), with a media manager running, causes a "no such device error" and then mount fails. o MME passed a fatal error for shadow set MME (MME_MNTREQ) broke the RAID BIND command with shadow sets. MME passes a fatal error to Host-Based Shadowing or Host-Based Raid on a MOUNT request, if the shadow set virtual unit has not been created. o Dismounting raidsets crashes system (for MME) A media management application can crash the system with an invalid exception bugcheck. The reason for the crash is due to an access violation. The crashing image is [SYSLIB]MMESHR.EXE. Problems Addressed in the ALPMOUN05_071 Kit: 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: ALPSYSA02_071 ALPBACK03_071 ALPDISM01_071 ALPINIT01_071 ALPMTAA01_071 Problems Addressed in the ALPMOUN04_071 Kit: 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 the ALPMOUN03_071 Kit: 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 the ALPMOUN02_071 Kit: o Wrong image was placed in the ALPMOUN01_071 kit. This kit fixes that problem. Problems Addressed in the ALPMOUN01_071 Kit: o If a DCL 'MOUNT DSAxxx/SHAD' is performed by a process that does not have BYPASS or READALL privileges, the MOUNT will fail if the DSAxxx did not previously exist. If the command is immediately repeated by the same process, it will be successful. 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). NOTE: After the installation, any process that attempts to do a MOUNT will fail unless a the following command is issued: $ SET COMMAND/TABLE=SYS$LIBRARY:DCLTABLES.EXE Otherwise the user should log out and then log back in.



This patch can be found at any of these sites:

Colorado Site
Georgia Site



Files on this server are as follows:

alpmoun07_071.README
alpmoun07_071.CHKSUM
alpmoun07_071.CVRLET_TXT
alpmoun07_071.a-dcx_axpexe
alpmoun07_071.CVRLET_TXT

privacy and legal statement