ISO/IEC 10026-2:1992

Information technology - Open Systems Interconnection - Distributed Transaction Processing - Part 2: OSI TP Service

Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — Traitement transactionnel réparti — Partie 2: Service OSI TP

General Information

• Status: Withdrawn
• Publication Date: 09-Dec-1992
• Withdrawal Date: 09-Dec-1992
• ICS: 35.100.70 - Application layer
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 16-May-1996
• Completion Date: 30-Oct-2025

Relations

• Consolidated By: ISO 3098-2:2000 - Technical product documentation - Lettering - Part 2: Latin alphabet, numerals and marks
• Effective Date: 06-Jun-2022
• Revised: ISO/IEC 10026-2:1996 - Information technology - Open Systems Interconnection - Distributed Transaction Processing - Part 2: OSI TP Service
• Effective Date: 15-Apr-2008

Standards Content (Sample)

I NTERNAT I O NAL
ISOIIEC
STANDARD
10026-2
First edition
1992-1 2-01
Information technology - Open Systems
Interconnection - Distributed Transaction
Processing -
Part 2:
OS1 TP Service
Technologies de l'information - Interconnexion de systèmes ouverts -
Traitement Transactionnel Réparti -
Partie 2: Service OS1 TP
Reference number
ISO/IEC 10026-2 : 1992 (E)
Page
Con tents
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Definitions . 1
4 Abbreviations . 3
............................................................................................................................
5 Conventions 3 *
5.1 Service conventions . 3
5.2 Usage of the term transaction . 3
5.3 Usage of italics for notations . 3
6 Overview of the OS1 TP Service . 3
..
7 Service facilities . 4
7.1 Functional unit descriptions . 4
7.2 Services contained in functional units . 5
7.3 Service for modelling data transfer . 5
7.4 Structure of service descriptions . 5
7.5 Effects of dialogue termination . 6
8 Service primitives and their parameters . 7
9 Data transfer . 8
9.1 Overview of data transfer . . 8
9.2 Data transfer service. TP-DATA . 8
10 The Dialogue functional unit . . : . 9
e
10.1 Overview of the Dialogue functional unit . . 9
10.2 Dialogue Establishment service. TP-BEGIN-DIALOGUE . 9
10.3 Dialogue Termination service. TP-END-DIALOGUE . 13
10.4 User Error Reporting service. TP-U-ERROR . 14
10.5 User Abort service. TP-U-ABORT . 16
10.6 Provider Abort service. TP-P-ABORT . . 17
11 The Shared Control functional unit . . 18
11.1 Overview of the Shared . 18
12 The Polarized Control functional unit . 19
12.1 Overview of the Polarized Control functional unit . 19
12.2 Grant Control service. TP-GRANT-CONTROL . . 19
12.3 Request Control service. TP-REQUEST-CONTROL . : . 20
8 ISO/IEC 1992
All rights reserved . 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 per-
mission in writing from the publisher .
ISO/IEC Copyright Office Case Postale 56 CH-I211 Genève 20 Switzerland
Printed in Switzerland
ii
ISO/IEC 10026-2 : 1992 (E)
13 The Handshake functional unit . 21
13.1 Overview of the Handshake functional unit . 21
13.2 Handshake service, TP-HANDSHAKE . 21
13.3 Handshake and Grant Control service, TP-HANDSHAKE-AND-
GRANT-CONTROL . 22
The commitment-related functional units . . 24
14.1 Introduction . . .24
14.2 Overview of the Commit functional unit . . 24
14.3 Overview of the Chained Transactions functional unit . 25
14.4 Overview of the Unchained Transactions functional unit . 25
14.5 Begin Transaction service, TP-BEGIN-TRANSACTION . 26
14.6 Deferred End Dialogue service, TP-DEFERRED-END-DIALOGUE .
..................... 29
14.10 TP-READY indication .
4.11 TP-COMMIT request
4.13 TP-DONE request
4.14 TP-COMMIT-COM .
4.15 TP-ROLLBACK reques . .33
14.18 Heuristic Reporting service, TP-HEURISTIC-REPORT indication . 35
Annexes
A Service State Table . 36
A.l Overview .
A.2 Dialogue States
A.3 Variables .
A.4 Actions .
..................... 41
....................................... .42
............................... 42
iii
ISO/IEC 10026-2 : 1992 (E)
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 com-
mittees collaborate in fields of mutual interest. Other international organ-
izations, 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 vot-
ing. Publication as an International Standard requires approval by at least
75 % of the national bodies casting a vote.
International Standard ISO/IEC 10026-2 was prepared by Joint Technical
Committee ISO/IEC JTC 1, Information technology.
ISO/IEC 10026 consists of the following parts, under the general title In-
formation technology - Open Systems Interconnection - Distributed
Transaction Processing:
- Part 1: OS1 TP Model
- Part 2: OS1 TP Service
- Part 3: Protocol specification
- Part 4: Protocol implementation conformance statement fPICSj
proforma
I
- Part 5: Application context proforma
- fart 6: Unstructured data transfer
Annex A forms an integral part of this part of ISO/IEC 10026.

