open VMS directory structure

[iamhere]

Hi, I'm a beginner in open VMS. I want to learn the directory structure of open VMS. I want to know the location of all binaries, system files etc. in open vms. What is the best source for learning open vms.

[Joseph Huber_1]

At the bottom of the forum list You can find under usefull links the link to OpenVMS documentation.
Also usefull:

http://www.openvms.org/ with sections like "VMS beginners", FAQs and howtos...

The OpenVMS FAQ at http://www.hoffmanlabs.org/vmsfaq/

[Ian Miller. · Accepted solution]

Do see the OpenVMS documentation at
http://www.hp.com/go/openvms/doc

and if you really want a list of the system files
http://h71000.www7.hp.com/doc/84final/ba554_90015/apbs02.html

[Bob Blunt]

It would also help to know at what point you're working with computers in general. Primarily because that would tell us if you're already familiar with computers, hardware, operating systems and how deeply you've looked into these concepts in general.

Why? The details are deeper than the documentation alone and in addition to the documentation set there are other very in-depth books specifically related. OpenVMS Internals and Data Structures is the first and I believe that there were some independently written books on the file structure, RMS and programming for the platform/architecture.

[iamhere]

Thanks for the replies.
The URL provided by Ian Miller
http://h71000.www7.hp.com/doc/84final/ba554_90015/apbs02.html

has list of all files in specified directories. One thing that can be noticed here is VMS$COMMON is the directory at the top that has other directories containing files related to libraries(SYSLIB), executables(SYSEXE) etc.
Can you tell me if my understanding is correct. Also, is VMS$COMMON is under SYS$SYSDEVICE, as per below statement
"SYS$SYSDEVICE:[VMS$COMMON]"

[Jan van den Ende]

parul,

I will begin with WELCOME to VMS!

>>>
Can you tell me if my understanding is correct. Also, is VMS$COMMON is under SYS$SYSDEVICE, as per below statement
"SYS$SYSDEVICE:[VMS$COMMON]"
<<<

Strictly speaking, this IS mainly correct,
BUT
NEVER use this to access any of it this way (maybe except, sometimes, when manipulating the files themselves).

Normally, executables ( a special type of binary ) are accessed via SYS$SYSTEM, which itself is a logical name for a sequence of 2 directories: SYS$SPECIFIC:[SYSEXE],SYS$COMMON:[SYSEXE]
If a specified file exists in SYS$SPECIFIC:[SYSEXE], then that one is used, if not, it is searched for, and used from, SYS$COMMON:[SYSEXE]
A similar approach for SYS$LIBRARY, which also contains "binary", but non-executable, files like RTLs (RunTimeLibraries), something with functionality not unlike DLLs, but also text files like printer control libraries ("device control libraries") and other stuff.
A similar construct for [SYSMGR] holds most system management files.

This somewhat complex way of doing things is the heart of CLUSTERING.

For normal use, remember to ALWAYS use SYS$SYSTEM , SYS$MANAGER, SYS$LIBRARY etc

For executables there can be an extra level: a command definition. That definition specifies the location, and potentially any qualifiers and restrictions. In that case, ONLY the command should be used, WITHOUT location.

-- and it is always possible to create executables is any location you have write access, and specify that. VERY usefull for devellopment, also used by commercial packages.

hth.

Proost.

Have one on me.

jpe

[iamhere]

Thanks,
Is there any document that clearly mentions the hierarchy for the directory structure in VMS. Any diagram or document that completely describes the hierarchy for binaries, libraries etc.

[abrsvc]

Parul,

What you are asking for is a week long course in OpenVMS. There are many issues that must be understood in order for your initial question to be answered completely. For example, an understanding of logical names and concealed devices is needed to paint a proper picture of how the system accesses executables and drivers. This is NOT a Windows system with DLLs. While not overly complex, basic concepts must be clear in order to comprehend the setup. Add in clustering and it gets a little more complex.

I would start with the introduction manuals first. If you have more specific questions, post them here. I realize that you may not know what to ask at this point. Try reading some of the overview documents. They should give you enough basic information to guide you along. More specifics can be provided by this group later.

Regards,

Dan

[Robert Gezelter]

parul,

With all due respect, Jan is almost correct. Certainly, his description is accurate in the default simple case. However, if you are really trying to understand the structure of OpenVMS, the default case is but one instance of a far larger universe.

