topic Re: VMS filesystem in Operating System - OpenVMS

VMS filesystem

Darijo — Wed, 05 Dec 2007 10:59:36 GMT

Hello!

Why doesn't VMS respond with error message when you want to enter the directory which doesn't exist, but instead it behaves like it does exist???

Re: VMS filesystem

Jan van den Ende — Wed, 05 Dec 2007 11:29:07 GMT

Darijo,

>>>
when you want to enter the directory which doesn't exist,
<<<

What exactly do you mean by that?
What command?
Is error reporting enabled.disabled (via SET MESSAGE)

Please supply more info.

Proost.

Have one on me.

jpe

Re: VMS filesystem

Robert Gezelter — Wed, 05 Dec 2007 11:33:28 GMT

Darijo,

Where appropriate, OpenVMS does return error codes. What command does your post refer to?

As a guess, your post refers to SET DEFAULT. Among other things, SET DEFAULT to a non-existent directory allows a subsequent CREATE/DIRECTORY [] command to create all directories in the path.

As a sample, do EITHER:

SET DEFAULT [.XX]
SET DEFAULT [.YY]
SET DEFAULT [.ZZ]

or

SET DEFAULT [.XX.YY.ZZ]

One is then able to do a CREATE/DIRECTORY [] and everything works correctly. One can argue that SET DEFAULT should check, and that the above behavior is a side effect, but that is the way it has always been, setting the default to a non-existent directory is not the error, using it as an actual reference is.

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

Re: VMS filesystem

Kris Clippeleyr — Wed, 05 Dec 2007 12:33:11 GMT

Darijo,

When you're logged in on a VMS system, and you do a SET DEFAULT you do NOT "enter" a directory, you simply change the default device/directory specification for your process.
Normally, whenever you try to access a file, you have to specify a valid file specification, i.e.:

node"access-control-string"::device:[directory]filename.type;version

To make our lives a bit easier, the VMS file system allows us to "forget" certain parts of this file specification, and will supply defaults.
The "node" defaults to the system you're logged in to.
The "access-control-string" is used in combination with an explicit "node" specification, so you can have a look at files sitting on storage devices on another system.
The defaults for the "device" and "directory" specifications are established at the time you log in (or are inherited), or are established/changed by a SET DEFAULT command.
It is only at the time the VMS filesystem has the need of using these defaults that a warning/error will be given if you specified either a device or a directory that does not exist.

Hope this helps,
Kris (aka Qkcl)

Re: VMS filesystem

Steven Schweda — Wed, 05 Dec 2007 12:41:41 GMT

Why shouldn't it do what it does? UNIX
compatibility? (Not a good reason.)

> [...] CREATE/DIRECTORY [] [...]

Exactly. I find this very convenient. Why
doesn't UNIX do it this way?

Strictly speaking, VMS doesn't behave as if
the directory exists. It simply doesn't care
whether it exists until you try to do
something with it.

alp $ set default [.no-such-dir]
alp $ show default
ALP$DKA0:[SMS.no-such-dir]
%DCL-I-INVDEF, ALP$DKA0:[SMS.no-such-dir] does not exist

Note: Only "-I-", so it's still a success.

Interestingly (to me, at least), I've noticed
that running UnZip in a non-existent
directory will get that directory created for
you:

alp $ unzip [-]VX.ZIP;1
Archive: ALP$DKA0:[SMS]VX.ZIP;1
inflating: [.vx]vx.mail
inflating: [.vx]zip_bug.txt
inflating: [.vx]zip_bug_u.txt
alp $ show default
ALP$DKA0:[SMS.no-such-dir]

Clever program. (Or perhaps it's just
lucky. Nice either way.)

Re: VMS filesystem

Jan van den Ende — Wed, 05 Dec 2007 12:57:15 GMT

Darijo,

Yes, I assume Bob guessed correctly.

Now it becomes an issue of semantics.

You phrase it as "enter the directory", and, and in practise I often here people talking about "sitting in " or "standing in " or "going to" a directory.
As a matter of speach that may be entirely acceptable, but literally, if you try that you will get quite dizzy spinning at 10 or 15 K rpm! (and I do not have any visualisation of how that would work out in solid state!).

Actually, VMS phrasing is pretty exact: what

SET DEFAULT
does, is, it SETs a DEFAULT string in process memory, and that default string is used every time an incomplete file reference is used, to parse that reference to give the complete file syntax.

Play around with parse (from DCL: the lexical F$PARSE, see HELP LEXICAL F$PARSE ARGUMENTS) and the default file spec field, to get the feel of it.

