ISO/IEC 8831:1992

ISOIIEC
I NTER NATIONAL
STANDARD
Second edition,
1992-03-01
Information technology - Open Systems
Interconnection - Job transfer and manipulation
concepts and services
Technologies de t'information - Interconnexion de systhmes ouverts -
Concepts et services pour le transfert et manipulation de travaux
Reference number
ISOilEC 8831:1992(E)
ISOIIEC 8831 :1992( E)
Contents
Foreword . vii
...
Introduction . VIII
Section 1 : General
1.1 Scope . 1
1.2 Normative references . 1
1.3 Definitions . 2
1.3.1 CCR service definitions . 2
1.3.2 JTM service definitions . 2
1.4 Abbreviations . 5
1.5 Conventions . 5
Section 2 : Overview
2.1 Overview and general description . 6
2.1.1 Overview . 6
2.1.2 Work specification contents . 6
2.1.3 Proformas and spawning . 7
2.1.4 Source, sink and execution agencies . 7
2.1.5 OS1 jobs . 8
2.1.6 Processing of work specifications . 8
2.1.7 Reporting and the monitor function . 9
2.1.8 Commitment, concurrency and recovery . 11
2.1.9 Transfer control . 14
2.1.1 O Report manipulation . 15
2.1.1 1 Work manipulation . 15
2.1.12 Transfer manipulation . 16
2.1.13 Authorisation and accounting . 17
0 ISO/IEC 1992
All rights reserved . No part of this publication may be reproduced Or utilized in any form or by any
or mechanical. including photocopying and microfilm. without permission in
means. electronic
writing from the publisher .
ISO/IEC Copyright Office 0 Case postale 56 0 CH-1211 Genève 20 0 Switzerland
Printed in Switzerland
ii
ISOIIEC 8831:1992(E)
2.1.14 Work specification identification . 17
2.1.15 Reporting responsibility . 18
2.1.16 Documents . 19
2.1 . 17 JTM relays . 20
2.2 Overview of the service . 20
2.3 Basic and extended implementations .
2.4 Model for the service specification . 22
Section 3 : Definition of primitives
.............................................................. 24
3.1 JTM service primitives .
3.1.1 Service primitive groups . 24
3.1.2 Components of service primitive groups . 25
3.1.3 Parameters of CCR-related primitives . 27
3.1.4 Sequence of service primitive groups .
3.1.5 Sequence of service primitives . 28
3.2 Notation for service primitive and datastructure definition . 29
......................... 29
3.2.1 Basic datatypes .
.................................................... 29
3.2.2 Structuring mechanisms .
........................... 30
3.2.3 Definition of basic datatypes .
3.3 JTM events and report parameters . 31
3.3.1 Event categories . 32
........................................ .................................................. 34
3.3.3 Diagnostic information parameter .
.................. 37
3.4 Fields of the conceptual data structures .
.. 38
3.4.1 Work specifications .
3.4.2 OS1 job parameters . 39
3.4.3 OS1 subjob parameters . 42
3.4.4 JTM action parameters . 44
3.4.5 Proformas . 53
3.4.6 Header lists . 55
3.4.7 Transfer control records . 57
3.5 JTM documents . 57
3.5.1 JTM report-display document . 58
iii
ISOIIEC 8831:1992(E)
3.5.2 JTM work-display document . 58
3.5.3 JTM TCR-display document . 59
3.6 Parameters of JTM service primitives . 59
3.6.1 J-INITIATE request and confirm primitives . 59
3.6.2 J-DISPOSE service primitives . 60
3.6.3 J-GIVE service primitives . 61
3.6.4 J-ENQUIRE indication and response primitives . 62
3.6.5 J-MESSAGE request primitive . 63
3.6.6 J-SPAWN request primitive . 63
3.6.7 J-END-SIGNAL request primitive . 63
3.6.8 J-STATUS indication and response primitives . 63
3.6.9 J-HOLD, J-RELEASE, J-KILL, J-STOP indication primitives . 64
I
3.6.10 Summary . 65
Section 4 : Basic Class
4.1 Primitive groups and document types for Basic Class . 67
4.1.1 Service primitive groups . 67
4.1.2 Document types . 67
4.2 Conceptual datastructures for Basic Class . 68
4.2.1 Reports . 68
4.2.2 Work specifications . 69
4.2.3 Document movement operations . 70
4.2.4 Work manipulation operations . 71
4.2.5 Report movement operations . 71
4.2.6 Proformas . . 71
4.2.7 Transparency of proformas . 71
4.2.8 Transfer control records . 72
4.2.9 JTM documents . 72
4.3 J-INITIATE primitive group parameters for Basic Class . 72
4.3.1 Top level parameters . 72
4.3.2 OS1 job parameters . 73
4.3.3 OS1 subjob parameters . 73
4.3.4 JTM action parameters . 73
iv
ISOllEC 8831:1992(E)
4.3.5 Proformas . 74
4.3.6 Summary of information contained in a Basic Class J-INITIATE
request . 75
4.4 Other primitive groups in Basic Class . 76
4.4.1 J-DISPOSE . 76
4.4.2 J-GIVE . 76
4.4.3 Other groups . 76
4.5 Summary of Basic Class primitives and parameters . 76
Annexes
A JTM service conventions . 78
A.l Introduction . 78
A.2 Scope . 78
A.3 References . 78
A.4 Definitions . . 78
A.5 Model for the JTM service . 79
A.6 Service primitives . 79
A.7 Time sequence diagrams .
A.8 Conventions for naming service primitives . 81
B Registers of document types . 83
..................................................................
B.l Introduction . . 83
8.2 Purpose of the entry .
8.3 Identification . 83
8.4 Document semantics . .
B.5 Transfer syntax . . 83
B.6 Relation of syntax and semantics . 84
B.7 Syntactic considerations . 84
B.8 Contents of the register . 84
C Tutorial material . 86
C.l Introduction . . 86
C.2 Architecture . . 86
C.3 Reporting . . 88
C.4 Manipulation . 89
C.5 J-INITIATE primitives . 89
V
ISOllEC '8831:1992(E)
C.6 Naming . 89
C.7 Aaibentication . 89
C.8 JTM terminology . 90
C.9 Th OS1 job parameters . : 91
C.lO'i&mtification of management . 92
C.11.4XM activity (subjobs) . 92
C.12 !Mion on errors . 96
C.13 Documents . 96
C.14.dTM relays . 98
C.dg&gency access protocols . 98
C.16 Time-relations on service primitives . 102
....................................
C.17 Subsets and conformance .
j02
C.18 Interworking of Basic Class and extended implementations . 105
C.19 The JTM protocol . 106
C.20 Examples of the authorisation mechanism .
D Glossary of terms . .
vi
ISOllEC 8831:1992(E)
Foreword
IS0 (the International Organization for Standardization) ancl IEC (the
International 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 or-
ganizations, 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, ISWEC JTC 1. Draft International Siandards
adopted by the joint technical committee are circulated to national bod-
ies for voting. Publication as an International Standard requires ap-
proval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 8831 was prepared by Joint Technical
Committee ISO/IEC JTC 1, lnformation technology.
This second edition cancels and replaces the first edition
(IS0 8831:1989). The text of this second edition of ISO/IEC 8831 includes
changes resulting from alignment with ISO/IEC 9804 (CCR) and the full
protocol amendment to ISO/IEC 8832.
Annexes A and B form an integral part of this International Standard
Annexes C and D are for information only.
vii
Introduction
The purpose of the job transfer and manipulation (JTM) standard is to provide a set of
communication-related services which can be used to perform work in a network of in-
~
terconnected open systems. This work can include both the running of traditional back-
ground jobs and other forms of information processing.
Background jobs have, in the past, been submitted either directly on the host system
where they ran, or else at a remote job entry station connected to that system. Data
files, program and "JCL" would be already available on the host, or would form part of
the submitted "job deck. Output would be delivered on the host system, or alternative-
ly on a printer aîiached to the remote job entry station. In a network of open systems,
such jobs can be submitted at any open system supporting JTM to be run on another
open system, using files collected from any other open systems, with output directed to
peripherals or files held on any other open systems.
The JTM protocol covers not only the movement of job-related data (input and output)
between open systems, but also provides for the movement of data concerned with
monitoring job-related activity, and for controlling and manipulating the progress of this
activity.
This International Standard does not specify individual implementations or products, nor
does it constrain the implementation of entities and interfaces within a computer sys-
tem. There is, therefore, no conformance to this International Standard.
Annex A is part of this International Standard, and describes the notation used for JTM
service definition. This differs from that used by lower layers of OS1 only because JTM
is concerned with concurrent and related activity on more than two open systems. It is
a superset of the notation used in the lower layers.
Annex B is part of this International Standard, and defines the requirements of JTM for
a Document Type Registration Authority. These requirements of JTM apply to private,
enterprise-specific, Registration Authorities; they are, however, also expected to be sat-
isfied by any International Standard covering this area.
Annex C is tutorial material, and is not part of this International Standard. It gives a broad
introduction to JTM, and should be read first by readers unfamiliar with the JTM work.
Annex D is not part of this International Standard, and contains an alphabetic glossary
of the definitions appearing in the body of this International Standard.
viii
INTERNATIONAL STANDARD ISO/IEC 8831:1992(E)
Information technology - Open Systems Interconnection -
Job transfer and manipulation concepts and services
Section 1 : General
1.1 Scope
This International Standard is an application layer standard within the Open Systems Interconnection framework set up by IS0
7498.
It defines the concepts and services for job transfer and manipulation.
This International Standard requires that the user of JTM
- specifies the open systems where work is to be done;
- knows the local functions and facilities of the open systems where work is to be done;
- knows the control languages used to specify local work on the open systems where work is to be done.
This International Standard provides the means to
- to specify work to be done on one or more open systems. The work done at one open system can result in new work
to be done at other open systems;
- monitor the execution of work previously specified;
- modify work previously specified.
This International Standard does not address the standardisation of control languages, but is also applicable to the use of a
standardised control language. This International Standard does not address the standardisation of user interfaces.
1.2 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this International Stan-
dard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agree-
ments based on this International Standard are encouraged to investigate the possibility of applying the most recent editions
of the standards listed below. Members of IEC and IS0 maintain registers of currently valid International Standards.
IS0 646:1991, Information technology - IS0 7-bit coded character set for information interchange.
IS0 2022:1986, Information processing - IS0 7-bit and 8-bit coded character sets - Code extension techniques.
IS0 2375:1985, Data processing - Procedure for registration of escape sequences.
IS0 7498: 1 984, Information processing systems - Open Systems Interconnection - Basic Reference Model.
ISOiTR 8509: 1 987, Information processing systems - Open Systems Interconnection - Service Conventions.
ISOllEC 8831:1992(E)
IS0 8571 -31 988, Information processing systems - Open Systems interconnection - File Transfer, Access and Management
- Part 3 : File Service definition.
IS0 8649: t9B8, Information processing systems - Open Systems interconnection - Service definition for the Association Control
Service Element.
IS0 8822:W8, information processing systems - Open Systems Interconnection - Connection oriented Presentation Service
Definition.
ISO/IEC %&%:1990, information technology - Open Systems interconnection - Specification of Abstract Syntax Notation One
(ASN. 1).
ISO/I EC 8832:1992, Information technology- Open Systems interconnection - Specification of the Basic Class and Full Protocol
for Job Transfer and Manipulation.
ISO/IEC 98634:1990, information technology - Open Systems Interconnection - Service definition for the Commitment ,
Concurrency and Recovery service element.
1.3 Definitions
1.3.1 CCR service definitions
This International Standard makes use of the following terms defined in ISO/IEC 9804:
a) atomic action
b) master
c) superior
d) subordinate
e) commitment
f) rollback
1.3.2 JTM service definitions
The definitians are grouped into major categories, corresponding to the subclauses of clause 2.1.
For the purposes of this International Standard, the following definitions apply.
1.3.2.1 General
1.3.2.1.1 agency: An abstract description of those functions of a real open system which are needed to support the JTM
service.
1.3.2.1.2 wrk specification: A conceptual data structure within the JTM service provider which specifies in a defined way
the work which is to be done.
A collection of data which forms part of a work specification, and which forms a unit of interaction
1.3.2.1.3 hcument:
between the JTM service provider and an agency.
That agency which causes a work specification to be created.
1.3.2.1.4 initiation agency:
1.3.2.2 Pmiiformas and spawning
1.3.2.2.1 proforma: Part of a work specification which specifies further work and is used to form a new work specification
as part of the processing of earlier work.
ISOllEC 8831:1992(E)
1.3.2.2.2 spawning: The process of taking the data from a proforma and using it to produce a new work specification.
1.3.2.2.3 spawning control data: Data contained in a proforma which controls the circumstances in which spawning takes
place from that proforma.
1.3.2.2.4 top level proforma:
A proforma which is not contained within any other proforma.
NOTE - A proforma which is not a top-level proforma can become a top-level proforma as a result of spawning from its parent.
1.3.2.3
Source, sink and execution agencies
1.3.2.3.1 source agency: Any part of an open system which can provide documents for inclusion in a work specification
when required by the JTM service provider as a result of processing the work specification.
1.3.2.3.2 sink agency:
Any part of an open system to which documents can be passed by the JTM service provider as a
result of processing a work specification.
NOTE - Source and sink agencies can obtain and dispose of documents locally, or by use of non-standard protocols, or by use of FTAM.
1.3.2.3.3 execution agency: Any part of an open system which initially acts as a sink for documents, but which subsequently
acts as a source of related documents produced as a result of processing the earlier documents.
1.3.2.3.4 activity (in an agency): Work performed by an agency, initiated by a service primitive issued to the agency by
the JTM service provider; the completion of the activity is indicated by a service primitive issued to the JTM service provider by
the agency.
1.3.2.4 OS1 jobs
1.3.2.4.1 initial work specification: A work specification created as a result of the issue of an initiation service primitive by
an initiation agency.
1.3.2.4.2 OS1 job: The total work on all open systems arising directly or indirectly from an initial work specification.
1.3.2.4.3 OS1 subjob (subjob): The total work arising from the processing of a single work specification, including the
spawning of further work specifications, but excluding work arising from the processing of these further work specifications.
1.3.2.4.4 OS1 job submission: The use of the initiation service primitive by an initiation agency for the creation of an initial
work specification.
1.3.2.4.5 OS1 job submission system: The open system on which OS1 job submission occurs.
1.3.2.5 Reporting and the monitor function
1.3.2.5.1 JTM report: Encoded information recording the progress or failure of an OS1 job, generated by the JTM service
provider, possibly as the result of interaction with an agency.
1.3.2.5.2 OS1 job monitors: Open systems to which JTM reports about a particular OS1 job are sent.
1.3.2.5.3 report work specification: The type of work specification created by the JTM service provider to move JTM re-
ports; the target open system for these work specifications is one of the OS1 job monitors.
1.3.2.6 Commitment, concurrency and recovery
1.3.2.6.1 level of commitment: A parameter which determines whether operations requested in an atomic action are com-
pleted at the time of the atomic action, or are noted (as secure data) for later performance.
1.3.2.6.2 warning diagnostic: Information carried by the CCR service on an offer of commitment which reports (usually for
a human being) any variations on the expected action or unexpected consequences of the action.
1.3.2.6.3 retry-later diagnostic: Information carried by the CCR service on a rollback when an action cannot be completed
for reasons which can be transient.
1.3.2.6.4 no-retry diagnostic: Information carried by the CCR service on a rollback when an action cannot be completed,
and a later retry is not proposed.
ISOllEC 8831:1992(E)
1.3.2.7 Transfer control
1.3.2.7.1 work specification transfer: An atomic action by which a work specification is created at the receiving open sys-
tem and destroyed at the sending open system.
1.3.2.7.2 transfer control record: A conceptual data structure held by an open system to control the transfer of work spe-
cifications and the issue of service primitives.
1.3.2.8 Report manipulation
1.3.2.8.1 report manipulation operations: Operations requiring deletion or display of reports held by an open system nomi-
nated as a monitor point by some work specification.
1.3.2.8.2 report manipulation work specification: A work specification containing report manipulation operations.
1.3.2.9 Work manipulation
1.3.2.9.1 work manipulation operations: Operations which select one or more work specifications or proformas and re-
quest displaying, killing, stopping or modification.
A work specification containing work manipulation operations.
1.3.2.9.2 work manipulation work specification:
1.3.2.9.3 selector: Data which is used to select zero, one, or more work specifications.
1.3.2.9.4 update: Data which is used to modify a selected work specification or proforma.
1.3.2.1 O Transfer manipulation
1.3.2.10.1 transfer manipulation operations: Operations requiring setting, displaying or checking transfer control records.
1.3.2.10.2 transfer manipulation work specification: A manipulation work specification containing transfer manipulation
operations.
1.3.2.1 1 Authorisation and accounting
1.3.2.1 1.1 identification authority: A naming authority which issues identifications; these identifications can be used to
determine the capabilities to be made available to a particular authenticated identification (authorisation), or can be used to levy
charges (accounting), or both.
1.3.2.1 1.2 authenticated identification: Data which is known to correctly identify the user or management who requested
the work to be performed, either by the use of a password check, or by some other checking mechanism.
1.3.2.11.3 user identification: Data which can be used in a particular context to identify the user on whose behalf work is
being requested.
1.3.2.1 1.4 account identification: Data which can be used in a particular context to identify the account to be debited with
any charges which are levied.
NOTE - User and account identifications ccnsist of the name of an identification authority together with one of the identifications it issues.
1.3.2.1 1.5 open system management identification: The name of an open system which, when authenticated, authorises
JTM activities or charging related to the management of that open system.
NOTE - Examples of such activities are the holding of work specifications about to be transferred to it, or the setting of transfer control rec-
ords.
1.3.2.1 1.6 identification authority management identification: The name of an identification authority which, when auth-
enticated, authorises JTM activities related to control of activity initiated by user identifications issued by that authority.
1.3.2.12 Work specification identification
A reference for an OS1 job which is unambiguousaithin the OS1 job submission sys-
1.3.2.12.1 OS1 job local reference:
tem, assigned by that open system.
1.3.2.12.2 initiating identification: An identification provided by the JTM user at submission time to identify the initiator of
1.3.2.12.3 OS1 job name: A string provided by an initiation agency when submitting an OS1 job.
1.3.2.12.4 work specification identifier: A unique reference for a work specification which includes the name of the OS1
job submission system, the identification of the initiating user, the OS1 job local reference and the OS1 job name; where a work
specification was created by spawning, the identifier also contains one or more proforma names.
1.4 Abbreviations
open systems interconnection
job transfer and manipulation
FTAM file transfer, access and management
commitment, concurrency and recovery
1.5 Conventions
The conventions used in this service definition are contained in annex A.
ISOllEC 8831:1992(E)
Section 2 : Overview
2.1 Overview and general description
In order to define JTM services, a model of the elements involved in the services is required. This JTM model is derived from
the definitions given in IS0 7498 by adding further detail to encompass the services.
2.1.1 Werview
The JTM model recognizes the existence of a number of independent application entities on different open systems which co-
operate to provide the JTM service and together form the JTM service provider. The JTM model also recognizes the existence
of a number of agencies which are the users of the JTM service. The conceptual interactions between the JTM service provider
and an agency are defined by service primitives. The JTM service provider receives from an initiation agency enough informa-
tion tQ create a work specification.
The work which is requested is performed by
a) standardized functions of the JTM service provider;
b} functions of the local system environment accessed by the movement of documents between the JTM service pro-
vider and agencies.
2.1.2 Work specification contents
A work specification contains fields which provide data for
a) identification of the work;
b) authorisation of the work;
c) defining where reports on the work are to be sent;
d) selecting the reports which are required;
e) identifying the type of the work specification;
f) identifying the open systems which are to perform the work;
g) specifying the urgency of the work:
h) holding parts of the work until specified events occur;
i) specifying the actions to be performed by the JTM service provider to carry out the initial work;
j) specifying further work to be carried out when the initial work is completed.
A work specification refers to documents in the local system, or to documents which are obtained by the use of IS0 8571 -3;
these documents are subsequently passed by the JTM service provider to the same or to some other open system for storage
locally, or for disposal using IS0 8571 -3. When an open system has completed the work specified by a work specification (poss-
ibly including the generation of one or more new work specifications), the work specification ceases to exist. The JTM protocol
transfers work specifications between open systems in order to progress the work.
The contents of a work specification relate to the following features supported by the JTM service, and are completely defined
in clause 3.4.
The identification field of a work specification provides a universal and unique name by which the work can be referenced for
subsequent reporting and manipulation. The work specification identifier is allocated when the work specification is created fol-
lowing submission by the initiation agency, or when it is created as the result of processing an earlier work specification. In the
latter case, the identifier will reflect the parentage of the work specification.
The initiating identification field, and the time of submission field are generated when a work specification is created as a
result of submission by the initiation agency. These fields are copied when new work specifications are created by JTM as a
result of processing earlier work specifications.
The authorisation and accounting fields provide data which enables open systems to allow the performance of the requested
work. When a work specification references files for obtaining or disposing of documents, additional authorisations and accounts
can be included for the access to the files.
OS1 job monitors can be specified; these are open systems to which any selected reports are to be sent.
The report selector field determines (for each OS1 job monitor) which categories of event are to be reported to that monitor.
Different types of work specification are defined, corresponding to the different types of initial work to be performed. The most
important type is the document movement work specification which provides for the movement of user documents between
open systems. Other types provide for the movement of reports and manipulations: they are introduced later.
The target open system is that open system which carries out the final processing of the initial work, and which can generate
new work specifications for further work. Relays can be specified for use as store-and-forward sites on the way to the target.
The urgency for the performance of the desired work and the holding of it can be specified.
JTM actions specify - in relation to the various types of work specification -what specific actions the JTM service provider has
to perform. They determine the interactions between the JTM service provider and its local system environment, and determine
the actions to be taken by it on its own data, or with regard to the reporting of events.
The further work field provides data in a form which allows the creation of new work specifications by a target.
2.1.3 Proformas and spawning
A proforma can contain further proformas nested to any depth. The JTM service provider spawns work specifications using top
level proformas and the spawning control data in the proformas. The new work specifications are formed using both data in the
proformas, and also data in other fields of the original work specification. An important feature of spawning is the addition to the
new work specifications of documents which have become available as a result of earlier activity. The spawning process is in-
itiated by an execution agency (see 2.1.4), or as the result of completion of activity on a sink or execution agency (see 1.3.2.3.4).
2.1.4 Source, sink and execution agencies.
The model recognizes that the JTM service provider, when processing a work specification, can - according to information in
the work specification - interact with source, sink and execution agencies.
There are service primitives for interactions between a JTM service provider and agencies. Following these interactions with a
source, the activity is complete. Following these interactions with a sink or execution agency the activity can either be complete
or the agency can indicate only acceptance, that is, that the request for some activity has been secured. In the latter case, com-
pletion of the activity will be signalled by the agency at some later time, using another set of service primitive interactions.
An execution agency can, on completion of an activity, indicate that a number of documents are available for collection by a
work specification resulting from spawning. It can also, at any time prior to completion, and if required by the activity, use ser-
vice primitives to demand spawning using specified proformas; the resulting work specifications can collect documents which
have become available before the end of the activity.
At any time prior to the completion of an activity in a sink or execution agency, the following events can occur:
a) the JTM service provider can, as a result of processing a request for work manipulation (see 2.1.1 I), require that the
activity be killed or stopped or held or released:
b) the JTM service provider can ask for status information about the activity;
c) the agency, if required by the activity, can cause the JTM service provider to generate a report about some significant
event in the life of the activity;
if required by the activity, can ask the JTM service provider to spawn from specified proformas.
d) the agency,
All service primitives defined for interaction with an agency relate to a single work specification, and are independent of primi-
in relation to other work specifications.
tives used
An agency which cannot support concurrent activity on behalf of several work specifications can reject an attempt by the JTM
service provider to initiate new activity with the response “retry later”.
Primitives used to obtain or dispose of documents using source and sink agencies carry information relating to the activity being
attempted. The information is in one of two forms:
a) in a JTM-specific form suited to simple local access, or to remote access in a non-standardised manner; or
b) in a form specified by IS0 8571 -3 (FTAM), suitable for local or remote access where FTAM is supported.
2.1.5 OS1 jobs
A complete OS1 job can involve access to source agencies on the OS1 job submission system, access to source agencies, sink
agencies and execution agencies on other open systems, the spawning of further work specifications and their processing. The
complete OS1 job comprises a set of activities performed either consecutively or simultaneously, potentially involving many
open systems.
2.1.6 Processing of work specifications
2.1.6.1 Normal processing
After OS1 job submission, an initial work specification can cause accesses by the JTM service provider to source agencies at
the OS1 job submission system, together with accesses to agencies at other open systems. The processing of a work specifi-
cation typically comprises the following steps, performed repeatedly if necessary:
a) source agencies are accessed and the documents delivered by them are (conceptually) embedded in the work speci-
fication;
b) the work specification (including any embedded documents) is transferred to another open system, using the JTM
protocol;
c) documents within the work specification are passed to one or more sink or execution agencies as specified by the work
specification;
d) new work specifications are spawned using top level proformas contained within the original work specification, either
on acceptance of documents by agencies, or on demand from an activity in an agency, or following completion of the sink
or execution agency activity; documents which have been made available as a result of activity in an execution agency or
which are specified to be obtained from other source agencies can be included in the new work specifications;
e) the original work specification is destroyed when ’all the activity resulting from the above processing is completed.
If new work specifications have been produced by the processing of a work specification then these can cause further accesses
to source agencies, followed by processing, as described above.
An illustration of the processing of a work specification, the activities of the JTM service provider related to an OS1 job, includ-
ing reporting (see 2.1.7) and manipulation (see 2.1 .I I), and the relationship between JTM model elements is given in annex
C.
2.1.6.2 Errors in OS1 job processing
Where errors are detected in a work specification (being received by an open system) before it has taken responsibility for it
(offered commitment -see 2.1.8), such errors are reported to the sending open system using facilities present in the JTM proto-
col. This is seen by the sending system as a failure to transfer the work specification.
Errors which are detected by an open system (with responsibility for a work specification) while processing it are treated as de-
scribed below.
ISOllEC 8831:1992(E)
The normal processing of a work specification, as described in 2.1.6.1, involves obtaining documents from source agencies
and disposing of documents to execution agencies and sink agencies. Errors can arise which prevent one or more of these do-
cument exchanges being completed successfully. For example, the work specification might contain the name of a document
which does not exist in the filestore accessed by the specified source agency, or might contain the name of a sink or execution
agency which does not exist at the specified open system. Such errors are events for which JTM reports can be generated (see
2.1.7).
An error which prevents a document being obtained does not necessarily prevent further progress of the OS1 job, as further
useful processing can still be possible on other documents which have been obtained successfully. The work specification can
indicate that an error diagnostic is to be included in the work specification in place of the document which could not be obtained;
this error diagnostic is passed to the intended sink or execution agency instead of the document. In this case, all specified in-
teractions with agencies still take place, and the sink or execution agericy decides what action to take in the event of an error
diagnostic being present.
An error detected while disposing of a document to a sink or execution agency, or while attempting a JTM transfer, prevents
further processing of the OS1 job. In this situation, the JTM servic
...