F MACHINE-DEPENDENT FEATURES

Although the implementations of HDS on different computer systems have been made as similar as possible, there are necessarily some differences in behaviour (especially compared to earlier VAX/VMS implementations) due to the underlying operating system. This appendix describes the behaviour for the operating systems on which HDS is currently supported.

F.1 File Naming

This section describes the naming rules for files when opening individual HDS container files. The rules used when searching for container files using the “wild-carding” facilities provided by HDS_WILD differ slightly (see §F.2).

File names may contain characters of either case on UNIX systems and HDS therefore does not perform any case conversion on file names. All leading and trailing white space on file names is ignored.

If a file name does not have an extension (i.e. does not have a period in the last field of its UNIX pathname), then HDS provides a default extension by appending ‘.sdf’ to the name. This occurs both when searching for existing files and when creating new ones. To make it possible to create file names without a period if required, HDS will also remove exactly one period (if present) from the end of a file name before using it.

If a file name contains any “special” characters¹⁰ and the value of the SHELL tuning parameter (§15.2) indicates that a shell is to be used for interpreting such file names, then the name will be passed to a process running the required shell for expansion before use. Thus any shell expression resulting in a valid file name may be used, such as:

(the precise syntax and capabilities depending on which shell is selected). The actual algorithm used for expanding file names is described in §F.2. If expansion results in more than one file name, then only the first one is used.

There are no file version numbers on UNIX systems. If an existing file name is given as the name of a new output file, then the original file will be over-written. It is an error to specify a file which has already been opened by HDS (e.g. for input) as the name of a new output file.

F.2 Wild-Card File Searching

When searching for HDS container files using the “wild-card” facilities provided by HDS_WILD and HDS_EWILD, the following rules apply.

Since traditional UNIX systems do not generally provide callable pattern-matching facilities for finding files, nor do they support the concept of default file type extensions, HDS implements these by passing wild-card file names to a shell process and expanding them using the following algorithm:

(1)

The string supplied (which may also be a list of files or file specifications separated by white space) is first expanded with the shell’s file name expansion facility turned off. This performs operations such as environment variable substitution and execution of embedded shell commands, but leaves pattern-matching characters in place.

(2)

The resulting string is then scanned as a list of file specifications separated by white space.

(3)

If any element of this list does not contain a file type extension, as indicated by the absence of a period in the final field (fields being separated by slash characters ‘/’), then an extension of ‘.sdf’ is appended to it. If an element initially ends in a period, then this is removed and no extension is added. This stage performs file type defaulting on all elements of the list consistent with the rules applied to individual file names (§F.1).

(4)

The resulting list of file specifications is then expanded with the shell’s file name expansion facility turned on, resulting in the final list of files.

HDS will further filter the list of files found to exclude any which appear not to exist, cannot be accessed, or are not valid HDS container files.

F.3 File Mapping

The sun4_Solaris and alpha_OSF1 implementations of HDS currently provide a choice between the use of file mapping to perform I/O operations on primitive objects and the use of direct read/write operations. This is selectable via the ‘MAP’ tuning parameter (see §15.2). The default is to use file mapping on both systems.

Only read/write operations will be supported on other systems, regardless of the setting of the ‘MAP’ tuning parameter.

F.4 Scratch Files

The environment variable HDS_SCRATCH is used on UNIX systems to define the directory in which HDS will create scratch container files to hold temporary objects created with DAT_TEMP. When creating a scratch file, HDS will use the file name:

where $HDS_SCRATCH is the translation of this environment variable. If HDS_SCRATCH is undefined, then the file name will be used alone, so that scratch files will then be created in the current directory.

F.5 File Locking

HDS file locking is not currently implemented on UNIX systems. This means that any number of processes may access a container file simultaneously. This should not be allowed to happen, however (apart from shared read access), because modifications to the file will not be propagated consistently between the file and the separate processes. The result will be a corrupted container file and/or hung or crashed processes.

Note that HDS supports access to container files over the Network File System (NFS), but does not provide file locking.