Chapter 7: The User Environment

This chapter will discuss the OpenVMS user environment; how to work with files, directories, printers, and batch queues; and how to run programs and perform other common tasks.

As with earlier sections in this book, the DCL CLI interface will be used. Most common functions may also be carried out using a GUI interface, as described in Chapter 15.

Files

Most OpenVMS operations act on files, the primary unit of data storage. With few exceptions, all data processed by the system reside, at one time or another, in files. An understanding of files is essential to using most operating systems. Our description of the OpenVMS environment will begin with files.

Definition of a File

The file is the central unit of data storage. Programs, letters, memos, pictures, audio clips, and just about any other type of data are stored in files. A single file usually represents a single entity: one file per picture, one file per audio clip, etc. However, some file formats support the storage of multiple entities within a file. Examples of the latter are backup savesets, libraries, and zip files.

Compare this to a popular method of presenting data—the Web page. A given Web page may contain pictures, text, sounds, and other elements. This may give the illusion that all of these types of data are stored together as a single unit. In reality, each of these elements is stored in a separate file; they are presented together by the browser program at the time of viewing.

A file is a single logical unit on a computer storage device (e.g., a disk or tape) and is made up of records. A given file may consist of records of varying length (e.g., lines in a memo or letter) or each record may have a fixed length. A record may be divided into smaller units called fields. An employee name, a telephone number, or an identification number may be a field within a record, and all related records (say, one for each employee of a company) comprise a file.

OpenVMS supports many different file and record formats. Most other systems provide relatively few formats, so new users of OpenVMS may not be familiar with all of them. In addition, users familiar with other operating systems may be accustomed to slightly different definitions of some key terms. These terms are presented here as they are used with OpenVMS.

Within the file organizations listed below, there are many possible variations of the control information used to describe each record. These variations are not addressed in this book. They are handled automatically by OpenVMS Record Management Services (RMS) and the file system and are of little concern to the new user.

The overwhelming majority of files you will encounter will be sequential files. This is true for experienced users as well as novices. When you do come across files of other organizations, they will be for a specific purpose and will most often be managed by a particular piece of software.

As a new user, you will rarely need to know the details of a file's organization or of the record format within it. They are presented here mainly for informational purposes.

Sequential

Most files on a given OpenVMS system are sequential. As their name implies, they are suitable for sequential processing. That is, every record is expected to be processed in order from the beginning to the end of the file. Please note that they are expected, but not required, to be processed in this way.

There are two main variations of record formats used with a sequential file: variable-length and fixed-length. With variable-length records, the records within the file may differ in size from one another. This means that records in the file must usually be processed from the beginning of the file, one at a time, going toward the end of the file. Records may be added to the end of the file, but usually not inserted at an earlier point. Inserting records is usually accomplished by rewriting the entire file, but theoretically this can be done by rewriting all records from the point of insertion onward.

With fixed-length records, all of the records in the file are the same length. Even though the file is sequential, it is possible to retrieve a given record without reading the file from the beginning, because one may mathematically calculate the record's position within the file (but extra work is required of the program doing so). Nevertheless, records are usually accessed sequentially. Inserting a record still requires rewriting the file, as the remaining records must shift to accommodate the new record.

There is no key portion of a record, nor are the records required to be in any particular sorted order, as in some definitions of sequential.

Indexed

This type of file encompasses the terms Indexed and indexed sequential (ISAM), depending on what other operating systems one has used. Each record has one or more keys, which indicate the logical sequence of records within the file. For example, an employee's last name or identification number may serve as a key. This allows a given record to be reached quickly and allows insertions of records without rewriting the entire file. Complex pointers are automatically manipulated so that the ordering of records is maintained when inserting and deleting records. When read sequentially, records are automatically read in key order. The previous and next records may also be accessed, relative to the record most recently referenced.

Relative

In relative files, records are of a fixed length and are accessed by record number within the file, starting from the beginning. The system calculates the position of a record from the record size and record number within the file.

This type of access is similar to directly accessing a sequential file with fixed-length records. With a relative file, however, OpenVMS services automatically perform much of the necessary work.

Why Are Programs Stored As Sequential Files?

