Document revision date: 28 June 1999

OpenVMS Version 7.2 implements Extended File Specifications, which consists of two major components:

• A new, optional, volume structure, ODS-5, which provides support for names that are longer and have a greater range of legal characters than previous versions of OpenVMS
• Support for deep directories

DECdfs for OpenVMS Version 2.3 provides support for Extended File Specifications and ODS-5 volumes, with certain restrictions outlined in this appendix.

For more information on Extended File Specifications and ODS-5 volumes, refer to the OpenVMS Guide to Extended File Specifications in the OpenVMS Version 7.2 documentation set.

F.1 Requirements for Mounting DECdfs Access Points on an ODS-5 Volume

Only OpenVMS Alpha Version 7.2 systems running DECdfs Version 2.3 are capable of serving and mounting access points on ODS-5 volumes. If a pre-Version 7.2 client running DECdfs Version 2.3 attempts to mount a DECdfs access point on an ODS-5 volume, the operation fails with the following error:

%DFS-F-UNSUPPFS, Unsupported file system structure

A client system running an older version of DECdfs fails with a different error on an attempt to mount or access an ODS-5 access point, as follows:

%SYSTEM-E-UNSUPPORTED, unsupported operation or function

On OpenVMS VAX Version 7.2 systems, you can mount DECdfs access points on ODS-5 volumes, but you are limited to ODS-2-compliant file operations.

You can determine whether a mounted DECdfs access point is associated with an ODS-5 volume by executing a SHOW DEVICE/FULL command and checking the ODS-5 characteristic in the resulting volume status display. From a DCL command procedure, the F$GETDVI lexical function returns the string F11V5 for the ACPTYPE argument. The $GETDVI system service returns the value DVI$C_ACP_F11V5 for the item code DVI$_ACPTYPE.

F.2 XQP Programming Considerations

DECdfs functions as a layer between OpenVMS Record Management Services (RMS) and the OpenVMS XQP file system. DECdfs accepts I/O requests from RMS on the client system and sends the I/O request information over a DECnet connection to the DECdfs server. The server takes the request and builds an equivalent I/O request for the XQP file system on the server and returns the results.

Since the DECdfs server and client systems can have different CPU architectures and may be running different versions of OpenVMS, compatibility issues can arise between the version of RMS on a DECdfs client and the version of XQP on the DECdfs server. One goal of DECdfs is to transparently handle any differences between systems in order to provide the expected result.

When the DECdfs client system is running an earlier version of OpenVMS than the DECdfs server, there are few compatibility issues because the XQP has maintained excellent upward compatibility from one release to the next. However, when the DECdfs client is running a later version of OpenVMS than the DECdfs server, there are compatibility issues to consider. For example, the Extended File Specifications support introduced with OpenVMS Version 7.2 creates certain problems when a DECdfs client running OpenVMS Version 7.2 accesses volumes served by a DECdfs server running an earlier version of OpenVMS.

F.2.1 File Naming and Format Changes

DECdfs Version 2.3 fully supports Extended File Specifications at the $QIO interface of the Files-11 XQP when both the client and server systems are running OpenVMS Version 7.2. This includes 8- and 16-bit character set formats.

When you access files on an ODS-5 volume from an OpenVMS VAX Version 7.2 system, no escaped file name forms are returned. For an ODS-2 or ISO Latin-1 file format, the name stored in the file header is returned. For a UCS-2 file format, a pseudoname is returned, followed by the file identifier in parentheses.

When the DECdfs client system is running OpenVMS Version 7.2 and the DECdfs server system is running an earlier version of OpenVMS, file names are limited to ODS-2-compatible formats and character sets.

F.2.2 Wildcards in File Specifications

Historically, OpenVMS has used the percent sign (%) as the single-character wildcard in file specifications. The OpenVMS Version 7.2 XQP also recognizes the question mark (?) as an additional single-character wildcard. DECdfs Version 2.3 automatically replaces all question marks with percent signs if the access point being addressed is served by a pre-Version 7.2 system unless the FIB$V_PERCENT_LITERAL flag is set. In this case, a SS$_BADFILENAME error status will be returned.

F.2.3 Modified XQP Attributes

ATR$C_ASCNAME

The ATR$C_ASCNAME attribute allows the file specification stored in a file's primary file header to be read and written. In OpenVMS Version 7.2, the maximum buffer size that can be specified has been increased from 86 to 252. If the DECdfs server system is running an older version of OpenVMS, the limit is still 86 bytes. In that case, a Version 7.2 client system can specify a larger buffer, but DECdfs automatically truncates it to 86 bytes before sending the request to the server.

As stated in the OpenVMS Guide to Extended File Specifications, the ability to write this attribute is provided solely to permit compatibility with existing applications. New and modified programs should not write this attribute. Changing its value can prevent a file from being permanently deleted.

ATR$C_FILE_SPEC

ATR$C_FILE_SPEC is a read-only attribute that returns the physical file specification. In OpenVMS Version 7.2, the largest permitted buffer that can be specified has increased from 512 to 4098 bytes. On ODS-2 volumes, the attribute is returned as always. If the DECdfs server is running a version of OpenVMS prior to Version 7.2 and the client system is running OpenVMS Version 7.2, DECdfs automatically truncates any buffer larger than 512 bytes.

	privacy and legal statement
6548_CPRO_010.HTML