How to read Directory structure of VMS Server

[Hemang]

Hello, I am new to VMS environment. In my project, the VMS server is migrated to HP(UX) server. I want to create a similar directory structure in HP(UX) server. I don't know how to read the directory structure of VMS server?
Is there any utility available which do this for me? Need help.

[Jess Goodman]

Well the obvious answer to your question is: the DIRECTORY command displays directory sturctures.

If that answer is not what you were looking for perhaps you could be more specific in stating your project requirements.

[Hemang]

Thanks for the reply. Is it possible to differentiate between system files and User created files?

[RBrown_1]

Generally

$ DIRECTORY :[*...]*.DIR

If you don't know which device or logical name to substitute for , then you will have to do all disks. You can get a list by

$ SHOW DEVICE D

[RBrown_1]

You asked "Is it possible to differentiate between system files and User created files?"

System files are found in these places:

SYS$SYSDEVICE:[SYSn...]
SYS$SYSDEVICE:[VMS$COMMON...]

There "should not" be user files in these two trees. There "should not" be system files outside of these two trees. But there is no telling what a previous system manager might have done.

[Mike Kier]

VMS doesn't track who created the files, but it will display who currently owns the file and what access is available for various users or holders of various identifiers.

To see the ownership-only, use the /OWNER switch on the DIRECTORY command. To see the default protection use the /PROTECT switch. To see all of the default access (i.e. access not provided through an image installed with elevated privilege or holding an identifier) use the /SECURITY switch on the DIRECTORY command.

Also, remember that VMS doesn't have a concept of a single filesystem root - there is a separate directory tree for each mounted volume.

[Hoff]

You're brand new to OpenVMS and your management has tossed you into the lead on a project where you're now re-implementing the OpenVMS volume structure and the OpenVMS file structure?

With all bluntness and with no insults intended, you're either going to be massively successful in your career path, or your management has set you up to fail.

In Unix terms, you've been asked to write your own version of VxFS and your own version of SQLite here, and versions of tar or zip and a few other bits and tools for good measure, and to ensure compatibility with all of this with an existing implementation. And to integrate this all with HP-UX. Big, big, big project.

If you want a starting point, see the ODS tools on the OpenVMS Freeware. These provide a partial solution.

http://mvb.saic.com/freeware/freewarev40/ods2/
http://mvb.saic.com/freeware/freewarev50/ods2/
http://mvb.saic.com/freeware/freewarev40/ods2-reader/
http://mvb.saic.com/freeware/freewarev80/ods-2-reader-for-osf-1/
http://mvb.saic.com/freeware/freewarev80/ods-2-reader/

(Some of those URLs may effectively be repeats. Some are ODS-related tools, and the first is the older ODS-2 specs. ODS-5 has some changes to ODS-2, but those specs are not AFAIK published.)

Even with the ODS tools (which don't cover anywhere near as much as you'll need for an arbitrary application or system file format on OpenVMS), the most appropriate approach is often to re-process the files on OpenVMS into XML or such, and to transfer those files over. This approach leverages the use of the OpenVMS volume structure and file system and application code; you're not writing that.

Here's some reading on this topic:

http://64.223.189.234/node/225

If you decide to go as far as the applications, this is what you're signing off to provide a general implementation of:

http://64.223.189.234/node/817

One (other) attempt at this stuff is the FreeVMS project.

http://www.systella.fr/~bertrand/FreeVMS/indexGB.html

The usual approach is to either transfer over and process the files directly or (more commonly) to export the files out into a SQLite database or XML or sequential text, and then re-load them in the new environment.

If you really do decide to go for the native or (more likely) with a FUSE implementation, this is not going to be a small engineering project. If you get most of this stuff to work here with some reliability (as a FUSE or otherwise), you may also have a salable product in its own right, too.

Good luck with this, too, and welcome to ITRC.

[Hoff]

> Thanks for the reply. Is it possible to differentiate between system files and User created files?

As you'll find as you dig into this more, in general, no.

While there are files that are specific to the volume structure and that have known names and that are variously present or occasionally not present, and there are a whole host of operating system files and user files that are not particularly distinguished in any way. And there are the inevitable corner cases, such as the relative lack of a prohibition on user files named with a .DIR extension; cases where you might not get directory data when you access a directory file. You might get user data.

And complicating the processing of OpenVMS directories through means outside of the OpenVMS implementation, the whole of the directory data that applications can expect to access spans the volume structure's index file (the MFD, in generic terms) and the individual directory file.

With Microsoft FAT, most of the file structure per-file metadata is in the dirent directory entire, and there's basically nothing over in the FAT. With OpenVMS, the directories have comparatively little file structure data and most of (basically all of) the per-file metadata is over in the index file.

See the ODS2 specifications for details.

And the RMS record structures commonly used within files are akin to a hierarchical database; applications have and use RMS mini-database. There's no direct analog to this record structure layer in most Unix environments; the closest analog would be application use of SQLite or MySQL or PostgreSQL to manage the data store.

Go read the ODS2 specs and what all else I've posted in the previous reply, and call us back. That'll give you a better feel for what direct access to OpenVMS volume structures and file structures on HP-UX; for the scale of this project.

And I haven't even touched on the shared access, something that most Unix applications expect to happen with SQLite or MySQL or such, and that many OpenVMS applications tend to inherently expect...

Another approach here is an entirely brute-force one. You can emulate and run OpenVMS on HP-UX via simh or otherwise. (I haven't specifically confirmed that simh runs on HP-UX, but it's a portable VAX emulator.)

Now if you're HP, there are other options. You could conceivably look to port pieces of the OpenVMS source code.

Big, big, big project...

[Steven Schweda]

If all you're trying to do is copy the files
in a directory tree from a VMS system to an
HP-UX system, then programs like Zip and
UnZip might do the job. "tar" is also
possible, but probably less likely to succeed
with easily available tools.

If any files on the VMS system have any
structure more interesting than simple byte
streams, then what you get on the UNIX system
may be less useful than you might like.

[Hein van den Heuvel]

>> am new to VMS environment. In my project, the VMS server is migrated to HP(UX) server.

I have to concur with Hoff.
The level and details of the questions suggest you are not (yet!) well equiped to deal with this.
Think steep learning curve and shortcuts.

On the steep learning curve trajectory you'd run into DCL lexicals F$SEARCH, F$PARSE and F$FILE to explore directory structure and file from a 'shell' procedure.

On the shortcut trajectory think VMSTAR, and ZIP as Steven already points out.
Also be sure to check out PERL.
It will offer glob functions and file tests much like you may be used to in a Unix environment. For example the -f function to test for a 'normal file' and -d for a directory.

Good luck! ... you'll need some.

Hein.