HP 3000 Manuals HP 3000 Manuals
MPE/iX New and Enhanced Intrinsics
by Craig Fairchild
Commercial Systems Division
Overview
In this release of MPE/iX, two new file system intrinsics have been
added. These intrinsics allow language independent use of features
provided for the POSIX.1 C languaged based standard. Other existing
intrinsics have also been enhanced in this release. The following
sections will discuss these additions in detail.
New Intrinsics
HPDEVCREATE.
HPDEVCREATE can be used to create several types of device related files.
These include streams files, FIFO files, and device link files. Streams
files abstract terminal file behavior and allow for asynchronous,
bidirectional data flow. FIFO files are named pipes (see the HPPIPE
intrinsic for a definition of a pipe). Device link files are disk based
files that are associated with a specific logical device (LDEV). Whenever
the device link file is opened, the caller actually opens the LDEV
associated with the device link. This is similar to a file equation of
the form;
:FILE TAPE;DEV=7
Where opening the name "TAPE" actually results in LDEV 7 being opened.
The difference between a device link and a file equation is that the
device link is a disk object and is therefore as permanent as any other
disk file.
The specifics on calling this intrinsic can be found in the Release 5.0
MPE/iX Intrinsics Reference Manual (32650-90028). HPDEVCREATE is an item
number/item value intrinsic similar in form to HPFOPEN. To create a
device link file, several options must be specified. The device file
category (item 1) must be specified with a value of 3 for a device link
file. Next, item 2 (LDEV) must be specified as the desired LDEV number.
An ACD may also be applied to the device link by specifying option 6,
Access Control Definition.
Once a device file is created, the name of the device file can be used as
an alias for the device. For example, if a device link file TAPE.DEV.SYS
existed and was associated with a tape device on LDEV 7, the following
command would print the contents of the tape mounted on LDEV 7 to the
screen;
:PRINT TAPE.DEV.SYS
All of the normal characteristics of opening a device still apply to
device link files. If the device is already opened by another job or
session, access to the device will be denied. Users lacking ND
capability will not be able to open devices. If an operator reply is
required to open a device, it will still be required to open the device
link file.
One of the characteristics of device link files that makes them useful,
also makes them behave oddly in some circumstances. Since referencing
the device link file is actually referencing the LDEV associated with the
file, some normal file system operations will not work as expected. For
example, PURGE or RENAME will not work on device link files. This is due
to the internal implementation of these commands within the Command
Interpreter. These commands first open the specified file and then
attempt the purge or rename operation against the file. When a device
link file is opened, access is established with the LDEV, not with the
disk file. Performing a RENAME or a PURGE on a device is a meaningless
operation and will result in an error.
To perform the file management operations of purging and renaming device
link files, the POSIX.2 shell may be used. The shell command rm can be
used to remove or purge the device link. The shell command mv can be
used to move or rename a device link file. These commands use POSIX.1
procedures (unlink() and rename(), respectively) to perform their
operations, which do not require that the file be opened first.
Device link files will be typically used in environments that wish to
make use of POSIX.1 or POSIX.2 features. An example of this would be
using the POSIX.2 tar utility (Tape ARchive) to restore data saved off of
an HP-UX system. Device link files would typically be found in a /dev
directory, though there is no requirement that they be restricted to any
specific directory.
HPPIPE.
The HPPIPE intrinsic allows the caller to create a pipe. A pipe is a
nameless file that is typically used for interprocess communication
between parent and child processes. Pipes are defined to have two ends;
a read end, and a write end. Just as water flows in one direction
through the pipes in your home, data is considered to be written to the
write end, and then flow to the read end. The data is read in the same
order that it was written (First In, First Out). Refer to the Release
5.0 MPE/iX Intrinsics Reference Manual (32650-90028) for details on
calling this intrinsic.
Calling HPPIPE will return two file numbers to the caller. The first is
the file number of the read end of the pipe. The other is the file
number of the write end of the pipe. The caller may then use these file
numbers to call the FREAD and FWRITE intrinsics, respectively, to perform
I/O to the pipe. It is important to note that pipes are byte-stream
record based files. Reads will read the requested amount of data until
the pipe becomes empty. If two writes of 10 characters each were done to
a pipe, a read of 15 characters would read the 10 characters of the first
write, and then 5 more of the second. The next read would start with the
5 remaining characters from the second write. This behavior is different
from MPE/iX MSG files which reads data in the same quantity as it was
written.
The general usefulness of the HPPIPE intrinsic is somewhat limited in
this release. Typical usage of pipes is that a parent process will open
a pipe and then use the fork() and exec() POSIX.1 system calls to create
a child process. When the child process is created through fork(), all
of the parent process' environment, including the pipe file numbers just
opened, is duplicated in the child's environment. This allows the parent
process to access one end of the pipe, and the child process to access
the other end of the same pipe. Without the ability to duplicate the
pipe's file numbers in the child process there is no way to share the
pipe with another process. Since intrinsic access to the fork() and
exec() functions does not yet exist, users must include calls to these
POSIX.1 functions in order to make full use of pipes.
Enhanced Intrinsics
FFILEINFO.
Seven new items have been added to FFILEINFO (items 92-98) for Release
5.0. These items allow various types of POSIX and non-POSIX file related
information to be returned. This information includes the KSAM XL file
version, the NM Plabel of a MSG file interrupt handler, the MPE/iX device
type, the state of the POSIX close-on-exec flag, the state of the POSIX
append mode flag, the state of the POSIX non-block mode flag, and whether
or not carriage control is on for the file.
In addition to the items added for 5.0, many other items were added to
FFILEINFO in the 4.5 Release. Please refer to the MPE/iX Intrinsics
Reference Manual (32650-90028) for more information.
FLABELINFO.
Several new items have been added to FLABELINFO, and a new field has been
defined in the mode parameter. The mode parameter now has the following
definition:
(0:11) Reserved for future use
(11:1) Symbolic link traversal
= 0 traverse through symbolic links, if they exist
= 1 do not traverse through symbolic links, if they exist
(12:2) Callers privilege level
Allows the caller to execute the FLABELINFO call in a less
privileged mode than they are currently executing
(14:2) File equations
= 0 use file equations if they exist
= 1 a file equation must be used
= 2 do not use file equations
Four new items have been added to FLABELINFO (items 50-53) to allow the
caller to retrieve the KSAM XL file version, KSAM XL parameters, the
MPE/iX device type, and the Secure/Release state of a file.
FOPEN.
The formaldesig parameter of FOPEN is interpreted using MPE-Escaped
syntax. Prior to MPE/iX Release 4.5, it was interpreted using MPE
syntax. FOPEN has been enhanced to allow creation of standard files with
byte-stream record format. Not all file types support byte-stream record
format in Release 5.0. File types that do support this record type
include standard file type, Pipes, FIFOs, Streams, and Symbolic links.
FOPEN foptions bits 0 and 1 have always been reserved for MPE system use,
but were never checked. In this release of MPE/iX, bit 1 is now defined
as the record format extension field and is used to specify that a
byte-stream record file should be created. This means that a previously
ignored field of the foptions is now being validated. In order to avoid
unexpected problems, be sure to initialize the unused foption fields to
zero before calling FOPEN.
In Release 5.0, FOPEN can be used to create files in the HFS domain.
This was not possible in Release 4.5, but HFS support for the new file
domain in 5.0 has allowed FOPEN to create HFS files. Note that there are
several new file types (including directories) that can only be created
through other intrinsics such as HPFOPEN and HPDEVCREATE.
FRENAME.
The formaldesig parameter of FRENAME is interpreted using MPE-Escaped
syntax. You no longer must be the creator of a file to FRENAME it. You
need only have sufficient access to read and delete the old file, and
create the new file. While FRENAME allows you to rename a file from any
name to any other name, there are some restrictions that are applicable.
KSAM, RIO, and CIR files may only be renamed within the MPE namespace.
Files may not be renamed across volume sets. Directories may not be
renamed.
FRENAME also potentially adds some attributes to files when they are
renamed. Whenever a file is renamed, FRENAME guarantees that the file
owner name in the file label is fully qualified (user and account).
Also, if the file does not have an ACD and is renamed into another
account or outside a group, an ACD is automatically placed on the file to
protect its original security.
HPFOPEN.
Two new items have been added to HPFOPEN for Release 5.0. Item 79 allows
the caller to specify the POSIX non-block mode for a file, and item 81
allows the caller to indicate whether or not symbolic links should be
traversed during the open. Item 80 is reserved for future use by the
system.