The logical name mechanism is at the heart of much of OpenVMS, and while it can be viewed as formulaic much of the time, this is a far too simplistic.

For example, the series of logical names used to access the system files (e.g., SYS$SYSTEM, SYS$LIBRARY, SYS$MANAGER, SYS$STARTUP) are all logical name search lists. These recursively define an ordered sequence of locations to look for a file. There is reason that I say "recursively". If one examines the definition of SYS$SYSTEM using the SHOW LOGICAL command, one will see that is defined in terms of the logical SYS$SYSROOT. In turn, SYS$SYSROOT is defined as a search list of a bootstrap root (e.g. SYS$SYSDEVICE:[SYS3.]) and SYS$SYSDEVICE:[SYS3.SYSCOMMON.] -- an alias for SYS$SYSDEVICE:[VMS$COMMON.]).

There is also nothing sacred about the number of elements in the logical name search path. Various HP/Compaq/Digital products have inserted extra terms in the search path, as have third parties and end-users. So long as appropriate care is used, it is a powerful and useful technique. Care is required, however, as at least one major third party had a product which did this operation in a not well thought out manner, and caused other products to malfunction.

While such logical name techniques are the foundation of creating an OpenVMS system disk to be shared between two or more members of an OpenVMS cluster, it is useful in far more contexts than merely OpenVMS clusters.

It is not unusual to create multiple boot personalities for an OpenVMS system, predefining configurations and options for various contingencies. This eliminates the dangers of changing configurations during an emergency.

I showed some examples of how these search paths can be manipulated in my OpenVMS Technical Journal paper "Inheritance Based Environments in Stand-alone OpenVMS Systems and OpenVMS Clusters", a reprint of which can be found at http://www.rlgsc.com/publications/vmstechjournal/inheritance.html).

Multiple alternative boot roots, in the context of both standalone and clustered nodes were also one of the foundations of "Evolving OpenVMS Environments: An Exercise In Continuous Computing" my presentation at the 2009 HP Technology Forum. The slides and audio track from this presentation are available at http://www.rlgsc.com/hptechnologyforum/2009/continuous-openvms.html.

As a beginner, I am most definitely recommending that you start by exercising these techniques. It is all too easy to have an accident that requires a restore of a system disk (or at the least, some delicate surgery by one who thoroughly understands the structures). However, from an educational viewpoint it is as important, if not more so, that one understands that the default configuration is but a single instance of a far more flexible facility.

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

[Hoff]

If you're a beginner at OpenVMS (old product name: VMS), then this is an odd approach for knowledge.

You're starting your quest for knowledge looking at the analog of a giant pile of unassembled and unlabeled and randomly organized car parts, and trying to fathom what sort of mechanical device you're even looking at, and then how it all fits together, and how it works.

Might I suggest starting with an assembled automobile and not a pile of parts, and starting with the owner's manual and related materials? This before you grab the mechanic's manual and start pulling the car apart.

In the VMS world, the owner's manual is the User's Guide (for gaining a basic understanding of the operating system and its norms) and then the System Management Manuals (for the major pieces, and how the platform operates), and then (for learning about VMS programming) the Programming Concepts Manual and then various other library and linker and language manuals. Those manuals are located here:

http://www.hp.com/go/openvms/doc

There are also new-user FAQs posted around the network.

http://www.openvms.org/pages.php?page=Beginner

Once you're ready to start pulling VMS apart (and that can require a few months of use to get the hang of the user-visible interfaces and APIs and command-level operations, working your way up to the single-system image and distributed shared-write storage system and the distributed lock manager; in aggregate, known as clustering), then the analog of the mechanic's manual is known as the VMS Internals and Data Structures Manual (the IDSM), and where several editions of this book were available for purchase separately from the OpenVMS documentation. That, in conjunction with the C device driver manual (available separately from the documentation) can help you figure out how the pieces fit together.

Or get yourself into some training classes or somebody with experience in the platform that's willing to serve as a mentor...

But don't go looking for the biggest and most complex and least overtly-organized interface as a way to fathom the whole of an operating system.

And yes, dumping Windows system directories, or /usr and /sbin and /var and /etc on Unix, would be just as massive and confusing a project when trying to learn those platforms.