ISO/IEC 13719-1:1995

Information technology - Portable Common Tool Environment (PCTE) - Part 1: Abstract specification

Technologies de l'information — Environnement d'outil courant portable (PCTE) — Partie 1: Spécifications abstraites

General Information

• Status: Withdrawn
• Publication Date: 31-May-1995
• Withdrawal Date: 31-May-1995
• ICS: 35.060 - Languages used in information technology
• Technical Committee: ISO/IEC JTC 1/SC 22 - Programming languages, their environments and system software interfaces
• Drafting Committee: ISO/IEC JTC 1/SC 22 - Programming languages, their environments and system software interfaces
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 15-Oct-1998
• Completion Date: 30-Oct-2025

Relations

• Consolidated By: ISO/TS 14505-1:2007 - Ergonomics of the thermal environment - Evaluation of thermal environments in vehicles - Part 1: Principles and methods for assessment of thermal stress
• Effective Date: 06-Jun-2022
• Revised: ISO/IEC 13719-1:1998 - Information technology - Portable Common Tool Environment (PCTE) - Part 1: Abstract specification
• Effective Date: 15-Apr-2008

Standards Content (Sample)

I N TE R NAT I O NA L
ISOJIEC
STANDARD
13719-1
First edition
1995-06-01
Information technology - Portable
Common Tool Environment (PCTE) -
Part 1:
Abstract specification
Technologies de l’information - Environnement d’outil courant portable
(PCTE) -
Partie I: Spécification d’abstrait
Reference number
ISO/IEC 13719-1 :1995(E)
Contents
Scope
Conformance
2.1 Conformance of binding
2.2 Conformance of implementation
Normative references
Definitions
4.1 Technical terms
4.2 Other terms
Formal notations
Overview of PCTE
6.1 PCTE structural architecture 5
6.2 Object management system 5
6.3
Object base
6 5~
6.4 Schema management
6.5 Self-representation and predefined SDSs
6.6 Object contents 6
6.7 Process execution 7
6.8 Monitoring 7
6.9 Communication between processes 7
6.10 Notification
6.11 Concurrency and integrity control 7
0 ISO/IEC 1995
All rights reserved. Unless otherwise specified, no part of this publication may be
reproduced or utilized in any form or by any means, electronic or mechanical, including
photocopying and microfilm, without permission in writing from the publisher.
HSO/IEC Copyright Office Case postale 56 CH-121 1 Genève 20 * Switzerland
Printed in Switzerland
0 ISO/IEC
ISOBEC 13'719-f:1995(E)
6.12 Distribution
6.13 Replication
6.14 Security
6.15 Accounting
6.16 Implementation limits
Outline of ISO/IEC 13719
8 Foundation
8.1 The state
8.2 The object base
8.2.1 Objects
8.2.2 Attributes
8.2.3 Links
8.3 Types
8.3.1 Object types
8.3.2 Attribute types
8.3.3 Link types
8.3.4 Enumeral types
8.4 Types in SDS
8.4.1 Object types in SDS
8.4.2 Attribute types in SDS
8.4.3 Link types in SDS
8.4.4 Enumeral types in SDS
8.5 Types in working schema
8.5.1 Object types in working schema
8.5.2 Attribute types in working schema
8.5.3 Link types in working schema
8.5.4 Enumeral types in working schema
8.6 Types in global schema
m
8.7
Operations
8.7.1 Calling process
8.7.2 Direct and indirect effects
8.7.3 Errors
8.7.4 Operation serializability
9 Object management
9.1 Object management concepts
9.1.1 The basic type "object"
9.1.2 The common root
9.1.3 Datatypes for object management
9.2 Link operations
9.3 Object operations
9.4 Version operations
iii
ISO/IEC 13719-1: 1995(E)
0 ISO/IEC
1 O Schema management
10.1 Schema management concepts
10.1.1 Schema definition sets and the SDS directory 59
10.1.2 Types 60
10.1.3 Object types
10.1.4 Attribute types
10.1.5 Link types
10.1.6 Enumeral types 64
10.1.7 Datatypes for schema management 64
10.2 SDS update operations
10.3 SDS usage operations
10.4 Working schema operations 96
11 Volumes, devices, and archives 100
1 1.1 Volume, device, and archiving concepts 100
11.1.1 Volumes 100
1 1.1.2 Administration volumes
1 1.1.3 Devices 102
1 1.1.4 Archives 102
1 1.2 Volume, device, and archive operations 103
12 Files, pipes, and devices 110
12.1 File, pipe, and device concepts 110
12.2 File, pipe, and device operations
13 Process execution 120
13.1 Process execution concepts
13.1.1 Static contexts
13.1.2 Foreign execution images 121
13.1.3 Execution classes 121
13.1.4 Processes
13.1.5 Initial processes
13.1.6 Profiling and monitoring concepts
13.2 Process execution operations
13.3 Security operations
13.4 Profiling operations
13.5 Monitoring operations
14 Message queues
14.1 Message queue concepts
14.2 Message queue operations
iV
O ISO/IEC ISO/IEC 13719-1:1995(E)
15 Notification
15.1 Notification concepts
15.1.1 Access events and notifiers
15.1.2 Notification messages
15.1.3 Time of sending notification messages
15.1.4 Range of concerned message queues
1 5.2 Notification operations
16 Concurrency and integrity control
Concurrency and integrity control concepts
16.1
16.1.1 Activities
16.1.2 Resources and locks
16.1.3 Lack modes
16.1.4 Inheritance of locks
16.1.5 Establishment and promotion of locks
16.1.6 Implied locks
16.1.7 Conditions for establishment or promotion of a lock
16.1.8 Releasing locks
16.1.9 Permanence of updates
16.1.10 Tables for locks
Concurrency and integrity control operations
16.2
17 Replication
17.1 Replication concepts
17.1.1 Replica sets
17.1.2 Replicated objects
of an appropriate replica
17.1.3 Selection
17.1.4 Administration replica set
17.2 Replication operations
18 Network connection
18.1 Network connection concepts
18.1.1 Execution sites
18.1.2 Workstations
18.1.3 Foreign systems
18.1.4 Network partitions
18.1.5 Accessibility
18.1.6 Workstation closedown
18.2 Network connection operations
18.3 Foreign system operations
18.4 Time operations
19 Discretionary security
19.1 Discretionary security concepts
19.1.1 Security groups
19.1.2 Access control lists
v
0 ISO/IEC
19.1.3 Discretionary access modes
19.1.4 Access control lists on object creation
19.2 Operations for discretionary access control operation
19.3 Discretionary security administration operations
2 O Mandatory security
20.1 Mandatory security concepts
20.1.1 Mandatory classes
20.1.2 The mandatory class structure
20.1.3 Labels and the concept of dominance
20.1.4 Mandatory rules for information flow
20.1.5 Multi-level security labels
20.1.6 Floating security levels
20.1.7 Implementation restrictions
20.1.8 Built-in policy aspects
230 a
20.2 Operations for mandatory security operation
20.3 Mandatory security administration operations
20.4 Mandatory security operations for processes
21 Auditing
24 1
2 1.1 Auditing concepts
24 1
2 1.1.1 Audit files
21.1.2 Audit selection criteria
2 1.2 Auditing operations 244
2 2 Accounting 248
22.1 Accounting concepts 248
22.1.1 Consumers and accountable resources
22.1.2 Accounting logs and accounting records 249
22.2 Accounting administration operations 0
22.3 Consumer identity operations 257
23 Common binding features
23.1 Mapping of types
23.1.1 Mapping of predefined PCTE datatypes
23.1.2 Mapping of designators and nominators
23.1.3 Mapping of other values
23.2 Object reference operations
23.3 Link reference operations
23.4 Type reference operations
2 4 Implementation limits
24.1 Bounds on installation-wide limits
vi
0 ISO/IEC ISO/IEC 13719-1: 1995(E)
24.2 Bounds on workstation-dependent limits 275
Annex A (normative) VDM Specification Lnaguage for the abstract specification 278
Annex B (normative) The Data Definition Language (DDL) 283
Annex C (normative) Specification of errors 292
Annex D (normative) Auditable events 311
Annex E (informative) The predefined schema definition sets 318
Index of Error Conditions
Index of Technical Terms 344
vii
ISO/IEC 13719-1: 1995(E) O ISO/IEC
~ Foreword
IS0 (the International Organization for Standardization) and IEC (the Inter-
national Electrotechnical Commission) form the specialized system for worldwide
standardization. National bodies that are members of IS0 or IEC participate in the
development of International Standards through technical committees established
by the respective organization to deal with particular fields of technical activity.
IS0 and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with
IS0 and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a joint
technical committee, ISO/IEC JTC 1. Draft International Standards adopted by the
joint technical committee are circulated to national bodies for voting. Publication
% of the national
as an International Standard requires approval by at least 75
bodies casting a vote.
International Standard ISOAEC 137 19-1 was prepared by the European Computer
Manufacturers Association (ECMA) (as Standard ECMA- 149) and was adopted,
~
under a special “fast-track procedure”, by Joint Technical Committee ISOAEC
‘
STC 1, Information technology, in parallel with its approval by national bodies of
IS0 and IEC.
ISO/IEC 13719 consists of the following parts, under the general title Information
technology - Portable Common Tool Environment (PCTE):
- Part 1: Abstract specification
- Part 2: C programming language binding
- Part 3: Ada programming language binding
Annexes A to D form an integral part of this part of ISOAEC. Annex E is for
information only.
..I
VllP
INTERNATIONAL STANDARD O ISO/IEC ISO/IEC 13719-1 1995(E)
Information technology - Portable Common Tool
Environment (PCTE) -
Part 1:
Abstract specification
1 Scope
This part of ISO/IEC 137 19 specifies PCTE in abstract, programming-language-independent, terms.
It specifies the interface supported by any conforming implementation as a set of abstract operation
specifications, together with the types of their parameters and results. It is supported by a number
of standard bindings, i.e. representations of the interface in standard programming languages.
The scope of this part of ISO/IEC 13719 is restricted to a single PCTE installation. It does not
specify the means of communication between PCTE installations, nor between a PCTE installation
and another system.
A number of features are not completely defined in this part of ISO/IEC 13719, some freedom being
allowed to the implementor. Some of these are implementation limits, for which constraints are
defined (see clause 24). The other implementation-dependent and implementation-defined features
are specified in the appropriate places in this part of ISO/IEC 13719 .
PCTE is an interface to a set of facilities that forms the basis for constructing environments
supporting systems engineering projects. These facilities are designed particularly to provide an
infrastructure for programs which may be part of such environments. Such programs, which are
used as aids to systems development, are often referred to as tools.
2 Conformance
2.1 Conformance of binding
A binding conforms to this part of ISO/IEC 13719 if and only if:
- it consists of a set of operational interfaces and datatypes, with a mapping from the operations
and datatypes of this part of ISODEC 137 19 ;
- each operation of this part of ISODEC 13719 is mapped to one or more sequences of one or
more operations of the binding (distinct operations need not be mapped to distinct sets of
sequences of binding operations);
- each datatype of this part of ISO/IEC 137 19 is mapped to one or more datatypes of the binding;
- each named error of this part of ISODEC 13719 is mapped to one or more error values (status
values, exceptions, or the like) of the binding;
0 ISODEC
ISO/IEC 13719-1 : 1995(E)
- the conditions of clause 23 on common binding features are satisfied;
- the conditions for conformance of an implementation to the binding are defined, are achievable,
and are not in conflict with the conditions in 2.2 below.
2.2 Conformance of implementation
The functionality of PCTE is divided into the following modules:
- The core module consists of the datatypes and operations defined in clauses 8 to 19 (except
13.1.6, 13.4, and 13.5) and 23.
- The mandatory access control module consists of the datatypes and operations defined in clause
20.
- The auditing module consists of the datatypes and operations defined in clause 21.
- The accounting module consists of the datatypes and operations defined in clause 22.
- The profiling module consists of the datatypes defined in 13.1.6 and the operations defined in
13.4.
- The monitoring module consists of the datatype Address defined in 13.1.6 and operations
defined in 13.5.
An implementation of PCTE conforms to this part of ISO/IEC 137 19 if and only if it implements
the core module.
An implementation of PCTE conforms to this part of ISO/IEC 13719 with mandatory access
control level 1 or 2 if it implements the core module and in addition:
- for level 1: the mandatory access control module except the floating security levels features
defined in 20.1.6;
- for level 2: the mandatory access control module.
An implementation of PCTE conforms to this part of ISODEC 13719 with auditing if and only if it
implements the core module and in addition the auditing module.
An implementation of PCTE conforms to this part of ISODEC 13719 with accounting if and only if
it implements the core module and in addition the accounting module.
An implementation of PCTE conforms to this part of ISODEC 137 19 with profiling if and only if it
implements the core module and in addition the profiling module.
An implementation of PCTE conforms to this part of ISODEC 13719 with monitoring if and only if
it implements the core module and in addition the monitoring module.
By 'an implementation implements a module' is meant that, for the clauses of the module:
- the implementation conforms to a binding of this part of ISO/IEC 13719 which itself conforms
to this part of ISODEC 13719 and which is itself an International Standard;
- if an operation of this part of ISO/IEC 13719 is mapped to a set of sequences of operations in
the binding:
. case 1 : operation-A; 0peration-B; . operation-F;
. case 2: operation-G; operation-H; . operation-M;
. etc.
then in each case the sequence of invocations of the operations of the implementation must have
the effect of the original operation of this part of ISODEC 13719;
- the relevant limits on quantities specified in clause 24 are no more restrictive than the values
specified there;
O ISODEC ISO/IEC 13719-1 : 1995(E)
- the implementations of the implementation-defined features in this part of ISODEC 13719 are all
defined.
An implementation of PCTE does not conform to this part of ISODEC 13719 if it implements any
of the following, whether or not the PCTE entity mentioned is in a module which the
implementation implements:
- an operation with same name as a PCTE operation but with different effect;
- an SDS with the same name as a PCTE predefined SDS but with different contents;
- an error condition with the same name as a PCTE error condition but with different meaning.
3 Normative references
The following standards contain provisions which, through reference in this text, constitute
provisions of this part of ISODEC 13719. At the time of publication, the editions indicated were
valid. All standards are subject to revision, and parties to agreements based on this International
Standard are encouraged to investigate the possibility of applying the most recent editions of the
Members of IEC and IS0 maintain registers of currently valid
standards indicated below.
International Standards.
ISODEC 2022 : 1994, Information technology - Character code structure and extension
techniques.
IS0 8601 : 1988, Data elements and interchange formats -Information interchange -
Representation of dates and times.
IS0 885 1 : 1987, Information processing - 8-bit single-byte coded graphic character sets
-Part 1 : Latin alphabet No. 1.
0646- 1 : 1993, Information technology - Universal Multiple-Octet Coded Character Set
ISODEC
(UCS) - Part 1: Architecture and Basic Multilingual Plane.
ISODEC 1404 : ---I), Information technology -Programming languages, their environments
and system software interfaces - Language-independent datatypes.
Information technology -Programming languages, their environments
ISO/IEC 13303- : -I),
and system software interJCaces - Vienna Development
Method/Specification language - Part I : Basic Language.
BS 6145 : 1981 Method of Defining Syntactic Metalanguage.
4 Definitions
4.1 Technical terms
All technical terms used in this part of ISODEC 13719, other than a few in widespread use, are
defined in the text, usually in a formal notation. All identifiers defined in VDM-SL or in DDL (see
5.2) are technical terms; apart from those, a defined technical term is printed in italics at the point of
its definition, and only there. For the use of technical terms defined in VDM-SL and DDL see
clause A.3 and clause B.9 respectively. All defined technical terms are listed in an index, with
references to their definitions.
1) To be published.
O ISO/IEC
, ISO/IEC 13719-1 : 1995(E)
4.2 Other terms
For the purposes of this International Standard, the following definitions apply.
4.2.1 implementation-defined: Possibly differing between PCTE implementations, but
defined for any particular PCTE implementation.
4.2.2 implementation-dependent: Possibly differing between PCTE implementations and
not necessarily defined for any particular PCTE implementation.
4.2.3 binding-defined: Possibly differing between language bindings, but defined for any
particular language binding.
4.2.4 datatype: The type of a parameter or result of an operation defined in this part of ISO/IEC
13719, or used to define such a type. Where, as in clause 23, it is necessary to distinguish these
types from datatypes defined elsewhere, the term PCTE datatype is used.
5 Formal notations
Four formal notations are used in this part of ISO/IEC 13719.
For datatypes and for operation signatures, a small subset of the Vienna Development Method
Specifîcation Language or VDM-SL is used; it is defined in annex A. This subset of VDM-SL is
also used to define some types used for operation parameters and results.
The Data Definition Language or DDL is used to define types; it is defined in annex B. Where a
concept is defined in both VDM-SL and DDL, the same identifier is used.
To define the error conditions detected by operations, a parameterized notation is used; it is defined
in annex C.
The BSI syntactic notation (BS 6154 : 1981) is used to define the syntax of VDM-SL and DDL,
and in a few other places where the syntax of strings is defined.
6 Overview of PCTE
PCTE is designed to support program portability by providing machine-independent access to a set
of facilities. These facilities, which are described in ISO/IEC 13719, are designed particularly to
provide an infrastructure for programs to support systems engineering projects.
The PCTE architecture is described in two dimensions: the structural architecture and thefunctional
architecture. The structural architecture is described in 6.1, and shows how a PCTE installation is
built of a system of communicating workstations and how the software providing the PCTE
interfaces is structured. The functional architecture is described in 6.2 onwards, and gives an
outline of the functional components of PCTE and the facilities they provide.