ISO/IEC 10026-2 : 1992 (E)
INTRODUCTION
ISO/IEC 10026 is one of a set of standards produced to facilitate the
It is related to other International
interconnection of computer systems.
Standards in the set as defined by the Reference Model for Open Systems
Interconnection (IS0 7498). The Reference Model subdivides the area of
standardization for interconnection into a series of layers of specification, each
of manageable size.
The aim of Open Systems Interconnection is to allow, with a minimum of
technical agreement outside the interconnection standards, the interconnection
of computer systems
a) from different manufacture rs ;
b)under different management;
c) of different levels of complexity; and,
d)of different technologies.
ISO/IEC 10026 defines an OS1 TP Model, an OS1 TP Service and specifies an
OS1 TP Protocol available within the Application Layer of the OS1 Reference
Model.
The OS1 TP Service is an Application Layer service. It is concerned with
information which can be related as transactions, which may involve two or
more open systems.
This part of ISO/IEC 10026 defines a basic OS1 TP Service. It provides
sufficient facilities to support transaction processing, and establishes a
framework for coordination across multiple TP resources in separate open
systems.
ISO/IEC 10026 does not specify the interface to local resources or access
facilities that are provided within the local system. However, future
enhancement of the standard may deal with these issues.
V
ISO/IEC 10026-2 : 1992 (E)
INTERNATIONAL STANDARD
ISO/IEC 10026-2 : 1992 (E)
Information technology - Open Systems
I ntercon nection - Distributed Tra nsaction
Processing -
Part 2:
OS1 TP Service
lSO/TR 8509:1987, Information processing systems -
1 Scope
Open Systems Interconnection - Service conventions.
This part of ISOAEC 10026 defines in an abstract way the
ISOAEC 10026-1 3992, Information technology - Open
Distributed Transaction Processing Service within the
Systems Interconnection - Distributed Transaction
Application Layer in terms of
Processing - Part 1: OS1 TP Model.
a) the actions and events of the service primitives;
ISOAEC 10026-3:1992, Information technology - Open
Systems Interconnection - Distributed Transaction
b) the parameter data associated with each service
Processing - Part 3: Protocol specification.
primitive's action and event; and,
c) the relationship between, and the valid sequences
3 Definitions
of these actions and events.
It does not specify individual implementations or products, For the purpose of this pari of ISOAEC 10026, the
nor does it constrain the implementation of entities or definitions of ISOAEC 10026-1 and the following
interfaces within a computer system. definitions apply.
3.1 dialogue establishment indication outstanding: A
2 Normative references
dialogue state in which a TP-BEGIN-DIALOGUE indication
with the Confirmation parameter set to "always" has been
The following standards contain provisions which, through
issued but has not yet been responded to by a TP-
reference in this text, constitute provisions of this part of
BEGIN-DIALOGUE response.
ISO/IEC 10026. At the time of publication, the editions
indicated were valid. All standards are subject to revision,
and the parties to agreements based on this part of
3.2 dialogue establishment request outstanding: A
ISO/IEC 10026 are encouraged to investigate the
dialogue state in which a TP-BEGIN-DIALOGUE request
possibility of applying the most recent editions of the
with the Confirmation parameter set to "always" has been
standards indicated below. Members of IS0 and IEC
issued but has not yet been responded to by a TP-
maintain registers of currently valid International
BEGIN-DIALOGUE confirm.
Standards.
IS0 86493 988, Information processing systems - Open
3.3 dialogue termination indication outstanding: A
Systems Interconnection - Service definition for the
dialogue state in which a TP-END-DIALOGUE indication
Association Control Service Element.
ISO/IEC 10026-2 : 1992 (E)
with the Confirmation parameter set to "true" has been 3.8 rollback-initiating request: A request that triggers a
issued while there is no user error request outstanding, rollback; it is one of the following service primitives:
but has not yet been responded to by a TP-END-
DIALOGUE response, or by a TP-U-ERROR request. - TP-ROLLBACK request;
- TP-U-ABORT request for a dialogue with a
coordination level of "cornmitment" not issued during
3.4 dialogue termination request outstanding: A the termination phase of a transaction.
diaiogue state in which a TP-END-DIALOGUE request
with the Confirmation parameter set to "true" has been
issued, but has not yet been responded to by a TP-END- 3.9 rollback-initiating service primitive: A service
DIALOGUE confirm, or by a TP-U-ERROR indication. primitive that triggers a rollback; it may be either a
rollback-initiating request or a rollback-ir?itiating indication.
3.5 handshake indication outstanding: A dialogue
state in which one of the following service primitives: 3.10 subordinate dialogue: A dialogue with a
subordinate.
- TP-HANDSHAKE indication;
- TP-HANDSHAKE-AND-GRANT-CONTROL
3.1 1 subordinate subtree: A subtree of a subordinate.
indication:
user error request
has been issued while there is no
outstanding, but has not yet been responded to by one of 3.12 superior dialogue: The dialogue with the superior.
the following service primitives (respectively):
- TP-HANDSHAKE response; 3.13 termination phase of a transaction: The phase of
- TP-HANDSHAKE-AND-GRANT-CONTROL response; a transaction between initiation of commitment or rollback
and the end of the transaction.
or by a TP-U-ERROR request, or, if the coordination
level of the dialogue is "commitment", by any rollback- This phase is entered, for a given TPSUI, upon issuance
initiating service primitive. of a TP-COMMIT request or any rollback-initiating service
primitive.
For a TPSUI which does not have a dialogue
3.6 handshake request outstanding: A dialogue state
establishment indication outstanding, this phase is exited
in which one of the following service primitives:
upon issuance of a TP-COMMIT-COMPLETE indication or
a TP-ROLLBACK-COMPLETE indication.
- TP-HANDSHAKE request;
- TP-HANDSHAKE-AND-GRANT-CONTROL request;
For a TPSUI which does have a dialogue establishment
indication outstanding when the termination phase is
has been issued, but has not yet been responded to by
one of the following service primitives (respectively): entered (this can only happen when a TP-ROLLBACK
indication is issued), this phase is exited by a TP-BEGIN-
- TP-HANDSHAKE confirm; DMLOGUE response with the Result parameter set to
"rejected(user)" or by a TP-P-ABORT indication for the
- TP-HANDSHAKE-AND-GRANT-CONTROL confirm:
dialogue; if the dialogue is accepted during the
or by a TP-U-ERROR indication, or, if the coordination termination phase, the termination phase is exited by the
subsequent TP-ROLLBACK-COMPLETE indication.
level of the dialogue is "commitment", by any rollback-
initiating service primitive.
3.1 4 transaction tree constraint: A constraint that
cannot be checked at a single node.
3.7 rollback-initiating indication: An indication or
confirm that triggers a rollback; it is one of the following
service primitives:
3.15 user error indication outstanding:
A state of a
- TP-ROLLBACK indication; dialogue with the Polarized Control functional unit
- TP-U-ABORT indication with the Rollback parameter selected. In this state, a TP-U-ERROR indication, issued
set to "true"; while the recipient had control of the dialogue and has
neither a handshake request oufstanding nor a dialogue
- TP-P-ABORT indication with the Rollback parameter
termination request Outstanding, has not yet been
set to "true";
- TP-BEGIN-DIALOGUE confirm with the Rollback responded Po by a TP-GRANT-CONTROL request, or, il
parameter set to "true".
ISO/IEC 10026-2 1992 (E)
whereas indications and confirms are described as being
the coordination level of the dialogue is "commitment", by
issued by the TPSP.
an y rollback-initiating service primitive.
For a given primitive, the presence of each parameter is
described by one of the following values:
3.16 user error request outstanding: A state of a
dialogue with the Polarized Control functional unit
blank: not applicable;
selected. In this state, a TP-U-ERROR request, issued
M: presence is mandatory;
without having control of the dialogue and without having
U: presence is a user option;
either a handshake indication outstanding or a dialogue
O: presence is a provider option; and,
termination indication outstanding, has not yet been
C: presence is conditional.
responded to by a TP-GRANT-CONTROL indication, a
TP-HANDSHAKE indication, a TP-HANDSHAKE-AND-
In addition the notation (=) indicates that a parameter
GRANT-CONTROL indication, a TP-END-DIALOGUE
value is semantically equal to the value of the parameter
indication with the Confirmation parameter set to "true",
of the preceding primitive in the table.
or, if the coordination level of the dialogue is
"Co mm it m e nt " , by an y rollback-initiating service primitive.
5.2 Usage of the term transaction
4 Abbreviations
In this part of ISO/IEC 10026-2, the term "transaction" is
used to denote a distributed provider-supported
Abbreviations used in this part of ISO/IEC 10026 are
transaction.
defined in ISO/IEC 10026-1 (OS1 TP Model), except for
the following which are used in some tables:
5.3 Usage of italics for notations
cnf confirm service primitive;
ind indication service primitive;
In this part of ISO/IEC 10026-2, the following notations,
req request service primitive;
defined in clause 3, appear in italics:
rsP response service primitive.
- dialogue establishment indication outstanding;
- dialogue establishment request outstanding;
5 Conventions
- dialogue termination indication outstanding;
- dialogue termination request outstanding;
5.1 Service conventions
- handshake indication outstanding;
- handshake request outstanding;
This part of ISO/IEC 10026 defines services for
- rollback-initiating indication;
Distributed Transaction Processing guided by the
- rollback-initiating request;
descriptive conventions defined in ISO/TR 8509.
- rollback-initiating service primitive;
- subordinate dialogue;
However, the terms "request" and "indication" are
- subordinate subtree;
sometimes used in the following ways:
- superior dialogue;
- termination phase of a transaction;
a) a single request may result in multiple indications
- user error indication outstanding;
(an example is that a single TP-COMMIT request
- user error request outstanding.
may result in TP-PREPARE indications to each
direct subordinate TPSUI);
6 Overview of the OS1 TP Service
b) several requests may result in a single indication (an
example is that a single TP-COMMIT-COMPLETE
The Distributed Transaction Processing Service and its
indication may be issued to a superior TPSUI only
supporting protocol are concerned with creating an
after TP-DONE requests have been issued by this
environment in which two or more users may interact to
TPSUI and by all subordinate TPSUIs in the
transaction tree);
a) establish dialogues;
c) the convention that a request primitive results in an
b) invoke services of specific user application service
indication primitive of the same name, is not always
elements, subject to the constraints of the TPSP;
followed (for example, the issuance of a TP-
COMMIT request will cause a TP-PREPARE
6) delimit provider-supported transactions;
indication to be issued).
d) coordinate work for application-supported Irans-
NOTE - In this part of ISO/IEC 10026-2, requests and
actions or provider-supported transactions;
responses are described as being issued by the TPSUI
ISWIEC 10026-2 : 1992 (E)
e) prepare for commitment, and commit or rollback a c) Polarized Control: the Polarized Control functional
provider-supported transaction; unit allows only one TPSUl to have control of the
dialogue at any point in time. Many request
primitives may be issued only by the TPSUl which
f) heuristically place bound data either in the final or
initial state; has control of the dialogue. This restriction is in
addition to the normal sequencing constraints for
8) report errors; the primitives. For example, a handshake may only
be requested by the TPSUl which has control of the
h) terminate dialogues allowing all resources allocated dialogue;
to these dialogues to be freed;
d) Handshake: the Handshake functional unit allows
i) terminate dialogues abnormally; the TPSUls to synchronize their processing with one
another:
j) synchronize processing by handshaking;
e) Commit: the Commit functional unit allows reliable
k) support chained or unchained sequences of
commitment and rollback of transactions;
provider-supported transaction branches for a
dialogue.
f) Chained Transactions: the Chained Transactions
functional unit supports coordination of both TPSUIs
A node crash may result in the TPSP issuing certain TP with a chained sequence of transaction branches.
service primitives more than once (i.e., TP-COMMIT The coordination level of the dialogue will always be
indication, TP-ROLLBACK indication, and TP-
"commitment". The subordinate TPSUl will always
HEURISTIC-REPORT indication). The TPSP and the
be a participant in the same transaction as the
TPSUl are both aware of the node crash through local superior TPSUI;
means.
g) Unchained Transactions: the Unchained Transac-
tions functional unit supports coordination of both
TPSUIs with an unchained sequence of transaction
7 Service facilities
branches. The superior determines when the
coordination level of the dialogue is "commitment".
7.1 Functional unit descriptions
At a given point in time, the two TPSUls may be
participants in the same transaction, in different
The following functional units are defined:
transactions, or one or both TPSUls may not be
involved in a transaction.
a) Dialogue: the Dialogue functional unit supports the
basic services required to establish a dialogue
The Dialogue functional unit shall always be selected.
between two TPSUls within which U-ASE primitives
may be invoked, signal user-initiated errors and
For a given dialogue, the Shared Control and Polarized
terminate the dialogue. The user or the provider
Control functional units are mutually exclusive. One and
may signal abnormal termination;
only one of these two functional units shall be selected.
b) Shared Control: the Shared Control functional unit
For a given dialogue, the Chained Transactions and
supports both TPSUls having control of the dialogue
Unchained Transactions functional units are mutually
at the same time and allows them to issue request
exclusive. If the Commit functional unit is selected, one
primitives subject only to the normal sequencing
and only one of them shall be selected. If the Commit
constraints of the primitives. For example, data
functional unit is not selected, neither one shall be
may be transferred by both TPSUIs at the same
selected.
time;
ISO/IEC 10026-2 : 1992 (E)
7.2 Services contained in functional units
Table 1 lists the functional units and the associated services.
Table 1 - Functional units and their services
Functional Unit Services
Dialogue TP-BEGIN-DIALOGUE
TP-END-DIALOGUE *
TP-U-ERROR
TP- U-ABORT
TP-P-ABORT
~~ ~
Shared Control (no associated services)
Polarized Control TP-GRANT-CONTROL
TP-REQUEST-CONTROL
Handshake TP-HANDSHAKE
TP-HANDSHAKE-AND-GRANT-CONTROL **
Commit TP-DEFERRED-END-DIALOGUE
TP-DEFERRED-GRANT-CONTROL **
TP-PREPARE
TP-READY
TP-COMM IT
TP-DONE
TP-COMMIT-COMPLETE
TP-ROLLBACK
TP-ROLLBACK-COM PLETE
TP-HEURISTIC-REPORT
Chained Transactions (no associated services)
Unchained Transactions TP-BEGIN-TRANSACTION
* This service shall not be used if the Chained Transactions functional unit is
selected.
** This service may be used only if the Polarized Control functional unit is also
selected.
7.3 Service for modelling data transfer
Table 2 shows the service for modelling data transfer.
Table 2 - Service for modelling data transfer
I Data Transfer 1 TP-DATA
TP-DATA is not a service in the normal sense. It represents the capability of a TPSUl to invoke specific U-ASE services on
a dialogue, constrained by the TPSP.
7.4 Structure of service descriptions 7.4.2 "Service and parameters" subclause
7.4.1 "Purpose" subclause The "Service and parameters" subclause describes the
service primitives and their parameters.
The "Purpose" subclause describes, in a few words, the
The constraints or conditions on the presence or values of
purpose of the service.
these parameters are described in this subclause.

