VMS filesystem

[Darijo]

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???

[Jan van den Ende]

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

[Robert Gezelter]

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

[Kris Clippeleyr]

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)

[Steven Schweda]

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.)

[Jan van den Ende]

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

[Darijo]

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::

[Jan van den Ende]

Darijo,

re-read my answer.

It contains a similar example, with the explanation.

hth

Proost.

Have one on me.

jpe

[Darijo]

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.

[Darijo]

"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?

[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

[John Gillings]

Robert,

>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.

here it is:

>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).

Yes, you can SET DEFAULT to another node, and it works for SOME (maybe even most)things, but not all. You may have been using it for a long time, and you may not have found any of the cases where it doesn't work, but that doesn't make it supported! Nor does it mean it works the way you might expect in all cases - trust me, it doesn't!

You won't find anywhere in the documentation that says it's valid to include a node specification in SET DEFAULT or explains when you can expect it to work.

The documentation for SET DEFAULT says the syntax is:

Format

SET DEFAULT [device-name[:]][directory-spec]

Note the complete absence of node and access control string.

Over the years I've dealt with numerous cases where a host specification in the current default has resulted in odd, bizzare, or even dangerous behaviour.

In every case OpenVMS engineering has reiterated that it's not supported, and there is no intention to make it supported. There is also no intention to deliberately break it, so if it works, great. If it doesn't, don't complain!

Here's a really simple example of something that doesn't work:

$ SHOW DEFAULT
TEST"john password"::DISK_USER1:[JG]
$ run/debug anyprog
%DEBUG-F-CANTGETMAINFID, cannot get file-id for the main image file opened on channel 32
-SYSTEM-F-ACCVIO, access violation, reason mask=8C, virtual address=000000000000001B, PC=0000000000000006, PS=00002604
%DEBUG-F-INITERR, an error has occurred during debugger initialization, unable to continue this session.
$

[Hoff]

Darijo, I'd suggest that you avoid mapping your knowledge of Linux or Unix onto OpenVMS. This is an area where having expertise and having experience can prove to be somewhat of a hindrance.

The name of the SET DEFAULT command is quite literal, as the command sets your default parsing specification; the value that will be applied when you omit portions of a file specification.

One of the useful things is that you can redirect where an operation goes using defaults and logical names, and you can have the lookup search multiple directories.

There's no direct analog to these capabilities in a typical Unix environment. (And logical names are a source of confusion for many Unix programmers looking at OpenVMS. The usual assumption is environment variable, and that can lead down a path to confusion.)

Some related articles on filename defaults and filename parsing are here:
http://64.223.189.234/node/77
http://64.223.189.234/node/71

And there's an explicit caution here:
http://h71000.www7.hp.com/doc/731FINAL/6489/6489pro_009.html#index_x_471

And sticking DECnet node names in a default specification can get ugly. There are corner cases where you can go off the rails.

Here's what the DCL Dictionary has to say on the matter "The SET DEFAULT command will accept a node name with the device name (that is, node-name::device-name). However, the results of operations using a default with a node name are unpredictable. Some utilities and applications do not allow a node name to be specified in a file specification and will fail if the default file specification contains a node name." (I'm not sure who added that text -- John G. or I or somebody else got that added into the manual -- but the inclusion was a result of folks that have gone off the rails.)

And Darijo, do take the time to skim the OpenVMS User's Guide in the OpenVMS manual set. The OpenVMS documentation is large, and relatively detailed. And you'll almost certainly see a payback for the time spent in this effort.

And a correction to an earlier comment by JvdE: I am not an "original developer of OpenVMS", though I was an engineer working within the OpenVMS engineering group for many years, and have worked on various areas.

Stephen Hoffman
HoffmanLabs LLC

[DECxchange]

>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???

Hello,
I've read some of the answers briefly. I'm not going to thoroughly read everyone's answer. But I think what you're asking is, if you do the commands:

$ set def [directory_that_does_not_exist]
$ dir
$ sho def
Now the system will give you an error message that this directory does not exist in response to the latter two commands. Well, personally I've just learned to live with this. It's not really a problem. All you have to do now is either:

$ set def [directory_that_does_exist]
that is, the directory you meant to set default to, or:

$ create/dir [directory_that_does_not_exist]

Now when you do a

$ sho def
The system will echo the disc drive name and directory you are now in.

[Jan van den Ende]

@Greg (DECxchange:

>>>
$ sho def
The system will echo the disc drive name and directory you are now in.
<<<

The whole point of the discussion above, was to _loose_ the concept of "being in a directory"

You ARE NOT IN a directory (at least, I sincerely hope).
You are at your terminal/behind your desk/mayby remotely connected while onboard a train/whatever; and you are LOGGED in to your own/someone else's/the SYSTEM account; but the ENTIRE effect of the SET DEFAULT command is to JUST, and ONLY, specify a default string for file _syntax_ completion on ANY incomplete file specification for ANY file-related command (and a directory is also only just a special type of file).
And the execution of the command is responsible for checking the correct prerequisite for it; like existence.
For instance, in case of CREATE/DIRECTORY [] the prerequisite is the ABSENCE of the directory specified by SET DEFAULT

hth

Proost.

Have one on me.

jpe

[Robert Gezelter]

John,

I rarely disagree, but in this case I must, at least insofar as SET DEFAULT is concerned.

From the error message, I presume that the case of doing a RUN/DEBUG from a remote node will fail. This failure would occur whether or not the file information was explicitly specified or filled in by defaulting from a SET DEFAULT.

I apologize for not checking it in more detail, but I am tied up trying to do a resurrection (technical, not religious).

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