Concealed device 2

[Wim Van den Wyngaert]

In the context of Jan's subject :

Why is nesting concealed devices not allowed ?

E.g.

def ops$root DISK$WSYS01_CONF:[OPERATIONS.] /tr=conc
def ops$mgr ops$root:[mgr.]/tr=conc
dir ops$mgr:[000000]
%DIRECT-E-OPENIN, error opening OPS$MGR:[000000] as input
-RMS-F-DEV, error in device name or inappropriate device type for operation

[Jan van den Ende]

Wim,

One of my favorite wooden horses!

It would make life sooooo much easier!

Quite a long time ago I was told (at some Decus Europe, probably by someone in Engeneering, specifics lost in my aging memory :-( ) that it had mainly to do with the expected problems with growing depth of physical directories if recurrency was allowed. In that case that depth was expected to grow out of control.

Even now one can create a concealed device that conceals up to 8 directories, and that root can again contain 8 directories.
But, the moment the sum of those two numbers exceeds 8, you are in for some nastiness, eg., when you try to restore /SELECT= from Backup.
An /IMAGE restore of an /IMAGE backup is OK, but all other combinations are problematic, to say the least.

But: I have my hopes up. The V8.2 Release Notes mention that directories can be 256 levels deep.
I wonder what would be needed to make use of that for Nested Concealed Devices....?
My personal guess is that it would have quite some impact on RMS.

Hein, can you explain/explore that some deeper?

Maybe we can build this into a formal request if more of the crowd agree with us.

Proost.

Duvel on me.

Jan

[Craig A Berry]

ISTR the eight-level directory depth limit was lifted on Alpha in 7.2, though the CRTL was not modified to accommodate that change until 7.3. I think the limit was also lifted on VAX in 7.3, though I'm less sure about that.

[John Gillings]

Wim,

>Why is nesting concealed devices not allowed ?

Simple answer "because" ;-)

It's a bit like asking "why do I have to stop at a red light". Them's the rules!

Longer answer - Logical name translation is a critical path on OpenVMS. Most DCL level actions require numerous translations. The more simplifying assumptions that can be made and fewer cases that need to be considered in the code paths, and the fewer potential loops, the faster it will be, and the fewer potential errors.

For performance, it's better to do the translations at the time the logical name is defined, than to repeat them every time it's translated.

Yes it would be possible to revisit the implementation and generalise it, making nestings valid, but it would require engineering and qualification resources that just don't exist at the moment.

The problem here is that DCL and RMS will sometimes let you get away with strictly invalid syntax.

[Uwe Zessin]

A maximum directory depth of 8 was a limit in RMS, because some things were hard-coded. For fun, do a:
$ search sys$library:starlet.req nm$v_wild

Apparently, that was for things like: [*.*.*.*.*.*]


With the XQP, this has never been a problem, because the programmer was always responsible to properly traverse the tree. You gave it a DID (directory file id) and it returned all FIDs.

[Wim Van den Wyngaert]

John,

Simply adding a field to each logical structure indicating "nested check to be done".

def ops$mgr ops$root:[mgr.]/tr=(nested,conc)

will solve the problem without modifying all the existing stuff.

Excuse not accepted.

Many programmers don't understand why this was never implemented. Or better, don't understand how to use logicals because of it. Result : they don't use logicals.

It should have been in the relase notes of 4.4.

Wim

[DICTU OpenVMS]

Uwe,

I think you mean : search sys$library:starlet.req nam$v_wild

[Willem Grooters]

See my comment on Jan's thread on this subject.
You can - as long as the whole translation does not contain a TERMINAL attribute without full spec. What, in your case, is the tanslation of DISK$WSYS01_CONF? Is this a device? That would be contradictionary to Jan's subject - and my experience.

That there will be a penalty in terms of performance if you do - accepted. If some limit is imposed: I can live with that.

But THIS should simply be possible:

$ DEF/SYSTEM/TRANS=(CONC,TERM) APPL_DISK DKA200:
$ DEF/SYSTEM/TRANS=CONC APPL_ROOT APPL_DISK:[2004A.]
$ DEF/SYSTEM/TRANS=(CONC,TERM) DATA_DISK DKA300:
$ DEF/SYSTEM/TRANS=CONC APPL_DATA DATA_DISK:[2004A.]

$ DEF/SYSTEM EXE APPL_ROOT:[EXE]
$ DEF/SYSTEM COM APPL_ROOT:[COM]
$ DEF/SYSTEM CFG APPL_ROOT:[CFG]
$ DEF/SYSTEM REF APPL_DATA:[REF]
$ DEF/SYSTEM GEG APPL_DATA:[GEG]
$ DEF/SYSTEM/TRANS=(CONC) DOC APPL_DATA:[DOC.]

[Jan van den Ende]

Willem,

