IRAC Preface |
1 Introduction |
2 General Design Objectives |
3 General Syntax and Semantics of the Abstract Specification |
4 Object Management System |
5 Program Execution Facilities |
6 Input and Output |
7 Protection and Security |
8 Requirements for Tool Management and Services for Tools |
9 Ancillary Requirements |
10 Definitions |
Submission of Comments
INPUT AND OUTPUT
Security mechanisms, and data consistency mechanisms shall apply to all
PCIS facilities required by this section.
Input and output are defined in terms of logical devices. Logical and
physical devices are regarded as logical and physical resources
respectively, and the requirements in Sections 2.9 and 2.10 apply.
The paragraph above categorizes logical and physical devices as logical
and physical resources respectively, allowing the more general
Section 2.9 and
to be invoked. In particular the IRAC requires a process to be able to
use a logical device. The mapping of that logical device onto a
particular physical device is achieved by
Requirement 2.10A and
The requirements in this section are stated in terms of concepts
expressed in the following Entity Relationship diagram which is
intended as clarification of some of the terms used.
| Logical |
| Device |
| Type |
^ defines properties of
| | |
v | +-------------+ |
v instance of | |+-----------+| |
| | || Process || |
+----+----+ | || Connector || |
+---------+ | | | |+-----------+| |
| | uses | | maps to | | | |
| Process |-<<------->>-| Logical |-<<------------->-| | | |
| | used by | | mapped to by | |+-----------+| |
+---------+ | | | || Physical || |
+---------+ | || Device || |
| |+-----------+| |
Key: Double-headed arrows show "to-many" relationships.
Single-headed arrows show "to-one" relationships.
Note: This diagram is intended solely for clarification of
the language in which the requirements are stated and
not as a model that is to be directly provided by the
It is seen as undesirable that a tool should be able to connect itself
to a particular physical device. Rather, tools should operate only on
logical devices, otherwise tool portability is seriously impaired. How
can a tool be portable if it asks to be connected to a printer at a
particular physical location? What happens when that particular device
is not serviceable? A tool must expect a logical device to be of a
particular logical device type. It is a function of the administration
of resources that allows a given logical device to be mapped to a
particular physical device. This mapping can be delayed and occur at
run-time to answer to the general requirements of flexibility and the
ability of PCIS to evolve (see
Logical Device Types
A logical device type defines the properties of a set of logical
devices. One or more instances of a logical device type may be
available for input or output.
The properties of a logical device type are the abstractions of the
properties of a set of physical devices so that these properties have a
defined effect on each physical device that the logical device type
represents. The list of types of logical devices that the PCIS should
support is indicated in the rest of this section. A process may use
several instances of a single logical device type, for example, a tool
may wish to output results to one line printer and a summary to
6.1A Introducing Device Types. PCIS shall support the introduction
(and possibly the cancellation) of logical device types.
The set of logical device types should evolve with the introduction of
novel physical devices (for example, data gloves, 3D-mice, display
helmet, softpen, etc.). PCIS implementations are not required to
support all the device types specified in all the requirements of
to be conformant. A device can become obsolete, for example, a card
reader. On the other hand, it could be acceptable not to provide a line
printer. This complements
6.1B Serial Device Types. The PCIS shall support at least the
following serial logical device types:
Serial logical device types are those that handle a stream of data
units in a purely serial fashion, in particular, these devices do not
allow selective overwriting of information.
- Magnetic tape unit
- Alphanumeric terminal
- Line printer
- Magnetic tape units not only read and write data serially
but also support rewinding.
- Serial terminals are the basic form. They may emulate
teletypes or similar hard copy devices.
- Line printers are similar to serial terminals, except they
only provide for output. Additionally they support pagination
and wider pages.
- Scanners can read serially (or not!) alphanumeric or non
alphanumeric data (for instance, bar code which also can be
read with wands).
6.1C Positional and Interactive Device Types. PCIS shall support at
least the following positional and interactive logical device types:
Positional device types allow input and output operations to be
specified by position.
- Page addressable printer
- Cursor addressable terminal
- Bulk storage
- Locator input
- Bit-mapped terminal
- Graphical terminal
- 3D devices
Interactive device types communicate with the end user and typically
require coordination between input and output. They also provide
facilities unique to these devices.
- The pen position of a plotter must be controlled.
- Page printers, notably laser printers, allow information to
be explicitly positioned on the page. Dot matrix and laser
printers also support production of complete pixel-detailed
- Cursor addressable terminals allow text to be explicitly
positioned on the screen and may also support reading back of
data from locations of the screen.
- On bulk storage devices such as discs it is efficient to
provide for indexed access to a file, that is, for input and
output to be specified by position.
The latter device types are currently evolving with the introduction of
multi-media devices such as video, speakers, voice recognizers, etc.
- A locator input device may be a mouse, track-ball or
joystick. These provide positional information as well as the
state of a number of buttons. A touch sensitive screen may also
act as a locator input device.
- Bit-mapped terminals support pixel addressing and raster
- Graphical terminals are vector driven and are typically
used for line drawing.
- Three-dimensional interactive devices include
three-dimensional locator input devices such as flying mice as
well as three-dimensional sound devices.
We should distinguish between input and output device types, then
between alphanumeric and non alphanumeric with the sense they address
(eye, ear, both). A lot of devices can be both positional and
6.1D Communications Device Types. PCIS shall support end-to-end
communications from a PCIS implementation to an external system,
including a connected target machine and another PCIS implementation.
The use of communication devices in this requirement is not concerned
with the support of a distributed PCIS, but provides the underlying
mechanism by which a tool on a PCIS implementation may communicate with
an external system. Communications may be supported by permanent
connections, circuit switched networks or packet switched networks. By
supporting end-to-end communication it is anticipated that
communication standards, such as the Open Systems Interconnection (OSI)
7-layer model, may be supported. In a secure PCIS, Requirements
will need to be satisfied in such communication.
6.2 Operations on Logical Devices
This section describes the general characteristics of the input, output
and control operations which may be used on logical devices.
6.2A General. The PCIS shall provide facilities for input from,
output to and control of logical devices.
6.2B Common Subsets. The PCIS shall provide a subset of the input
and a subset of the output facilities which operate on instances of
several logical device types. These subsets shall provide for at least
serial character input and output.
While a logical device abstracts physical devices with similar
properties, the purpose of subset facilities is that they should apply
to a wider range of physical devices than those encapsulated in a
single logical device type. For instance serial device facilities
should work on positional devices. This requirement calls for similar
functions on different logical device types to use the same facilities.
This is a necessary prerequisite for device independence to have any
real benefit and allows tools to be written without being constrained
to particular physical device types. This should allow for redirection
of input and output and supports the process connector mechanism (see
6.2C Device Status. The PCIS shall support the interrogation of the
status of a logical device including the availability of data on input
devices. The PCIS shall support a mechanism to allow a process to be
notified of a change of status on a set of one or more logical
This requirement embraces such status returns as "printer out of paper"
or "modem hung-up". The ability to check for availability of input data
are frequently useful, especially for interactive tools, where the tool
may be able to proceed with another task in the absence of a new user
The intent of the second sentence is to provide a facility, like
select(2) of BSD4.2 UNIX, which allows a tool to wait for something to
happen to a set of devices without consuming resources (CPU time).
6.2D Timeout. The PCIS shall provide mechanisms to permit timeout on
input and output operations.
This mechanism permits tools to wait for some maximum period for the
availability or operation of a device.
A more elaborate time management scheme may be required for PCIS
implementations executing over a wide area network.
6.2E Buffering. The PCIS shall support the control of buffered and
unbuffered input and output of data items on logical devices. The PCIS
shall support the clearing of input buffers without requiring
processing of their contents. The PCIS shall support the clearing of
output buffers with and without onward transmission of their contents.
The use of unbuffered input and output to a device can have significant
performance consequences. In the absence of a buffer, output must
happen when the command is executed.
The requirements to support buffering and clearing of input buffers
include what is generally implemented as type-ahead and flushing.
Forced output is often essential on device closing, across data links,
when debugging, or in maintaining external data bases. The total
absence of buffering delays is necessary in screen oriented debuggers
In a reset after an exception, pending data often becomes irrelevant. A
user of a tool may request the suppression of the output he is seeing
(for example, with control-O), and it becomes necessary to prevent the
output of what may be an immense buffer. A consumer may refuse to
consume, and the buffer must be eliminated to permit the process to
terminate. The disposition of the data in the buffer is of no
Note the difference between flushing with and without forced
processing. The word flushing can be used in two senses. One sense is
the concept used here: to force the processing of pending data units
gathered in a buffer. The second sense is to discard the contents of
such a buffer.
The data may need to be sent despite the buffer not being full. This
facility is often useful in debugging, when a paused process has
generated output which cannot yet be examined. It can also be used when
it becomes clear that the buffer will not be soon filled. This may also
be used when a datastream is redirected.
Screen oriented editors and debuggers make use of single keystrokes to
govern their interface with the user. This requirement ensures that
tools be able to use such interfaces if they are able to control input
buffering. If this is not provided, it becomes impossible to implement
a large class of tools in a portable manner on a PSE. Screen oriented
editors have shown themselves to be useful. It is unfortunate that
interfaces using this feature tend to overuse system resources. They
should thus be used with restraint in systems where the process using
them shares a processor with other programs. In the future, most
editors will probably run on intelligent remote nodes where the
interface is provided through a single-user processor and no meaningful
penalty is incurred.
6.3 Specific Common Subsets
6.3A Textual Subset. The PCIS shall support at least the following
presentational characteristics of text: margins, page width, page
length, boldness, fonts, slant, justification, underlying, overlying,
subscript, superscript, type size, color, inverse video, blinking and
Color includes intensity, which can be the same as brightness on
monochrome terminals. It is undesirable to try to include everything,
and future interfaces can take up the slack for such things as extra
dimensions, olfactory output, and the still unimagined. Note that color
can be specified in several ways: by wavelength and intensity
(chrominance and luminance), by component strength (amount of each
process color), by intensity/value/hue, or by an enumerated list of
colors. The choice of one or more color representations is left to the
PCIS designer. Not all text characteristics may be supported on all
textual devices, for instance, blinking is difficult on a hard copy
6.3B Graphical Subset. PCIS shall support a bit-map editor. At
least, a process to build icons is expected.
There is no existing standard that has universal acceptance as the
definition of graphic capabilities. Consequently, the requirement for a
specific interface is an issue requiring the sort of investigation and
consideration expected of the PCIS designer. The imminent ISO/ANSI
Graphics Standards for Graphical Kernel System (GKS), Computer Graphics
- Video Display Interface (CG-VDI) and The Programmer's Hierarchical
Interactive Graphics Standard (PHIGS) should be considered as
Facilities to erase geometrical figures are intended for use on
interactive, bit-map and graphic terminals where dynamic updating of
diagrams is necessary for graphical editors.
Graphics in a windowing environment may require a different set of
facilities because of the added functionality of such a system.
However, it is desirable that the facilities called for by this
requirement are supported by a windowing environment in order to
enhance the device independence of tools which only require the lesser
The decision as to whether bit-mapped or line graphics are to be
supported is left to the PCIS designer. Although bit-mapped graphics
are important, efficient use of more limited forms is essential. Some
devices will not support all of this, but such shortcomings are
characteristics of all input/output interfaces. In general, vector and
raster devices will achieve the same effect by different means. The
limitations of the geometric interfaces are to be determined by the
PCIS designer, but at least segments and circles are expected.
6.3C Interactive Subset. PCIS shall:
a) Support facilities for the use and management of windows
b) Support mechanisms for the management of user interfaces
Window managers simply manage the screen real estate, tracking locator
input, and focusing keyboard input. They include the management of
overlapping windows. They may include the notion of rooms. It would
still be possible for the PCIS to map a logical device, that emulated a
single physical device, onto a window so that the use of the window was
transparent to tools. However, if tools can participate in the use of
windows then more supportive user interfaces can be constructed, such
as those found in interactive graphical editors. X-Windows for UNIX and
Microsoft Windows for MSDOS are the two widely accepted standards
today. Top of X-Windows, OSF Motif, Sun OpenLook could be considered as
candidates for a PCIS windowing facility. A PCIS style guide could also
Basic facilities to operate several windows are analogous to primitive
file handling and leave each tool with a lot of additional support to
provide. There is also the danger that these windowing primitives will
constrain a tool to particular physical devices. It is therefore
desirable to support a user interface management system which gives a
higher level abstract interface, relieving each tool of replicating
such functionality. A user interface management system will also ensure
consistency of style and utility of the user interface, thereby
providing for tool integration at the user interface.
Facilities to manage the user's preferences of tailorable aspects under
control of the window manager of the User Interface allow choices such
as found on Windowing control panels, such as color, mouse sensitivity,
locator choices (mouse versus keyboard, left versus right hand
operation), pen, overlapping window focus models, etc.
Some questions that may be asked concerning the User Interface:
In response to these questions, the following three solutions are
- Should the user interface be specific to tools or should it
- What level of user interface should PCIS provide?
The rationale for the first solution is: if PCIS chooses a standard
user interface and if the rest of the world chooses another one, should
the tools suppliers have to support two user interfaces? No.
- PCIS does not provide a user interface.
- PCIS provides a user interface at the level of Motif or higher.
- PCIS chooses an existing standard.
The rationale for a combination of the first and third solutions is:
PCIS should not be involved in user interface standardization, as a lot
of people can do that better than the PCIS definers. In addition, these
solutions enable the tools of the PCIS environment to accept general
cut and paste.
The rationale for a combination of the second and third solutions is:
if there is no user interface provided by PCIS, how can integration of
presentation be done?
The rationale for the second solution by itself is: this solution can
perhaps assure security at the level of the user interface.
c) Provide facilities to control echoing
Passwords should not generally be echoed. Commands should. When
keystrokes have screen-oriented semantics, their echoing is useless and
confusing. If typing C moves the cursor forward one character on the
screen, the echo of C would overwrite the current character. This
control is also essential for windowing, so that the appropriate window
may be addressed before echoing is simulated.
It is normal for an operating system to provide echoing of characters
and locator position (cursor) to an interactive device, since this is a
general requirement and can be achieved much more efficiently than by
requiring each tool to perform its own.
Note that any echoing is output and thus subject to the requirement
about sequencing. Echo suppression is essential in screen-oriented
programs and for passwords.
d) Provide facilities to control proper sequencing of input from
and output to interactive logical devices
This is a necessary condition for a usable interactive device.
It seems apparent to a programmer that if he calls two subroutines and
the first outputs an A, the second a B, the A should come out first.
There is debate over the level at which such sequencing should be
required. Within a single datapath, it is most likely to be compromised
when separate tasks use that datapath. Sequencing could also be
required between datapaths accessing the same device or different
devices or between datapaths used by different processes, even
different processors. The appropriate level of control is left to the
PCIS designers should consider the relationship between sequencing of
input from these devices and transactions as provided for by the OMS.
The interaction between these devices and transactions should be
compatible and consistent between different PCIS implementations.
PCIS designers should consider the effects on window manager actions
related to inter-window (and inter-process) focus so that these effects
are well specified and consistent between PCIS implementations.
6.4 Physical Devices
Process Connectors. The PCIS shall support process connectors.
A logical device may be mapped to a process connector so that output by
one process may be received as input by another process and similarly
A process connector is equivalent to a physical device and provides a
mechanism whereby the output of one process to a logical device may be
consumed as input from a logical device by another process. This
mechanism is similar to pipes in UNIX. Tools which use this mechanism
only need to cooperate to the extent that they both use complementary
subsets of input and output facilities. This encourages the reuse of
tools and tool fragments.
Unsupported Features. The PCIS shall define the consequences
when the physical device does not have all of the features required by
the logical device.
If, for example, a device does not support cursor control, it may be
desirable to let the cursor control sequences echo on the screen (in
some readable form) for debugging purposes (that is, to treat the
device as another device), to do nothing, or to raise an exception. The
control over this behavior is not required in all interfaces, but an
explanation should be offered as to why the selections were made. The
exceptions response is technically general in that the calling program
can handle the exception with whatever action is desired, but this may
raise high costs in complexity and run-time efficiency.
Not all missing features present reasonable alternatives. An attempt to
plot on a line-printer should raise an exception and be done with it.
PCIS may be implemented on top of an underlying operating system that
does not provide full support. For example, when the underlying
operating system does not support some control of buffering, which is
needed, the tools should have a choice between ignoring the request and
raising an exception. The underlying device may be another device
driver, such as a specific physical driver or the window manager.
Device Mapping. The PCIS shall provide mechanisms that permit
both static and dynamic mapping between a logical device and a physical
device or a process connector.
This requirement should not be confused with the so-called device
redirection, which is a Command Language Interpreter function to direct
input to, or output from, a tool to a particular device or file. This
may be supported by the device mapping facilities described here, but,
since the Command Language Interpreter is typically a tool, device
redirection is typically implemented within a tool.
In typical situations logical device mapping may be specified:
In conjunction with the requirements for resource administration, this
requirement allows selection of a particular physical device.
- At compilation or build time, for example in some
Fortran systems output to device 6 may be predefined to go to a
- At run-time, by the tool making a PCIS call to open a
channel to a particular device or file. The device or file
identification may have been passed as a parameter to the tool
so that, for example, the Command Language Interpreter can
control the device which is used.
A logical device allows the specification of some form of generic
device, without directly specifying a particular instance of that
device. For example, a program may transfer output to "lp:" or "mt:" or
"line-printer (with lowercase)", and the system may choose, in some
way, which particular device to use from among the group of similar
devices. In these situations there may be only a single device having
the appropriate characteristics, or the system manager may have
determined which devices particular users should use, or the system may
make a random choice among available devices.
The requirement suggests such a generic facility but does not require
If a generic facility is provided, the usual situation is that the
binding to a particular physical device is determined before the tool
is executed and cannot be changed during the tool execution. However, a
more powerful facility, for example, to allow output to be switched
between the user's terminal and a file, during tool execution, can be
very useful. The requirement allows for such a dynamic binding.
6.4D Exclusive Access. The PCIS shall provide facilities to obtain
and relinquish exclusive access to a logical device and hence to the
physical device to which it is mapped.
A process must be able to obtain total control of a logical device, to
prevent data corruption caused by interleaving by other processes. For
example a screen editor would normally be designed to utilize the whole
screen and to prevent intrusion. Similarly a print spooler would obtain
exclusive access to the printer.
A more extensive requirement referring to resources instead of devices
was considered but rejected since it was felt undesirable to provide
PCIS facilities to obtain or relinquish exclusive access to resources
such as a processor. The normal process exclusion necessary to the
operation of any multi-tasking system is expected to be implicit in the
implementation and does not appear at the PCIS.
PCIS designers should consider the interaction between exclusive access
procedures and trees of (nested) transactions. The transaction
interaction should be consistent between PCIS implementations.
PCIS designers should specify the interaction between window manager
focus models, exclusivity visualization, and modality of dialogue box
windows. The model should be consistent between PCIS implementations.
Go forward to
Section 7, Protection and Security.