ECO NUMBER: VAXMOUN04_062 PRODUCT: OpenVMS VAX OPERATING SYSTEM 6.2 UPDATE PRODUCT: OpenVMS VAX OPERATING SYSTEM 6.2 COVER LETTER 1 KIT NAME: VAXMOUN04_062 2 KITS SUPERSEDED BY THIS KIT: VAXMOUN03_062 3 KIT DEPENDENCIES: 3.1 The following remedial kit(s) must be installed BEFORE installation of this, or any required kit: VAXCLUSIO01_062 3.2 In order to receive all the corrections listed in this kit, the following remedial kits should also be installed: The following kits are only required if you are running MME-based applications: VAXSYSA02_062 VAXMTAA03_062 VAXDISM02_062 VAXINIT01_062 VAXBACK03_062 4 KIT DESCRIPTION: 4.1 Version(s) of OpenVMS to which this kit may be applied: OpenVMS VAX V6.2 4.2 Files patched or replaced: o [SYSLIB]MOUNTSHR.EXE (new image) o [SYSEXE]VMOUNT.EXE (new image) o MOUNT.CLD (UPDATE TO DCLTABLES.EXE) 5 PROBLEMS ADDRESSED IN VAXMOUN04_062 KIT o A new check was provided, in the previous superseded kit, 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. -- COVER LETTER -- Page 2 9 June 1999 This size discrepancy occurs when a disk is moved from one controller type to another (eg. 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 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, 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 VAXMSGF01_062. 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 made last fall 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 -- COVER LETTER -- Page 3 9 June 1999 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 6 PROBLEMS ADDRESSED IN VAXMOUN03_062 KIT o This kit provides a new check to determine if the disk that being MOUNTed is initialized to a size that is larger than the number of blocks that are currently available. This condition is a result of a disk that is moved from one controller type to another (for example, from a local SCSI connection to an HSJ) without the disk being initialized on the new controller. o 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 When MOUNTing a volume (usually immediately after the volume has been dismounted), the error MOUN$_IVLOCKID is returned. However, if the command is simply retried, then the MOUNT succeeds. This change allows MOUNT to automatically retry on the IVLOCKID error, just as it does with many other errors. o 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 A MOUNT/POLICY=(REQUIRE_MEMBERS,VERIFY_LABELS) switch was added to the MOUNT command. This change is an enhancement, not a fix. -- COVER LETTER -- Page 4 9 June 1999 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 mis-typed 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". o %MOUNT-F-VOLALRMNT errors are received when MOUNTing multiple CDs privately. o The stack receives a corrupted DATA_POINTER variable since the LOAD_MSG_DSCDEV macro declares a local variable DEV_SIZE as long. Previously, the GETDVI system service wrote the devnam size to the DEV_SIZE variable. o Tapes are not correctly initialized when using the /SCRATCH qualifier with a Media Management Extension (MME) application. Although the tape is rewound, the HDR1 information is not being reset/rewritten properly. As a result, HDR1 items such as FILESEQNO may not be correct. Subsequent tapes are also not initialized. 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 to eliminate all known instances of this problem, the following remedial kits (or their supersedants) will also need to be installed: VAXSYSA02_062 VAXINIT01_062 -- COVER LETTER -- Page 5 9 June 1999 VAXBACK03_062 VAXMTAA03_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. o $MOUNT DSAn/SHAD=$n$ddcu (shadow set), with a media manager running, causes a "no such device error" and then mount fails. o 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 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 7 PROBLEMS ADDRESSED IN VAXMOUN02_062 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. 8 PROBLEMS ADDRESSED IN VAXMOUN01_062 KIT 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. -- COVER LETTER -- Page 6 9 June 1999 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. -- COVER LETTER -- Page 7 9 June 1999 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. o When using MME with MOUNT, and an error is encountered, an EXEC mode exception will occur. 9 KIT INSTALLATION RATING: The following kit installation rating, based upon current CLD information, is provided to serve as a guide to which customers should apply this remedial kit. (Reference attached Disclaimer of Warranty and Limitation of Liability Statement) INSTALLATION RATING: INSTALL_3 : To be installed by customers experiencing the problems corrected. 10 INSTALLATION INSTRUCTIONS: Install this kit with the VMSINSTAL utility by logging into the SYSTEM account, and typing the following at the DCL prompt: @SYS$UPDATE:VMSINSTAL VAXMOUN04_062 [location of the saveset] The saveset location may be a tape drive, CD, or a disk directory that contains the kit saveset. The images in this kit will not take effect until the system is rebooted. If you have other nodes in your OpenVMS cluster, 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. Copyright (c) Compaq Computer Corporation, 1999 All Rights Reserved. Unpublished rights reserved under the copyright laws of the United States. The software contained on this media is proprietary to and embodies the confidential technology of Compaq Computer Corporation. Possession, use, or dissemination of the software and media is authorized only pursuant to a valid written license from Compaq Computer Corporation. DISCLAIMER OF WARRANTY AND LIMITATION OF LIABILITY -- COVER LETTER -- Page 8 9 June 1999 THIS PATCH IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR PARTICULAR PURPOSE, OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED TO THE EXTENT PERMITTED BY APPLICABLE LAW. IN NO EVENT WILL COMPAQ BE LIABLE FOR ANY LOST REVENUE OR PROFIT, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, WITH RESPECT TO ANY PATCH MADE AVAILABLE HERE OR TO THE USE OF SUCH PATCH.