O 1somc ISO/IEC 13719-1 : 1995(E)
6.1 PCTE structural architecture
The preferred structural architecture for a PCTE installation is a set of workstations and associated
resources communicating over a network, though other architectures are possible. There is no
hierarchy or ordering of workstations within a PCTE installation. If a workstation is part of a
PCTE installation then the PCTE installation appears to the workstation's user as a conceptually
single machine, although each workstation can act as an autonomous unit. Such a user has access
to the total resources of a PCTE installation, subject to the necessary access controls.
The PCTE database (called the object base) is partitioned into volumes. Volumes are dynamically
allocated to (mounted on) particular workstations, and, once mounted, are globally available in that
PCTE installation.
The program writer does not need to be aware of the distribution architecture, but the PCTE
interfaces do provide all the facilities needed to configure a PCTE installation and control its
distribution. The PCTE interfaces appear to the tool writer as available within a PCTE installation
irrespective of the tool's physical location within a PCTE installation and independent of any
particular network topology.
6.2 Object management system
An aspect of PCTE that is of major importance to the process of constructing and integrating
portable tools is the provision of the object base and a set of functions to manipulate the various
objects in the object base. The object base is the repository of the data used by the tools of a PCTE
installation, and the Object Management System or OMS of PCTE provides the functions used to
access the object base.
In a general sense, the users and programs of the PCTE installation have the ability to manage
entities that are known to, and can be designated in, a particular PCTE installation. These may be
files in the traditional sense, or peripherals, interprocess message queues or pipes, or the
description of processes themselves or of the static context of a process. Tools supporting user
applications establish classes of objects defined by the user: these can represent information items
such as project milestones, tasks, and change requests.
6.3 Object base
The basic OMS model is derived from the Entity Relationship data model and defines objects and
links as being the basic items of a PCTE object base,
Objects are entities (in the Entity Relationship sense) which can be designated, and can optionally
have:
- Contents: a storage of data representing the traditional file concept;
- Attributes: primitive values representing specific properties of an object which can be named
individually;
- Links: representations of associations between objects. Links may have attributes, which may
be used to describe properties of the associations or as keys to distinguish between links of the
same type from the same object.
Designation of links is the basis for the designation of objects: the principal means for accessing
objects in most OMS operations is to navigate the object base by traversing a sequence of links.
O ISO/IEC
ISO/IEC 13719-1 : 1995(E)
6.4 Schema management
Entities used by the user and those used by the system that are represe ted by objects in the object
base can be treated in a uniform manner, and facilities to control their structure, to store and to
designate these objects, are provided by PCTE.
The object base of each PCTE installation is governed by a typing mechanism. All entities in the
object base are typed and the data must conform to the corresponding type rules. Type rules are
defined for objects, for links, and for attributes.
PCTE is designed to allow, but not to require, distributed and devolved management of the object
base. To this end the definition of the typing rules which govern an object, a link, or an attribute in
the object base may be split up among a number of schema definition sets (or SDSs). Some
an object, a link, or an attribute must be the same in every SDS which contributes to
properties of
the definition of the typing rules for that object, link, or attribute: these are properties of the type.
Other properties may differ for different SDSs: these are properties of the type in SDS.
Each SDS provides a consistent and self-contained view of the data in the object base. A process,
at any one time, views the data in the object base through a working schema. A working schema is
obtained as a composition of SDSs in an ordered list. The effect of such a composition is to
provide a union of all the types contained in the listed SDSs. A uniform naming algorithm,
dependent on the ordering of the SDSs, is applied to all the contained types.
The object base of a PCTE installation has a notional global schema, composed of all the SDSs.
The global schema is not directly represented in the object base, and the concept is used mainly to
state certain consistency constraints on the object base as a whole.
Child types of object types can be defined with the effect of implicit inheritance of all properties of
their parent types. Additionally, child types can have properties of their own.
6.5 Self-representation and predefined SDSs
Many of the entities in a PCTE installation are represented by objects in the object base. The types
of these objects are defined in predefined SDSs, which are available in any conforming
implementation; for example processes are represented by objects of type "process" which is
defined in the predefined SDS 'system'. This property of PCTE is called self-representation. In
general, in this part of ISO/IEC 137 19, the name of an entity is used also to refer to the object that
represents it.
In some cases an object of a type representing some kind of entity requires initializing, or must be
it can be used in operations to represent an entity of that
created by a particular operation, before
kind. Such an object which has been initialized or correctly created is referred to as a known entity
of that kind (i.e. known to the PCTE installation); any other object of that type is referred to as an
unknown entity. For example an object of type "process" created by PROCESS-CREATE is a
known process, while one created by OBJECTCREATE is an unknown process.
6.6 Object contents
A set of operations is provided to access the contents of some types of objects (files, pipes, and
devices). These operations provide conventional input-output facilities on files and pipes and
control of input and output on devices. These contents are not interpreted by PCTE.
Other types of objects (accounting logs and audit files) have contents with structure that is defined
by PCTE and for access to which special operations are provided.
O ISOrnC ISO/IEC 13719-1 : 1995(E)
6.7 Process execution
PCTE is an interface to support programs. When a program is run, this is either the execution of
the program itself, or the execution of an interpreter which interprets the program. An execution of
a program is aprocess. Processes are represented by objects in the object base, so the hierarchy of
processes, the environment in which a process runs, the parameters it has been passed, and the
various stages of the program execution can be controlled, manipulated and examined.
These facilities can be used also to control processes running on foreign systems. A foreign
system can be a foreign development system, a target system running a real-time operating system,
or even a PCTE workstation in another PCTE installation.
6.8 Monitoring
PCTE provides three sets of features to support debugging and monitoring of processes.
- To measure the amount of time spent in selected parts of the code.
- To observe, and modify, the execution of a child process.
- To measure the processor usage of the calling process.
6.9 Communication between processes
PCTE provides a number of different mechanisms for communicating between processes. The
principal ones supplied are:
- the objects, links and attributes in the database;
- message queues;
- pipes.
Message queues and pipes are essentially special forms of object. Thus both pipes and message
queues are special cases of the general use of the object base for interprocess communication.
Pipes and message queues also provide communication between PCTE processes and foreign
processes running on foreign systems (if the foreign systems allow it).
6.10 Notification
In PCTE there is a mechanism that allows the designation of objects so that certain types of access
in a message queue which can be accessed by the process
result in a message being posted
requesting the notification.
The notification mechanism allows a process to specify events, corresponding to operations on
objects, of which it wants to be notified.
6.11 Concurrency and integrity control
The object base is subject to concurrent access by users, and is liable to underlying system failure.
PCTE provides locking facilities to control the strength of object base concurrency and consistency,
ranging from unprotected behaviour, through protected behaviour, to protected atomic and
serializable transaction activities. PCTE ensures object base consistency and object base integrity
for atomic and serializable transactions.
Each user carrying out a transaction on the object base sees some grouping of operations as an
atomic operation which transforms the object base from one consistent state to another. If
transactions are run one at a time then each transaction sees the consistent state left by its
O ISO/IEC
ISO/IEC 13719-1 : 1995(E)
predecessor. When transactions are run concurrently PCTE ensures that the effect on the object
base is as though they were run serially. With a few exceptions, such as messages sent to or
received from a message queue, the effect of a sequence of operations performed within a
transaction is atomic: either all the operations are performed or none are performed.
Another important aspect of activities arises in composition of programs. A single program
carrying out an atomic transaction on the object base can be regarded as performing a single
function. More powerful functions can be built up by an outer program invoking a set of other,
inner, programs, each of which carries out its own specific function. PCTE provides nested
activities to allow each inner activity to behave in an atomic way, and at the same time to allow the
whole function to be atomic. Thus the outer program can start a transaction, which may be either
committed or aborted, and finally the whole outer transaction is committed or aborted. Each such
inner program could itself invoke further nested programs, and so on.
6.12 Distribution
PCTE is based on a community of workstations of possibly differing types connected together by a
network. The community is normally seen by the user as a single environment, grouping together
the facilities, services and resources of all the different workstations, though in some circumstances
a PCTE installation may be temporarily divided into separated partitions, each of which supports
useful work.
Objects, including processes, are distributed throughout a PCTE installation. A user is able to
disregard both the location of objects on volumes in the network and that of the workstation
concerned in executing processes. Alternatively a user may choose to exercise control over the
location of objects on volumes and the location of processes. On creation of an object a volume can
be specified to indicate its location. Every process executes on a particular workstation and a user
can specify which workstation by either static or dynamic means: the static context of a program
has an execution class identifying the range of workstations upon which the static context may be
executed; the workstation on which a process executes can be specified on invocation.
6.13 Replication
As it is possible that one or more workstations of a PCTE installation become temporarily
unavailable, certain installation-wide objects must still be accessible. Replication facilities are
available whereby a copy of an object's contents, attributes and links are made to each workstation.
Installation-wide objects are predefined as replicated and other objects can be added. This feature is
intended for non-volatile, rarely varying, widely consulted objects.
6.14 Security
A PCTE installation has to support many users and many projects. Different users are expected to
have different roles within projects and to be authorized to access different objects. The user
accesses objects using programs (themselves modelled as static contexts within the object base).
The purpose of security is to prevent the unauthorized disclosure, amendment or deletion of
information. Security facilities are provided to support the definition of the different authorizations
of users and programs.
Security in PCTE is provided by discretionary and mandatory access controls. Access controls as
defined in the security clauses form one aspect of the correct operation of the installation with
regard to the integrity of the information held and the correctness of its use. In this regard, the
facilities described in the security clauses complement the data modelling facilities of the OMS and
schema management, and the transaction and concurrency control facilities.
Each OMS object is associated with access control lists which define which types of access to the
object are permitted for designated users or programs. Access control lists are expressed in terms
ISO/IEC 13719-1 : 1995(E)
O ISO/IEC
of discretionary access rights which are explicitly granted or denied to designated individual users,
user groups or program groups. Access rights on a particular object are combined in order to
determine a process's permission to perform each particular operation on the object.
Mandatory access controls cover both mandatory confidentiality and mandatory integrity, with
distinct controls. Mandatory access controls are additional to discretionary access controls.
Mandatory confidentiality controls prevent the disclosure of infomation to unauthorized users.
They prevent the flow of information to the unauthorized user directly, by controlling read access
(simple confidentiality), and indirectly, by controlling the flow of information between objects
(confidentiality confinement).
Mandatory integrity controls prevent unauthorized sources from contributing to the information in
an object, They prevent the flow of information from the unauthorized user directly, by controlling
write access (simple integrity), and indirectly, by controlling the flow of information between
objects (integrity confinement).
6.15 Accounting
The accounting facilities of PCTE allow the automatic recording of the consumption of selected
installation resources by users, groups of users, or groups of programs.
Authorized users may designate selected objects like programs, files, pipes, message queues,
Access to an accountable
devices, workstations, and SDSs as being accountable resources.
resource by a process implies the automatic logging of usage information into the associated
the operation.
accounting log on completion of
6.16 Implementation limits
PCTE permits the user to examine the implementation-defined limits for the PCTE installation in
which a program executes.
Minimal values are defined for limits, so that a program respecting those values is portable to any
PCTE installation.
7 Outline of ISO/IEC 13719
Clause 6 gives an informal, non-normative explanation of the concepts of PCTE. Clause 7 gives an
overview of the document and of the structure of the definition.
The partly formal, normative definition of PCTE is in clauses 8 to 24 and annexes A to C. It is in
two main parts. The first main part is the foundation (clause 8) which defines the concept Object
and its parts, for example Attribute and Link, and the concepts of the associated typing mechanism,
for example Type and Type in SDS. This uses a subset of VDM-SL; see annex A.
The second main part of the definition is the interface definition (clauses 9-22). This defines the
other concepts of PCTE, for example Process and Workstation, as specializations of the concept
Object (clauses 11-22). This definition is in terms of the typing structure associated with these
specializations, that is in terms of the typing concepts of the foundation. A language for the
definition of types and types in SDS, called Data Definition Language or DDL, is defined in annex
B.
The concept Object is itself further specialized, i.e. details not necessary for the foundation are
added, in clause 9. (The name Object is used in both the foundation and the interface definition
because it is the same concept although only a few of its details are defined in the foundation.)
Thus the foundation is a relatively simple general model that is specialized in later clauses to provide
the PCTE interface definition.
0 ISO/IEC
ISO/IEC 13719-1 : 1995(E)
Instances of the PCTE concepts are called entities and they are referred to by the names of the
underlying concepts, for example instances of Object are called objects. All the entities existing at a
time are called the state of the PCTE installation. PCTE is defined in terms of the permissible values
of the state and the permissible operations on the state. The foundation defines part of the state,
namely that part concerned with entities of the foundation concepts; the interface definition defines
the rest of the state and all the operations.
The concepts of the typing mechanism cannot be treated as specializations of the concept Object
because the definition of PCTE would then be circular. They can however be represented by
specializations of Object so that tools can determine the current state of the typing mechanism using
the operations provided for determining the current state of objects. Operations for manipulating the
state of the typing mechanism also manipulate the representing objects automatically and
equivalently. The representations and operations of the typing mechanism are defined in clause 10.
The interface is defined by operations grouped according to function. For each group some
concepts are defined first in DDL and possibly VDM-SL, as described above. There follow the
operation definitions; a VDM-SL definition of the signature, an informal English description of the
normal action of the operation, and a list of the possible error conditions (using an abbreviated
notation defined in annex C).
Other parts of ISO/IEC 13719 define application programming interfaces to PCTE in terms of
specific programming languages by defining the mapping of datatypes, operations, and error
conditions of the abstract specification to datatypes, operations, and error conditions respectively of
the programming language (see 3.1). Such mapping specifications are called bindings. Clause 23
defines a number of features to which all bindings must conform.
24 defines the limits on the sizes and numbers of various entities which a conforming PCTE
Clause
implementation must respect. These are given as minima which an implementation must meet or
exceed.
Annexes A to C define various notations used in the Abstract Specification. Annex A defines the
subset of VDM-SL used for type definitions and operation signatures; annex B defines DDL; and
annex C defines the notation for operation error conditions.
it collects the DDL definitions of the types in the predefined
Annex D is provided for information;
schema definition sets.
Annex E contains a list of auditable events classified by event type.
Annex F is provided for information; it contains an index of error conditions.
Clauses 8 to 24 contain commentary (headed NOTE or NOTES) which is not normative and is
intended as a help to the reader in understanding the definition.
8 Foundation
8.1 The state
state PCTE-Installation of
SYSTEM-TIME : Time
OBJECT-BASE : map Object-designator to Object
PROCESSES :set of Process
M ESSAGEQU EU ES : set of Message-queue
CONTENTS-HANDLES
: map Contents-handle to Current_position
CURRENT-POSITIONS : map Current_position to Natural
WORKSTATIONS : set of Workstation
end
Name = Text
Name-sequence = seq of Name
O ISOLIEC
ISO/IEC 13719-1 : 1995(E)
Working-schema ::
VISIBLE-TYPES : set of Typejnworking-schema
SDS-NAMES : Name-sequence
Process ::
PROCESS-OBJECT : Object-designator
WORKING-SCHEMA : Working-schema
OPENCONTENTS : set of Open-contents
Message-queue ::
QUEUE-OBJECT : Objectdesignator
M ESSAG ES : seq of Message
Workstation ::
WORKSTATION-OBJECT : Object-designator
AUDIT-CRITERIA : set of Selectioncriterion
The state comprises the entities of a PCTE installation that endure from one operation call to
another. The effect of an operation call is to modify the state, or to return values derived from the
state (and any parameters), or both.
The system time is the date and time of day at any instant, as given by some system clock. For the
format of the time see 23.1.1.5. The current time for an operation is a value of the system time at
some moment between the start and end of the operation.
The object base is a set of objects identified by object designators (see 8.2.1).
A working schema is associated with a process (see clause 13) and consists of a set of types in
working schema, derived from a sequence of SDSs. The types in working schema in the working
schema of the calling process are called visible types. For the creation of a working schema for a
process see 13.2.12.
The initial value of the state consists of the following objects:
- at least one workstation, at least one device managed by that workstation, at least one volume
mounted on that device, and at least one process running on that workstation (see 18.1.2,
11.1.3, 11.1.1, and 13.1.5);
- the administration replica set, the common root, and the administrative objects (see 17.1.4 and
9.1.2);
- at least one user (see 19.1.1);
- at least the schema definition sets system, metasds, discretionary-security, mandatory-security
(if implemented), and accounting (if implemented) (see 10.1);
- the predefined user group ALL-USERS, and the predefined program groups PCTE-AUDIT,
PCTE-REPLICATION, PCTE-EXECUTION, PCTE-SECURITY, PCTE-HISTORY,
PCTE-CONFIGURATION, and PCTE-SCHEMA-UPDATE (see 19.1.1).
NOTE - It is intended that the system time should be as near as possible the same throughout a PCTE installation.
8.2 The object base
8.2.1 Objects
Object ::
OB J ECT-TY P E : Object-type-nominator
ATTRIBUTES : set of Attribute
LINKS : set of Link
DI RECT-COM PONENTS
: set of Object
: [ Link-type-nominator ]
PREFERRED-LINK-TYPE
PREFER RED-LINK-KEY : [ Text ]
CONTENTS : [ Contents ]
O ISO/IEC
ISO/IEC 13719-1 : 1995(E)
Object-designator :: Token
Object-designators = set of Object-designator
Contents = Structuredcontents I Unstructured-contents
Structuredcontents = Accounting-log I Audit-file
Unstructured-contents = File I Pipe I Device
Object-scope = ATOMIC I COMPOSITE
The object type constrains the properties of the object (see 8.3.1).
No two attributes of an object have the same attribute type. There is a basic set of attributes which
all objects have; it is defined in 9.1.1.
The preferred link type and preferred link key, if present, are used as defaults in the identification
of a link of the object (see 8.2.3). The preferred link key has the syntax of a key (see 23.1.2.7).
Every direct component of an object is the destination of a composition link of the object, and vice
versa.
An outer object of an object A is an object of which A is a Component.
The atomic object associated with an object comprises the links, attributes, preferred link type,
preferred link key, and contents of the object. The atoms of an object are the atomic objects
associated with the object and all its components.
A component of an object is a direct component of the object or of a component of the object. An
object which is a component of each of two distinct objects, neither of which is a component of
the other, is called a shared component of those two objects.
An internal link of an object is a link of the object or of one of its components for which the
destination is either a component of the object or the object itself. An external link of an object is a
direct or indirect outgoing link of the object which is not an internal link of the object. An object is
called the origin of each
...