HP OpenVMS Systems Documentation
Guide to OpenVMS File Applications
4.3 Creating and Accessing Tagged Files
RMS supports the use of compound document text through the implementation of tagged files. The term compound documents refers to files that contain a number of integrated components including text, graphics, and scanned images.
Tagged files are made distinguishable by the RMS file attribute stored semantics. The value of the stored semantics attribute is called the file tag, and it specifies how file data is to be interpreted.
RMS support for compound document text requires that compound document files be tagged with the appropriate stored semantics values. These are binary values that can be up to 64 bytes long and can be expressed using hexadecimal notation. The hexadecimal value of the DDIF tag, for example, is 2B0C8773010301. The operating system lets you assign names to tag values so that DCL commands such as DIRECTORY/FULL and utilities such as FDL and ANALYZE/RMS_FILE display a more easily remembered mnemonic for the DDIF tag instead of the hexadecimal value.
Assigning a name to the tag also aids in using the /SEMANTICS qualifier with the DCL SET FILE command when you want to tag a file from the DCL interface. For example, you can use a command like the following:
To assign a tag a name, you must have privileges to make appropriate entries in two system tables, RMS$SEMANTIC_TAGS and RMS$SEMANTIC_OBJECTS.
For example, the following DCL commands have been included in the system startup command file to assign the mnemonic DDIF to the hexadecimal value for a DDIF tag:
You can tag files through the DCL interface, the FDL interface, or from your program by way of the RMS interface. This section describes the implementation of tagged files through the RMS interface including:
4.3.1 Programming Interface for File Tagging
You can tag a file from the RMS interface by using the Create service in conjunction with an item XAB ($XABITM). See OpenVMS Record Management Services Reference Manual for more information about using the $XABITM macro.
Example 4-6 illustrates a BLISS--32 program that tags a DDIF file through the RMS interface. The tag value shown is a 7-byte hexadecimal number representing the code for the DDIF tag. The RMS program interface accepts only hexadecimal tag values.
To write to a tagged file, the application program must use a $XABITM macro to specify access semantics that match the file's stored semantics as established by a $XABITM macro. As shown in the example, the Create service tags the file and the Connect service specifies the appropriate access semantics.
4.3.2 Accessing a Tagged File
This section details how RMS handles access to tagged files at the program level. When a program accesses a tagged file, RMS must determine whether and when to associate an RMS extension with the access. This is important to the programmer because an RMS extension can change the attributes of the accessed file.
RMS extensions are system images that perform specialized file or record operations within the context of RMS. Record management services can invoke an extension if specified conditions are met. Functions provided by an extension are only accessible through the record managment services and are generally transparent to the application.
An example of an RMS extension is the DDIF-to-ASCII text translator. RMS can call this extension to extract ASCII text from a DDIF file. The conditions that determine when this extension is called are described in this section.
A DDIF file is a sequentially organized file with 512-byte, fixed-length records. If the DDIF-to-ASCII RMS extension is used to extract text from a DDIF file, the accessed file appears as a sequentially organized file having variable-length records with a maximum record size of 2048 bytes and an implicit carriage return.
One consideration in determining whether an access requires the RMS extension is the type of access (FAB$B_FAC). When an application program opens a file through the RMS program interface, it must specify if it will be doing record I/O (default), block I/O (BIO), or mixed I/O (BRO) operations, where the program has the option of using either block I/O or record I/O for each access. For example, if block I/O operations are specified, RMS does not associate the RMS extension with the file access.
Another consideration is whether the program senses the tag when it opens a file. If the program does not sense the tag when it opens a DDIF file for record access, RMS associates the RMS extension with the file access during the Open service and returns the file attributes that have been modified by the extension.
The final consideration is the access semantics that the program
specifies and the file's stored semantics (tag). If the program
specifies block I/O (FAB$V_BIO) operations, RMS does not associate the
RMS extension with the file access and the Open service returns the
file's stored attributes to the accessing program regardless of whether
the program senses tags.
This section describes what happens when a program does not use a XABITM control block to sense a tag when it opens a file.
When a program opens a DDIF file for record operations and does not sense the tag, RMS assumes that the program wants to access text in the file. In this case, RMS associates the RMS extension with the file access, which provides file attributes that correspond to record-mode access.
When a program opens a DDIF file with the FAB$V_BRO option and does not
sense the tag, any subsequent attempt to use block I/O fails. If the
program specifies block I/O (FAB$V_BIO) when it invokes the Connect
service, the operation fails because the file attributes returned at
Open permit record access only. Similarly, if the program specifies the
FAB$V_BRO option when it opens the file and then specifies mixed mode
(block/record) operations by not specifying RAB$V_BIO at connect time,
block operations such as READ and WRITE are disallowed.
RMS does not associate the RMS extension with the file access as part of the Open service if a program opens a DDIF file and senses the stored semantics. This allows the program to specify access semantics with the Connect service. RMS returns the file attributes, including the stored semantics attribute (tag value), to the program as part of the Open service.
When the program subsequently invokes the Connect service, RMS uses the specified operations mode to determine its response. If the program specified FAB$V_BRO with the Open service and then specifies block I/O (RAB$V_BIO) when it invokes the Connect service, RMS does not associate the RMS extension with the file access.
But, if the program specifies record access or FAB$V_BRO when it opens the file and then decides to use record I/O when it invokes the Connect service, RMS compares the access semantics with the file's stored semantics to determine whether to associate the RMS extension with the file access. If the access semantics match the stored semantics, RMS does not associate the RMS extension with the file access. If the access semantics do not match the stored semantics, RMS associates the RMS extension with the file access. In this case, the program must use the Display service to obtain the modified file attributes. If RMS cannot find the appropriate RMS extension, the operation fails and the Connect service returns the EXTNOTFOU error message.
If the application program senses the file's stored semantics, RMS allows mixed-mode operations. In this case, mixed block and record operations are permitted because the application gets record mode file attributes and data from the RMS extension and block mode file attributes and data from the file.
Example 4-7 illustrates a BLISS--32 program that accesses a tagged file from an application program that does not use an RMS extension.
4.3.3 Preserving Tags
In order to preserve the integrity of a tagged file that is being copied or transmitted, the tag must be preserved in the destination (output) file. The most efficient way to use the RMS interface for propagating tags involves a 2-step procedure:
4.4 Defining File Protection
You can protect a disk file in two ways:
4.4.1 UIC-Based Protection
You can protect the disk with UIC-based protect codes that are described in the OpenVMS Guide to System Security.
The owner UIC is normally the UIC of the person who created the file. The protection code indicates who is allowed access and what type of access they are permitted.
You can specify the UIC-based protection value you need when the file is created if you use either an FDL specification or RMS directly.
The previous list omits CONTROL access because it is never specified in the standard UIC-based protection code. However, CONTROL access can be specified in an ACL and is automatically granted to certain user categories when UIC-based protection is evaluated.
CONTROL access grants the accessor all the privileges of the object's
actual owner. For more information, see the documentation related to
You can also protect disk files with access control lists (ACLs). (ACLs cannot be used with magnetic tape files.)
An ACL is a list of people or groups who are allowed to access a particular file. ACLs offer more scope than UICs in determining what action you want taken when someone tries to access your file. You can provide an ACL on any file to permit as much or as little access as you want.
You can specify the ACL for a file when you create it if you use RMS directly. You cannot specify an ACL in an FDL specification, and ACLs are not supported over DECnet.
After a file is created, you can define the access control list for it with the ACL Editor. You can invoke this editor with either of the following DCL commands:
For more information about how to invoke, modify, and display ACLs, see
the OpenVMS System Management Utilities Reference Manual. For additional information about operating system
security features, see your system or security manager, or consult the
documentation related to OpenVMS security.
The next two sections explain how to use the Convert utility to
populate a file.
To create a file, you need an input data file and an FDL file that describes the output file you want to create. You issue a DCL command in the following form:
As with the CREATE/FDL command, the CONVERT/CREATE/FDL command creates a file named by the output-file parameter and having characteristics specified in your FDL file. Unlike the CREATE/FDL command, CONVERT populates the output file with the records from the input file. For example, to create the file CUST.IDX from the specifications in the FDL file STDINDEX.FDL and copy the records from the input file CUST.SEQ into CUST.IDX, you enter the following command:
RMS assigns the characteristics specified in the file STDINDEX.FDL to
the records in CUST.IDX. Note that the Convert utility processes
relative files by sequentially reading records from the input file,
then writing them to the output file. As a result, the relative record
numbers (RRN) change when the input file contains deleted or unused
You can invoke the functions of the Convert utility from your application program by calling the following series of convert routines:
The routines must be called in this order.
Example 4-8 shows how to call the CONVERT routines from a Fortran program.
Example 4-9 shows how to call the CONVERT routines from a COBOL program.