Re: concerned and confused about adding shadow-set members to system disk

From: H Vlems (hvlems.nieuw_at_zonnet.nl)
Date: 10/11/03 

Date: Sat, 11 Oct 2003 16:29:03 +0200

"Phillip Helbig---remove CLOTHES to reply" <helbig@astro.multiCLOTHESvax.de>
schreef in bericht news:bm8si7$dnl$2@online.de...
> In article <bm8om5$j6ca4$1@ID-143435.news.uni-berlin.de>, "H Vlems"
> <hvlems.nieuw@zonnet.nl> writes:
>
> > You do come up with interesting questions on an early Saturday morning,
> > don't you Phillip :-)
>
> As Chaucer said, the lyf so short, the craft so long to lerne. :-)

Mr. Chaucer had remarkable insight ...

>
> > There are two options in handling shadowed system disks across a reboot:
> >
> > 1) if the system is shutdown and the systemdisk shadowset has more than
one
> > volume then these volumes will be part of the system shadowset when the
> > system is rebooted (unless you change SYSBOOT parameters in between but
that
> > would be cheating, right)
>
> Right. That's what I'm doing.
>
> > 2) if volumes are removed from the systemdisk shadowset, in
SYSHUTDWN.COM,
> > then they must be mounted explicitly; that is in SYSTARTUP_VMS.COM.
>
> Why would one do this (remove them during shutdown)?
>
> > Both methods work and it just depends on how much you have faith in your
> > diskfarms. The trouble with it is that if one volume fails then you must
> > correct the situation manually. That takes a quick analysis of what just
> > went wrong during the boot process and the knowledge to fix the problem.
Not
> > that this is really difficult but VMS systems are usually only rebooted
> > after a calamity (a problem, or a new VMS version), anyway at a time
when
> > your blood pressure might be higher than usual.
>
> In scenario 2), right?

Actually that situation descibes scenario 1. If VMS reboots and expects,
say, a two member shadow set and one of those members is damaged then the
error messages seem to confuse the operators. As long as one volume is
functional VMS itself proceeds without a problem.
>
> > That is why Digital recommends the second option. It is safer and easier
to
> > handle when something has broken during the shutdown procedure.
>
> Where is this recommendation spelled out?

Well, you quoted a manual when you wrote the part about unmounting and
mounting shadowed system disks. I took that text as a recommendation for
scenario 2.
>
> > Simply put, if you trust your hardware then use the first method, if you
> > don't use the second.
> > The way you end your post I take it you tend to trust hardware over
> > software, right :-)
>
> I trust the hardware. I trust VMS to do the right thing in the case of
> a hardware failure. I don't always trust my own untested startup
> procedures. :-|
>
I understand the sentiment but have learned te be somewhat more careful with
non-Digital designed/built equipment :-(

Relevant Pages

  • Re: What will many cores mean to future Windows releases?
    ... Obviously the hardware might be indeterminant --that would be the normal 'cross-platform' use case. ... But I would rather see an inline operation or compiler switches that would allow you to set or monitor the operations without a JIT compile each time the process ran. ... VMs have their purposes, but optimization is better determined at coding time when you know where the code is going to be deployed, rather than leaving it to be determined at runtime. ... The run time then chooses the algorithm and number of processors to devote to the task, so it's rather like an SQL 'ORDER BY' clause--the programmer specifies what the results need to look like, and the implementation details--being fairly mechanical once the business logic is understood--are handled by the compiler and runtime. ...
    (borland.public.delphi.non-technical)
  • [Full-Disclosure] Trustworthy Computing Mini-Poll
    ... It is technically doable and in the line of liberalism, ... I was talking about the "web of trust model", ... selecting hardware from different vendors and using a TCPA CPU. ... I think the copy protection features in the TCPA hardware will be born ...
    (Full-Disclosure)
  • Re: DEFCON 16 and Hacking OpenVMS
    ... But VMS cannot use the space in other ways than the hardware makes possible. ... Many of the privileged CPU registers ... All of this is hardware limitations, and VMS can't do diddly squat about it. ...
    (comp.os.vms)
  • Re: Limitations of VMs?
    ... Would anyone with direct experience of working with VMs like to comment on this review and/or on the limitations of other VM products? ... Memory or data Intensive applications and/or critical applications can have their own OS dedicated to that one application. ... No other applications outside applications that would normally running on a single instance server. ... Consolidation of Hardware: Instead of 5 servers, each with an OS, you can choose to buy one redundant server with multiple CPUs and lots of RAM and create VMs based upon need on that one box. ...
    (borland.public.delphi.non-technical)
  • Re: OpenVMs Cluster
    ... specify a hardware address. ... This is VMS 7.3-1 but Example 8–8 Sample Interactive CLUSTER_CONFIG.COM ... Long time since I did booting over LAN, so maybe the flags will be 0,0 ... >>As regards firmware version, depends on the version of VMS, later ...
    (comp.os.vms)
Loading