Concealed Device definitions

[Ian Miller.]

There is always new things to learn :-)

The DISK$volumelabel logicals are special in that they are created by $MOUNT and I think are linked to the device data structures but I can't find the reference at present.

However the restriction is there. I translate the DISK$volumelabel logicals when defining other logicals.

[Joseph Huber_1]

Ian, yes, I even don't think there is a special link of DISK$label logicals to I/O data-structures, they are just [EXEC] logicals with the [concealed,terminal] attributes defined by mount.
With "more work if not relying to the unsupported behaviour" I mean:
instead of just remount a volume, which redefines the DISK$label logical and hence depending logicals, which contain DISK$label in their equivalence string, one has to redo all those definitions via single applications startup-file.
For applications which install images, this was always needed, but I have many which merily define logicals to point to various files/directories, it was handy just to use DISK$label.
Well now I know that I may have to edit all those when upgrading in future ...

[Jan van den Ende]

Joseph,

goes to show that VMS (by its consistent structure) more-or-less automatically leads to parallel devellopment of similar ideas!

ONE file to define Logical Names for disks
and another ONE to define the concealed devices.
Noone outside the VMS crowd will even believe a system (or cluster) can be SO flexible!

(your idea of using the DISK$xxx logicals has one advantage: even those are defined automatically; and one disadvantage: because they are defined by MOUNT, they do not exist BEFORE the MOUNT, and so, cannot be used to specify the MOUNT command).

Proost.

Have one on me.

jpe

[Joseph Huber_1]

>> cannot be used to specify the MOUNT command

Oh yes, that's my final wish: I would like to tell the system just "I want to mount a disk labelled xyz".
Don't laugh, I used to use such a system many years ago: CMS (although the underlying VM still had to know the physical device :-). For a user (not so much the system manager) it made a big difference: he has to say just what he wants, not WHERE it is.

[Jan van den Ende]

Joseph,

let me explain in some more detail how we do that.

In our LNM$SYSCLUSTER table we have defined for each disk a logical name with the disklabel as name and the physical name as translation. (plus logical names for tapedrives and CDs, but that aside)

On the unlikely event of a cluster reboot (at least, unlikely at our site :-) we have: ONE procedure FYSDEV.COM that is executed during bootstrap. It DEFINEs those logicals, but only if they are not alserady present in the cluster LNM table.

After that, we never ever use any physical names anymore:

$ MOUNT/CLUSTER DISKnn /SHADOW=(DISKnnA,DISKnnB,DISKnnC) DISKnn

Where all disks have labels DISKnn

All data stuctures are relative to Concealed Devices derived from their current DISKxx:

Is this getting closer to ure desired situation?

hth

Proost.

Have one on me.

jpe

[Joseph Huber_1]

Jan, Yes, that's the closest we can come in VMS.
I know well with the big variety of bound volume-,shadow-sets, and SANs it will never be possible to implement a general "mount by volume label".
So let's summarize:
With the current behaviour it is possible to have a central point of assigning logicals for disks via the MOUNT command, and then use it in derived concealed device definitions.
But the supported way is to always use the translation to a physical device in concealed device logicals.

[John Gillings]

> it will never be possible to implement a general "mount by volume label".

Rather than mounting disks by volume label, something I've used on several clusters is mounting disks by "nickname". The point is to break the connection between a logical storage "thing" and the physical device containing it.

During startup, whenever a disk is needed, I execute (for example):

$ @SYS$STARTUP:GETDISK USRDSK

The procedure works out which physical disk is needed, and mounts it if it isn't already mounted. When it returns, the symbol USRDSK_DISK is defined with the physical name of the device. The definitions of the disks can be stored in a file, or hard coded logic. Whatever, it makes it MUCH easier to rearrange your storage, and you no longer have to care about sequencing of MOUNT commands. Multiple logical stores can be mapped to the same physical drive.

In one implementation, all the stores are 3 member shadow sets, with all the policies coded inside GETDISK. A second parameter can be specified to reduce the shadow set to 2 members for backup, or reform the 3 member set. By ruling that no "naked" MOUNT commands are allowed on the system, we can be fairly confident that there won't be any accidents that stomp on data.

As is often the case, a layer of abstraction between application logic and physical implementation increases flexibility and maintainability.

I agree that it will probably never be possible to implement a truly general mechanism to mount disks - there are far too many combinations and permutations. On the other hand, as more systems are using SAN storage exclusively, things get easier!