and of course I recognise your DOC example! :-(

This one, together with APPL_ROOT and COMM_ROOT, being xxx$DISK:[COMM.] and xxx$DISK:[APPL.], and xxx$DISK being DISKyy:[xxx.]

And to all others: yes, those structures ARE fixed, and I am a little ashamed about the way they are implemented.
Especially the second app uses the plain dir structure, the upper root, and the lower root intermingled randomly. (that is what I mean by fixed).
Probably reflects the way various generations of programmers understood the concept :-(

And of course, absolutely NO way to inluence the sources (or even get a look at them).
And of course the app is VITAL!!

Does this explain why I would love to see nested roots?

Proost.

Have one on me.

jpe

[Ian Miller.]

I like the idea of a new attribute to allow nested translations but I wonder how high a priority it will be on the list of new features on VMS. As we all know VMS Engineering have limited resources and can't do everything. This feature would be handy but I think a better business case is needed.

[Wim Van den Wyngaert]

As I said, It should have been in 4.4. It's too late now. The damage has been done.

Wim

[Jess Goodman]

This is usually only a problem when you want to define one rooted logical based on another rooted logicals definition. For instanace suppose you have the following concealed logical:

$ SHOW LOGICAL MYAPP_ROOT
"MYAPP_ROOT" = "$1$DKA0:[MYAPP.]"
[concealed,terminal]

You want to define a new rooted logical for log files in a subdirectory of MYAPP_ROOT. If this DEFINE has to be in a different command file for some reason then you don't really want to do this:

$ DEFINE/TRAN=CONCEALED MYAPP_LOGS -
$1$DKA0:[MYAPP.LOGS.]

because then the physical device $1$DKA0
is used in two places and it would break your application if it was updated in only one place.

Unfortunately as discussed here this DEFINE command won't work for many cases:
$ DEFINE/TRAN=CONCEALED MYAPP_LOGS -
MYAPP_ROOT:[LOGS.]

You could use this work-around:
$ DEFINE/TRAN=CONCEALED MYAPP_LOGS -
'F$STRI(F$TRNL("MYAPP_ROOT")-"]"+"LOGS.]")

But that is really ugly, and do you really want to try to explain that syntax to anyone else?

Here's my suggestion for a DCL improvement (Guy?) that will handle this problem without breaking any existing code:

Add a new keyword for DEFINE /TRANSLATION=, perhaps call it RESOLVE (suggestions here are welcome). This keyword would also create a TERMINAL logical name, but it would first attempt to iteratively translate the equivalence string, or the first part of an equivalence string containing a ":" token, and define the logical name using the results of the translation. It would also handle replacing any ".][" in the results with ".".

So the DEIFINE statement would be:
$ DEFINE/TRAN=(RESOLVE,CONCEALED) -
MYAPP_LOGS MYAPP_ROOT:[LOGS.]

But the result would be:
$ SHOW LOGICAL MYAPP_LOGS
"MYAPP_LOGS" = "$1$DKA0:[MYAPP.LOGS.]"
[concealed,terminal]

Now with this method you still have to redefine any logical names derived from MYAPP_ROOT at the same time that you update the MYAPP_ROOT definition, but you just have to re-execute existing DEFINEs, not edit a bunch of them at once.

[Wim Van den Wyngaert]

Jess,

That would be nice but a concealed device should be displaying the logical name instead of the equivalence string (ref help define/tra). And not sure, but it shouldn't be terminal in that case.

$ DEFINE/TRAN=(RESOLVE,CONCEALED) -
MYAPP_LOGS MYAPP_ROOT:[LOGS.]

should not result in

$ SHOW LOGICAL MYAPP_LOGS
"MYAPP_LOGS" = "$1$DKA0:[MYAPP.LOGS.]"
[concealed,terminal]

but in
$ SHOW LOGICAL MYAPP_LOGS
"MYAPP_LOGS" = "MYAPP_ROOT:[LOGS.]"
[concealed]

otherwise you still have to do some explaining to the application guys that don't have knowledge of what is behind myapp_root.

Wim

[Willem Grooters]

Wim,



I LOVE logicals!
And, indeed, I do not see why nesting of concealed logicals is not allowed - officially. Even worse, it seems to work, if properly set up. The example is of a running, VITAL application. Jan knows.
It's not just the programmers that have been "mislead" by the erring documentation. What about system managers? Both havebeen practicing nesting for years. Way back, I have written commandprocedures and programs that parsed logicals "to the bone" using F$PARSE and it's system service counterpart.

So Engineering should be aware that, due to this documentational error AND the ability that things simply work, it will not be acceptable to turn back time.
If deep nesting would imply a penalty in performance - so be it. As a system manager, I have some control over it, I should be warned that this penalty exists. Engineering may limit the depth. But nesting as it exists now should NOT be broken.

[Wim Van den Wyngaert]

Willem,

What do you mean with "it" works ? You mean
by using a construct such as
$ DEFINE/TRAN=CONCEALED MYAPP_LOGS -
'F$STRI(F$TRNL("MYAPP_ROOT")-"]"+"LOGS.]")
?

Wim

[Jan van den Ende]

Willem,


Jan knows

Urmphf

Perhaps "Jan should know", but our current implementation is still along the line of
$ Define x 'f$trn - ".]" + [.DOC},
(in the DOC case), and
$ xx = f$trn
$ if f$parse(x,,,) etc
$ Then etc
$ eldse etc
$ endif
(to cater for genuine nested rooting, as well as the case where the upper concealed device is actually implemented as a disk synonym, which also is found for this particular applic)

The way I understand your posting, you actually DO USE
$DEFINE x_root y_root:[dir.] /tran=conc
where y_root is DEV:[dir.] (concealed) ?
I don't think I ever tried that the last decade or so, but I DO remember running into some form of it FAILING when trying to bring our desired transparancy (here: device-independancy) into some applications.

I quite like Wim's idea:

$ DEFINE/TRAN=(RESOLVE,CONCEALED) -
MYAPP_LOGS MYAPP_ROOT:[LOGS.]

should not result in

$ SHOW LOGICAL MYAPP_LOGS
"MYAPP_LOGS" = "$1$DKA0:[MYAPP.LOGS.]"
[concealed,terminal]

but in
$ SHOW LOGICAL MYAPP_LOGS
"MYAPP_LOGS" = "MYAPP_ROOT:[LOGS.]"
[concealed]
/quote>

And, I agree with Willem:
if there is a performance penalty like John says, I would gladly pay it.
I would bet it is quite minor compared to many other performance devourers.
( for a "nice" example of that, see
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=859853 )

But, not knowing the required Engeneering resouces if this is to be implemented, I would rank it as "nice to have", but not as "merits a big investment".

Like Jess wrote, it looks UGLY, and is not so easy to explain to those that are not so deep into it (read: programmers, read: newbies), but, it IS functioning, and if you are looking for ugly or hard-to-explain code, VMS has LOTS less of that than any OS that I know of!

FWIW,

Proost.

Have one on me.

jpe

[Wim Van den Wyngaert]

I should have studied a little more. I was brought up with a certain usage and never questioned it.

My findings :
/tran=conc is only needed for hiding the translation (e.g. in messages or headers). It has no influence on the usage of the logical for finding the directory or file.

/tran=terminal is never needed unless you want to avoid further translation (e.g. a points to b but you don't want b to be translated to c).

So,
$ define mydir mydisk:[dir.]
$ dir mydir:[doc]
is working just as wel as the version with /tra=conc.
It just displays things in a bad format.


Wim

[Ian Miller.]

I suspect /trans=terminal is a optimisation as it allows the logical name translation code to stop trying to translate.

[Uwe Zessin]

Yes, it replaced the old pre-V4 handling which used a "_" in front of the logical name to stop translation. And there is a default recursion depth of 10:
$ define a b
$ define b a
$ show logical a

(I think you can still see something similar in the mail utility, where you can prefix the username with a "_" to suppress forwarding.)

[Willem Grooters]

Wim,

AUCH. Now you mention it:
CONCEALED and TERMINAL are both TRANSLATION attributes and have nothing to do (actually) with how logicals work. Just influence translation......That may be the reason that it fails in some cases....
In that context it is obvious that translation will stop in the logical carrying the CONCEALED attribute - casuing the trouble. However, it _can_ be translated deeper - by F$PARSE attribute "NO_CONCEAL" - that seem to bypass the attribute.
The TERMINAL attribute really is terminal - there is no "NO_TERMINAL" attrubute in F$PARSE. I guess it's main purpose is to create an anchorpoint but it requires the translation contains the device itself:

$ DEF APPL_ROOT :[ROOT_DIR.VRS.]

with both CONCEALED and TERMINAL attributes, and

$ DIR APPL_ROOT:[SRC]

will not fail....

[labadie_1]

I think the rule at the moment is that you can have in a path/file name ony once the string

.][

I had seen long ago

A rooted directory is designed to behave like a device and its MFD
(i.e. [000000]) directory. Asking a path name to have two rooted
directories in it is equivalent to asking a path name to have two
devices and two MFDs.

[Robert_Boyd]

One of the problems that I am picking up on in this discussion is the distinction between a simple concealed logical name and the rooted logical name construct. The implementation makes them look like you're dealing with the same thing, but when it comes to how they are used, they are not EXACTLY the same.

I would advise separating out the discussion of concealed names from the discussion about rooted names. I have often wished that the original implementation of rooted names had a separate flag bit so that the 2 types were kept distinct.

The feature that many have expressed to have supported is nested rooted names. There are probably many pros and cons for these constructs. The thing that occurs to me is that the beauty of them if they worked is that you could easily remap a set of translations at the system, group or process level by setting up a different translation for the root of a nest and have the whole set of names follow. Otherwise you have to redefine a larger set of names -- any of the rooted names that branch from the root.

I think in reading the examples that Bob Gezelter writes about, it is easy to imagine some useful creative uses of such a feature.

Robert