An agency provides an abstract representation of part of a real open system.
Each conceptual interaction between the JTM service provider and an agency is defined by the issue of a sequence of service primitives (called a JTM service primitive group or a commitment group).
This International Standard associates Commitment, Concurrency, and Recovery semantics (as defined in ISO/IEC 9804) with these service primitives. This provides a means of defining the points in the JTM protocol when externally visible events are to occur, and of stating the commitment, concurrency, and recovery capability which the total real system is to exhibit.
Provided the external behaviour corresponds with that of the model open system, no constraints are placed on the internal structure, interfaces, or procedures of the real system.
A JTM service primitive group is a sequence of service primitives, some of which are mapped onto the CCR service primitives of ISO/IEC 9804, and some of which have a purely JTM function.
There are four groups of primitives (initiated by an initiation agency) which each define the creation of a new work specification in an open system. These are
| J-INITIATE-WORK | this group is used by an initiation agency to create a work specification for document movement; |
| J-INITIATE-WORK-MAN | this group is used by an initiation agency to create a work specification for the manipulation of existing work specifications; |
| J-INITIATE-REPORT-MAN | this group is used by an initiation agency to create a work specification for the manipulation of reports received by an OSI job monitor; |
| J-INITIATE-TCR-MAN | this group is used by an initiation agency to create a work specification for manipulation of JTM transfer control records; |
Note that where a statement applies to all the above primitive groups, the term "J-INITIATE" is used. In particular, the only difference between the parameters of these primitives is in the nature of the JTM action parameters outside of proformas, and the Basic Class restrictions.
There are three groups of primitives initiated by the JTM service provider as the result of processing a document movement work specification, that is, as the result, directly or indirectly, of a J-INITIATE group of primitives. The first group is issued to a sink or execution agency, and the last two groups to an execution agency or source. These groups are
| J-DISPOSE | this group is used by the JTM service provider to pass a document to a sink or execution agency, creating a new activity in that agency; |
| J-GIVE | this group is used by the JTM service provider to request a document from a source or execution agency; |
| J-ENQUIRE | this group is used by the JTM service provider to obtain from a source or execution agency a list of document names for satisfaction of references. |
There are three groups of primitives which are initiated by a sink or execution agency in relation to a specific activity which is in progress in the agency. These are
| J-MESSAGE | (execution agency only) this group is used by the agency to cause the JTM service provider to generate a USER-MESSAGE report work specification; |
| J-SPAWN | (execution agency only) this group is used by the agency to specify that demand spawning from a specified proforma is to occur; |
| J-END-SIGNAL | this group is used by a sink or execution agency to signal the end of an activity which is in progress following an earlier ACCEPTANCE commitment. |
There are five groups of primitives which are initiated by the JTM service provider to a sink or execution agency to control an activity which is in progress following earlier ACCEPTANCE commitment. These are
| J-STATUS | this group is used by the JTM service provider to obtain information about the progress of an activity; |
| J-HOLD | this group is used by the JTM service provider to request temporary suspension of the progress of an activity (its only defined effect is to prevent the issue of the primitive groups of 3.1.1.3; other effects are not standardised); |
| J-RELEASE | this group is used by the JTM service provider to cancel an earlier J-HOLD; |
| J-KILL | this group is used by the JTM service provider to cause termination of the activity; this causes an immediate J-END-SIGNAL, and no documents are provided by an execution agency; it is desirable, but not required, for all effects of the activity being killed to be undone; |
| J-STOP | this group is used by the JTM service provider to cause termination of the activity; this causes an immediate J-END-SIGNAL, but documents can be supplied; it is recommended that any work already done should not be undone, but this is not required. |
These groups consist of the following primitives (in order):
The primitives in a), c), and d) carry only CCR parameters, and correspond exactly to CCR service primitives of the same name. Their sequence, semantics and parameters are completely defined by ISO/IEC 9804, except for the user data parameter (see 3.1.3). The agency is the commitment master (and issues the CCR atomic action identifier and defines the commitment level ) in all cases except the J-MESSAGE and J-SPAWN group. Where these groups are issued following ACCEPTANCE commitment, the agency is the commitment master, otherwise it is a sub-master. Where the agency is a sub-master, it chooses a commitment level greater than or equal to that received. For a J-END-SIGNAL request, the agency always specifies PROVIDER-ACCEPTANCE (level 1), and does not refuse commitment if the JTM service provider offers commitment.
These groups consist of the following primitives (in order):
The primitives in a), c) and d) carry only CCR parameters, and correspond exactly to CCR service primitives of the same name. Their sequence, semantics and parameters are completely defined by ISO/IEC 9804, except for the user data parameter (see 3.1.3). The JTM service provider is the commitment master (and issues the CCR atomic action identifier) if and only if it has already given ACCEPTANCE commitment to the J-INITIATE, J-SPAWN or J-END-SIGNAL group which generated the work specification causing the primitives to be issued, otherwise it is a submaster. When the JTM service provider is the master it always requests commitment level 1.
This sequence consists of one or more repetitions of
The parameters of the CCR-related primitives identified in 3.1.2.1 and 3.1.2.2 are specified in ISO/IEC 9804. The user-data parameter specified in ISO/IEC 9804 is used to carry JTM-specific CCR-related parameters as defined below.
These primitives carry
The user data parameter is not used.
The user data parameter is not used.
These primitives carry
The user data parameter is not used.
The user data parameter is not used.
When issued from a subordinate to a superior, these primitives carry
The user data parameter is not used.
The user data parameter is not used.
The user data parameter is not used.
The following groups are issued at any time:
J-INITIATE-WORK
J-INITIATE-WORK-MAN
J-INITIATE-REPORT-MAN
J-INITIATE-TCR-MAN
J-DISPOSE
J-GIVE
J-ENQUIRE
There is an additional restriction on the J-GIVE and J-ENQUIRE groups when issued to an execution agency. In this case they are only issued (and complete) between a J-END-SIGNAL or J-SPAWN request, and the corresponding J-READY or J-ROLLBACK indication or between a J-DISPOSE response where COMPLETION commitment is offered and the corresponding J-COMMIT or J-ROLLBACK indication.
The following groups are issued between a J-DISPOSE indication and the corresponding J-READY or J-ROLLBACK request:
J-MESSAGE
J-SPAWN
The following groups are issued between a J-COMMIT response in a J-DISPOSE group which gave ACCEPTANCE commitment, and the J-BEGIN request commencing the J-END-SIGNAL for the activity:
J-MESSAGE
J-SPAWN
J-END-SIGNAL
A J-END-SIGNAL group is not started if any other group is incomplete in relation to the same activity, nor is a J-READY request to a J-DISPOSE indication issued if a J-MESSAGE or J-SPAWN sequence is incomplete.
The following groups are started if and only if no other group is in progress in relation to the same activity:
J-STATUS
J-HOLD
J-RELEASE
J-KILL
J-STOP
In addition to these primitives, J-RECOVER is defined with the same semantics and parameters as C-RECOVER, and can occur as defined in ISO/IEC 9804.
An arbitrarily complex JTM activity involves many primitive groups. The possible sequences of all the primitives in these groups can be determined, for any specific JTM activity, by applying the following rules:
An example applying these rules to specific JTM activity is provided in annex C.
NOTE -- An implementation can support only a single agency (initiation, sink, source, or execution), or can support several agencies of the same or different types. Where a type of agency is not supported, service primitive groups interacting with that type of agency do not occur on that open system.
This clause specifies the notation used for defining the parameters of the JTM service primitives which are not CCR-related. (The parameters of the CCR-related primitives have a less complex structure, and are defined in 3.1.3.)
Each JTM service primitive parameter or field in a JTM conceptual datastructure is either a basic datatype or a structured datatype. Each structured datatype is constructed using one of the structuring mechanisms in 3.2.2 below applied to either basic datatypes or to further structured datatypes.
There are six basic datatypes used by JTM. These are
A literal is specified by giving the literal name in capitals. Each literal is an unambiguous identification whose semantics are entirely defined in this service definition. For example,
MOVE HIGH CREATION
All other basic datatypes are written with a lower case name enclosed in angle brackets, with an "=I", "=S" or "=OS", "=N" or "=NA" or "=ND", ="R", and "=D" included to denote the basic datatypes b) to f) above. For example:
integer <qualifying integer = I>
string <OSI job name =S>
<source name = S>
name <authority name = NA>
<open system name = N>
<document type = ND>
referenced <security parameters = R>
document <basic document = D>
The definition of these basic datatypes is given in 3.2.3 below.
There are four mechanisms (and corresponding notation) for forming a structured datatype. These are
<subjob name-list>
<target list>
<urgency>
<holds>
<subjob type>
each of which is another structured datatype;
[<basic document = D>]*L
[<permission element>]*C
( HIGH | MEDIUM | LOW )
A structured datatype is defined by placing its name on the left of a "::=" symbol, with the structure notation on the right. For example
<permissions>::= [<permission element>]*C
The meaning of each literal is defined as it occurs.
An integer is any value from zero upwards, and is not bounded.
A string datatype is either a sequence of characters plus space taken from any character set registered for use as a G0, G1, G2, or G3 set in the ISO Register of Character Sets, or is an octet string. In the former case "=S" is used, in the latter case "=OS" is used.
The JTM protocol conformance requirements specify that an implementation
Where a string is used for naming, the non-ambiguity requirements are met by this International Standard by associating with the string field another datatype "name" which limits the scope of the string (see 3.2.3.3). For example, the identification of a user is expressed as
<authority name = NA>
<user identification = S>
where <user identification> is required to be unambiguous within the scope of <authority name>.
The length of a string is unbounded.
A name is a data-type which provides a globally unambiguous identification. The definition of its form is outside the scope of this International Standard. The means by which unambiguous names are assigned is outside the scope of this International Standard. There are only three sets of entities for which JTM requires unambiguous names. These are
A datatype which identifies a JTM application-entity is denoted by "=N". A datatype which identifies a user identification authority is denoted by "=NA". A datatype which identifies a document type is denoted by "=ND". It is possible, but not required, for the same name to identify both a JTM application-entity and a user identification authority.
Names are unambiguously assigned by ISO Registration Authorities, with escape mechanisms to support private registration authorities. Names assigned by a private registration authority are only unambiguous within the scope of a particular enterprise.
Names of objects of type a) and b) have the form and allocation mechanisms defined for OSI application-entity-titles. Names of type c) have the form and allocation mechanisms defined for the OBJECT IDENTIFIER datatype in ISO/IEC 8824.
A referenced datatype is defined by some other International Standard. The accompanying text will identify the International Standard defining the datatype. The form of these datatypes is not constrained by this International Standard.
NOTE -- The only use currently made of these datatypes is for the security parameters.
A document is a datatype defined using any notation which provides (either directly or by using an abstract syntax notation):
NOTE -- This information is sufficient for JTM purposes. Other uses of Document Type Registration can require additional information.
Document datatypes are defined in this International Standard (see clause 3.5), in other International Standards or CCITT Recommendations, or directly in the ISO Register of Document Types. All documents carried by JTM have associated with them an unambiguous name (=ND) assigned when they are defined.
The categories of event which can cause the JTM service provider to generate reports are listed in 3.3.1. The parameters carried by a report of an event in each of the categories are listed in 3.3.2.
The processing of a work specification involves one or more atomic actions during which responsibility for progressing the work can be transferred from one open system to another. Responsibility is transferred only when an atomic action commits. Reports can be generated by the master of the atomic action, or by the open system first detecting the occurrence of an event. This is defined for each event. Where the following definitions specify that a report is to be produced as part of some atomic action, the branch of the atomic action producing the report commits if and only if the main atomic action commits; the main atomic action fails if the branch of the action progressing the report fails. The commitment level for the report follows the normal rules. Where the following definitions specify that the report is issued as a separate atomic action, the commitment level is one, and success or failure of the two actions is independent.
The event categories are listed and defined below.
| CREATION | A report is to be produced by the open system where J-INITIATE is issued, as part of that atomic action; |
| TRANSFER | The JTM protocol operates by transferring between open systems the conceptual data structures (work specifications) defining the remaining parts of the OSI job; this literal requires an open system taking responsibility for a work specification (that is, committing with PROVIDER-ACCEPTANCE or AGENCY-ACCEPTANCE commitment level) to generate a report as part of the atomic action transferring responsibility; |
| SPAWNING | A report is to be produced by an open system when it uses the data in a proforma to initiate a new subjob (spawning); this report is produced as part of the atomic action performing the spawning; |
| AGENCY-ACCEPTANCE | A report is to be produced by the open system which is the master of an atomic action processing a work specification for which it is responsible when an AGENCY-ACCEPTANCE commitment level (or greater) is achieved for all branches of the atomic action; this is produced as part of the atomic action; |
| NOTE -- This is not produced if all branches of the action produced COMPLETION commitment level, as this generates the NORMAL-TERMINATION event. | |
| NORMAL-TERMINATION | A report is to be produced by a target open system which is processing a work specification when all branches of the atomic action produce COMPLETION commitment; it is generated as part of the atomic action; it is also produced as part of the J-END-SIGNAL atomic action when a work specification is discarded following any necessary spawning; note that spawning reports can also be produced as part of this same atomic action, and that the requested minimum commitment level for J-END-SIGNAL is always PROVIDER ACCEPTANCE; |
| MANIPULATION-TERMINATION | A report is to be produced by the open system performing the manipulation if the work specification is cancelled by a KILL manipulation operation; this is generated as part of the manipulation atomic action; |
| MODIFICATION | A report is to be produced by the open system performing the manipulation whenever the work specification is modified by a manipulation operation, or stopped by a STOP operation; it is generated as part of the manipulation atomic action; |
| ERROR-DIAGNOSTIC | A report is to be produced by an open system whenever a document source reference (see 3.4.4.1.3) in a work specification is replaced by an error diagnostic; it is generated as part of the main atomic action; |
| NO-PROGRESS | A report is to be produced whenever an open system responsible for a work specification, and master of an atomic action trying to progress it, receives C-ROLLBACK or J-ROLLBACK indication with a NO-RETRY diagnostic and retains the work specification; it is also generated if continuous rollbacks with RETRY-LATER diagnostics recur for an implementation-dependent time; the CCR diagnostic is made available in the report, and the work specification is retained for correction by subsequent modification; this report is generated as a separate atomic action; |
| ACCOUNTING-DATA | A report is to be produced by an open system whenever charging information relating to this OSI job becomes available; the report is generated as a separate atomic action by the open system which is the master of an atomic action processing a work specification for which it is responsible; |
| USER-MESSAGE | A report is to be produced by an open system when the J-MESSAGE request is issued by an activity in an execution agency; it is generated as part of the J-MESSAGE atomic action; |
| NOT-SUPPORTED-TERMINATION | A report is to be produced by an open system responsible for a work specification and master of the atomic action if the complexity of the subjob exceeds the capabilities of the open system processing it; it is generated as a separate atomic action and the work specification is discarded; |
| NOTE -- An open system checks a work specification received in a transfer element, and refuses the transfer if it is unacceptable; this normally produces a NO-PROGRESS report by the sender; the NOT-SUPPORTED-TERMINATION event only occurs when a proforma is used for spawning which exceeds the capabilities of the spawning system. | |
| ABNORMAL-TERMINATION | A report is to be produced whenever an open system responsible for a work specification, and master of an atomic action trying to progress it, receives a J-ROLLBACK or C-ROLLBACK with a NO-RETRY diagnostic and discards the work specification; it is also generated if continuous rollbacks with RETRY-LATER diagnostics recur for an implementation-dependent time; the CCR diagnostic is made available in the report; this report is generated as a separate atomic action; |
| VIOLATION-ATTEMPT | A report is to be produced if a manipulation work specifica tion attempts to modify, DISPLAY, STOP, or KILL this work specification, and does not contain an authorisation element permitting the operation; it is generated as a separate atomic action. |
| WARNING-REPORT | A report is to be produced if, during successful JTM activity, warnings are produced relating to the results or effects of that activity. |
A report consists of the following information:
<report>::= <name of reporter = N>
<time stamp>
<subjob identification>
<event identification> (see 3.4.2.2)
<event parameters>
<time stamp>::= ( NULL | <date-time = S> )
<subjob identification>::= <OSI job submission system = N>
<initiating identification>
<initiating time>
<OSI job name = S>
<OSI job local reference = S>
<subjob name-list>
<subjob type> (see 3.4.3.3)
<initiating identification>::= <identification>
<identification>::= ( <open system management> | <authority management> | <user> )
<open system management>::= <open system name = N>
<authority management>::= <authority name = NA>
<user>::= <authority name = NA>
<user identification = S>
<initiating time>::= <time stamp>
<subjob name-list>::= [<subjob name component>]*L
<subjob name component>::= <proforma name = S> (see 3.4.5)
<qualifying integer = I>
<event parameters>::= ( NULL | <target list> ) (see 3.4.3)
( NULL | <number spawned = I> )
( NULL | [<text = S>]*L )
( NULL | [<diagnostic information>]*C ) (see 3.3.3)
( NULL | <security data> ) (see 3.3.3.1)
( NULL | <hold state> )
( NULL | <stop signal> )
( NULL | <accounting information> ) (see 3.3.3.2)
where
<hold state>::= ( HELD | NOT-HELD )
<stop signal>::= ( STOPPED | MODIFIED )
The <name of the reporter> specifies the open system generating the <report>. The <time stamp> carries date and time of report generation, in the form specified for GeneralizedTime in ISO/IEC 8824, if this is available on an open system, otherwise it is NULL. Support for a time-stamp is optional in all JTM implementations.
The <subjob identification> identifies the subjob being reported on; its fields are copied from the work specification being reported on.
The <OSI job submission system> provides a globally unambiguous identification of the OSI job submission system. Other naming strings are unambiguous only within this scope.
The <initiating identification> is also globally unambiguous, and identifies the management of an open system, the management of a user identification authority, or a user.
The <initiating time> is inserted by the JTM service provider at the time of a J-INITIATE.
The <OSI jobname> is supplied by J-INITIATE and is used to identify the whole OSI job. There are no requirements that this should have different values on different OSI jobs.
The <OSI job local reference> is inserted by the JTM service provider (and returned in the J-INITIATE response). It unambiguously identifies the OSI job within the scope of the <OSI job submission system>.
The <subjob name-list> is empty for the first subjob of an OSI job. It is generated by the JTM service provider on spawning by appending a <subjob name component> to the <subjob name-list> of the parent subjob. The <subjob name component> contains the name of the proforma from which the subjob was spawned, and an integer which is the count of subjobs spawned from this proforma. (That is, the first or only subjob spawned from a proforma has a qualifying integer of one.)
The <subjob type> is defined in 3.4.3.3. It identifies the type of the subjob being reported on. It can never have the value "REPORT-MOVEMENT" when used as above, as reports are not generated on such subjobs.
The <event identification> identifies the event category being reported on. Event categories are defined in 3.3.1.
The <event parameters> are supplied as shown in table 1 for each type of event.
| Event type | Target list |
Number spawned |
Text | Diagnostic | hold state |
security state |
stop signal |
accounting information |
|---|---|---|---|---|---|---|---|---|
| CREATION | X | X | X | |||||
| TRANSFER | X | X | X | |||||
| SPAWNING | X | X | X | |||||
| AGENCY-ACCEPTANCE | X | |||||||
| ERROR-DIAGNOSTIC | X | X | ||||||
| NO-PROGRESS | X | X | ||||||
| USER-MESSAGE | X | |||||||
| ACCOUNTING-DATA | X | X | ||||||
| NORMAL-TERMINATION | X | X | ||||||
| MANIPULATION-TERMINATION | X | X | ||||||
| MODIFICATION | X | X | X | X | ||||
| NOT-SUPPORTED-TERMINATION | X | X | ||||||
| ABNORMAL-TERMINATION | X | X | X | |||||
| VIOLATION-ATTEMPT | X | X | ||||||
| WARNING-REPORT | X | X |
The ERROR-DIAGNOSTIC, ABNORMAL-TERMINATION, NO-PROGRESS and WARNING-REPORT reports are the only ones carrying defined diagnostics (see 3.3.3 for the form of defined diagnostics). The <text> strings are used in other cases to carry diagnostic information, and are not standardised.
The text-strings for the USER-MESSAGE event are obtained from the J-MESSAGE primitive (see 3.6.5).
The length of each <text> string is restricted to 40 characters.
The <target list> specifies the <target> and <relays> of the new work specification; it is defined in 3.4.3. The <number spawned> specifies the number of work specifications spawned from the old work specification.
The <security data> is defined in 3.3.3.1, and provides an identification of the work specification causing a VIOLATION-ATTEMPT event. (Thus the <subjob identification> in it differs from that in the head of the <report>, which is the work specification on which the violation attemmpt was made.) The <security data> contains a copy of the audit trace to permit detection of masquerade.
The <hold state> is HELD if one or more elements in the hold list prevent further progress, and is NOT-HELD otherwise.
The <stop signal> is STOPPED if the modification included a STOP operation, and MODIFIED otherwise.
NOTE -- A manipulation producing KILL generates a MANIPULATION-TERMINATION event, and not a MODIFICATION event.
<diagnostic information>::= <generator details>
<time stamp> (see 3.3.2)
<CCR diagnostics> (see below)
<generator details>::= ( <source details> | <se details> | <recipient = N> | PROVIDER)
NOTE -- In the naming of datatypes "se" has been used as a mnemonic for "sink or execution".
<source details>::= <source identification> (see 3.4.4.1.3)
<document source reference> (see 3.4.4.1.3)
<se details>::= <se identification> (see 3.4.4.1.1)
<document se reference> (see 3.4.4.1.2)
The <diagnostic information> is generated by the JTM service provider when it is a commitment master and has <CCR diagnostics> (see below) to process. The <CCR diagnostics> are returned from sources, sinks, or transfer attempts, and may have been generated by several open systems.
The <source details> identify the CCR subordinate and some parameters of J-GIVE when this produced the J-ROLLBACK. The <se details> identify the CCR subordinate and some parameters of J-DISPOSE. The <recipient> identifies another open system when a transfer attempt fails. PROVIDER identifies the JTM application-entity as itself the generator of the <diagnostic information>.
The <CCR diagnostic> is initially carried in a J-READY or a C-READY (for a diagnostic of WARNING only), or in a J-ROLLBACK or C-ROLLBACK for RETRY-LATER or NO-RETRY.
<CCR diagnostics> of WARNING are embedded in <diagnostic information> for the generation of WARNING REPORTS.
<CCR diagnostics> of NO-RETRY are embedded in <diagnostic information> for abnormal-termination, no-progress and error-diagnostic reports.
<CCR diagnostics> of RETRY-LATER are never embedded in <diagnostic information> unless repeated rollbacks with retry-later occur.
<CCR diagnostics>::= ( [Warning>]*C | [<Retry later>]*C | [<No retry>]*C )
<Warning>::= <generator = N>
<code>
( <reason> | <FTAM outcome> )
<Retry later>::= <generator = N>
<code>
( <reason> | <FTAM outcome> )
<retry timer = I>
<No retry>::= <generator = N>
<code>
( <reason> | <FTAM outcome> )
<FTAM outcome>::= <"Write transfer outcome" or "Read transfer outcome" as
defined in annex D of ISO 8571-3>
The <generator> identifies the open system producing the CCR diagnostic, and the <code> is one of the values listed in the JTM protocol specification. <reason> is human-readable text (see below).
The <FTAM outcome> is a datastructure capable of carrying all the information specified in annex D of ISO 8571-3 which results from a transfer attempt using FTAM.
The <retry timer> gives the suggested time delay before retrying the atomic action. The time is 2**I seconds, where I is the value of <retry timer>.
The <reason> consists of one or more <text> strings. Each <text> string consists of from zero to 40 characters.
NOTE -- This datatype is used to carry the human-readable portion of a JTM diagnostic. It has been chosen so that display of the diagnostic using a two-dimensional medium of width forty characters is possible. The generator of a diagnostic should note this intended model of a display.
The <security data> is copied from the work specification attempting the modification which caused the VIOLATION-ATTEMPT.
<security data>::= <audit trace> (see 3.4.2)
<subjob identification> (see 3.3.2)
The <audit trace> identifies the source of the work specification attempting the unauthorised modification or display. The use of the <audit trace> for this purpose gives protection against masquerade in the use of other fields. The <subjob identification> is copied from the offending work specification and provides information enabling it to be identified.
<accounting information>::= [<charging information>]*C
<charging information>::= <identification> (see 3.3.2)
<resource-name = S>
<charging-unit = S>
<charge = I>
The <accounting information> becomes available locally or as the result of a C-READY or C-ROLLBACK in a transfer attempt.
It is returned to the commitment master using CCR mechanisms, and then to the JTM monitor points using the reporting mechanisms.
The <identification> identifies the account which is being charged. The <resource-name> and <charging unit> are names issued by the authority in the <identification> for the purposes of charging. The same names may also be used for authorisation.
The <identification> identifies a unit of accountability, the <resource-name> identifies a resource which has been consumed, and the <charging-unit> and <charge> contain the charges levied.
All JTM activity is governed by conceptual data structures called work specifications.
A J-INITIATE primitive causes a work specification to be created using a combination of parameters from the J-INITIATE primitive and data supplied by the JTM service provider. As a result of processing this work specification at the local system, it can undergo some changes (for example, by the addition of "already checked" authorisation elements, or by the inclusion of documents obtained by J-GIVE).
Further processing can cause the semantics of the work specification to be passed to another open system, using the syntax of a JTM Transfer Element (the JTM PDU). Some semantic changes are made to the datastructure when it is transferred, notably the addition of information about where it came from.
A work specification contains a detailed specification of an OSI subjob, together with proformas. Proformas in a work specification are handled as "black boxes" until they are used for spawning or are the subject of manipulation. At the time of spawning they are "opened up", and work begins on the subjob they specify. When proformas spawn new subjobs, a new work specification is set up from them, with certain fields (the OSI job parameters) copied from the parent work specification.
The complexity of the work specification conceptual datastructure makes it difficult to work with for selection and modification. To aid this task, another (simpler) conceptual datastructure is defined. This is a simple list of the main fields of the work specification, without the structuring information. This simplified conceptual datastructure is called a header list, with one "header" for the subjob defined by the work specification, and one for each proforma (nesting ignored) that it contains. The headers for the proformas contain one field (not modifiable) which contains all proforma names leading to the proforma. From this, the nesting structure of proformas can be deduced.
This clause defines the fields of the work specification, the header list, and the transfer control record conceptual datastructure.
<work specification>::= <OSI job parameters> (see 3.4.2)
<subjob name-list> (see 3.3.2)
( <subjob specification> | NULL )
<proforma list>
<local fields>
<document list>
where
<subjob specification>::= <OSI subjob parameters> (see 3.4.3)
<JTM action parameters> (see 3.4.4)
<error action> (see 3.4.3.4)
<proforma list>::= [<proforma>]*L (see 3.4.5)
<local fields> ::= <agency activity parameters>
<time waiting = I>
<estimated size = I>
<document list>::= [<document = D>]*L
The <OSI job parameters> provide the identification and authorisation for the entire OSI job, and define the reporting which is required.
The <subjob name-list> identifies each of the subjobs of the complete OSI job. It is unambiguous within the scope of the OSI job. Following spawning from the initial subjob, many subjobs can be in existence (and being processed) concurrently.
The Value NULL only replaces a <subjob specification> when the <work specification> is held waiting for a J-END-SIGNAL from a sink or execution agency. A <work specification> is never transferred in this form.
The <OSI subjob parameters> define the open systems which are to do the work, the urgency of the subjob, a possible set of initial holds, and the type of the subjob.
The <JTM action parameters> depend on the type of the subjob, and define in detail the actions of the open systems which are to do the work.
The <error action> controls whether the work specification is held for modification or discarded when errors are detected during its processing or transfer.
The <proforma>s define the further work (if any) which is to be initiated following the processing of the <JTM action parameters>. This further work is defined by further <OSI subjob parameter>s and <JTM action parameters> in the proforma, together with the OSI job parameters for the entire OSI job. Each <proforma> contains an indication of when the subjob it defines is to be initiated and can contain further proformas. The range of activity which can be described by nested proformas is not bounded (nor is it necessarily finite), so that the definition of fields is necessarily recursive.
The <agency activity parameters> are present in the conceptual datastructure only when a sink or execution agency has an activity in progress in relation to it. They identify the activity in the agency for subsequent J-KILL, J-HOLD, J-RELEASE, or J-STATUS primitives. In the Basic Class, there is at most one agency activity associated with a work specification.
The form of <agency activity parameters> is not defined, as they have only local significance. They are used between a J-DISPOSE and a corresponding J-END-SIGNAL to identify activity in an agency associated with the work specification. They are supplied by the agency on a J-DISPOSE response, and used in all subsequent interactions concerning the activity. They do not appear in proformas.
The <time-waiting = I> contains the time in minutes since the work specification entered the state of waiting for processing by the JTM service provider. It can be waiting for transfer, or for the issue of J-GIVE or J-DISPOSE primitives. It is zero if the work specification is not waiting for the attention of the service provider, such as if it is in the hold state, or awaiting a J-END-SIGNAL.
The <estimated size> is zero unless the work specification is awaiting transfer to another open system, when it is the estimated size in kilo octets of the JTM Transfer Element (including any embedded documents) which would be used, using the Basic Encoding Rules for ASN.1 for the Transfer Element and the appropriate minimum implementation required transfer syntax for the embedded documents.
The <document>s (if any) form part or all of the material which is to be passed to sink agencies or to execution agencies during the performance of this OSI job. Each <document> is referred to from the <JTM action parameters> by its position in the list. Its <document type> is also recorded in the <JTM action parameters>.
<OSI job parameters>::= <OSI job submission system = N>
<initiating identification> (see 3.3.2)
<initiating time> (see 3.3.2)
<OSI job name = S> (see 3.3.2)
<OSI job local reference = S> (see 3.3.2)
<audit trace> (see below)
<primary monitoring specification> (see below)
<secondary monitoring specifications> (see below)
<authorisations> (see below)
<permissions> (see below)
<accounts> (see below)
<security parameters = R>
<CCR parameters> (see below)
The <OSI job submission system> is inserted by the JTM service provider (implementations of JTM are required to be configurable with this value). This open system name equals the first element in the audit trace once a successful transfer has occurred.
The <initiating identification> is provided by the JTM user and can be used in selecting a work specification by a later manipulation, and is present in displays and reports. The form of this identification is defined in 3.3.2. This identification is not subject to authentication.
The <initiating time> is inserted by the JTM service provider to identify the time of the submission.
The <OSI job name> is supplied by the JTM user to identify the job. The <OSI job local reference> is supplied by the JTM service provider, and is unambiguous within the scope of the <OSI job submission system>.
The <audit trace> is used to determine the source of a communication:
<audit trace>::= [<audit element>]*L
The <audit trace> is initially empty. Whenever the work specification is passed (using a transfer element) to another open system, an element is added to the end of the <audit trace> to identify the sender:
<audit element>::= <open system name = N>
( UNKNOWN | KNOWN | AUTHENTICATED )
A sender inserts his own open system name with the literal "UNKNOWN". If the receiver is able to verify this name by use of directory mechanisms and trust in lower layer calling addresses, UNKNOWN is changed to KNOWN. If positive authentication has been performed by the lower layers, then UNKNOWN is changed to AUTHENTICATED.
NOTES
- The OSI Security Architecture is still under development, but is likely to provide authentication services in the lower layers.
- The management of public networks normally provide some assurance of the correctness of calling addresses, sufficient for normal commercial work and category KNOWN. On local area networks, such assurance can be missing.
See 3.4.2.1 for the use made of the audit trace in establishing authorisation.
The <primary monitoring specification> is inserted by the JTM service provider. The <secondary monitoring specification>s (if any) are obtained from J-INITIATE.
<primary monitoring specification>::=
<monitoring specification>
<secondary monitoring specifications>::=
[<monitoring specification>]*L
<monitoring specification>::= <monitor specification> (see 3.4.2.3)
<report selector> (see 3.4.2.2)
The <monitor specification> identifies the monitor point, and (optionally) a sink, and (optionally) a relay. The report selector identifies the categories of report to be sent to this monitor point via the relay (if any). (See 3.4.2.2 and 3.4.2.3.)
The <authorisations>, <permissions>, and <accounts> are
<authorisations>::= [<authorisation element>]*C (see 3.4.2.1)
<permissions>::= [<permission element>]*C (see 3.4.2.1)
<accounts>::= [<account element>]*C (see 3.4.2.1)
These elements are supplied by J-INITIATE, but the JTM service provider can, from time to time, add additional elements derived from elements already present (see 3.4.2.1). In the Basic Class the <accounts> is empty.
The <security parameters> determines the use made by JTM of lower layer security mechanisms when transferring the work specification. It also determines the action taken by JTM on repeated denial of service. In the current standard it has only the value "NONE", meaning that no lower layer mechanisms are used to prevent disclosure or to detect tampering or to use only secure routes.
NOTE -- Following completion of work on the OSI Security Architecture, this clause is expected to be modified by an addendum.
The <CCR parameters> field is used when a work specification is, at the end of an atomic action, secured and retained by the JTM service provider. In the first atomic action of the OSI job, the CCR parameters on J-BEGIN are determined by the initiation agency. The value of the "diagnostic code indicator" parameters, used by the JTM service provider for subsequent atomic actions, are the same as the value on the J-INITIATE commitment group. The <CCR parameters> field records this value. (Note that it is never explicitly passed in a Transfer Element, being conveyed by C-BEGIN.)
<CCR parameters>::= <diagnostic code indicator = R>
The diagnostic code indicator controls the character set (and hence language) used in CCR (and hence in JTM) diagnostics. Non-standardised text messages (see 3.3.2) are also required to conform to the character sets specified in this parameter.
<authorisation element>::= <identification> (see 3.3.2)
<validation field>
<account element>::= <identification> (see 3.3.2)
<validation field>
<permission element>::= <identification> (see 3.3.2)
<validation field>::= ( <audit index = I> | <secret data> )
<secret data>::= ( UNSET | <graphic password = S> | <binary password = OS> )
Each <authorisation element> identifies either a user (using an <authority name> and one of the identifications it issued), or the management of an open system or identification authority (using the open system name or authority name).
An open system in general requires an authenticated identification known to it in order to authorise some activity. Such an identification is obtained by use of an authorisation element, possibly in conjunction with the audit trace.
An identification with <secret data> is authenticated (for use by a specific open system at a specific time) if the open system can access the necessary database to check the <secret data>, and if the check succeeds.
An identification with an <audit index = I> validation is authenticated if all <audit elements> from the point specified by the audit index to the end of the audit trace (inclusive) have a sufficient authentication (UNKNOWN, KNOWN, AUTHENTICATED) and are known to and trusted by the open system. This form of validation field is an assertion by the open system referenced by the audit index that the <identification> has been authenticated by it.
NOTE -- In the case of the results of processing returning to the OSI job submission system, the open system referenced by the audit index can be the same as the open system currently seeking an authenticated identifier.
The J-INITIATE primitive can only supply authorisation elements with validation fields containing <secret data>. The JTM service provider adds authorisation elements of the <audit index> variety as follows:
The <initiating identification> is the claimed identification of the initiator, supplied on J-INITIATE. A JTM implementation is not necessarily able to detect masquerade in this value, using local mechanisms. For reports of attempted security violations, the audit trace is also reported.
The <user> form of <identification> is the most common. The <authority> and <open system> forms are used to identify management activity (for the purposes of authorisation or accounting). The <authority> form of authorisation permits any JTM activity which would be allowed for any of the user identifications issued by that authority. The <open system> form of authorisation is needed to manipulate transfer control records, or to display or manipulate report work specifications. It also provides the right to manipulate any work specification which involves that open system.
The <account element> is used (in the same way as the <authorisation element>) to provide an authenticated account for levying charges. In the Basic Class subset, <account element>s are not present; account identifications, if required, are deduced from the identifications provided for authorisation.
Each <permission element> allows other work manipulation subjobs to make changes to the work specification containing the element, provided only that the manipulation subjob carries a validated <authorisation element> for the <identification> given in the <permission element>, or, in the case of a <user>, for its corresponding management.
<report selector>::= [<event identification>]*C
<event identification>::= ( NORMAL-TERMINATION | MANIPULATION-TERMINATION |
ABNORMAL-TERMINATION | USER-MESSAGE |
CREATION | TRANSFER | SPAWNING | AGENCY-ACCEPTANCE |
MODIFICATION | ERROR-DIAGNOSTIC | NO-PROGRESS |
ACCOUNTING-DATA | NOT-SUPPORTED-TERMINATION |
VIOLATION-ATTEMPT | WARNING-REPORT )
The <report selector> requires the JTM service provider to generate reports for all the categories of event specified in the collection. Reports are never generated on events related to the generation, transfer, processing or disposal of reports.
<monitor specification>::= [<relay=N>]*L (see 3.4.3)
<monitor system name = N>
<disposal instructions>
<disposal instructions>::= ( KEEP | <disposal data> )
<disposal data>::= <se identification> (see 3.4.4.1.1)
<document se reference> (see 3.4.4.1.2)
The subfields of the <disposal data> are identical to subfields of the <JTM action parameters> for document movement work specifications except that the <se identification> must reference a sink. The range of permitted values is defined in 3.4.4.1.
The <monitor system name> is the open system to which reports are to be delivered. If the <disposal instructions> are KEEP, the open system retains the reports (together with any relevant OSI job parameters) until it receives a suitably authorised report manipulation work specification requiring their display or deletion. If the <disposal data> is present, the report is passed to the specified sink agency using the J-DISPOSE primitive group with parameters derived from the <disposal data>.
NOTE -- An implementation can discard reports it is retaining after an implementation dependent time.
<OSI subjob parameters>::= <target list>
<urgency> (see 3.4.3.1)
<holds> (see 3.4.3.2)
<subjob type> (see 3.4.3.3)
<target list>::= <relays>
<target = N>
<relays>::= [<relay = N>]*L
The <target> is the open system which is to perform the JTM actions. The <relays> are open systems at which JTM relaying is to occur on the path to the target. A <relay> is removed from the head of this list by the sender during transfer of the work specification, so that the <relays> are empty on arrival at the target.
The <urgency> is used by open systems to assist with determining the order in which different OSI subjobs will be progressed.
The <holds> field is a collection of <hold element>s and specifies whether the conceptual data structure defining the subjob is to be progressed. An OSI job can progress to completion only if there are no <hold element>s preventing its progress. If a <hold element> prevents progress of an atomic action to the point needed for the specified level of commitment, the atomic action is rolled back by the JTM service provider with a NO-RETRY diagnostic. Subsequent manipulation can either remove <hold element>s or add <hold element>s to a work specification or to its proformas.
The <subjob type> defines the nature of the subjob, and the form of the <JTM action parameters>.
<urgency>::= ( HIGH | MEDIUM | LOW )
This field provides information from the originator of a work specification or proforma to open systems progressing the work. It can be used as one input to the scheduling of any activity needed to progress the OSI job. Its use is not standardised. In the absence of any other inputs to the scheduling process, a subjob with HIGH urgency is progressed before one with MEDIUM or LOW urgency (and MEDIUM before LOW).
<holds>::= [<hold element>]*C
<hold element>::= <hold location = N>
( <reason = S> |
<diagnostic information> ) (see 3.3.3)
<release permission>
<release time>
<release permission>::= ( <identification> | NULL) (see 3.3.2)
<release time>::= ( <date-time = S> | (see 3.3.2)
<time of day = S> | <time interval = I> )
A <hold element> is ignored by an open system unless the <hold location> is the name of that open system. If the <hold location> in one or more <hold elements> matches the name of the open system, then a work specification will not be processed by the open system (to transfer it, issue service primitives, or spawn from it). It can be transferred to the <hold location>, or created there by spawning or by J-INITIATE.
A <hold element> is either present initially (set by J-INITIATE), or added later by a work manipulation, or automatically inserted if processing is suspended due to errors (see 2.1.6.2 and 3.4.3.4).
If the <hold element> was inserted by the JTM service provider as a result of detecting an error in it, the <diagnostic information> carries details of the error, there is no <reason>, and the <hold location> is the name of the open system inserting the <hold element>.
If the <hold element> was inserted by a manipulation, the <reason> contains human readable text.
The release permission is NULL if the element was inserted by the JTM service provider, otherwise it can contain an <identification> which requires that a manipulation subjob wishing to release the hold has to contain an authorisation element with the same authenticated identification (in addition to satisfying the <permissions> field). If the <release permission> is NULL, the <permissions> in the OSI job parameters control release of the hold.
The <release time> specifies the time at which the JTM service provider automatically removes the hold element. (Note that this causes a MODIFICATION event to occur.) An implementation can place a limit on the length of time that it is prepared to maintain a hold state for a work specification. The <date-time> specifies that the hold element is to be removed at that absolute time. The <time of day> is of the form hhmm and specifies that the hold element is to be removed when that local time first occurs following spawning of the subjob from a proforma or arrival at that open system. The <time interval> is converted to a <date-time> when it is at the <hold location> in a top-level subjob i.e. when the work specification arrives at the <hold location>, or the proforma containing the hold element is spawned, or when a work manipulation adds the hold element to the top-level subjob. The <time interval> specifies the removal of the hold element when <time interval> minutes have passed from the conversion of the <time interval> to <date-time>.
<subjob type>::= ( DOCUMENT-MOVEMENT | WORK-MANIPULATION | REPORT-MOVEMENT |
TCR-MANIPULATION | REPORT-MANIPULATION )
The value of this field in the <subjob parameters> of J-INITIATE is fixed (for each J-INITIATE primitive) to the value corresponding to the name of the service primitive. It determines the form of the <JTM action parameters>. The value of this parameter in a proforma is not restricted by the J-INITIATE primitive used to specify the OSI job, but can not take the value REPORT-MOVEMENT.
<error action>::= ( HOLD <time interval =I> | TERMINATE )
The <error action> controls the action of the JTM service provider at an open system when acting as a commitment master for processing a work specification. The action is described below.
The master is initiating one or more branches of the atomic action for
One or more of these branches can produce rollback from a subordinate with a CCR diagnostic. The subsequent action by the master is determined by the <error action>.
NOTE -- Rollback of a J-GIVE by a source agency might or might not produce an error from that branch of the atomic action, depending on the setting of the <embed diagnostics> parameter in the <document source reference> (see 3.4.4.1.3).
A value of HOLD <time interval> causes the JTM service provider (when an error occurs) to
A value of TERMINATE causes the JTM service provider to
<JTM action parameters>::= ( <document movement operations> | (see 3.4.4.1)
<work manipulation operations> | (see 3.4.4.2)
<transfer manipulation operations> | (see 3.4.4.3)
<report manipulation operations> | (see 3.4.4.4)
<report movement operation> ) (see 3.4.4.5)
If the <subjob type> is DOCUMENT-MOVEMENT, this parameter consists of <document movement operations>.
If the <subjob type> is WORK-MANIPULATION, this parameter consists of <work manipulation operations>.
If the <subjob type> is TCR-MANIPULATION, this parameter consists of <transfer manipulation operations>.
If the <subjob type> is REPORT-MANIPULATION, this parameter consists of <report manipulation operations>.
If the <subjob type> is REPORT-MOVEMENT, this parameter consists of <report movement operations>.
<document movement operations>::=
[<document movement>]*L
<document movement>::= <document type = ND>
<se agencies>
<document block>
<se agencies>::= [<se identification>]*L (see 3.4.4.1.1)
NOTES
- All <se identifications> in the list are <JTM se>, or all are <FTAM se>. Mixed disposal in one document block is not supported.
- Where the <multiple form> is used, the <se identifications> are the <JTM se> form.
<document block>::= ( <single form> | (see 3.4.4.1.2)
<multiple form> ) (see 3.4.4.1.4)
Each <se identification> identifies a sink or execution agency.
Each <single form> generates (by use of one or more J-GIVE primitives) a single document (possibly with embedded diagnostics – see 3.4.4.1.3) for disposal by the target, possibly as the result of concatenating several documents obtained from source agencies. Each <multiple form> generates zero, one or more documents for disposal, each in a separate <single form> <document block>. All documents moved by a single <document movement> are of the same document type. Thus a single <document movement> provides for either
The processing by the target of each <document movement> takes all of the documents described by the <document block> and passes each of them to all of the <se agencies>, with separate J-DISPOSE primitive groups for each document.
Where a document (for disposal) is formed by the concatenation of documents from sources, each document has the same document type, and the result of the concatention is required to be a document of the same type.
The <document movement>s are processed by the target in order, all J-DISPOSE indications for one being given before any J-DISPOSE indication for the next. The order of J-DISPOSE indications in the processing of a single <document movement> is not defined. The results of a document movement become visible to other atomic actions only after commitment. They become visible to other parts of the same atomic action at the time of the J-DISPOSE indication.
<se identification>::= ( <JTM se> | <FTAM sink> )
<JTM se>::= <se name = S>
<additional authorisations>
<agency parameter>
<agency activity label = S>
<se prefix>
<FTAM sink>::= <filestore-name = N>
<agency parameter>::= ( NULL | STORE | <agency format = S> )
<se prefix>::= [<name = S>]*L
<additional authorisations> ::= ( NULL | <password = S> )
( NULL | <account element> ) (see 3.4.2.1)
( NULL | <authorisation element> ) (see 3.4.2.1)
There are two forms of <se identification>. The first, <JTM se>, is used for both sinks and execution agencies which dispose of the document either locally, or remotely in a way which is not standardised. The second, <FTAM sink>, is used to identify a local sink agency which disposes of a document (locally or remotely) using ISO 8571-3.
The <JTM se> identifies a sink or execution agency at the target site whose name is given by <se name>. <se name> is a string defined by the target open system to unambiguously identify a sink or execution agency (within that open system) to which a J-DISPOSE is to be issued for disposal of a document.
The <additional authorisations> provide an optional additional password, authorisation element, and account element for this access to this sink or execution agency.
The <agency parameter> is passed in J-DISPOSE, and is used (together with the <document type>) by the sink or execution agency to determine the way in which the document is to be presented, stored or interpreted. If the parameter value STORE is supported by a combined sink and source agency, it stores the document in such a way that any subsequent J-GIVE quoting the same <document type> and <agency parameter> together with an appropriate <document source reference> generates the identical document.
NOTE -- The value STORE is not applicable to an execution agency.
If the parameter specifies NULL, the document is stored or presented in a way determined locally. If the parameter specifies an <agency format>, the sink or execution agency uses this to determine the way the material is to be stored, presented or interpreted. The possible values of the <agency format> string are not standardised, and are determined by the agency.
The <agency activity label> allows an unambiguous association to be defined between a J-DISPOSE to an execution agency and a later J-GIVE (from a spawned proforma) to that agency. It is only needed when more than one activity is initiated in an agency by a single work-specification.
The <se prefix> names are placed at the head of the list of <document se reference> names (see below) for each document when forming the parameters passed in the J-DISPOSE primitive. This parameter enables the initial part of a <name-list> in a J-DISPOSE to be different for each of the sink or execution agencies in a <document movement>.
The <filestore-name> in the <FTAM sink> form identifies the (local or remote) FTAM virtual filestore to receive the document. All other information for the disposal is contained in the <document se reference> (see 3.4.4.1.2).
<single form>::= <document se reference>
[<document pointer>]*L
<document se reference>::= ( <JTM write-data> | <FTAM write-data> )
<JTM write-data>::= <se access parameter>
<name-list>
<FTAM write-data>::= <"write transfer specification" as defined in annex D of ISO 8571-3>
NOTE -- The <FTAM write-data> form is used if and only if the corresponding <se identification>s have the <FTAM sink> form.
<se access parameter>::= ( NORMAL | NEW | OLD | APPEND | ADD )
<name-list>::= [<name = S>]*L
<document pointer>::= ( EMBEDDED |
<single document reference> ) (see 3.4.4.1.3)
This form of <document block> specifies that the documents referred to in the <document pointer>s are to be concatenated (in order of the reference in the document block) to form a single document for disposal by J-DISPOSE.
The <se access parameter> specifies the required action of the agency in relation to any existing material of the same name in the sink or execution agency to which they are passed.
NOTE -- This parameter is ignored by an execution agency.
It is passed as a field of a parameter of J-DISPOSE. The meaning of the literals is as follows:
| NORMAL | overwrite any old documents with the same name, or create a new document at the sink; |
| NEW | create a new document at the sink if possible, but if an old document exists with the same name, rollback with a diagnostic; |
| OLD | overwrite an old document of the same name, but if an old document does not exist, rollback with a diagnostic; |
| APPEND | add to the end of any old document, but if an old document does not exist, rollback with a diagnostic; |
| ADD | add to the end of any old document, and if an old document does not exist, create a new one; |
The <name-list> has the <se prefix> (see 3.4.4.1.1) added at its head, and then forms the <name-list> passed in the J-DISPOSE to the sink or execution agency to identify the document.
The EMBEDDED literal references a document in the <document list>. The number of documents in the <document list> equals the total number of occurrences of EMBEDDED in the work specification (including proformas). The correspondence is by position in the <document list> and in the transfer syntax of the work specification.
Where <FTAM write-data> is provided, the sink agency uses the ISO 8571-3(FTAM) services to dispose of the document to a local or remote virtual filestore, as defined in ISO 8571-3.
The <single document reference> requires the inclusion of a document to be obtained by a J-GIVE primitive or by use of FTAM. This is processed by the JTM service provider into an EMBEDDED form, or an error diagnostic is included.
<single document reference>::= <action open system = N>
<source identification>
<document source reference>
<embedded diagnostics>
<state>
<source identification>::= ( PROVIDER | <JTM source> | <FTAM source> )
<JTM source>::= <source name = S>
<additional authorisations>
<agency parameter> (see 3.4.4.1.1)
<FTAM source>::= <filestore-name = N>
<document source reference>::= ( <JTM read-data> | <FTAM read-data> )
<JTM read-data>::= <source access parameter>
<name-list>
<FTAM read-data>::= <"Read transfer specification" as defined in annex D of ISO 8571-3>
NOTE -- The <FTAM read-data> form is used if and only if the <source identification> has the <FTAM source> form.
<source access parameter>::= ( MOVE | COPY )
<embedded diagnostics>::= ( EMBED | ERROR )
<state>::= ( NOT ATTEMPTED | FAILED <error information> )
<error information>::= <time stamp> (see 3.3.2)
<CCR diagnostics> (see 3.3.3)
The <action open system> specifies the name of the open system which is to issue the J-GIVE indication (which can include use of FTAM to obtain the document). The <action open system> is either the open system creating the work specification (by spawning or as a result of J-INITIATE), the target, or one of the relays.
The <source identification> is PROVIDER only when the reference occurs in a proforma which is spawned as a result of a work manipulation, transfer manipulation, or report manipulation. It is used to reference the documents produced by the service provider as the result of a display command.
The <source identification> has the <JTM source> form for sources which obtain a document locally or by non-standard remote access. The <FTAM source> form identifies a local source agency which obtains a document (locally or remotely) using ISO 8571-3.
The <source name> is a string defined by the <action open system> to unambiguously identify a source agency (within that open system) to which a J-GIVE is to be issued to obtain a document.
The <agency parameter> is used to determine how the document was stored. If this field is inconsistent with any directory information held by the source agency, an error diagnostic results. (See also 3.4.4.1.1.)
The <additional authorisations> perform the same function as they do for access to sink or execution agencies.
The <source access parameter> is passed as one of the fields in the J-GIVE primitive; if it is COPY, the source agency is not affected by the activity. If it is MOVE, the document is marked for deletion from the source on commitment, and left unchanged on rollback. If concurrent activities (part of the same atomic action) are accessing this source, it is deleted (if any of them have committed to move) following commitment or rollback by all of them.
The <name-list> is passed on a J-GIVE, and identifies the document which is referenced. It identifies precisely one document; if it does not, the agency to which the J-GIVE was issued rollsback with a diagnostic.
The <filestore-name> in the <FTAM source> form identifies the (local or remote) FTAM virtual filestore which is to provide the document. All other information needed to obtain the document is provided by the <FTAM read-data>.
Note that in resolving a single document reference using J-GIVE, the <document type> of the <document movement> is also supplied.
The <embedded diagnostics> specifies the action to be taken by the <action open system> if J-GIVE is rolled back by the agency with a diagnostic or the <source identification> is PROVIDER and the referenced document is not available.
A value EMBED requires the <state> to be changed from its initial value of NOT ATTEMPTED to FAILED. The <time stamp> records the time of the unsuccessful J-GIVE, and the J-ROLLBACK diagnostic is placed in the <CCR diagnostics> field. Processing of the document reference proceeds to an offer of commitment — the rollback from the agency is not visible to the master. If the main action proceeds to commitment, the change to <state> commits. If it is rolled back (for other reasons) the change to <state> is rolled back. This action generates the DIAGNOSTICS event, which can be selected for reporting.
A value of ERROR leaves the <state> as NOT ATTEMPTED, and propagates the rollback and diagnostic up the atomic action tree to the master. Subsequent action is determined by the value of the <error action> field for the whole subjob. (See 3.4.3.4.)
<multiple form>::= <action open system = N>
<document se skeleton>
<embedded diagnostics>
<JTM source> (see 3.4.4.1.3)
<additional authorisations>
<document source skeleton>
<document selector>
<document selector>::= ( NULL | <local string = S> )
<document se skeleton>::= <se access parameter> (see 3.4.4.1.2)
<partial name-list>
<document source skeleton>::= <source access parameter> (see 3.4.4.1.3)
<partial name-list>
<partial name-list>::= [<name =S>]*L
The fields <action open system>, <JTM source>, <additional authorisations>, <embedded diagnostics>, <se access parameter>, and <source access parameter>, are defined in 3.4.4.1.2 and 3.4.4.1.3.
The multiple form document block is used to generate one or more single form document blocks, each containing an EMBEDEDDED <document pointer>.
The <document se reference> for the <single form>s are constructed from the fields of the <document se skeleton> by adding names (suffices) to the end of the <partial name-list>.
The documents are obtained by the <action open system> from the source agency specified by the <source identification>. They are all of the same <document type> specified for the <document movement>. The <document source reference> for the J-GIVE to obtain each document is constructed from the fields of the <document source skeleton> by adding names (suffices) to the end of the <partial name-list>. The suffices are supplied by J-ENQUIRE.
The multiple form document block is processed by the <action open system> by first issuing J-ENQUIRE to the source agency, passing the <document type>, <document source skeleton>, and <document selector>. This returns a list of suffices (name-lists), one for each document which is to be accessed. Each of these suffices (name-lists) is added to the <partial name-list> in the <document se skeleton> and <document source skeleton> as defined above. The set of suffices (name-lists) returned by J-ENQUIRE is the maximal set for which the resulting J-GIVEs can produce documents, subject to the use of the <document selector> and <document type>. The semantics of the <local string> are not standardised. The value NULL for the <document selector> means maximum selection.
NOTE -- FTAM does not currently provide the facilities needed for J-ENQUIRE, so <multiple form> document blocks are restricted to local access.
The source agency can use any or all of the following information to determine which documents are being selected:
Resolution of this reference is of particular use when collecting documents following processing by an execution agency, where the names and number of the documents might not be known in advance, and can depend on the degree of success of the processing, or on whether it is interrupted by a STOP manipulation.
<work manipulation operations>::=
[<work operation>]*L
<work operation>::= ( <select operation> | <kill operation> | <stop operation> |
<work display operation> | <modify operation> )
<select operation>::= SELECT <selector> (see 3.4.4.2.1)
<kill operation>::= KILL
<stop operation>::= STOP
<work display operation>::= DISPLAY <doc name = S>
( FULL | BRIEF )
<modify operation>::= MODIFY <update> (see 3.4.4.2.4)
The work manipulation operations cause the target open system to display or modify the definition of a work specification for which it is responsible.
The KILL, STOP and MODIFY operations can cause the JTM service provider to issue J-KILL, J-STOP, J-HOLD or J-RELEASE indications to associated agencies, and the DISPLAY operation causes a J-STATUS indication to associated agencies.
The SELECT operation selects zero, one or more work specifications or proformas for subsequent operations. It does this by testing the value of fields in the work specification, using JTM literals to specify the fields being tested. The selected work specifications or proformas are used by subsequent operations (KILL, STOP, MODIFY and DISPLAY). The selection is effective until the next SELECT operation is issued.
The KILL operation causes MANIPULATION-TERMINATION of subjobs, and prevents spawning at the end of the killed activity. It will produce a J-KILL or J-ROLLBACK to any associated agency, and rollback of any transfer activity, and discard of the associated work specification.
The STOP operation also produces a J-STOP or J-ROLLBACK indication to associated agencies, but does not prevent spawning at the end of the activity, nor cause termination of the work specification. The STOP operation causes rollback of any transfer activity, which will be reattemped. Use of STOP is signalled in any MODIFICATION report which is generated.
The MODIFY operation causes changes to be made to the specification of the selected work specification(s) or proforma(s). The <update> causes changes to specified fields; if the <holds> changes, this can result in a J-HOLD or J-RELEASE indication. Changes to the hold-state are signalled in any MODIFICATION report which is generated.
The DISPLAY operation causes a copy of data from the selected work specification(s) or proforma(s), together with information from J-STATUS, to be produced as part of a <work display document> with name <doc name>. A <work display document> is defined in 3.5.2.
A work specification can only be modified by a work manipulation subjob if the subjob contains an <authorisation element> for an authenticated <identification> which is allowed to modify the work specification.
The following authenticated <identification>s are allowed to modify a work specification:
In addition, the removal of a <hold element> or <permission element> can only be performed by a validated <identification> equal to that appearing in the <hold element> (if any) or the <permission element>, or related to it as in b) above. If the <hold element> does not contain a <release permission> this additional restriction does not apply.
Following a DISPLAY <docname> operation, a document of type <work display document> is available for collection by reference to a <source identification> of PROVIDER and a <name-list> containing only <docname>. Two display operations with the same <docname> produce both work displays in the same document. The display can be a full display or a brief display, as defined in 3.5.2.
<selector>::= <selector form>
<header test>
<selector form>::= ( CONTAINS-HEADER | DOES-NOT-CONTAIN-HEADER |
FIRST-HEADER-IS | HEADER-IS )
<header test>::= ( <field test> |
<NOT clause> | <AND clause> | <OR clause> |
SUCCESS | FAIL )
<NOT clause>::= NOT <header test>
<AND clause>::= AND <header test><header test>
<OR clause>::= OR <header test><header test>
<field test>::= <field name>
<selection operator>
<selection value>
A <selector> comprises a series of tests applied to a conceptual data structure called the header list which contains fields corresponding to the work specification and its proformas.
The fields of this data structure are defined in 3.4.6.
The header list consists of one or more headers. Each header comprises fields which are global to the whole OSI job together with fields which are specific to an OSI subjob as specified by the work specification or by one of its proformas (at any level of nesting) (see 3.4.6).
A <field test> is applied to a named field in a <header> and produces a value of SUCCESS or FAIL. The values of the <field test>s are combined by AND, OR, and NOT operators to produce a SUCCESS or FAIL value for the <header test>.
A proforma is selected by the form HEADER-IS if and only if the <header test> produces SUCCESS when applied to the header corresponding to the proforma.
The form CONTAINS-HEADER selects work specifications which contain at least one proforma (at any depth) corresponding to a <header> for which the <header test> succeeds. The form DOES-NOT-CONTAIN-HEADER selects work specifications for which the <header test> fails on all <header>s corresponding to proformas in it. The form FIRST-HEADER-IS selects work specifications for which the <header test> succeeds on the header corresponding to the work specification itself.
NOTE -- HEADER-IS selects (identifies) a work specification or proforma. In the latter case, it also implicitly identifies the work specification containing the proforma when used in a <transfer control record>. CONTAINS-HEADER, DOES-NOT-CONTAIN-HEADER and FIRST-HEADER-IS always select a complete work specification.
<selection operator>::= ( EQUALS |
LIST-CONTAINS | FIRST-OF-LIST-IS | LAST-OF-LIST-IS |
GT | GE | LT | LE )
The <selection operator>s of GT, GE, LT and LE are only used with fields which are integer items (TOTAL-SIZE and TIME-WAITING). (See 3.4.6.)
The <selection operator> EQUALS can be applied to any type of field. The test succeeds if and only if the <selection value> is equal in type and value to the field (but see 3.4.4.2.3).
The other three <selection operator>s are applied to lists; LIST-CONTAINS can also be applied to collections. The test succeeds if and only if the <selector value> is the same type as an element of the <header> field, and matches any element, the first element, or the last element of the list respectively.
Subclause 3.4.6 defines the operators which can be applied to each field of a header.
The <selection value> field is of the same type as the <header> field corresponding to the <field name> except for the "list" operators, when its type is the same as an element of the <header> field list or collection.
For every syntactic item (basic or structured datatype) in the <header> field, the literal ANY-ITEM can be used in the <selection value> instead of a syntactic item of the appropriate type. This matches any syntactic item of any type.
<update>::= <field name>
<update operator>
<update value>
This updates a single field of the selected proforma or work specification according to the <update operator> and <update value>. If a complete work specification was selected, the <update> applies to the work specification itself, corresponding to the first <header> in the <header list>.
<update operator>::= ( SET-TO | REMOVE | ADD )
REMOVE and ADD are only applied to collections. SET-TO can be applied to any type of field. The operators applicable to each field of <header> are given in 3.4.6.
This is the same type as the <header> field corresponding to <field-name> except for the operators REMOVE and ADD, when it is the same type as an element of the header field. If an element is added to a collection which already contains an element equal to that value, the collection is unchanged.
<field name>::= ( OSI-JOB-SUBMISSION-SYSTEM | OSI-JOB-NAME | SUB-JOB-TYPE |
INITIATOR | OSI-JOB-LOCAL-REFERENCE |
PRIMARY-MONITOR | SECONDARY-MONITORS |
SECURITY-PARMS | AUTHORISATION-SET | ACCOUNT-SET | PERMISSION-SET |
SUBJOB-NAME-LIST | RELAYS | TARGET |
SE-LISTS | SE-REF-LISTS | SOURCE-LISTS | SOURCE-REF-LISTS |
URGENCY | HOLDS | ERROR-ACTION |
TIME-WAITING | TOTAL-SIZE )
The type of each header field corresponding to these field-names, the meaning of its contents, and the permissible operations is given in 3.4.6.
<transfer manipulation operation>::=
( <set operation> | <check operation> | <transfer display operation> )
<set operation>::= SET
<set by = N>
<recipient = N>
<control specification> (see 3.4.7)
<check operation>::= CHECK
<checking by = N> (see 3.4.2.1)
<recipient = N>
<control specification> (see 3.4.7)
<transfer display operation>::= DISPLAY
( <destination> | ALL )
<docname = S>
The SET operation sets a <transfer control record> (see 3.4.7) to the values specified. It is normally invoked by the management of a site which knows that it is the frequent recipient of work specifications from some site, and wishes to control such transfers. It does this by setting a transfer control record at the sending site. The manipulation work specification must have an authority for the <identification> of the open system specified in the <recipient> field and for the <identification> of the open system in the <set by> field. The <set by> field is used only to determine the open system to which a subsequent CHECK should be sent. The <set by> field is the name of the open system whose management has determined that a particular transfer path is be controlled. It will normally be identical to the <recipient> field, but can be distinct. The <recipient> is the name of the open system to which transfers are to be controlled. This operation establishes the <control specification> to control transfers to the <recipient>.
The CHECK operation provides data (a <recipient> and <control specification>) in use at the <checking by> open system, and requires the open system to which the CHECK operation is sent to create a transfer control manipulation work specification if the value of the data is no longer appropriate. It guards against the indefinite use of inappropriate transfer control records.
NOTE -- It is recommended that open systems should send a CHECK manipulation to the <set by> open system if they have been disconnected from the open systems environment for some time.
The CHECK operation requires an authority for the <identification> of the <checking by> open system.
The transfer DISPLAY operation produces a <transfer display document> (see 3.5.3) containing a copy of the <control specification> and the <set by> for the specified <recipient>. The use of ALL displays the transfer control records for all <recipients> which are not UNCONTROLLED (see 3.4.7).
<report manipulation operations>::=
( <delete operation> | <JTM-report-display operation> )
<delete operation>::= DELETE <report selection>
<JTM-report-display operation>::=
DISPLAY <report selection>
<docname = S>
<report selection>::= <submission constraint>
<initiator constraint>
<reference constraint>
<jobname constraint>
<subjob constraint>
<type constraint>
<event constraint>
<initiating-time constraint>
<submission constraint>::= ( NULL | <OSI job submission system> ) (see 3.4.4.2.7)
<initiator constraint>::= ( NULL | <initiating identification> ) (see 3.4.2.1)
<reference constraint>::= ( NULL | <OSI job local reference = S> ) (see 3.4.6)
<jobname constraint>::= ( NULL | <OSI job name = S> ) (see 3.4.2)
<subjob constraint>::= ( NULL | <subjob name-list> ) (see 3.4.3)
<type constraint>::= ( NULL | <subjob type> ) (see 3.4.3.3)
<event constraint>::= ( NULL | <report selector> ) (see 3.4.2.2)
<initiating-time constraint>::= ( NULL | <time bounds> )
<time bounds>::= <starting time>
<finishing time>
<starting time>::= ( NULL | <date-time=S> )
<finishing time>::= ( NULL | <date-time=S> )
The <report selection> identifies all reports from subjobs (or spawned subjobs) which have the given
The DELETE operation deletes these reports, the DISPLAY operation displays them as a JTM-report-display document (see 3.5.1). The DELETE operation requires an authority for an <identification> matching a <permission element> which appeared in the work specification being reported on. The type of a JTM-report-display document is given in 3.5.1.
A report in which the <initiating time> is NULL is included by an <initiating-time constraint> only if at least one of the <starting time> and the <finishing time> is NULL.
<report movement operations>::=
[<report operation>]*C
<report operation>::= [<monitor index = I>]*C
<report> (see 3.3.2)
Each <report operation> causes a single report to be processed (on arrival at the target) as specified by the monitor specification identified by the monitor index. A value of zero identifies the primary monitor, and one, two, and so on identifies the successive secondary monitors in the secondary monitoring list of the work specification.
<proforma>::= <proforma name = S>
<spawning control data> (see 3.4.5.2)
[<demand spawning handle>]*C
( <proforma reference> | (see 3.4.5.1)
<proforma specification> )
<number spawned = I>
<proforma specification> ::= <subjob specification> (see 3.4.1)
<proforma list> (see 3.4.1)
In Basic Class, the contents of a <proforma list> in a <proforma specification> are wholly transparent, and are not restricted by Basic Class restrictions.
The fields of a <proforma> are the same as the top-level fields defined in 3.4.1. They define the parameters for the subjob which is to be created when the proforma is spawned.
The <proforma name> identifies the <proforma> uniquely within a containing <proforma list>. A <proforma> containing a <proforma list> is called the parent of that <proforma list>. A <proforma> which is not contained in any other <proforma> is called a top-level proforma.
The <number spawned> contains the count of work specifications spawned from this proforma. As spawning only occurs at the target, this is implicitly zero during transfer. It is used in forming the <subjob name-list> when spawning a new work specification from the proforma.
The <demand spawning handle> strings specify whether the proforma is to be spawned by a J-SPAWN service primitive group. The proforma is spawned if the <demand spawn handle> parameter of the J-SPAWN request primitive is equal to one of the strings in the collection of <demand spawning handle> of the proforma. If the collection of <demand spawning handle> is empty or absent, the proforma cannot be demand-spawned.
<proforma reference>::= <proforma name = S> (see 3.4.5)
This field is used to reference the <subjob specification> in the named <proforma>. The named <proforma> is required to be in the same <proforma list> as the parent of the referencing <proforma>; it can be the parent. When spawning occurs, top-level proformas in the new work specification have the <proforma reference> replaced by the <subjob specification> in the named <proforma>. (Note that this can include the proforma containing the <proforma reference>.)
<spawning control data>::= ( DEMAND-ONLY | ACCEPTANCE | COMPLETION | CONDITIONAL )
This field specifies when spawning is to take place from the <proforma>.
If it specifies DEMAND-ONLY, spawning only occurs on the issue of a J-SPAWN service primitive group from activity in an execution agency produced by the parent subjob.
If it specifies ACCEPTANCE, spawning occurs when all the sink or execution agencies of the parent subjob have given either ACCEPTANCE or COMPLETION commitment.
If it specifies COMPLETION, the subjob is created only when all the sink or execution agencies of the parent subjob have either given COMPLETION commitment, or have made a J-END-SIGNAL request.
If it specifies CONDITIONAL, the subjob is created as for COMPLETION, but only if the source reference resolution following spawning collects at least one document from an execution or source agency at that open system.
NOTE -- This facility is provided to support the case where processing might produce several outputs for different destinations but might also produce a lesser number. The use of CONDITIONAL ensures that proformas are only spawned for those destinations for which output has actually been produced.
All types of spawning can occur either as part of the initial atomic action, or as part of a later atomic action.
The commitment level for demand spawning is specified in the J-SPAWN request. For all other spawning, PROVIDER-ACCEPTANCE level is used if the spawning is not part of the initial atomic action.
When several <proforma>s are to be spawned as the result of a single event (e.g. a J-END-SIGNAL request), they are spawned in the order of their appearance in the <proforma list>.
Any J-GIVE primitives to be issued at the local site to the agency producing spawning proceed to an offer of commitment before the next proforma is spawned. (This ensures that MOVE access by some proformas to collect named documents, and CONDITIONAL spawning of a later proforma to collect all remaining documents, proceeds correctly.)
<header list>::= [<header>]*L
<header>::= <OSI job submission system = N>
<initiating identification> (see 3.3.2)
<OSI job name = S> (see 3.3.2)
<OSI job local reference = S> (see 3.3.2)
<audit trace> (see 3.4.2)
<primary monitoring specification> (see 3.4.2)
<secondary monitoring specifications> (see 3.4.2)
<authorisations> (see 3.4.2)
<permissions> (see 3.4.2)
<accounts> (see 3.4.2)
<security parameters = R> (see 3.4.2)
<subjob name-list> (see 3.4.3)
<relays> (see 3.4.3)
<target = N> (see 3.4.3)
<urgency> (see 3.4.3.1)
<holds> (see 3.4.3.2)
<subjob type> (see 3.4.3.3)
<se lists>
<se-ref lists>
<source-lists>
<source-ref lists>
<error action> (see 3.4.3.4)
<time waiting = I> (see 3.4.1)
<estimated size = I> (see 3.4.1)
<se lists>::= [<se identification>]*L (see 3.4.4.1.1)
<se-ref lists>::= [<document se reference>]*L
(see 3.4.4.1.2)
<source-lists>::= [<source identification>]*L
(see 3.4.4.1.3)
<source-ref lists>::= [<document source reference>]*L
(see 3.4.4.1.3)
These fields correspond to fields in a work specification or proforma. Changing the fields in <header list> changes the corresponding work specification or proforma.
The first <header> contains fields corresponding to the <OSI job parameters> and the <subjob specification> in the work specification itself. Subsequent headers contain fields corresponding to the <OSI job parameters> and to the <subjob specification> of a proforma, with one header for each proforma (at any depth).
NOTE -- The order of subsequent headers is not specified, and does not affect the results of any operation.
The <password> in a <document se reference>, and the <secret data> in the <validation field> in an <authorisation element> or <account element> always appear as the item NULL in a <header>.
The semantics of the fields of <header> and the operations on them are defined below. Those marked with an * have the same value in all the <header>s of a particular <header list>, that is, they relate to the whole OSI job. These fields can be modified by selecting any of the headers in the header list, the changed values appearing in all headers.
| *<OSI job submission system> | This is defined in 3.3.2. Only EQUALS can be applied. |
| *<initiating identifications> | This is defined in 3.3.2. Only EQUALS can be applied. |
| *<OSI job name> | This is defined in 3.3.2. Only EQUALS can be applied. |
| *<OSI job local reference> | This is defined in 3.3.2. Only EQUALS can be applied. |
| *<audit trace> | This field is defined in 3.4.2. Operations are EQUALS, LIST-CONTAINS, FIRST-OF-LIST-IS, LAST-OF-LIST-IS. |
| *<primary monitoring specification> | This is defined in 3.4.2. Operations are EQUALS and SET-TO. SET-TO requires an authorisation for the <identification> of the OSI job submission system. |
| *<secondary monitoring specifications> | These are defined in 3.4.2. Operations are EQUALS, LIST-CONTAINS, SET-TO, REMOVE, and ADD. In the case of report work specifications, the only permitted operations are EQUALS and LIST-CONTAINS. |
| *<authorisations> | This is defined in 3.4.2. (Note that <secret data> in the <validation field>s all appear as NULL in <header>s.) Operations are EQUALS, LIST-CONTAINS and ADD. (A <validation> containing a checked index can not appear in an ADD operation.) |
| *<permissions> | This is defined in 3.4.2. Operations are EQUALS, LIST-CONTAINS, ADD and REMOVE. REMOVE requires an authorisation for the identity being removed. |
| *<accounts> | This is defined in 3.4.2. (Note that <secret data> in the <validation field>s all appear as NULL in <header>s.) Operations are EQUALS, LIST-CONTAINS and ADD. (A <validation> containing a checked index can not appear in an ADD operation.) |
| *<security parameters> | This is defined in 3.4.2. Only EQUALS can be applied. |
| <subjob name-list> | This list is defined in 3.4.3 for the first header. In the header for a proforma, this field has a series of subjob name components, one for each proforma name used to reach it. The first component is a J-INITIATE request top-level proforma name, the last is the name of this proforma. The value of the <qualifying integer> is zero if the subjob specification is still in the form of a proforma. Only EQUALS, and FIRST-OF-LIST-IS can be applied. |
| <relays> | This field is defined in 3.4.3. Operations are EQUALS, LIST-CONTAINS, FIRST-OF-LIST-IS, LAST-OF-LIST-IS, SET-TO. |
| <target> | This is defined in 3.4.3. Operations are EQUALS and SET-TO. |
| <urgency> | This is defined in 3.4.3.1. Operations are EQUALS, SET-TO. SET-TO requires an authenticated <identification> equal to the OSI job submission system. |
| <holds> | This is defined in 3.4.3.2. Operations are EQUALS, LIST-CONTAINS, SET-TO, REMOVE, ADD. REMOVE requires an authority for the <identification> appearing in the <hold element>, or for its <authority>, or for an <open system> named in one of the <target>s or <relays>. |
| <subjob type> | This is defined in 3.4.3.3. The only operation is EQUALS. |
| <se lists> | This list contains all the <se identification>s appearing in the subjob specification, in the order of their appearance. Any change is required to retain the same number of <se identification>s. Operations are EQUALS, LIST-CONTAINS, SET-TO. |
| <se-ref lists> | This list contains all the <document se reference>s appearing in the <document block>s in the subjob specification, in the order of their appearance. Any change is required to retain the same number of <document se reference>s. Note that the <password> field always appears as NULL. Operations are EQUALS, LIST-CONTAINS, SET-TO. |
| <source lists> | This list contains all the <source identification>s appearing in the subjob specification, in the order of their appearance. Any change is required to retain the same number of <source identification>s. Operations are EQUALS, LIST-CONTAINS, SET-TO. |
| <source-ref lists> | This list contains all the <document source reference>s and <document source skeleton>s appearing in the <document block>s in the subjob specification, in the order of their appearance. Any change is required to retain the same number of elements in the list. Note that the <password> field always appears as NULL. Operations are EQUALS, LIST-CONTAINS, SET-TO. |
| <error action> | This is defined in 3.4.3.4. Operations are EQUALS and SET-TO. |
| *<time waiting> | This is defined in 3.4.1. Only EQUALS, GT, GE, LT, LE are allowed. |
| *<total size> | This is defined in 3.4.1. It is zero unless the work specification is waiting for transfer. Only EQUALS, GT, GE, LT, LE are allowed. |
An open system contains zero one or more transfer control records which control the way in which that open system transfers work specifications to other open systems.
Each transfer control record at an open system is set to control the transfer of work specifications to a specified open system. It enables the receiver of work specifications to influence concurrency and priority for the transfer of work specifications by the sender.
<transfer control record>::= <set by =N>
<time stamp> (see 3.3.2)
<recipient =N>
<control specification>
<control specification>::= ( UNCONTROLLED | <selection> )
<selection>::= [<selector>]*L (see 3.4.4.2.1)
Initially, all transfer control records held by an open system are set to UNCONTROLLED. In this case the open system will attempt transfers with a concurrency determined locally. It can adopt any algorithm for selecting work specifications for transfer. (Algorithms will normally use some combination of oldest first, smallest first, and highest <urgency> first).
If the value is UNCONTROLLED, <set by> and <time stamp> is not recorded. The <time stamp> is the time of the SET operation.
If the value is not UNCONTROLLED, then the <selection> is used not only to determine those work specifications which can cause transfers to be attempted, but also to control the degree of concurrency. If the <selection> list is empty, only transfer manipulation work specifications cause transfers. These are always permitted, but they are not allowed to cause the concurrency established by the <selection> to be exceeded by more than one.
An attempt to transfer a work specification to a <recipient> is not attempted unless each of work specification (if any) already being transferred to that recipient, and the work specification to be transferred are each selected by a different <selector> in the <selection> list.
NOTE -- This means that each selector permits the transfer of at most one work specification at any time. Several identical <selector>s can occur in the <selection>. Where more than one work specification satisfies a <selector>, the choice of work specification for transfer is a local implementation matter. (See also 3.4.3.1.)
This clause defines the semantics of the documents carrying JTM report displays, JTM work displays, and JTM-TCR-displays. A transfer syntax for these documents is specified in the JTM protocol specification.
The documents can form part of a work specification and parameters of J-GIVE and J-DISPOSE.
<JTM-report-display document>::=
[<JTM-report-display>]*L
<JTM-report-display>::= <OSI job monitor system = N>
<time stamp> (see 3.3.2)
[<report>]*L (see 3.3.2)
When produced by JTM, these documents contain only a single <JTM-report-display>. Concatenation of these documents produces a list of JTM-report-displays.
When such documents are produced as the result of a report manipulation, the selected reports are listed in the order they were received by the OSI job monitor system, to provide the <report> list for the <JTM-report-display>. The <time stamp> gives the date and time the display was produced.
When such documents are produced by a monitor point for use of J-DISPOSE to dispose of a <report> in accordance with the <disposal data>, the <time stamp> is the time the document was constructed by the monitor point, and there is a single <JTM-report-display> containing all the <report>s that were present in the REPORT-MOVEMENT subjob.
This document type is named by an ASN.1 ObjectDescriptor value (see ISO/IEC 8824) of
"JTM report-display document"
and by an ASN.1 OBJECT IDENTIFIER value which is specified in ISO/IEC 8832.
<work display document>::= [<work display>]*L
<work display>::= <displaying system = N>
<time stamp> (see 3.3.2)
[<ws display>]*L
<ws display>::= ( <full display> | <brief display> )
<full display>::= <header list> (see 3.4.6)
[<destination status>]*C
<destination status>::= <destination>
<status>
<time stamp> (see 3.3.2)
[<text = S>]*L
<CCR diagnostics>
<destination>::= ( <recipient = N> | <source agency> | <se agency> )
<source agency>::= ( <source name = S> |
<filestore-name =N> ) (see 3.4.4.1.3)
<se agency>::= ( <se name = S> |
<filestore-name =N> ) (see 3.4.4.1.1)
<status>::= ( IN-PROGRESS | ACCEPTED | WAITING )
<brief display>::= <subjob identification> (see 3.3.2)
[<destination status>]*C
The <time stamp> in the <work display> gives the time the display was produced.
The <header list> in the <full display> contains the <header>s for a selected subjob, and for all the proformas it contains.
The <destination status> provides information about any agencies or transfers associated with the work specification. The <time stamp> in the <destination status> gives the time that the state was entered.
The <CCR diagnostics> are those of the most recently received retry-later result and are absent unless the <status> is WAITING.
The <filestore-name> form is used for agencies which are obtaining or disposing of documents using FTAM. The <source name> and <se name> forms are used otherwise.
IN-PROGRESS means that there is an atomic action currently in progress. The JTM service provider generates the <text>, which contains human-readable, non-standardised information.
ACCEPTED means that acceptance commitment has been given by an agency. The text list is obtained by the J-STATUS primitive, which returns human-readable, non-standardised information.
WAITING means that resources are not available, a retry-later result has been received, or that a transfer control record prevents progress. The JTM service provider generates the text list, which contains human-readable, non-standardised information.
Concatenation of these documents produces a new list of work displays.
This document type is named by an ASN.1 ObjectDescriptor value (see ISO/IEC 8824) of
"JTM work-display document"
and by an ASN.1 OBJECT IDENTIFIER value which is specified in ISO/IEC 8832.
<transfer display document>::= [<transfer display>]*L
<transfer display>::= <displaying system = N>
<time stamp> (see 3.3.2)
[<transfer control record>]*L (see 3.4.7)
The <time stamp> is the time that the display was produced.
Concatenation of these documents produces a new list of <transfer display>s.
This document type is named by an ASN.1 ObjectDescriptor value (see ISO/IEC 8824) of
"JTM tcr-display document"
and by an ASN.1 OBJECT IDENTIFIER value which is specified in the extended JTM protocol specification.
The J-INITIATE request carries the following fields of a work specification:
<initiating identification> (see 3.3.2)
<OSI jobname> (see 3.3.2)
[<secondary monitoring specification>]*L (see 3.4.2)
<authorisations> (see 3.4.2)
<permissions> (see 3.4.2)
<accounts> (see 3.4.2)
<security parameters> (see 3.4.2)
<subjob specification> (see 3.4.1)
<proforma list> (see 3.4.1)
<document list> (see 3.4.1)
This completely defines the work to be performed.
The J-INITIATE confirm carries only the single parameter
<OSI job local reference = S>
This string is generated at the OSI job submission system to unambiguously identify this use of J-INITIATE within that open system. A local representation of the date and time of the issue of the primitive would be suitable, but any other unambiguous string can be used.
The commitment level and diagnostic code indicator CCR parameters (carried by J-BEGIN) are chosen by the issuer of the J-INITIATE request.
CCR diagnostics and accounting information can be returned to the user on the other CCR-related parameters.
The J-DISPOSE indication is issued by the <target> of a work specification to a sink or execution agency identified by <se name = S> for the <JTM se> form and to the local sink agency performing FTAM access for the <FTAM sink> form.
The J-DISPOSE indication carries the following parameters:
<provider activity id = S>
<user authority>
<user account>
<additional authorisations> (see 3.4.4.1.1)
( <filestore-name = N> |
<agency parameter> ) (see 3.4.4.1.1)
<document se reference> (see 3.4.4.1.2)
<errors>
<disposal document>
<errors>::= [<diagnostic information>]*L (see 3.3.3)
<user authority>::= ( NOT-KNOWN |
<identification> | (see 3.3.2)
<authorisation element> ) (see 3.4.2.1)
<user account>::= ( NOT-KNOWN |
<identification> | (see 3.3.2)
<account element> ) (see 3.4.2.1)
<disposal document>::= <document type = ND>
<document = D>
The <provider activity id> represents the local information needed to identify the activity for future primitive groups issued by the agency (such as J-END-SIGNAL, J-MESSAGE, etc). Its form is not standardised.
NOTE -- Where the agency and the provider are part of the same open system, the <provider activity id> is not visible in the OSI environment.
The <user authority> and <user account> are obtained from an <authorisation element> and an <account element>. They are validated by the JTM service provider if only <identification> is provided, otherwise the complete <authorisation element> or <account element> is supplied. The choice of which <authorisation element> to use for a J-DISPOSE is performed by a local directory function, using the sink or execution agency name and the user identification authority name in the <authorisation element>. The value NOT-KNOWN indicates that no suitable authorisation element could be found, and would often be a reason for rollback by the agency. In some cases, however, the <additional authorisations>, or data in the document itself, can suffice to allow the activity to take place.
One J-DISPOSE primitive group is issued for each <se identification> in the <se agencies> field for each document produced by a <document block>. The <filestore-name> or <agency parameter> are obtained from the <se identification>.
A J-DISPOSE primitive group is also issued to the sink agency specified in the <disposal data> (if any) for an OSI job monitor for each report which reaches the OSI job monitor.
The <document se reference> is obtained from the <se prefix>, <document block> or <disposal data>.
The <errors> consist of a list of <diagnostics information> formed from the <source identification> and <error information> for any <single document reference> with <state> FAILED (see 3.4.4.1.3). The <errors> (if any) are supplied to the sink agency together with the <disposal document>. The disposal of the <errors> is not standardised.
The <disposal document> contains either a <JTM-report-display> or a document of any other (standard or non-standard) document type supported by the implementation.
NOTE -- Implementations are required to state the document types they support (for J-GIVE, J-DISPOSE, and transfer). Implementations claiming to be general-purpose are expected to support at least the first three document types defined in annex C.
Disposal of reports to sink agencies is done by J-DISPOSE after converting the <report> into a <JTM-report-display>.
The J-DISPOSE response carries the single parameter
<agency activity id = S>
This represents the local information needed to identify the activity for future primitive groups issued by the JTM service provider (J-KILL, J-STATUS, etc). Its form is not standardised.
The J-GIVE indication is issued to a source or execution agency as a result of a <single document reference>, or as the result of a <document source skeleton> and a <name-list> following a J-ENQUIRE. Refer to 3.4.4.1.3, 3.4.4.1.4 and 3.6.4 for details of these fields.
The J-GIVE indication is issued by the
<action open system = N>
to the source or execution agency identified by <source name = S> for the <JTM se> form and to the local source agency performing FTAM access for the <FTAM source> form.
The J-GIVE indication carries the following parameters
<user authority> (see 3.6.2)
<user account> (see 3.6.2)
<additional authorisations> (see 3.4.4.1.1)
<document source reference> (see 3.4.4.1.3)
( <filestore-name = N> |
<agency parameter = S> ) (see 3.4.4.1.3)
<document type = ND>
<document group>
where
<document group>::= ( PERMANENT | <activity end group> | <proforma group> )
<activity end group>::= <agency activity id> (see 3.6.2)
<proforma group>::= <agency activity id> (see 3.6.2)
<demand spawn handle = S>
All parameters and their meaning have been defined in earlier clauses except <document group>. This is PERMANENT unless the J-GIVE is issued to an execution agency, when it is <activity end group> or <proforma group>. In this case it indicates that the J-GIVE indication is for documents available at the end of an activity or from spawning any proformas that have a <document spawning handle> that is equal to the <demand spawn handle>, respectively.
Where the <source name> is an execution agency, the activity to which the J-GIVE relates is identified by the <agency activity id>. The set of documents being accessed is those available at the end of an activity for the <activity end group>, and those available when J-SPAWN was issued for the <proforma group>. In the latter case, the <demand spawn handle> is that which appeared in the J-SPAWN request.
The J-GIVE response carries a single <document> parameter. The <document>is of the <document type> specified in the J-GIVE indication. Note that if no suitable document can be found, a J-ROLLBACK request is issued instead of a J-GIVE response, and the C-service diagnostic is then used by the JTM service provider for a JTM diagnostic.
An agency which is both a source and a sink permits immediate J-GIVE access to a document written by a J-DISPOSE indication, provided the same atomic action identifier is used.
The agency permits several J-GIVE accesses by the same atomic action, even if MOVE is specified by the last access. The source document is deleted when and only when all J-GIVE primitive groups have committed or backed-up, with at least one committing to MOVE.
Concurrent activity with a different atomic action identifier follows the normal rules of CCR.
The J-ENQUIRE indication is issued to a source or execution agency as a result of a <multiple form> document block in the OSI subjob being processed.
The source or execution agency to which it is issued is obtained as for the J-GIVE indication. It carries the following parameters:
<user authority> (see 3.6.2)
<user account> (see 3.6.2)
<additional authorisations> (see 3.4.4.1.1)
<agency parameter = S> (see 3.4.4.1.1)
<document source skeleton> (see 3.4.4.1.4)
<document selector = S> (see 3.4.4.1.4)
<document type = ND>
<document group> (see 3.6.3.1)
The J-ENQUIRE response carries only
[<name-list>]*L
The J-ENQUIRE is used to obtain the names of all documents whose <name-list>s begin with the <partial name-list> in the <document source skeleton>, and which are accessible by a J-GIVE using the quoted parameters (see 3.4.4.1.4).
The returned <name-list>s provide the suffices to be added to the <partial name-list> for the issue of J-GIVE primitives.
If no document can be found, a J-ROLLBACK request is issued instead of a J-ENQUIRE response, and the C-service diagnostic is then used by the JTM service provider for a JTM diagnostic.
Note that it is not required that the J-ENQUIRE response should remain valid after the corresponding J-COMMIT indication. The JTM service provider issues all necessary J-GIVE groups (with the same atomic action identifier) prior to committing to J-ENQUIRE.
The J-MESSAGE request carries the parameters:
<provider activity id>
<message>
where
<message>::= [<text=S>]*L
The <message> is used by the JTM service provider to form the text list of a report which is delivered to an OSI job monitor if reporting of the USER-MESSAGE event type is selected. (If reporting of this event type is not selected for any monitor point, the <message> is discarded.)
The <commitment level> parameter is set to PROVIDER-ACCEPTANCE, and the atomic action always proceeds to commitment. The diagnostic code indicator is identical to that on the corresponding J-DISPOSE, and the <message> conforms to the character sets required by the diagnostic code indicator. Each line of <text> in the <message> is restricted to a length of 40 characters.
The J-SPAWN request is used to cause the creation of new work specifications from one or more of the top-level proformas in the work specification associated with an activity. The parameters are
<provider activity id>
<demand spawn handle>
Any top-level proforma with a <demand spawning handle> that is equal to the <demand spawn handle> of the J-SPAWN request is spawned.
Following the corresponding J-READY indication, any documents to be used in spawning can be deleted (collection by J-GIVE is complete).
The <commitment level> parameter can take any defined value. The atomic action can be rolled back by a J-ROLLBACK.
The J-END-SIGNAL request implicitly refers to an earlier J-DISPOSE which gave ACCEPTANCE commitment. It contains only:
<provider activity id>
Where there is only one activity involved, it causes all top-level proformas marked for COMPLETION or CONDITIONAL spawning to be spawned, in the order of their appearance in the <proforma list>. See also 3.4.5.2. Where more than one activity is involved, the spawning commits only when all J-END-SIGNAL primitive groups commit.
The commitment level is 1, and the atomic action always proceeds to commitment.
The J-STATUS indication is issued by the JTM service provider to a sink or execution agency which has given ACCEPTANCE commitment to a J-DISPOSE, but has not yet issued a J-END-SIGNAL request. It carries only the <agency activity id> parameter. The response carries the single parameter
<status message>
where
<status message>::= [<text = S>]*L
The indication is issued by the JTM service provider as a result of a work manipulation display operation on the work specification associated with the activity. The <status message> is carried in the display. Its form is not defined, but it should give as much information as possible about the state of the activity in the agency. Where the agency wants the report to carry the <agency activity id>, it includes it in the <status message>.
This atomic action always proceeds to commitment. The character set in the status message conforms to the requirements of the diagnostic code indicator. Each line of <text> is limited in length to 40 characters.
These primitives carry only the <agency activity id> parameter.
The J-HOLD indication informs the sink or execution agency that the JTM service provider wishes the activity to be suspended. No J-MESSAGE, J-SPAWN or J-END-SIGNAL request is issued until a J-RELEASE indication is received.
The J-RELEASE indication allows J-MESSAGE, J-SPAWN and J-END-SIGNAL requests, and is used to cancel a J-HOLD.
The J-KILL indication tells the sink or execution agency to terminate the activity produced by a J-DISPOSE, and to generate a J-END-SIGNAL request. The J-END-SIGNAL cannot provide any documents. (The JTM service provider does not issue J-ENQUIRE or J-GIVE groups.)
The J-STOP indication has the same effect as J-KILL, but documents are allowed on the resulting J-END-SIGNAL. (The JTM service provider issues J-ENQUIRE and J-GIVE groups.)
A subordinate does not issue a J-ROLLBACK for these atomic actions, but the superior may require rollback.
A summary of the JTM service primitives appears as table 3. An indication of their use appears in table 2.
| Document-movement subjob | ||
| J-ENQUIRE | if a multiple form document block is present | |
| J-GIVE | if a single document reference is present, or following a J-ENQUIRE | |
| J-DISPOSE | this either completes, or allows J-END-SIGNAL, J-SPAWN and J-MESSAGE | |
| Report-movement subjob | ||
| J-DISPOSE | ||
| Work-manipulation subjob | ||
| J-KILL | ||
| J-STOP | ||
| J-HOLD | ||
| J-RELEASE | ||
| J-STATUS | ||
| TCR-manipulation subjob | ||
| None | ||
| Report-manipulation subjob | ||
| None | ||
| Primitives | Request | Indication | Response | Confirm | |
| J-INITIATE-WORK | |||||
| document movement specification | X | - | |||
| OSI job local reference | - | X | |||
| J-INITIATE-WORK-MAN | |||||
| work manipulation specification | X | - | |||
| OSI job local reference | - | X | |||
| J-INITIATE-TCR-MAN | |||||
| transfer manipulation specification | X | - | |||
| OSI job local reference | - | X | |||
| J-INITIATE-REPORT-MAN | |||||
| report manipulation specification | X | - | |||
| OSI job local reference | - | X | |||
| J-DISPOSE | |||||
| provider activity id | X | - | |||
| user authority | X | - | |||
| user account | X | - | |||
| agency parameter | filestore-name | X | - | |||
| document se reference | X | - | |||
| additional authorisations | X | - | |||
| errors | X | - | |||
| document and document type | X | - | |||
| agency activity id | - | X | |||
| J-GIVE | |||||
| user authority | X | - | |||
| user account | X | - | |||
| agency parameter | filestore-name | X | - | |||
| document source reference | X | - | |||
| additional authorisations | X | - | |||
| document type | X | - | |||
| document group | X | - | |||
| document and document type | - | X | |||
| J-ENQUIRE | |||||
| user authority | X | - | |||
| user account | X | - | |||
| agency parameter | X | - | |||
| document source skeleton | X | - | |||
| additional authorisations | X | - | |||
| document type | X | - | |||
| document selector | X | - | |||
| document group | X | - | |||
| list of name lists | - | X | |||
| J-SPAWN | |||||
| provider activity id | X | ||||
| proforma name | X | ||||
| J-MESSAGE | |||||
| provider activity id | X | ||||
| message | X | ||||
| J-END-SIGNAL | |||||
| provider activity id | X | ||||
| J-STATUS | |||||
| agency activity id | X | - | |||
| status message | - | X | |||
| J-HOLD | |||||
| agency activity id | X | ||||
| J-RELEASE | |||||
| agency activity id | X | ||||
| J-KILL | |||||
| agency activity id | X | ||||
| J-STOP | |||||
| agency activity id | X | ||||
A J-INITIATE primitive group can cause further service primitives to be issued as a direct result of processing the first subjob. If the first subjob spawns further subjobs, either by J-SPAWN or by J-END-SIGNAL or on completion of a J-DISPOSE or following a manipulation, then further primitive groups can occur. The primitive groups caused by the original J-INITIATE primitive groups can occur concurrently with that primitive group, or can occur after it, depending on the level of commitment. As a proforma can consist of any type of subjob (except REPORT-MOVEMENT), any type of J-INITIATE primitive group can give rise to all forms of service primitive, depending on its parameters. In addition, reporting of events, including reporting caused by a J-MESSAGE group, can produce a J-DISPOSE. Table 2 gives details of primitives potentially used in processing a single subjob.