|
HP OpenVMS Systemsask the wizard |
|
The Question is: I had an annoying issue the other day. I just upgraded our AS 800 from OVMS 7.2-1 to 7.3-2. For the upgrade, I created a dir on the userdisk(dka100:) to hold all the patches for 7.3-2 as below. $ create/dir dka100:[system] I downloaded several patches such as: VMS732_UPDATE-V0200 DEC-AXPVMS-TCPIP_ECO-V0504 VMS732_DCL-V0200 VMS732_LIBRTL ... When I tried to do an image backup of the userdisk, the dev (dka100:) went offline and went into a mountverify loop. I tried this twice and both times the backup made it to the dka100:[system] dir that I had created and then went offline. I then booted mi n and did anal/disk/repair dka100: and it was clean. I then mounted the disk privately and tried backup dka100: mkb600:.... and the same thing happened. I then deleted the dir and all patches and the image backup ran just fine. My question is, was it the dir [system] or the patches the caused the device to go offline? I can try and get a test box to test this on but just wanted your thoughts. Thanks in advance. The Answer is : Mount verification is the expected OpenVMS response to retryable I/O errors. Please contact your prefered hardware support organization, or HP services. The most common causes of mount verification errors are transient hardware errors, though there are also cases where more serious hardware errors -- or occasionally even software errors -- have triggered mount verification errors. Mount verification occurs when an error that is deemed retryable and potentially fixable is returned on an I/O. There can be controller and network-level reconfigurations that cause transient connectivity losses, and an I/O occuring during such an outage will trigger the mount verification (MNTVER) processing -- at least one older disk storage subsystem had a fixed disk and a removable disk on the same spindle and motor assembly, and spinning down to remove the removable disk platter would trigger mount verification. There are other potential triggers -- mount verification can also be triggered by hardware problems. Details on instances of hardware errors can generally be retrieved from the system error log. As an obvious precaution -- should this be triggered by a failing disk spindle or other failing storage hardware -- please perform a full disk BACKUP/IMAGE operation of any critical data. Related discussions include (2602), (3277), (4680), (6685), (6745), (7033), (8101), (8764), (9036), and (9095).
|