ISWIEC 10026-2 : 1992 (E)
7.4.3 "Sequences of primitives" subclause
transaction resulting from the issuance of a service
primitive.
The "Sequence of primitives" subclause is included for
certain services; it shows the relationship in time between Effects include
the service request and the resulting indication, and, if
applicable, the subsequent response and the resulting - initiating or terminating the dialogue or the
confirm.
transaction;
- control of the dialogue;
- superior or subordinate status;
7.4.4 "TPSUI conditions" subclause - change of the coordination level;
- issuance of resulting service primitives.
The "TPSUI conditions" subclause applies to certain
NOTE - Effects of a service primitive on certain lower layers
requests and responses only; it specifies prerequisites for
facilities (e.g. Session tokens) are described in ISOAEC 10026-3.
the respective request or response to be issued by the
TPSUI. TPSUl conditions cannot be monitored by the
TPSP, nevertheless it is vital for orderly cooperation of the
7.4.7 "Collisions" subclause
TPSUl and for atomicity that they are obeyed.
There is a collision of two requests if the requests have
TPSUl conditions include
been issued:
- the state of bound data;
- on opposite sides of the same dialogue; and
- the success of synchronization.
- before the indication resulting from the request issued
on the other side is either issued or suppressed.
7.4.5 "TPSP constraints" subclause
The "Collisions" subclause describes any effects on a
service request or response caused by collision with a
The "TPSP constraints" subclause applies to all service
service primitive issued by the partner TPSUI.
primitives. For request and response service primitives, it
specifies prerequisites for issuance by the TPSUl that are
In general, the effects of a collision involving a particular
enforced by the TPSP. For indication and confirm service
service are described in the "Collisions" subclause for that
primitives, it specifies constraints on the issuance of the
service.
service primitives by the TPSP. Constraints on the values
of parameters for service primitives are described
These effects include
separately in the "Service and parameters" subclause for
each service.
- suppression of an indication;
- generation of a different indication.
In general, the constraints are based on information
associated with the state of the TPSUI at the time the
service primitive is issued. Constraints for service
7.5 Effects of dialogue termination
primitives that are associated with a particular dialogue
relate only to that dialogue unless the constraints explicitly
Whenever a dialogue is terminated for a particular TPSUI,
reference other dialogues or attributes that are not related
no further service primitives are issued to the TPSUl for
to a particular dialogue.
the dialogue, except TP-HEURISTIC-REPORT indication,
which may be issued during the termination phase of the
Information on which constraints are based includes
transaction.
- functional units selected for a dialogue;
For a particular TPSUI, a dialogue is terminated by one of
- superior or subordinate status;
the following service primitives:
- control of the dialogue;
- coordination level;
- TP-END-DIALOGUE request with the Confirmation
- state of bound data;
parameter set to "false";
- transaction state;
- TP-END-DIALOGUE indication with the Confirmation
- sequence of service primitives and associated
parameter set to "false";
parameter values.
- TP-END-DIALOGUE response;
- TP-END-DIALOGUE confirm;
- TP-BEGIN-DIALOGUE response with the Result
7.4.6 "Effects of a service primitive" subclause
parameter set to "rejected(user)";
- TP-BEGIN-DIALOGUE confirm with the Result
The "Effects of a service primitive" subclause describes
parameter set to "rejected(provider)" or
any effects on the characteristics of the dialogue or the
"rejected( user)";
ISO/IEC 10026-2 : 1992 (E)
- TP-U-ABORT request;
- TP-U-ABORT indication; Suppression of subsequent service primitives is not
- TP-P-ABORT indication; described in the collisions subclauses.
- TP-COMMIT-COMPLETE indication when a TP-
DEFERRED-END-DIALOGUE request or indication
has been issued.
8 Service primitives and their parameters
The OS1 TP Service is invoked using a sequence of OS1 TP service primitives.
Table 3 lists
a) the service primitives of the OS1 TP Service;
b) for each service primitive, whether the service primitive is associated with a particular dialogue or with the TPSUI as a
whole;
c) the subclause in which the service primitive is described; and,
d) the parameters associated with each service.
Blanks in the parameters column indicates that the service primitive has no parameters.
Table 3 - OS1 TP service primitives
Primitives Scope Subclause I Parameters
Services
TP-BEGIN-DIALOGUE reqlindirspicnf Dialogue 10.2 I Initiating-AP-Title
Initiating-API-Identifier
Initiating-AE-Qualif ier
Initiating-AEl-Identifier
Initiating-TPSU-Title
Recipient-AP-Title
Recipient-API-Identifier
Recipient-AE-Qualif ier
Recipient-AEl-Identifier
Recipient-TPSU-Title
Functional-Units
Quality-of-Service
Application-Context-Name
Begin-Transaction
Confirmation
Result
Diagnostic
R o I I back
User-Data
TP-END-DIALOGUE
TP-U-ERROR
TP-U-ABORT
TP-P-ABORT
TP-GRANT-CONTROL
TP-REQUEST-CONTROL
TP-HANDSHAKE
TP-HANDSHAKE-AND-
GRANT-CONTROL
TP-BEGIN-TRANSACTION 14.5
reqlind Dialogue
TP-DEFERRED-END- reqiind Dialogue 14.6
DIALOGUE
TP-DEFERRED-GRANT- reqlind Dialogue 14.7
CONTROL
ISO/IEC 10026-2 1992 (E)
Table 3 - OS1 TP service primitives (concluded)
Table 4 - TP-DATA primitives and parameters
9 Data transfer
T P - DATA
9.1 Overview of data transfer
parameters defined in the U-ASE I req I ind
Data transfer is performed within the framework of OS1 TP
NOTE - TP-DATA is modelled as an unconfirmed service. This is
by issuance of the service primitives offered by one or
not meant to exclude the possibility of other types of services (e.g.
more U-ASES. To specify the coordination between these
confirmed services).
service primitives and OS1 TP service primitives, these U-
ASE service primitives are modelled as TP-DATA.
9.2.3 TPSP constraints on TP-DATA request
NOTE - TP-DATA may not only be used to model data transfer but
also to model any other U-ASE services that may be constrained by
The requestor shall not have a dialogue establishment
the TPSP (see ISOiIEC 10026-3 for constraints on such services).
indication outstanding.
The requestor shall have control of the dialogue; or, if the
9.2 Data transfer service, TP-DATA
Polarized Control functional unit is selected, the
coordination level of the dialogue shall be "commitment"
9.2.1 Purpose
and a TP-PREPARE indication with the Data-Permitted
parameter set to "true" shall have been issued during the
This service represents the capability of a TPSUl to
current transaction.
transfer data. From the standpoint of the TPSP, it is used
to specify the coordination between data transfer and
The requestor shall not have a handshake request
other OS1 TP services.
outstanding.
This service is never invoked as such, but is used in the
The requestor shall not have a user error indication
OS1 TP Service Definition to represent any U-ASE service
outstanding.
primitive within the OS1 TP framework.
The requestor shall have neither a dialogue termination
This service is associated with one particular dialogue.
request outstanding nor a dialogue termination indication
outstanding.
9.2.2 Primitives and parameters
If the coordination level is "commitment", a TP-PREPARE
Table 4 lists the TP-DATA primitives.
request shall not have been issued during the current
transaction.
ISOIIEC 10026-2 : 1992 (E)
If the coordination level is "commitment", the current
1 O The Dialogue functional unit
transaction shall not be in the termination phase.
10.1 Overview of the Dialogue functional unit
9.2.4 TPSP constraints on TP-DATA indication
The Dialogue functional unit supports the basic services
required to establish a dialogue within which U-ASE
The recipient shall not have a dialogue establishment
primitives may be invoked, signal user-initiated errors, and
request outstanding.
terminate the dialogue. The user or the provider may
signal abnormal termination.
If the Polarized Control functional unit is selected
The Dialogue functional unit shall always be selected.
- the recipient shall not have control of the dialogue; or
-the coordination level of the dialogue shall be
10.2 Dialogue Establishment service, TP-
"commitment" and a TP-PREPARE request with the
BEGIN-DIALOGUE
Data-Permitted parameter set to "true" shall have
been issued during the current transaction.
10.2.1 Purpose
The recipient shall not have a handshake indication
This optionally confirmed service is used to establish a
outstanding.
dialogue with a new TPSUI.
The recipient shall not have a user error request
This service is associated with one particular dialogue.
outstanding.
The recipient shall not have a dialogue termination
10.2.2 Primitives and parameters
indication outstanding.
Table 5 lists the TP-BEGIN-DIALOGUE primitives and
If the coordination level is "commitment", neither a TP-
their parameters.
PREPARE indication nor a TP-READY indication shall
have been issued during the current transaction.
Table 5 - TP-BEGIN-DIALOGUE primitives and their
parameters
If the coordination level is "commitment", the current
-
transaction shall not be in the termination phase.
TP-BEGIN-Dlr .OGl
- - -
cnf
parameters
req -e -
Initiating-AP-Title
9.2.5 Collisions
Initiating-API-Identifier
Initiating-AE-Qualif ier
A TP-DATA indication is not issued to a TPSUI if there is a
Initiating-AEl-Identifier
collision of the TP-DATA request and a TP-U-ERROR
Initiating-TPSU-Title
U
request.
Recipient-AP-Title M
Recipient-API-ldentif ier U
A TP-DATA indication is not issued for a dialogue with a
Recipient-AE-Qualifier U
coordination level of "commitment" after a rollback-
Recipient-AEl-Identifier U
initiating service primitive.
Recipient-TPSU-Title U
Functional-Units M C
A TP-DATA indication is not issued for a dialogue with a
Quality-of-Service U
coordination level of "commitment" after a TP-COMMIT
Application-Context-Name M
request; instead a TP-ROLLBACK indication is issued
Begin-Transaction C
(unless a rollback-initiating service primitive has already
Confirmation M
been issued for the current transaction).
Result M M
Diagnostic C
If the Polarized Control functional unit is selected, a TP-
Rollback M
DATA indication is not issued for a dialogue with a
User-Data U *
U
- _.
coordination level of "commitment" after a TP-PREPARE
request with the Data-Permitted parameter set to "false";
10.2.2.1 Initiating-AP-Title, initiating-API-Identifier,
instead a TP-ROLLBACK indication is issued (unless a
Initiating-AE-Qualifier, and Initiating-AEl-Identifier are
rollback-initiating service primitive has already been
parameters optionally provided by the TPSP. They give
issued for the current transaction).
information about the application-entity-invocation of the
ISWIEC 10026-2 : 1992 (E)
I
TPSUI that has issued the TP-BEGIN-DIALOGUE 10.2.2.9 Confirmation is used to specify whether
confirmed dialogue establishment is required. It shall take
request.
one of the following values:
These parameters are of type AP-Title, API-Identifier, AE-
a) "always", when confirmed dialogue establishment is
Qualifier, and AEl-Identifier, respectively, as defined in
required;
ISOAEC 7498-3.
b) "negative", when the requestor only requires
10.2.2.2 Initiating-TPSU-Title is an optional parameter
notification of rejection of the dialogue.
which is provided by the TPSUI. It denotes the TPSU and
identifies the type of TPSUI which has issued the TP-
BEG1 N-DI ALOG U E request.
10.2.2.10 Result is used to specify the result of the
dialogue establishment attempt, It shall take one of the
10.2.2.3 Recipient-AP-Title, Recipient-API-Identifier,
following values:
Recipient-AE-Qualifier, and Recipient-AEI-Identifier
are parameters which are provided by the initiating TPSUI
a) "accepted" , when the Confirmation parameter was
in order to give information about the recipient application-
set to "always" and the recipient has accepted the
entity-invocation at which the remote TPSUI will be
dialogue;
located.
b) "rejected(provider)", when the TPSP has rejected
These parameters are of type AP-Title, API-Identifier, AE-
the dialogue.
Qualifier, and AEl-Identifier, respectively, as defined in
ISO/IEC 7498-3.
The value "rejected(provider)" is only valid on the
confirm service primitive;
10.2.2.4 Recipient-TPSU-Title is an optional parameter
provided by the initiating TPSUI in order to identify the
c) "rejected(user)", when the recipient has rejected the
type of TPSUI with which the initiating TPSUI wants to
dialogue.
establish a dialogue.
10.2.2.5 Functional-Units defines, in the
requesVindication, the functional units which may be used 10.2.2.11 Diagnostic is a conditional parameter which is
during the life of the dialogue. The rules according to present in the confirm if the Result parameter is set to
which functional units may be combined are described in "rejected(provider)". It describes the type of error which
7.1. In the confirm, Functional-Units is used, if the Result caused the dialogue to be rejected. It shall take one of
parameter is set to "rejected(provider)" and the Diagnostic the following values:
parameter is set to "functional-unit-not-supported, to
define the functional units that the recipient application- a) "recipient-unknown" when the parameters identifying
entity-invocation may support for a dialogue. the recipient application-entity-invocation do not
identify a known application-entity-invocation;
10.2.2.6 Quality-of-Service: this optional parameter
b) "recipient-tpsu-title-unknown" when the TPSP
specifies the quality of service required for the dialogue. It
is of type Quality of Service as defined in IS0 8649. cannot find the requested TPSU-Title at the
recipient:
NOTE - Quality-of-Service parameters are currently being studied
by ISOAEC.
c) "tpsu-not-available(permanent)" when the dialogue
request is recognized as being valid, but the
10.2.2.7 Application-Context-Name: this parameter
addressed TPSU is not available due to a
specifies the application context to be used for the
permanent failure. It is not worth trying again until
dialogue. It is of type Application Context Name as
the failure has been repaired;
defined in IS0 8649.
d) "tpsu-not-available(transient)" when the dialogue
10.2.2.8 Begin-Transaction is mandatory when the
request is recognized as being valid, but the
Unchained Transactions functional unit is selected and is
addressed TPSU is not available due to a transient
absent otherwise. This parameter is used to specify
condition. It might be worth retrying with a
whether a transaction branch is initiated on the dialogue.
reasonable expectation of success;
It shall take one of the following values:
e) "recipient-tpsu-title-required when the recipient
a) "false", when the subordinate TPSUI will not initially
application-entity-invocation requires the presence
be a participant in a transaction;
of the Recipient-TPSU-Title and this parameter was
not provided in the TP-BEGIN-DIALOGUE request;
b) "true", when the subordinate TPSUI will initially be a
participant in a transaction.
ISO/IEC 10026-2 : 1992 (E)
TPSP
f) "functional-unit-noi-supported" when one or more of
the functional units selected in the TP-BEGIN-
TP-BEGIN-DIALOGUE
DIALOGUE request are not supported by the request
b- -
recipient application-entity-invocation for the
dialogue;
TP-BEGiN-DIALOGUE
indication
.
g) "functional-unit-combination-not-supported" when
the combination of functional units, selected in the
TP-BEGIN-DIALOGUE request is not supported by
the recipient application-entity-invocation for the
dialogue; Figure 1 - Unconfirmed TP-BEGIN-DIALOGUE
sequence of primitives
h) "no-reason-given".
NOTE - It is recognized that, with respect to diagnostic values, work
The time sequence diagram of figure 2 shows the
IS still in progress to provide an integrated treatment across all the
of primitives when the
dialogue establishment sequence
layers of the OS1 Reference Model.
service is confirmed.
TPSP
10.2.2.12 Rollback is a parameter of the confirm
TP-BEGIN-DIALOGUE
primitive. It shall take one of the following values:
request
D
if the transaction in which the recipient is a
a) "true",
TP-BEGIN-DIALOGUE
participant is being rolled back; this value has the
indication
same usage and semantics as the TP-ROLLBACK
indication. This value occurs on a TP-BEGIN-
DIALOGUE confirm if the dialogue has a
TP-BEGIN-D IALOGUE
coordination level of "commitment", the Result
response
d
parameter is set to "rejected(provider)" or
"rejected(user)", and the TP-BEGIN-DIALOGUE
TP-BEGIN-DIALOGU
confirm is issued after a TP-COMMIT request;
confirm
t
b) "false", otherwise.
Figure 2 - Confirmed TP-BEGIN-DIALOGUE sequence
10.2.2.13 User-Data is an optional parameter that may
of primitives
be present in the request/indication and/or in the
response/confirm. This parameter may be present in the
response/confirm only if the Result parameter is set to
10.2.4 TPSP constraints on TP-BEGIN-DIALOGUE
"accepted" or "rejected(user)".
request
In the request and indication, this parameter may identify
The requestor shall not have a dialogue establishment
user-specific semantics associated with the dialogue
indication outstanding with the superior.
establishment attempt, for example, security-related
information for validation, or additional information
This service primitive shall be issued as the first service
regarding the particular activity to be commenced.
primitive for the particular dialogue and shall not be issued
more than once for a particular dialogue.
In the response and confirm, this parameter may identify
user-specific semantics associated with the acceptance or
If the TP-BEGIN-DIALOGUE request is used to establish
rejection of the dialogue by the recipient TPSUI.
a dialogue with a coordination level of "commitment", the
current transaction shall not be in the termination phase.
10.2.3 Sequence of primitives
10.2.5 Effects of a TP-BEGIN-DIALOGUE request
The time sequence diagram of figure 1 shows the
dialogue
...