To highlight the practical similarities of relative files to fixed-record-length sequential files, note that executable images (programs) on OpenVMS are stored as sequential files with a record size of 512 bytes (a size convenient for the OpenVMS virtual memory management subsystem, as well as the size of a disk "block"). Even though program files are sequential, they are typically accessed by block number.

Disk Structure Levels

Some versions of OpenVMS support more than one disk organization. This is similar to a Windows NT system, which supports both the FAT and NTFS disk structures.

Most OpenVMS disks are structured as On-Disk Structure Version 2 (ODS-2) volumes. Some versions of OpenVMS support a newer disk organization, ODS-5.

ODS-5 is intended primarily to provide a disk environment more akin to the environments found on personal computer systems, including Microsoft Windows. ODS-5 supports longer filenames, deeper directory nesting, and a wider variety of legal characters in filenames than does ODS-2. These characteristics make it convenient to serve an ODS-5 volume to computers running different operating systems across the network.

ODS-5 is supported on Alpha beginning with OpenVMS Alpha V7.2 and has limited support on VAX beginning with OpenVMS VAX V7.2. Even so, not all OpenVMS applications directly support ODS-5.

Examples given in this book use ODS-2 filename and directory rules, which will also work under ODS-5.

Components of an ODS-2 File Specification

In order for the system to identify a particular file correctly, each file must have a name that is unique among all files on the network, the operative phrase being "on the network." Two different OpenVMS systems may have disks, directories, and files with identical names, but must be able to tell them apart.

To differentiate among these files, a full file specification is necessary. It contains enough information to identify any given file on the network uniquely.

A full file specification follows this format:

    NODE::DEVICE:[DIR.SUBDIR1.SUBDIR2(...)]NAME.EXT;VERSION 

Let's examine each component.

NODE:: is the computer upon which the disk and directory reside. This field is required when only accessing a file or directory on some other computer on the network. It is the nodename of the computer followed by two colons. If the other node requires user authentication, this field takes the form NODE"username password"::. Chapter 14, "Using DECnet" contains more information on the NODE field.

DEVICE: is the disk device on which the directory resides. It ends with a single colon. The standard format for device names is discussed elsewhere in this chapter.

[DIR.SUBDIR1.SUBDIR2] is the directory. Directories are explained in detail in the following section. A directory is contained within brackets ([ ]), and each subdirectory level (if any) is separated by a dot (.). The top-level directory has the format [DIR]. The first subdirectory level is denoted [DIR.SUBDIR1]; the second, [DIR.SUBDIR1.SUBDIR2]; and so forth. Earlier versions of OpenVMS limited subdirectories to a depth of seven, but later versions lift this restriction.

The NAME consists of up to 39 characters that identify the file. On an ODS-2 disk, all alphabetic characters are treated as if they were upper case. They will be stored and displayed in upper case, but you may use any combination of upper and lower-case when identifying the file. Valid characters are letters, numbers, the underscore (_), the dollar sign ($), and the hyphen (-).

EXT stands for extension. This is a 0- to 39-character field that identifies the type of file it is. It is preceded by a dot, which is present even with a zero-length (null) filetype. Legal characters are the same as for the NAME field. You may use any legal characters you wish, but the system automatically assumes some default extensions for various types of files. Examples include.LOG for batch log files, .COM for DCL command procedures, and.EXE for executable programs. See Appendix C for common default filetypes.

VERSION is a number from 1 to 32767 identifying a version number for the file. Version numbers are a feature not found on some other systems. When you create a new file, it is assigned a version number of 1, unless you specify a different number. If you later edit and save the file, version 2 is created, but version 1 continues to exist. This avoids a common problem of some other systems, where saving a file overwrites the old contents. Under OpenVMS, a previous version of a file can be accessed by specifying its version number. Previous versions are deleted with the PURGE command or by an optional version limit which can be different for each file.

Under ODS-2, all fields are case-insensitive. You may use any combination of upper and lower case to specify filenames. The system will display filenames in upper case only.

Differences in ODS-5

OpenVMS Alpha V7.2 and later and presumably OpenVMS Itanium support an additional disk structure: On-Disk Structure Version 5 (ODS-5). ODS-5 supports additional legal characters in filenames and a deeper directory level nesting. These extended filename rules support filenames similar to those found in Microsoft Windows 95/98 and Windows NT.

