WEBES install and VMS

[rman]

Ok. We have finally installed WEBES v5.1 on an Itanium system running VMS v8.2-1, it installed but it did not install in the Common directory instead it install in the specific area. This customer swings the disk between production and test, so WEBES stops working due to the different root. Any thoughts on how to get WEBES to install in the common area?

[comarow]

You can rename the file to common
Sys$common directory.


Go to the top level directory and work your way
down to the common directory.

[rman]

Please read my tread in the ISEEWebes area. I believe what you are trying to get me to do will not work because the way WEBES behave but I could be wrong.

[Hoff]

WEBES installs in the specific area. I never did sort out specific details, but it looked due to file access (locking) conflicts when the various data files are accessed in parallel from multiple nodes. Accordingly, the WEBES devos seem to have trumped this by loading everything into SYS$SPECIFIC:.

What, exactly, do you mean by "swinging the disk" here?

[rman]

I will have to get a definition of a swing disk from the customer. More or less what they do is; they have a test disk we the new patches already tested then they swing the disk into production but the production systems are different roots because they are in the same cluster, do that make sense?

[Hoff]

I might guess I know what your customer is up to here, though (if I've guessed correctly) this approach looks mildly hazardous.

There are cases when what's in the particular local root Really Matters, and it looks like the production tests here are missing that case.

Based on empirical observations, I'd also tend to assume that more of this sort of stuff lurking in the cluster-specific root will be increasingly commonly found, as various of the tools and some other pieces tend to use that area far more heavily than has been traditional. (It's an easy way to avoid dealing with shared locking.)

At its simplest, might want to install WEBES into both roots, and you might want to test in both roots.

Might also want to review the test coverage, too, but that's another discussion.

[comarow]

Obviously, if it does not use the distributed lock manager, or it root specific, it will have to stay. My advise was based on general movement from specific to common directories.

That is sad as they move away from the distributed lock manager, cluster advantages would normally be automatic.

[rman]

A swing disk is a disk that is in Test and all the changes get applied to it, after that they do a save set of the sys$roots then they go to the production shadowset and break it ten they take one of this disk and strip all the root specific info and the they lay the save_set roots from the test system and then they boot.

[rman]

They are using the lockmanager!

[Hoff]

They are using the lockmanager?

"Swing disk" and "lock manager"? Those two constructs don't immediately map as related.

Can I have an antecedent for "they are using the lockmanager!" comment?

Somebody here is seriously confused.

It might well be me, of course.