Concealed Device definitions

[Jan van den Ende]

Working my way through the 8.2 Release Notes I was shocked by chpt 5.14, second bullet:


... and the device specification must be a physical device name. The equivalence name for a rooted-device logical name must not contain other logical names.


AFAIK, somewhere in the V5 timeframe, this restriction was significantly loosened, and now functions somewhat like: "... must not contain another rooted logical name."

This regression would cause us LOTS of trouble!

Luckily, a quick test (at least on Alpha) showed the V7 functionality still present:

$ DEFI/EXEC/SYST/TRAN=CONC DISKA DKA0:
$ DEFI/EXEC/SYST/TRAN=CONC TEST_ROOT DISKA:[TEST.]
$ DIR TEST_ROOT:[000000]/TOTAL

DIRECTORY TEST_ROOT:[000000]

Total of 28 files.

Various other small tests also OK.

I now expect this functionality to also work OK in I64.
Is anybody able to confirm this?

If _NOT_, that would be a severe hurdle in migration.
If _OK_, then the Release notes are incorrect.

The Alpha 8.2 HELP does not mention it at all.

On the Documentation CD the sentence about physical device name is not present, but all examples reference physical devices.

Maybe the documentation can be made a bit more exact?

Proost.

Have one on me.

Jan

[Volker Halle · Accepted solution]

Jan,

it still works on I64 E8.2:

I64VMS $ DEFI/EXEC/SYST/TRAN=CONC DISKA $1$DKA0:
I64VMS $ DEFI/EXEC/SYST/TRAN=CONC TEST_ROOT DISKA:[TEST.]
I64VMS $ DIR TEST_ROOT:[000000]/TOTAL

Directory TEST_ROOT:[000000]

Total of 1 file.

Volker.

[Jan van den Ende]

Volker,

Danke!

So, it looks like a documentation issue.

Proost.

Have one on me.

Jan

[Volker Halle]

Jan,

the reference to Section 6.6.3 of the Guide to OpenVMS File Applications in the V8.2 Release notes Chapter 5.14 is wrong. It should refer to Section 6.3.6 - so that's at least a (near-zero-impact) bug in the documentation.

My impression is, that there was always the advice to only use PHYSICAL device names when defined a rooted logical name. See the following ATW article from 2001:

http://h71000.www7.hp.com/wizard/wiz_6826.html

In your example, I would have probably used:

DEFI/EXEC/SYST/TRAN=CONC TEST_ROOT 'F$TRNLNM("DISKA")'[TEST.]

Volker.

[John Gillings]

Jan,

"Appears to work with cursory testing" and "guaranteed to work in all circumstances" can be two very different things. The documentation is now correct.

Although concealed devices *mostly* "work" even with non-physical devices or logical names in the equivalence string, but they cannot be guaranteed to work in all cases.

The day 1 (since V4 days), restriction of requiring the equivalence string to be a physcial device specification was NEVER relaxed but at some point it was incorrectly dropped from the documentation. I'm thankful that it's been reinstated. As far as I'm aware there have been no changes in the code, just the documentation corrected (most likely as a result of my request ;-).

If you have concealed device definitions which contain logical names, then sorry, they're wrong! If they work to your satisfaction at the moment, they will probably continue to work as they always have, BUT there WILL be instances where they won't work correctly.

So, you probably don't need to rush out and fix them all overnight, BUT please heed the rules for future uses of concealed device logical names, and ensure you eventually correct any existing incorrect usage.

Why did I request the doc change? I've seen many cases where customers complain because something doesn't work, which I can trace to an incorrect concealed device logical name definition. Correcting the definition (ie: no nesting) corrects the problem. However, when they changed the docs back around V5.3, I no longer had a section I could reference to show why the definition is wrong. That's now been fixed!

You can argue that concealed devices COULD have been defined and implemented in a more general manner. That's certainly true, but they weren't, and won't be, so you'll just have to live with the limitations - even if you can sometimes get away with ignoring them. Sorry.

I've attached a command procedure you can use to define concealed device logical names, which will resolve all nested logical names, and nested concealed devices.

[Willem Grooters]

Just my 2 cents - based on PRACTICAL experience and some deduction:

$ DEF/TRANS=CONC DISK1 DKA0:
$ DEF/TRANS=CONC TEST_ROOT DISK1:[TEST.]
$ DIR TEST_ROOT:[000000]

No problem indeed. Obviously, since VMS will tranlate TEST_ROOT to finally DKA0:[TEST.]

You _can_ define - without trouble:

$ DEF/TRANS=(CONC,TERM) DISK1 DKA0:

and still DIR will work: DISK1 = device....

But with

$ DEF/TRANS=(CONC,TERM) TEST_ROOT DISK1:[TEST.]

DIR will fail:
%DIRECT-E-OPENIN, error opening TEST_ROOT:[000000]*.*;* as input
-RMS-F-DEV, error in device name or inappropriate device type for operation

Quite obvious: DISK1 will NOT be translated any further (due to TERMINAL attribute)

So DISK1 MUST now be defined as device:

$ def /trans=(conc,term) test_root 'f$trnlnm("disk1")'[test.]

and then there is no problem.

So, the issue is not the CONCEALED attribute, but TERMINAL.

This is what I tell my users - for years: if you specify TRANS=TERM, the translation must be complete - contain no more logicals.

If the CONCEALED attribute would _require_ a full translation, it has no meaning at all.

Willem

[Ian Miller.]

"This is what I tell my users - for years: if you specify TRANS=TERM, the translation must be complete - contain no more logicals.
"

this is exactly what the terminal attribute means - end translating here.

On the other subject -
as John G. said nested translations sometimes (parhaps even mostly work) but they are not recommended and VMS Engineering could choose to change something and they work in less cases.

[Jan van den Ende]

John,


Why did I request the doc change? I've seen many cases where customers complain because something doesn't work, which I can trace to an incorrect concealed device logical name definition. Correcting the definition (ie: no nesting) corrects the problem.


exactly: "nested" roots have always been, and are, not working. And, /TERMINAL ends lnm translation attempts.

And yes, we have such procedures (for a long time already)

Proost.

Have one on me.

Jan
That why it was so pleasant to have the need for /TERMINAL removed from concealed device definitions!

Perhaps my desire blinds my insight, but I really fail to see that a logical name for a physical device used in a root definition would stop functioning!
-- a favorite topic in various discussions: it would break existing code!

I KNOW that nested logicals do not work, and I have lived with it for so long now that I could accept it if that never gets implemented. (one can keep wishing though)

[Jan van den Ende]

Willem,

are we or the same wavelength, or what :-)

Ian,

as John G. said nested translations sometimes (parhaps even mostly work)

If you mean by "nested translations" situations where the device part of one concealed device is itself a (directory-containing) concealed device, then I have NEVER seen it working (and I found the hard way several instances ot it NOT working!)

Proost.

Have one on me.

Jan

[Joseph Huber_1]

Wow, still learning !
I hope that this is one such occasion in VMS where the rule "many customer applications rely on this feature, so we will not break it" applies !

I have all my logicals for disks concentrated in one mount_disks.com at startup, and rely in all other command-files on the existance of the DISK$label logicals for defining rooted logicals.
Makes a lot more work for system-maintenance in a cluster, if one cannot simply exchange disks without redefining many logical names (hidden in product startup command-files !).

[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!