[Info-vax] Unpleasant Disk Shadowing Surprise

[Michael Moroney]

tadamsmar <tadamsmar at yahoo.com> writes:

>This is VMS 7.3-2 on a DS10.  I am at V19.0 on patch updates (applied
>in July 2009)

>Our real-time application halted for more than 3 minutes.

>After the incident I found here was a disk error on one member of the
>shadow set.

>The first indication was whe the application watchdog alarm went off.

>According to the console log, more than 30 seconds after the watchdog
>sounded, the shadow set changed state, the offending disk went
>offline, a mount verification started and completed.

>Immediately after the mount verification completed, VMS started
>working again.

>Looks like the disk system was inaccessible for about 3 minutes and
>any process that tried to use it got
>halted somehow.

>Is this to be expected?  We have had VMS and disk shadowing running
>the application for 20 years or so, but I don't know that we have ever
>had a disk error while the watchdog was configured to sound, so we
>might not have noticed the halting and recovery.

What is the value of SYSGEN parameter SHADOW_MBR_TMO (or SHADOW_SYS_TMO
if the shadowset in question was the system drive) ?

What is the value of MVTIMEOUT?

If a drive goes bad, SHADOWING will try SHADOW_MBR_TMO seconds before
giving up on it.  The default is 120 seconds, I think it's 600 seconds on
older versions of VMS.

MVTIMEOUT is an overall retry timer, its default is 3600 seconds (1 hour).