ODS-5 is provided primarily to support file-sharing capabilities for DCOM and JAVA applications and remote systems supporting file specifications that cannot be directly represented by ODS-2. General users can use ODS-5 volumes, but please be aware that many OpenVMS programs are not guaranteed to work properly with ODS-5 volumes. The number of compatible applications will likely increase over the next few versions of OpenVMS.

OpenVMS VAX Version V7.2 and later include only limited support for ODS-5. While participating in a cluster with an OpenVMS Alpha system, a VAX system may mount an ODS-5 disk, but can process only files that comply with ODS-2 rules.

Filenames under ODS-5 can be up to 236 8-bit characters in length, or 118 16-bit characters. Filenames can contain 8-bit ISO Latin-1 and 16-bit Unicode (UCS-2) characters, except for double quotes (""), asterisks (*), backslashes (\), colons (:), angle brackets (< >), slashes (/), question marks (?), and vertical bars (|). To enter certain characters unambiguously in a file specification (such as a space), you must precede the character with a circumflex (^). Directory names can support most of the same characters as filenames. Periods and other special characters must be preceded by a circumflex.

ODS-5 file specifications are case-sensitive, and ODS-5 can support up to 255 levels of directory nesting.

See the OpenVMS Guide to Extended File Specifications for further information.

Working with Files

The following sections introduce the reader to commonly performed functions related to files. As stated previously, the file is the basic unit of data storage and most operations will involve files in some way.

Displaying a List of Files (the DIRECTORY command)

The DIRECTORY command displays information about one or more files contained in one or more directories. Directories are explained in detail later, but for now just be aware that a directory is a grouping of related files. Each user typically has a separate directory to keep his or her files separate from those of other users. Some operating systems use the term folder in place of directory.

DIRECTORY can display the names, sizes, dates of creation, and other details about files, depending on the qualifiers you use. The simplest form of the command shows only the names, types, and versions of files in the current default directory:

    $ DIRECTORY    Directory DKA100:[MIKE.SCENE]    SCENE.C;1           SCENE.EXE;1        SCENE.OBJ;1    Total of 3 files. 

The top line of the display indicates that the current directory is DKA100:[MIKE.SCENE] This means that the directory resides on a disk called DKA100:, on which there is a directory called MIKE, and within it, a directory called SCENE. A directory may contain subdirectories; think of such subdirectories as folders within a folder.

In this example directory, there are three files: SCENE.C, SCENE.EXE, and SCENE.OBJ. You will notice that directories automatically maintain files in alphabetical order.

The information shown by the simplest DIRECTORY command is quite basic, displaying only the names of the files. But DIRECTORY has numerous qualifiers that can display detailed information about files. For example, let's say you wish to see the date and time each file was last modified, its size, and its owner. You would use this command:

    $ DIRECTORY/SIZE/DATE=MODIFIED/OWNER    Directory DKA100:[MIKE.SCENE]    SCENE.C;1                 23  5-NOV-2002 20:47:50.14  [MIKE]    SCENE.EXE;1              128  5-NOV-2002 20:49:02.88  [MIKE]    SCENE.OBJ;1               11  5-NOV-2002 20:48:23.61  [MIKE]    Total of 3 files, 162 blocks. 

Note 

File sizes are shown in 512-byte blocks. SCENE.OBJ is about 5,632 bytes in size.

You may use DIRECTORY to show only certain files by specifying one or more files as parameters:

    $ DIRECTORY/SECURITY SCENE.OBJ    Directory DKA100:[MIKE.SCENE]    SCENE.OBJ;1          [MIKE]                 (RWED,RWED,RE,)    Total of 1 file. 

The example above also includes the /SECURITY qualifier, which instructs the DIRECTORY command to show the ownership and file protection of any files displayed.

You may even examine files in another directory by specifying the directory as part of the parameter:

    $ DIRECTORY [MIKE]*.EXE    Directory DKA100:[MIKE]    DECRYPT.EXE;8       ENCRYPT.EXE;1     FINGER.EXE;1     FIRST.EXE;1    MIKESUMM.EXE;1      MYSTIFY.EXE;3     TEST.EXE;3       UNZIP_AXP.EXE;1    ZIP_AXP.EXE;1    Total of 9 files. 

