|
|
|
|
|
|
|
|
New Features of MPE/iX: Using the Hierarchical File System: 300 MPE/iX Computer Systems > Chapter 4 What's New for Programmers?
New File Types |
|
Release 4.5 and 5.0 of MPE/iX provide some new file types. Here is a brief description of them. Since these interfaces are based on a commonly used standard, many textbooks are available that contain a detailed discussion of their use. Symbolic links are permanent MPE/iX files that can be created, removed, renamed, and archived. Symbolic links can be created by one of the following two ways:
Symbolic links can be removed in the following ways:
Symbolic links can be renamed by calling the POSIX C-library function rename. The MPE/iX command RENAME does not rename the symbolic link itself, it renames the file pointed to by the symbolic link. Symbolic links can be stored and restored to your MPE/iX system by using the MPE/iX STORE and RESTORE commands like any other file on the system. This command displays information about the symbolic link file and its contents. For example: If the file
is a symbolic link to /SYS/PUB/NL, then
displays information about the file syml and in addition, it displays:
A pipe provides a method to take output from one process and use it as input to another process. The HPPIPE intrinsic creates a new file type object called pipe for this purpose. It provides a one-way flow of data. After creating a pipe file type object, the HPPIPE intrinsic returns both read-access and write-access file numbers. Related processes can access the pipe. Data can be written to the write-end and read from the read-end of the pipe. The data is accessed in a first-in-first-out manner, or FIFO. A pipe file does not have a name associated with it and is not inserted into any directories upon creation. After the final close of a pipe file, the file is deleted. Pipe files are treated as new files. A FIFO is similar to a pipe. It is a one-way flow of data, with the first byte written to it being the first byte read from it. Unlike pipes, a FIFO has a name associated with it, allowing unrelated processes to access a single FIFO. FIFOs are also called "named pipes." The program MKNOD.PUB.SYS has been modified to support the creation of a new file type object called fifo to be used for this purpose. It creates a FIFO file and inserts it into the directory. The HPFOPEN intrinsic has been modified to support the opening of the FIFO file. After the final close of a FIFO file, the data remaining in the FIFO is deleted, but the FIFO container remains and can be reopened and used again. FOPEN can open FIFOs as well. Beginning with MPE/iX Release 4.5, the byte-stream record format is available to allow an MPE/iX file to reproduce POSIX byte-stream behavior.
The standard file used in a POSIX environment is the byte-stream file. Conceptually, a POSIX byte-stream file has no system-defined record structure. A user can write any number of bytes from a user buffer to a byte-stream file starting at the current file offset. By default, byte-stream files created by HPOPEN have a file limit of 2 Gigabytes. Byte-stream files created by FOPEN have a default file limit of 1023 bytes. The size can be defined by the user. Likewise a user can read any number of bytes from a byte-stream file to the user's buffer starting at the current file offset. In short, a byte-stream file is a file that stores data in the form of a stream of bytes. It is the responsibility of the programmer to provide meaning and structure to the data. You use either the HPFOPEN or FOPEN intrinsics to create a byte-stream file. (Byte-stream files can also be created using POSIX.1/iX library functions.) You can also use the BUILD command, for example:
where B; indicates byte-stream record format. The following table defines the file and access attributes imposed on an MPE byte-stream file when it is created. These attributes cannot be changed during the life of the byte-stream file. Table 4-3 Access Attributes of Byte-Stream Files
User-defined labels can be attached to a byte-stream file. For these files, the behaviors of both the FREADLABEL and FWRITELABEL intrinsics remain unchanged. MPE/iX provides two mechanisms to open and access a byte-stream file. The behavior of the byte-stream file differs depending on how you open it. The two mechanisms are:
Opening a byte-stream file as a buffered variable-length record format file allows existing applications to access a byte-stream text file in a known and expected manner without having to perform any code revisions. For example, many text editors supported today can access either fixed-length record format files or variable-length record format files. By allowing a byte-stream file to be opened as a variable-length record format file, these text editors can read from and write to byte-stream files without concern for compatibility problems that occur when trying to access a file with an unknown record structure. Both the blocking factor and the record size of a byte- stream file are equal to one. The record pointer is defined by its offset from the beginning of a file of one-byte records. The offset of the first record, or byte, is zero. When a byte-stream file is first created, the record pointer points to byte zero. Conceptually, there should be no limit to the number of bytes a user can transfer to and from a byte-stream file. In fact, processes performing data transfer using POSIX.1/iX library functions can transfer up to two gigabytes of data in one operation. However, the length parameter used by MPE/iX data transfer intrinsics (FREAD, FREADDIR, FWRITE, FWRITEDIR) to specify the number of bytes to transfer limits the value to 32,768 (this value must be passed as a negative-signed integer value to indicate byte transfer). Byte-stream files are always opened for multirecord access. Because data transfer to and from byte-stream files usually occurs in blocks of bytes, data transfer to and from byte- stream files usually occurs using sequential access. Sequential access is the typical form of byte-stream data transfer. The behavior of both the FWRITE and FREAD intrinsics are straightforward with respect to byte-stream files. Data transfer to and from byte-stream files is usually accomplished by transferring a number of bytes to or from the file. After a successful data transfer, the record/byte pointer is set to the next unread/unwritten byte. Carriage controls are ignored when accessing byte-stream files. Care should be taken when accessing a file using sequential access methods. Because there is no system-imposed record structure in a byte-stream file, applications that require some form of record structure in order to sequentially access user-defined records in the file must define and manage their own record blocking and deblocking. The behavior of both the FWRITEDIR and FREADDIR intrinsics are straightforward with respect to byte-stream files. When performing random access on a byte-stream file, remember that the logical record number passed in the lrecnum parameter corresponds to the desired byte offset from the beginning of the file (byte offset 0). Successful data transfers set the record/byte pointer to the next unread/unwritten byte. Carriage controls are ignored when randomly accessing byte-stream files. Care should be taken when accessing a file using random access methods. Because there is no system-imposed record structure in a byte-stream file, applications that require some form of record structure in order to randomly access user-defined records in the file must define and manage their own record blocking and deblocking. A byte-stream file opened for append access using the HPFOPEN/FOPEN "access type" option performs in a straightforward manner. When the file is opened, the record/byte pointer is set to the end of the file. Subsequent writes to the file using FWRITE appends data to the end of the file, ensuring that existing data cannot be overwritten. Beginning with MPE/iX Release 4.5, item number 51 of the FCONTROL intrinsic can be used to enable a new type of append access called "append mode". Append mode is available only for byte-stream files. Append mode differs from append access in the following ways:
Update access is not allowed on byte-stream files. If you attempt to set the access type option of HPFOPEN/FOPEN to "update" when opening a byte-stream file, an error occurs. Likewise, a call to the FUPDATE intrinsic on a byte-stream file results in an error. Use the FPOINT intrinsic to move the record pointer from its current offset to any offset in a byte-stream file. FPOINT also allows you to set the record pointer beyond existing data in the file. If data is later written at this point, the resulting gap is padded with the fill character, which is defaulted to the ASCII null character, but may be set to any character at creation time. This case is the only circumstance where the file system pads a byte-stream file. Use the FCONTROL intrinsic with a control code of 5 to "rewind" the record pointer of a byte-stream file to the first record/byte, a file offset of zero. Use of the FSPACE intrinsic on a byte-stream file is not allowed. An attempt to do so results in an error. Instead, use the FPOINT intrinsic.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||
|
|
|
|||||||||
|
|||||||||
