VMS filesystem

[Jan van den Ende]

Darijo,

>>>
What is the advantage of this filesystem?
<<<

I am not sure if this particular aspect has a definite advantage or disadvantage. But it _IS_ different.
The filesystem _IS_ however quite closely interwoven with the Logical Name (LNM) mechanisms.
And _THAT_ is a terrific advantage over anything _I_ have ever come across (others me have wider experience, but then that is also kept secret rather good).

It might be that this implementation of default file syntax completion is desired by, or just facilitates, the LNM implementation.

I would speculate that Hoff (one of the original VMS devellopers) or Hein, ( _THE_ RMS specialist) can provide much more exact and detailed info.

>>>
Im coming from UNIX so this is very new to me.
<<<

I think you will just have to accept that it _IS_ different, just as Microsoft filesystem, and Mac, and (...) are all different beasts.

If it is any consolation: I have your problem the other way araound. :-)

Proost.

Have one on me.

jpe

[Robert Gezelter]

Darijo,

As has been said, SET DEFAULT only manipulates the default filename string in the process context. It does not access (or create) any file.

The CREATE/DIRECTORY command actually creates the directory (and allocate a minimal size file allocation to the directory itself).

From the follow up postings, there appears to be some confusion about the differences between the *IX cd command (which checks to see if the directory exists; rather than just manipulating the default string; this behavior is also apparent in Windows) and the OpenVMS SET DEFAULT, which does not actually do anything until a file access/create is attempted.

As I noted, the command CREATE/DIRECTORY [] (which uses the [] syntax to refer to "the current default directory") is usable on OpenVMS; on the *IX model, it is not usable.

The semantics are simply different. Honestly, while I have never had problems with the OpenVMS approach (the error occurs on the first attempt to access a file), I admit that switching back and forth is sometimes an annoyance.

- Bob Gezelter, http://www.rlgsc.com

[Kelly Stewart_1]

Darijo,

"So does the filesystem allocates some drive blocks and then immediately unallocates them or...??? "

No. When you enter the "set default" command, you don't really touch the file system, not in the way you are thinking. Think of it as declaring a future intention. (Maybe, by the time you actually try to access the directory, somebody or thing will have created it! :)

