gtpc3m23Concepts and Structures

TPF File System Support

While not totally compatible with Portable Operating System Interface for Computer Environments (POSIX) standards, TPF file system support provides support for storing and operating on information in the form of stream files. A stream file is simply a file containing a continuous stream of data. Examples of stream files are PC files and the files in UNIX systems.

File ownership and accessibility are controlled using the POSIX-compliant structures of user ID, group ID, and access permissions associated with each file in the file system.

Application programs can interact with the TPF file system through TPF file system C functions. See TPF C/C++ Language Support User's Guide for more information.

Differences between Stream Files and Database Files

To better understand stream files, it is useful to compare them with TPF system database files. As shown in Figure 50, a database file is record oriented while a stream file is composed of a continuous string of bits. A database file has predefined subdivisions consisting of one or more fields that have specific characteristics, such as length and data type.

Figure 50. Stream File and Database File Comparisons


The different structure of stream files and database files affects how an application program is written to interact with them and where each type of file is best used in an application program. A database file, for example, is well suited for storing customer statistics such as name, address, and account balance, because these predefined fields can be individually accessed and managed. A stream file is better suited for storing information such as a picture, which is composed of a continuous string of bits representing variations in color. Stream files are particularly well suited for storing strings of data such as the text of a document, images, audio, video, HyperText Markup Language (HTML) documents, Java applets, and other Web-oriented files.

Using Stream Files in Programs

You can create C language programs that interact with stream files by using TPF file system C functions. There are some fundamental differences in the way you operate on database files from the way you operate on stream files.

The differences result from the different structure (or perhaps lack of structure) of stream files in comparison with database files. To access data in a database file, you typically define the fields to be used and the number of records to be processed. To access data in a stream file, you process the entire file sequentially or you indicate a byte offset and a length.

Because you define the format and characteristics of a database file ahead of time, the TPF system has knowledge of the file and can help you avoid performing operations that are not appropriate for the file format and characteristics. With stream files, the TPF system has little or no knowledge of the format of the file. The application program must know what the file looks like and how to operate on it correctly. Stream files allow an extremely flexible programming environment, but at the cost of having little or no help from the TPF operating system.

Directories

A directory is a file that is used to locate other files by name. Each directory contains a list of files that are attached to it. That list may include other directories.

TPF file system support provides a hierarchical directory structure that allows users and application programs to identify files in the TPF system. You might think of this directory structure as an inverse tree where the root is at the top and the branches are below. The branches represent directories in the directory hierarchy. These directory branches have subordinate branches that are called subdirectories. Attached to the various directory and subdirectory branches are files. A file is located by specifying a path through the directories to the subdirectory to which the file is attached. Files attached to a particular directory are sometimes described as being in that directory.

TPF file system directory support is similar to the directory support provided in UNIX, which was the model for many aspects of the IBM Disk Operating System (DOS), Windows, and OS/2 file systems. In addition, this support provides features typical of UNIX systems, such as the ability to store a file only once but access it through multiple paths using links. Figure 51 shows an example of an hierarchical directory structure.

Figure 51. TPF File System Directory Tree Example


Current Directory

When an application program requests an operation on a file the system looks for the file in the current directory unless the application program specifies an absolute path name. The current directory is also called the current working directory or just working directory.

The TPF_CWD_PATHNAME environment variable is used as the current directory when an application program starts. An application program can specify a directory other than the current directory by calling the chdir function at any place in the application program.

Path Name

A path name (also called a pathname) tells the system how to locate a file. The path name is expressed as a sequence of directory names that can also be expressed as symbolic links (see Symbolic Link), followed by the name of the file. Individual directories and the file name are separated by a slash (/) character; for example:

     directory1/directory2/file

There are two ways of indicating a path name:

Link and Symbolic Link

As shown in Figure 53, a link is a named connection between a directory and a file. A program can tell the system where to find a file by specifying the name of a link to the file. A link can be used as a path name or as part of a path name.

It is convenient to think of a file as something that has a name that identifies it to the system. In fact, it is the directory path to the file that identifies it. You can sometimes access a file by giving just the name of the file. You can do this only because the system is designed to assume the directory part of the path under certain conditions. The idea of a link takes advantage of the reality that it is the directory path that identifies the file. The name is given to the link rather than the file.

Figure 53. Identifying a File by a Link


There can be multiple links to the same file. For example, two application programs can share a file if each application program has a link to the file.

There are two types of links: hard links and symbolic links.

Hard Link

A hard link, which is sometimes called a link, cannot exist unless it is linked to an actual file. When a file is created in a directory, the first hard link is established between the directory and the file. Application programs can add other hard links. Each hard link is indicated by a separate directory entry in the directory. Links from the same directory cannot have the same name, but links from different directories can have the same name.

The TPF file system supports multiple hard links to a file either from the same directory or from different directories. The one exception is where the file is another directory. There can be only one hard link from a directory to another directory other than the dot (.) and dot-dot (..) directory entries. Figure 54 shows an example using multiple hard links to a file.

Figure 54. Multiple Hard Links to a File


Hard links can be removed without affecting the existence of a file as long as there is at least one remaining hard link to the file. When the last hard link is removed, the file is put at the end of an available list. If the application program continues to use the file, it can lose the file when the system reuses the storage.

