Re: Logical Names and Symbols (was: Re: Results of my straw poll.)
- From: Hoff Hoffman <hoff-remove-this@xxxxxx>
- Date: Tue, 16 May 2006 20:24:09 GMT
Bill Gunshannon wrote:
Personally, I see no difference in the way this would be handled between
the two systems beyond syntax. And, which one is easier is totally a
matter of opinion. It is obvious from some of the stuff posted here that
the biggest problem is people who don't know didily about Unix trying to
devise stranger and stranger ways to do common tasks and then point out
how convoluted the solution is.
I've seen no evidence that the C library calls perform similar symbol-level translations, and I was not aware that the Unix shell provided this I/O-level substitution for images. Is it the case that the substitutions happen inside the I/O processing? Or is this case involving operations with text that passes through the command shell and through its associated substitution processing?
The classic difference between symbols and logical names on OpenVMS is where the particular translation is performed. With the former, the shell (DCL) has to be involved in the command processing, and the shell performs the substitution before the command itself particularly gets involved. With logical names, no changes need be made in the specifications within the procedures or the executable images, as the translation happens within the depths of the I/O channel processing. The lower reaches of the operating system -- and specifically the I/O system -- performs the translation.
The other part of logical names is the defaulting-related processing, which is how SYSUAF logical name can redefine some or all of the file specification. The translation-related processing and the related file processing are also how the command stickiness is implemented, but that's sometimes useful and sometimes a problem.
Does any of this implementation really matter? No. (Most any current general-purpose computer system can solve most any current problem, quite obviously. Some are clearly better at certain problems and certain environments than others, and the choices and decisions then involve knowledge of the problem(s) and the salient difference(s) among the various options.)
Having a relational database underneath the file system interface (and not a hierarchical database) is something I've mentioned before. With that, you could change the entire instantiation of the file, based on any number of external or supporting attributes. If an older application expected text, the database coughs up text. If a newer application was looking for XML, well, that's what gets returned. Same apparent file, but completely transparent mechanisms for controlling the data stream, for instance. Implementing logical name redirection would be trivial, of course, and pragmatically comparatively little different within a relational scheme than within the existing low-level I/O implementation.
.
- References:
- Results of my straw poll.
- From: Bill Gunshannon
- Re: Results of my straw poll.
- From: Larry Kilgallen
- Re: Results of my straw poll.
- From: Bill Gunshannon
- Re: Results of my straw poll.
- From: Fred Bach
- Re: Results of my straw poll.
- From: Bob Koehler
- Re: Results of my straw poll.
- From: Dave Froble
- Re: Results of my straw poll.
- From: JF Mezei
- Re: Results of my straw poll.
- From: Bob Koehler
- Re: Results of my straw poll.
- From: Bill Gunshannon
- Re: Results of my straw poll.
- From: JF Mezei
- Re: Results of my straw poll.
- From: Bill Gunshannon
- Results of my straw poll.
- Prev by Date: Re: Hardware Question
- Next by Date: Electrical differences in DECserver serial ports
- Previous by thread: Re: Results of my straw poll.
- Next by thread: Re: Results of my straw poll.
- Index(es):
Relevant Pages
|