And yes, (yet) (partly) non-existing filespecs are allowed, if for no other reason than to be able to specify what is be be created.

This background info also makes it easier to understand phenomena as eg:

DIR DEVICE:

now, if DEVICE is another device as the device part previously specified by SET DEFAULT, and the default directory does not exist on DEVICE, the effect becomes evident.

eg

$ SET DEFAULT MY_DEVICE:[MY_DIR]

$ DIR OTHER_DEVICE:
%RMS-E-DIRNOUTFOUND directory OTHER_DEVICE:[MY_DIR] does not exist
(well, something like that, I am not at a VMS system at the moment so this is from bio memory)

The DIR command specified OTHER_DEVICE, so that was used in parsing.
it did NOT specify a directory, so THAT part of the filename was supplied from the DEFAULT setting.
(for completeness: the DIRECTORY command by its own default supplies a default filespec of *.*;* )

hth

Proost.

Have one on me.

jpe
eg

Re: VMS filesystem

Darijo — Wed, 05 Dec 2007 13:56:09 GMT

Hey guys!

Well here's the issue:

MZR1L2::set def [-]
MZR1L2::dir

Directory AEC:[000000]

AEC_SERVICE.DIR;1
1 8-SEP-2006 14:45:55.07 [AEC,SYS] (RWE,RWE,RWE,R)
LOG.DIR;1 1 8-SEP-2006 14:45:01.30 [AEC,SYS] (RWE,RWE,RWE,R)
MCC.DIR;1 1 8-SEP-2006 14:45:01.00 [AEC,SYS] (RWE,RWE,RWE,R)
MYDIR.DIR;1 1 5-OCT-2006 10:13:30.03 [AEC,SYS] (RWE,RWE,RWE,R)
RELEASE.DIR;1 1 9-AUG-1995 09:53:00.82 [AEC,SYS] (RWE,RWE,RWE,R)
SCRATCH.DIR;1 60 8-SEP-2006 14:45:01.21 [AEC,SYS] (RWE,RWE,RWE,R)
SHR.DIR;1 1 8-SEP-2006 14:45:01.09 [AEC,SYS] (RWE,RWE,RWE,R)
TOOL.DIR;1 1 26-AUG-1999 19:00:45.41 [AEC,SYS] (RWE,RWE,RWE,R)

Total of 8 files, 67 blocks.
MZR1L2::
MZR1L2::set def [.fake]
MZR1L2::dir
%DIRECT-E-OPENIN, error opening AEC:[000000.FAKE]*.*;* as input
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file
MZR1L2::

Re: VMS filesystem

Jan van den Ende — Wed, 05 Dec 2007 14:04:46 GMT

Darijo,

re-read my answer.

It contains a similar example, with the explanation.

hth

Proost.

Have one on me.

jpe

Re: VMS filesystem

Darijo — Wed, 05 Dec 2007 14:34:13 GMT

Im still confused but I think I got it...sort of :)
What is the advantage of this filesystem?
Im coming from UNIX so this is very new to me.

Re: VMS filesystem

Darijo — Wed, 05 Dec 2007 14:48:37 GMT

"Strictly speaking, VMS doesn't behave as if
the directory exists. It simply doesn't care
whether it exists until you try to do
something with it."

So does the filesystem allocates some drive blocks and then immediately unallocates them or...???
Why such a behaviour anyway?

Re: VMS filesystem

Jan van den Ende — Wed, 05 Dec 2007 15:00:05 GMT

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

Re: VMS filesystem

Robert Gezelter — Wed, 05 Dec 2007 15:45:49 GMT

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

Re: VMS filesystem

Kelly Stewart_1 — Wed, 05 Dec 2007 16:10:27 GMT

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

Re: VMS filesystem

Kelly Stewart_1 — Wed, 05 Dec 2007 16:15:34 GMT

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

Re: VMS filesystem

Jan van den Ende — Wed, 05 Dec 2007 17:06:30 GMT

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

Re: VMS filesystem

John Gillings — Wed, 05 Dec 2007 22:00:59 GMT

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.

Re: VMS filesystem

Darijo — Wed, 05 Dec 2007 22:24:18 GMT

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.

Re: VMS filesystem

John Gillings — Wed, 05 Dec 2007 22:26:03 GMT

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.

Re: VMS filesystem

Kelly Stewart_1 — Thu, 06 Dec 2007 14:32:13 GMT

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

Re: VMS filesystem

Robert Gezelter — Thu, 06 Dec 2007 15:36:13 GMT

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