You may have noticed that the previous example uses an asterisk (*) in place of part of a filename. This is a wildcard character, which means it will match any sequence of characters found at that location in a file specification. The use of wildcards is discussed subsequently.

File Sizes

OpenVMS expresses file sizes in blocks. A block is 512 bytes or 0.5KB. The following table shows various sizes expressed as blocks:

    Bytes     Blocks    512       1    1K        2    25K       50    50K       100    100K      200    500K      1,000    1M        2,048    10M       20,480    100M      204,800    1G        2,097,162 

File Specification Defaults

A full file specification can become quite long. However, you usually do not need to type all of it; OpenVMS assumes default values for almost all fields within the specification.

Every field from the nodename through directory, if omitted, will default to the current value: current node, current disk, and current directory. The version number, if omitted, will default to the highest version that currently exists. Even the file extension may assume a default value, depending on the context in which the file is referenced. Appendix C contains a listing of common default filetypes.

Let's say I have a command procedure in my home directory whose full file specification is PHOEBE::DKA100:[MIKE]TALLY.COM;34. Assuming my current disk and directory are the same, I can execute it by issuing this simple command:

    $ @TALLY 

Wildcards

Wildcards are special characters that match any character (or sequence of characters) in a file specification. You may use them to identify only those files in which you are interested. Wildcard characters may be used in the directory, filename, filetype, and version fields of a file specification. Using them in the node or device fields is not permitted.

Note 

Wildcards as used in directory specifications will be discussed later along with directories.

The wildcard characters used to match file specifications are as follows:

• *—The asterisk wildcard character matches zero or more characters at the position in a file specification where it appears.

• %—The percent sign matches exactly one character at the position in a file specification where it appears. Some examples follow.

    This file specification             Will match these files    *.DAT                               JUNIOR.DAT                                        BRADY.DAT    19*.TXT                             1996.TXT                                        19_BOTTLES_OF_BEER.TXT    *USE*.DAT                           USERGUIDE.DAT                                        SYSTEM_USERS.DAT    TEST.*                              TEST.C                                        TEST.EXE    199%.DAT                            1996.DAT                                        199A.DAT 

Some commands using wildcards might be:

    $ DELETE *.TMP;* 

Deletes all versions of all files in the current directory of the type .TMP.

    $ TYPE CHAPTER*.TXT 

Displays the contents of the most recent version of each file in the current directory whose name begins with "chapter" and that is of type .TXT.

    $ TYPE CHAPTER*.TXT;* 

Displays the contents of all versions of each file in the current directory whose name begins with "chapter" and that is of type.TXT.

    $ DIRECTORY CHAPTER2.TXT;-1 

Finds the previous version of CHAPTER2.TXT. The version ";-1" specifies the previous version, ";-2" specifies the version before that, etc. The notation ";-0" refers to the oldest version in existence. The notation ";" or ";0" specifies the highest version in existence.

Creating a File

To create a text file from scratch, you may use a text editor (see Chapter 13) or use the CREATE command. For most purposes, using a text editor is more convenient than using CREATE.

To use CREATE, enter "CREATE filespec" at the DCL prompt. Then, type the contents of your file. Each line you type will be placed into the file. You may fix mistakes on the current line only; once you press ENTER to end a line you may no longer make changes to that line. When finished entering lines, press CTRL/Z. This closes the file and returns you to the DCL prompt.

To create a file with the same contents as an existing file, use the COPY command, described later. You may also use a text editor on an existing file and save it under a different name.

Files other than text files are usually created by a program, not directly by a user, and are not covered here.

Displaying a File

To display the contents of a text file on the screen, use the TYPE command:

    $ TYPE filespec 

The contents of the file are displayed on your terminal. Use the /PAGE qualifier to display long files one page at a time. You may use the /TAIL= n qualifier to display the last n lines of a file.