Symbolic Link

A symbolic link, which is also called a soft link, is a path name contained in a file. When the system finds a symbolic link, it follows the path name provided by the symbolic link and then continues on any remaining path that follows the symbolic link. If the path name begins with a /, the system returns to the / (root) directory and begins following the path from that point. If the path name does not begin with a /, the system returns to the immediately preceding directory and follows the path name in the symbolic link beginning at that directory.

Consider the following example of how a symbolic link might be used.

Figure 55. Using a Symbolic Link


A user writes a program to show the status of customer accounts. The program uses the following path name:

     /Customer/Status/Summary

The system follows the Customer link, which leads to a directory (1), and then follows the Status link. The Status link is a symbolic link, which contains a path name (2). Because the path name begins with a /, the system returns to the / (the root directory) and follows the Records and Accounts links in sequence. This path leads to another directory (3). Now, the system completes the path in the path name provided by the program and follows the Summary link, which leads to a file (4) containing the data needed by the user.

Unlike a hard link, a symbolic link can exist without pointing to an existing file. Therefore, you can use a symbolic link to provide a path to a file that will be added later. You can also use a symbolic link as a variable path name that can be changed later.

Hard Link and Symbolic Link Comparisons

When using path names in programs, you have a choice of using a hard link or a symbolic link (see Link and Symbolic Link). Each type of link has advantages and disadvantages. Table 7 shows the conditions under which one type of link has an advantage over the other type.

Table 7. Comparison of Hard Link and Symbolic Link

Item Hard Link Symbolic Link
Name resolution Faster.

A hard link contains a direct reference to the file.

Slower.

A symbolic link contains a path name to the file, which must be resolved to find the file.

File existence Required.

A file must exist in order to create a hard link to it.

Optional.

A symbolic link can be created when the file it refers to does not exist.

File deletion Restricted.

All hard links to a file must be unlinked (removed) to delete the file.

Unrestricted.

A file can be deleted even if there are symbolic links referring to it.

TPF File System File Attributes

TPF file system files are identified externally by one or more different path names. TPF file system support translates path names to i-numbers, which are ordinals that index into #INODE and #FLOCK records that describe attributes (for example, the access mode) of a file.

Notes:

  1. I-number 0 is reserved as the anchor of the TPF file system.

  2. I-number 1 is reserved as the root directory of the TPF file system.

Special Files

The TPF system uses special files that can be opened to allow applications access to a device driver. At first glance, special files appear to be files just like any other. They have path names that appear in a directory and they have the same access protection as ordinary files. They can be used in almost every way that ordinary files can be used. However, an ordinary file is a logical grouping of data recorded on disk, while a special file corresponds to a device (such as a line printer), a logical subdevice (such as a large section of a disk drive), or a pseudo-device (such as the null file, /dev/null). You will have to create your own special files and device drivers for devices or logical subdevices. By convention, all the files located in the /dev directory are special files that correspond to device drivers. The file system initialization program (CBOT) sets up the /dev/tpf.omsg, /dev/tpf.imsg, and /dev/null special files when it initializes the file system. CBOT calls the UBOT user exit, which you can use to set up your own initial directories, files, special files, symbolic links, access modes, user IDs, and group IDs. See TPF System Installation Support Reference for more information about the UBOT user exit.

Table 8. Special Files and Their Associated Device Drivers

Special File Major Device Number Device Driver Description Device Address
/dev/tpf.omsg 0x0000 Sample code shipped with the UDDWTC segment provides write-only access for output messages that use the wtopc function. Use any current modifications of the puts and printf functions to customize UDDWTC for your own requirements. The terminal address (LNIATA) in hex (for example, 010000 would refer to the prime CRAS). Therefore, to explicitly open an output message file to terminal address ABCDEF, you would open /dev/tpf.omsg/ABCDEF. If there is no location data, the value of EBROUT at the time the file is opened is used as the terminal address.
/dev/tpf.imsg 0x0001 Sample code shipped with the UDDIPM segment provides read-only access to input messages that use MI0MI-format core blocks on data level D0. Use any current modifications of the gets and scanf functions to customize UDDIPM for your own requirements. None.
None 0x8000 Code shipped with the CDDTBL segment provides support for directories, regular files, and symbolic links. None.
/dev/null 0x8001 Code shipped with the CDDTBL segment provides support for the null device, or dummy file. None.
/dev/tpf.socket.file 0x8002 Code shipped with the CDDTBL segment provides support for mapping socket descriptors to file descriptors, and allows for the use of C application programming interfaces (APIs) that accept file descriptors but not socket descriptors. The file descriptor and corresponding socket descriptor are closed when the entry control block (ECB) exits. None.
None 0x8003 Code shipped with the CDDTBL segment provides support for pipes. See the pipe function in the TPF C/C++ Language Support User's Guide. None.
user-defined file name 0x8004 Code shipped with the CDDTBL segment provides support for FIFO special files (also referred to as named pipes). See the mkfifo function in the TPF C/C++ Language Support User's Guide. None.

See TPF C/C++ Language Support User's Guide for information about how to add a user-defined device driver.