Apparently, a few other people find the "set default" command a little limited. On the Freeware 8.0 site, there are 5 (!) replacements for it (and I've written one of my own). One of them, called "To", has an on-line manual that states that it tries to check for non-existent defaults. (Check the OpenVMS main page for a link to the freeware.)

Jan's mention of logical names is well taken. You can "set default" to a logical name and then redefine that logical name, which will change your default. So, even if "set default" were changed to check for the directory's existence, the "define" command could still surprise you.

And as an aside, if you'll be spending much time with VMS, you definitely should learn about logical names. They are unique, very powerful, and a little dangerous if you don't know what you're doing.

War story: long ago in a big IS department, a newbie VMS developer (no, it wasn't me, but it could have been) couldn't debug his executable because the project had been moved from DUA0: to DUA1:, and the debugger couldn't find the source files. He was told to define a logical name DUA0 that would be translated as DUA1. Of course, DUA0 was the system disk and, of course, developers had been given full privileges. (You can see this coming, right?) So he types in "define /group DUA0 DUA1:". It took less than 10 seconds before the heads started popping up above the partitions...

Kelly

[Kelly Stewart_1]

OOPS!

Sorry, I made an incorrect statement in my previous post.

You can set default using a logical name, but redefining the logical name later does *NOT* change that default. The default remains set to the translation that the logical had at the time you set the default.

Sorry for the mistake!

Kelly

[Jan van den Ende]

Kelly wrote:

>>>
Sorry, I made an incorrect statement in my previous post.

You can set default using a logical name, but redefining the logical name later does *NOT* change that default. The default remains set to the translation that the logical had at the time you set the default.

Sorry for the mistake!
<<<

Well, we ARE getting in the deep here!

In the case described, one should be careful with the interpretation of "changed"

No - the default is not changed
Yes - the output of the (implicit, under-the-hood) parsing DOES change.

Whenever parsing takes place, the current-at-that-moment value of the logical name is evaluated to get to a file spec that references a particular file.

And to make it even more confusing to people used to non-VMS file systems, the same Logical Name can have different valeus in different tables, in which case the first hit according to the LNM table search list applies.

But, SHOW LOGICAL DOES supply them in that order. (but be aware that different people DO see different tables!)

It really DOES pay to spend some time/get some instruction in getting used to it, but it IS fantastic.

One example that usually baffles Unix people:

the access to an application specified to be in a directory with a certain logical name.
Now, have a number od DIFFERENT directories, containing same-mnemd files to initiate the app.
in one instance, the app run "normal"
in another instance, the new (still under test) version
in a 3rd instance, the normal startup file just displays a nice message that the app is currently unavailable.

A suitable authorized System Manager ("Sysadmin" in Unix speak) can in a oneliner define the app (un-)available to general users, and (at the same time) direct a specified group to the new version. Effective immediately for all users!.

hth

Proost.

Have one on me.

jpe

[John Gillings]

As others have said, SET DEFAULT doesn't "enter a directory". Rough translation into Unix speak, it really just sets an evironment variable, a bit like PATH. (is there anything in Unix to prevent PATH from being set to a non-existent directory?)

The current default is a convenience, so you can give the system an incomplete file specification, and have parts of it filled in from the default.

This can be a double edged sword, especially when writing command procedures. Do you make assumptions about the default, or do you always code a complete filespec?

In debugging procedures, I often find hidden assumptions which depend on the current default, and sometimes cause procedures to break if executed with the default set to the "wrong" place. One trick to help eliminate this type of assumption is to test the procedure with default set like:

$ SET DEFAULT BADDEVICE:[BADDIRECTORY]

(so there's another advantage to being able to set default to a non-existent directory)

The DCL DEFAULT directory concept is really rather troublesome. Pre V4, it was fairly well behaved with a strict demarkation between DEVICE and DIRECTORY. Since the invention of concealed devices and search lists the line has become very blurred, leading to numerous ways of getting surprises in behaviour from interactions with filespec defaulting. When you start adding node specifications things get even uglier (strictly speaking that's not supported, but that doesn't stop it from "working" some of the time).

To understand SET DEFAULT you need to understand how RMS processes file names. See the RMS service $PARSE and the corresponding lexical function F$PARSE.

[Darijo]

Hey guys!
I have been on many forums but here....you are all really, really helpful.
I think that my employer will be satisfied with my VMS skills :)
Now Il take time to read what you guys wrote and test that tommorow.
Oh by the way. Three months ago one VMS node failed after 7.5 years of uptime. Well it wasnt VMS fault but SCSI controller that has failed. I heard couple of times that VMS set records in this field.

[John Gillings]

re Kelly,

>Sorry, I made an incorrect statement in my
>previous post.
>
>You can set default using a logical name,
>but redefining the logical name later does
>*NOT* change that default.

Not so fast... you weren't entirely incorrect. It depends on which component of the default the logical name defines.

This is one place where default directory gets very confusing. Roughly speaking, the default has two components DEVICE and DIRECTORY. In simple terms anything to the left of a colon ":" is the device, anything to the right is the directory.

If the logical name is interpreted as a DEVICE, it is NOT translated. If it has both DEVICE and DIRECTORY components it IS translated. In the former case, changes in the logical name WILL be reflected in future uses of the default, in the latter they will not.

Consider:

$ set def dra0:[jg]
$ create/dir []
$ create this_is_on_DRA0
$ dir

Directory DRA0:[JG]

THIS_IS_ON_DRA0.;1 0 6-DEC-2007 09:14:38.39

Total of 1 file, 0 blocks.

$ set def dra1:
$ create/dir []
$ create this_is_on_DRA1
$ dir

Directory DRA1:[JG]

THIS_IS_ON_DRA1.;1 0 6-DEC-2007 09:14:54.04

Total of 1 file, 0 blocks.
$ define mydir dra1:[JG]
$ set def mydir
$ show def
DRA1:[JG] ! Logical name has been translated
$ dir

Directory DRA1:[JG]

THIS_IS_ON_DRA1.;1 0 6-DEC-2007 09:14:54.04

Total of 1 file, 0 blocks.
$ define mydir dra0:[jg]
%DCL-I-SUPERSEDE, previous value of MYDIR has been superseded
$ show def
DRA1:[JG]
$ dir

Directory DRA1:[JG]

THIS_IS_ON_DRA1.;1 0 6-DEC-2007 09:14:54.04

Total of 1 file, 0 blocks.

So the default does NOT reflect the change in the logical name.

In contrast:


$ define mydisk dra1:
$ define mydir mydisk:[jg]
%DCL-I-SUPERSEDE, previous value of MYDIR has been superseded
$ set def mydir
$ show def
MYDISK:[JG] ! Note logical name in default
$ dir

Directory DRA1:[JG]

THIS_IS_ON_DRA1.;1 0 6-DEC-2007 09:14:54.04

Total of 1 file, 0 blocks.

$ define mydisk dra0:
%DCL-I-SUPERSEDE, previous value of MYDISK has been superseded
$ dir

Directory DRA0:[JG]

THIS_IS_ON_DRA0.;1 0 6-DEC-2007 09:14:38.39

Total of 1 file, 0 blocks.

In the second example, the change in MYDISK DOES affect the default.

Things get more confusing when you start playing with concealed devices and search lists.

[Kelly Stewart_1]

John,

Thanks for the clarification. I also didn't know that the use of a node name in the default was not supported (not that I use it that much...).

Kelly

[Robert Gezelter]

Kelly,

>John,
>
>Thanks for the clarification. I also didn't >know that the use of a node name in the default >was not supported (not that I use it that >much...).
>
>Kelly

I do not see the comment in John's post that node names are not supported. Indeed, I have been using that trick for a LONG LONG time.

Indeed, the syntax is straightforward:

$ SET DEFAULT nodename"user password"::device:[directory...]

Any of the parts are optional, and will default "appropriately". It comes in handy when a machine is overloaded, which is admittedly rare these days (I remember figuring this trick out back in my student days, when some of my files were on an instructional system and I had access to the instructional and staff systems; it was a way to work on files that were located on the other machine without having to deal with the other machine's overload).

It does, of course, rely on the the fact that the program(s) being run correctly use RMS $PARSE to do their file access. Needless to say, some programs have "rolled their own" file parsing, and have problems with this.

- Bob Gezelter, http://www.rlgsc.com