Use caution when trying to TYPE any files that are not ordinary text files. Other types of files (say, executable programs or object files) usually contain sequences of unprintable control characters that cause rapid scrolling and beeping (at best) or may cause your terminal to freeze (at worst). If this happens, you may need to reset your terminal.

Deleting a File

To delete one or more files, use the DELETE command:

    $ DELETE filespec 

When deleting files, you must specify a version number or use a wildcard in the version field. Use caution when using wildcards other than in the version field because you may accidentally delete more files than intended.

You may wish to consider using these qualifiers with the DELETE command:

• /CONFIRM — Displays each filespec before deletion and asks you whether you would like to delete it. Affirmative answers (which may be abbreviated) are yes, true, 1 and all. ALL deletes all remaining files without confirming them. Negative answers are no, false, 0, and quit. QUIT exits the delete command immediately without processing any more files.

• /LOG — Displays the file specification of each file deleted and its size; displays a summary after all files have been processed.

Renaming a File

Files are renamed by using the RENAME command. It has a simple format, as follows:

    $ RENAME original_name new_name 

If you exclude a specific version number, the highest version will be renamed, leaving any previous versions intact. Therefore, the previous version becomes the highest version of the original file. To rename all versions of a file, include the asterisk wildcard in the version field of original_name (filename.type;*).

You may also use the RENAME command to move a file from one directory to another, so long as it remains on the same disk. Simply include a new directory specification in new_name:

    $ RENAME [REPORTS]FEBRUARY.RPT [OLD_REPORTS]FEBRUARY_2003.RPT 

RENAME supports the /CONFIRM and /LOG qualifiers just as DELETE does.

Copying a File

Files are copied by using the COPY command:

    $ COPY original_name new_name 

As with RENAME, omitting a version number causes only the highest version to be copied. You may also use COPY to combine several files into one by using a plus sign between original files or by using wildcards:

    $ COPY CAKE.TXT+COOKIES.TXT+FLAN.TXT DESSERTS.TXT 

or

    $ COPY DECEMBER*.RPT DECEMBER_ALL.RPT 

Use this feature only with simple sequential files, and avoid using it with other formats, such as indexed and relative. As usual, this command supports /CONFIRM and /LOG. The original files are not deleted.

Deleting Previous Versions of Files

When you modify an existing file, OpenVMS creates a new version of that file and retains previous versions. In a very short time, a large number of previous versions can accumulate, consuming disk space and making directory listings longer.

You may use the PURGE command to delete previous versions of existing files.

Some examples are as follows.

• To delete all versions of all files in the current directory except the highest version of each file:

       $ PURGE 

• To delete all previous versions of all files with the.LOG filetype.

       $ PURGE *.LOG 

• To delete all but the latest five versions of LOGIN.COM:

       $ PURGE/KEEP=5 LOGIN.COM 

The /KEEP= n qualifier instructs PURGE to retain the highest n versions of each file processed.

Use /CONFIRM to verify each file to be deleted. Answering YES deletes one version at a time. Use caution when answering ALL: Some versions of OpenVMS purge all versions of that particular file only, prompting you again at the next file; other versions of OpenVMS process all remaining files with no further prompts.

You may use /LOG to show you each file deleted and provide a summary after all files have been processed.

Setting File Version Limits

There is another way to control the accumulation of multiple file versions: you may set a version limit for any file. Let's say you set a version limit of five on a particular file. When you create the sixth version of that file, the lowest version will automatically be purged.

If you set a version limit on a file, but a greater number of versions already exists, OpenVMS will not purge files to correct the difference. It will still purge one version for each version created. You must manually purge the extra versions.

You should generally avoid setting a version limit of one; this can occasionally cause problems with some applications that read a previous version in order to create the next version. A minimum value of two is recommended.

To set a version limit of six on a given file:

    $ SET FILE filespec /VERSION_LIMIT=6 

Use a value of zero to disable version limits.

If you wish to set an automatic version limit for all future files in a given directory, you may set a default version limit for the directory (see "Using Directories" below). This setting takes effect only for files created after the limit is set. Once set, you may override this value on a per-file basis by using SET FILE/VERSION_LIMIT for any file.

    $ SET DIRECTORY DKA100:[MIKE]/VERSION_LIMIT=5 

Again, use a value of zero to disable version limits.