[Info-vax] Reconfiguring VMS 6.2 - Shadow set question

[Jan-Erik Soderholm]

Stephen Hoffman wrote 2012-10-22 13:30:
> On 2012-10-22 10:42:43 +0000, Jan-Erik Soderholm said:
>
>> Stephen Hoffman wrote 2012-10-22 12:26:
>>
>>
>>>
>>> Now...
>>>
>>> You could have hardware problems with the disk devices that were specified
>>> in the shadowset MOUNT commands, or they could have been removed, or you
>>> could have one of the usual SCSI hardware problems with this box.  The only
>>> way to be sure is to open the box and look.
>>
>> He *wrote* that DKA200 and DKA400 was (or had been) external disks.
>> And he also wrote that he *knew* that they where "gone".
>
> Ok.  That was the "they could have been removed" option.    I've
> encountered folks that use "gone" to mean "not visible".  Such as "I re-ran
> the configuration, and then the disks were gone..." Technical-English is a
> funny language, and different folks use it, well, differently.
>
>>
>>> Given that you are not particularly experienced with VMS, I would strongly
>>> recommend nuking and paving this disk.  A fresh installation...
>>
>> No no no...
>
> You have your opinion.  I have mine.
>
> Reverse-engineering an existing OpenVMS installation - even when the system
> manager is experienced with OpenVMS system management - is not high on my
> list of tasks.
>
> Reverse-engineering one where the hardware has changed - using your
> interpretation of "gone" - is further down on my list.
>
> Now if this were an existing server in an existing production environment,
> then I wouldn't be suggesting that option directly, though I would be
> working toward it.  But a new-to-the-owner box?  I'd wipe and install the box.
>
>> *Is* there any actual problem with this system at all ??
>
> Other than being a disk that's filled with random junk?   Ummmmm. OK.
>
> I'm mildly surprised there's anything on the disk; it's more typical to
> erase the available storage to avoid leaking any sensitive data.  This if
> the supplier is going to transfer the disks at all.  Some don't. Some scrap
> the disks.  But I digress.
>
>> Apart from the *informational* message at the MOUNT, but that is
>> just "FYI", so to speek. It's not an error, from VMS's point of view.
>
> It's an error from the perspective of somebody that hasn't yet become
> comfortable with a MOUNT command, or we wouldn't be posting in this thread.
>
>> There is not any major problem here, two disks are "gone" and no
>> re-install in the world will get them back...
>
> I don't understand why VMS folks are so allergic to the nuke-and-pave. Like
> the folks striving for "uptime", system management isn't a contest.
> Nuke-and-pave gets a clean environment, with known settings, with pristine
> files, and with fewer lurking weirdnesses, and an environment that more
> directly matches the OpenVMS documentation.  It's more maintainable.
>
>


OK. I might have lost some of the background here. :-)

I read it like that this is some production system that
this guy has got the responsability of reasently.

Now, *if* this is a hobbyist system that has moved out from
it's former (production?) owner, well, then it is a whole
other situation of course, and your points are quite valid.

I only replied to the facts in this thread as such and to
the actual "problem" (or not :-) ) that was reported.

My point was only that the whole reason d'etre for shadowing
is to be able to lose a member and continue running. There
is nothing had *has* to be done about it in the short term.
VMS is very happy as is with single member shadow sets.

Jan-Erik.