- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Concealed device 2
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2005 03:38 AM
04-18-2005 03:38 AM
Concealed device 2
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2005 05:27 AM
04-18-2005 05:27 AM
Re: Concealed device 2
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2005 07:48 AM
04-18-2005 07:48 AM
Re: Concealed device 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2005 05:01 PM
04-18-2005 05:01 PM
Re: Concealed device 2
>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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2005 05:29 PM
04-18-2005 05:29 PM
Re: Concealed device 2
$ 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2005 05:55 PM
04-18-2005 05:55 PM
Re: Concealed device 2
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2005 06:31 PM
04-18-2005 06:31 PM
Re: Concealed device 2
I think you mean : search sys$library:starlet.req nam$v_wild
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2005 07:01 PM
04-18-2005 07:01 PM
Re: Concealed device 2
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.]
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2005 09:44 PM
04-18-2005 09:44 PM
Re: Concealed device 2
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2005 10:41 PM
04-18-2005 10:41 PM
Re: Concealed device 2
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-18-2005 11:08 PM
04-18-2005 11:08 PM
Re: Concealed device 2
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2005 10:47 AM
04-19-2005 10:47 AM
Re: Concealed device 2
$ 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2005 06:09 PM
04-19-2005 06:09 PM
Re: Concealed device 2
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2005 07:53 PM
04-19-2005 07:53 PM
Re: Concealed device 2
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.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2005 08:02 PM
04-19-2005 08:02 PM
Re: Concealed device 2
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2005 10:30 PM
04-19-2005 10:30 PM
Re: Concealed device 2
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2005 10:49 PM
04-19-2005 10:49 PM
Re: Concealed device 2
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2005 11:20 PM
04-19-2005 11:20 PM
Re: Concealed device 2
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2005 11:52 PM
04-19-2005 11:52 PM
Re: Concealed device 2
$ 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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-20-2005 12:43 AM
04-20-2005 12:43 AM
Re: Concealed device 2
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
with both CONCEALED and TERMINAL attributes, and
$ DIR APPL_ROOT:[SRC]
will not fail....
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-20-2005 11:39 PM
04-20-2005 11:39 PM
Re: Concealed device 2
.][
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-21-2005 05:19 AM
04-21-2005 05:19 AM
Re: Concealed device 2
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