- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Concealed Device definitions
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
Discussions
Discussions
Forums
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
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-17-2005 09:18 PM
тАО04-17-2005 09:18 PM
... 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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-17-2005 09:30 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-17-2005 09:36 PM
тАО04-17-2005 09:36 PM
Re: Concealed Device definitions
Danke!
So, it looks like a documentation issue.
Proost.
Have one on me.
Jan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-17-2005 10:55 PM
тАО04-17-2005 10:55 PM
Re: Concealed Device definitions
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-18-2005 04:37 PM
тАО04-18-2005 04:37 PM
Re: Concealed Device definitions
"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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-18-2005 06:41 PM
тАО04-18-2005 06:41 PM
Re: Concealed Device definitions
$ 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
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-18-2005 10:36 PM
тАО04-18-2005 10:36 PM
Re: Concealed Device definitions
"
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.
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-18-2005 11:06 PM
тАО04-18-2005 11:06 PM
Re: Concealed Device definitions
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-18-2005 11:37 PM
тАО04-18-2005 11:37 PM
Re: Concealed Device definitions
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-13-2005 09:21 PM
тАО09-13-2005 09:21 PM
Re: Concealed Device definitions
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 !).