These procedures are invoked by the service primitives listed in the first subclause of 1.5.6, and specify the issuing of the service primitives listed in the second subclause of 1.5.6. All service primitives are received and issued within a CCR commitment group. Presentation service primitives issued at other times represent a protocol error and shall be handled in an implementation-dependent manner. All presentation service primitives are received and issued in either "ISO JTM Basic Class Application-context" or "ISO JTM Full Application-context"; the handling of primitives issued in other contexts is not in the scope of this International Standard.
The issuing of a J-INITIATE request shall invoke the procedures of clause 3.2 and the clauses it references.
The issuing of an ACSE A-ASSOCIATE indication, a C-BEGIN indication, and a P-DATA indication (in the "ISO JTM Basic Class Application-context" or "ISO JTM Full Application-context" and the JTM presentation-context) shall invoke the procedures of clause 3.3 and the clauses it references.
The issuing of a J-END-SIGNAL request shall invoke the procedures of clause 3.13 and the clauses it references.
The issuing of a J-MESSAGE request shall invoke the procedures of clause 3.17 and the clauses it references.
The issuing of a J-SPAWN request shall invoke the procedures of clause 3.18 and the clauses it references.
The procedures make use of values returned by the management functions defined in annex A. The requirements to support values of these functions are specified in section 4. Each reference to a management function gives its serial number in annex A, for example, MF4 references the fourth function in annex A.
Throughout this procedure specification, parts of a work specification are referenced by using the name of fields in the standard syntactic representation of a work specification - a transfer element. The use of this notation does not in any way constrain the way in which a work specification (a semantic construct) is held locally: it is necessitated by the inability to clearly specify semantic values without the use of some syntactic notation.
The following 3.1.1.1 to 3.1.1.3 shall apply throughout the operation of the implementation.
3.1.1.1 The implementation shall ensure that service primitives are issued only in the sequence defined in ISO/IEC 8831, and that C-RECOVER primitives are issued in a timely manner when the implementation has recovery responsibility following an application failure or an aborting of the "ISO JTM Basic Class Application-context" or "ISO JTM Full Application-context".
NOTE -- Special attention is needed to this area when a programming or command language interface is provided to J-INITIATE.
3.1.1.2 The procedures of ISO/IEC 9805 shall be applied to the actions of the JTM ASE when it issues or receives J-service-primitives, and when it issues or receives C-service primitives.
3.1.1.3 In an extended implementation, and except where specified otherwise in the procedures, any "accounting-info" in the user data of C-READY indication or C-ROLLBACK indication shall be passed on to the CCR superior on the appropriate CCR primitive.
This clause is applicable to the creation and subsequent processing of a work specification as a result of a J-INITIATE request. If the implementation is Basic Class and the parameters of the J-INITIATE exceed the range of values specified in section 4 of ISO/IEC 8831, the implementation shall issue a J-ROLLBACK in reply to the J-INITIATE, with the JTM diagnostic code set to "sf-not-supported" and descriptive human-readable text obtained from the local management function MF1. Otherwise, the following clauses shall apply.
The sequence of primitives in the J-INITIATE group shall be the sequence defined in clause 3.1 of ISO/IEC 8831.
A work specification shall be created from the J-INITIATE parameters and local management functions as specified below, and shall then be processed in accordance with clause 3.4. The procedures of 3.2.9 and 3.2.10 shall be applied. A J-INITIATE confirm shall be issued as specified in 3.2.11. This completes the procedures specified by clause 3.2.
NOTE -- This International Standard does not specify the way data is supplied in J-INITIATE parameters, nor the time of binding of data to work specifications. The data is required when the work specification is transferred. It may be ignored, locked, or copied prior to that point, as an implementor's option.
Fields shall be set as follows:
| osi-job-submission-system |
Set from the local management function "Local-name" MF2. |
| initiating-identification | Set from J-INITIATE <initiating identification>. |
| initiating-time | Set to the current local time if this is accessible to the implementation. If this is not accessible, the Time-stamp shall be set to "not-available NULL". |
| osi-job-name | Set from J-INITIATE <OSI-job name>. |
| osi-job-local-reference | Generated as an unambiguous string. The value shall be returned in the J-INITIATE confirm (see 3.2.11). The same value of the string shall not be used for transfer elements produced by different J-INITIATE primitives issued at this JTM ASE. |
| NOTE -- A suitable value could be obtained from date and time. | |
| subjob-name-list | Set to { } |
| audit-trace | Set to |
{{ sender a, status unknown NULL}}
| where a is the open system name returned from the local management function "Local-name" MF2. | |
| primary-monitoring-specification |
Set from the local management function "Primary monitor" MF3. |
| secondary-monitoring-specification |
set from J-INITIATE <secondary monitoring specification> |
| authorisations | See 3.2.2 below. |
| permissions | See 3.2.2 and 3.2.3 below. |
| accounts | See 3.2.2 and 3.2.4 below |
| security parameters | See 3.2.5 below. |
| Subjob-specification | |
| - relays | Set from J-INITIATE <relays> |
| - target | Set from J-INITIATE <target> |
| - type | Set from the J-INITIATE <subjob type> |
| - urgency | Set from J-INITIATE <urgency> |
| - holds | See 3.2.6 below |
| - error-action | Set from J-INITIATE <error action> |
| - actions | Set to the appropriate CHOICE according to the particular J-INITIATE primitive, with the fields set as in 3.2.7. below. |
| proforma-list | Set from the fields of J-INITIATE as specified in 3.2.8 below. |
| <times spawned> | Set to zero for all top-level proformas |
| documents for transfer | Set from the J-INITIATE <document list>. |
| <time waiting> | This field shall contain the time in seconds from this point of creation. |
| <estimated size> | If the <target> is not the local system, this field shall contain the estimated size of the Transfer-element, plus the document values (if any) in kilo-octets. Otherwise it shall be set to zero. The estimated size shall be based on the transfer syntax specified as mandatory for the Transfer-element and the document types. |
| <agency activity parameters> |
This parameter shall be empty. |
| <CCR parameters> | This shall be set to the CCR "diagnostic code indicator" parameter in the user data of the J-BEGIN in the J-INITIATE commitment group. It is used in 3.5.4. |
3.2.2.1 A "Permission-element" shall be included for each <permission element> in the J-INITIATE.
3.2.2.2 An "Authorisation-element" with "validation" set to "password set OCTET STRING" shall be included for each <authorisation element> in the J-INITIATE. The OCTET STRING shall be set to the <secret data> of the J-INITIATE <authorisation element>.
3.2.2.3 Additional authorisation elements as specified in 3.2.2.3.1 to 3.2.2.3.4 shall be included according to the available local management functions. The additions in 3.2.2.3.1 to 3.2.2.3.4 shall be made, provided they do not result in two identical authorisation elements. This completes the procedures of 3.2.2.
3.2.2.3.1 If the local management function MF4 can provide an authenticated "Identification" associated with the initiation agency, then an "authorisation-element" shall be added containing a "checked-index" of 1 and the "Identification".
NOTE -- See 3.3.8.4.1 for details of the use of the checked-index.
3.2.2.3.2 Where the local management function MF5 (or remote protocols) are available to authenticate any "Identification" with a "password" "validation", this shall be invoked. If the "Identification" is not authenticated, no change shall be made. If it is authenticated, an authorisation-element shall be added with a checked-index equal to the number of elements in the audit trace.
NOTE -- The procedures of this subclause are also referenced by 3.3.8.3.
3.2.2.3.3 Additional authorisation elements provided by the local management function MF6 shall be added if necessary to ensure that reports can be delivered to the "primary-osi-job-monitor"; the implementation shall either
NOTE -- These may include temporary identifications and secret data (capabilities) used for this purpose only, or may include validations with a checked-index of 1.
3.2.2.3.4 Where the local management function MF7 is available to determine that a "user-identification" (issued by some "User-identification-authority") includes the right to operate as a "user-identification" issued by a different "User-identification-authority", then any authenticated "Identifications" for the first "user-identification" shall result in the addition of new "authorisation elements" with the same checked-index.
NOTES
- Where these functions are available, and where the remote system's management configures its data to "trust" the OSI job submission system, a user will be able to operate remotely with no additional password.
- The procedures of this subclause are also referenced by 3.3.8.3.
Where authorisation elements were added in 3.2.2.3.1 or 3.2.2.3.4 above, corresponding permission elements shall also be added.
NOTE -- The procedures of this subclause are also referenced by 3.3.8.3.
The procedures of 3.2.2.2 and 3.2.2.3 shall be applied to account elements as to authorisation elements, except for 3.2.2.3.3.
No value shall be set.
NOTE -- Following completion of work on Security Architecture, this subclause is expected to be modified by an Addendum.
The <hold state> for the work specification shall be set to NOT-HELD.
If the implementation supports full work-manipulation, the procedures of clause 3.19 shall be applied to the work specification.
NOTE -- This may change the <hold state> to HELD.
The JTM-action-parameters datatype is isomorphic with the <JTM-action-parameters> in the J-INITIATE, and shall be set from the corresponding fields. The "state" of each "single-document-reference" shall be set to "not-attempted NULL".
The proforma-list datatype is isomorphic with the <proforma list> in the J-INITIATE, and shall be set from the corresponding fields. The "state" of each "single-document-reference" (if any) shall be set to "not attempted NULL"
The procedures of clause 3.16 shall be invoked with the nominated bit the "creation" bit, and the "event-identification" of any "Single-report" created by that clause set to the value
creation
{text text ,
target-list t ,
hold-state h }
where text is set by management function MF1 and t is copied from the "relays" and "target" of the original work specification, and h is {not-held NULL} if the <hold state> is NOT-HELD and {held NULL} if the <hold state> is HELD.
If the implementation is an extended implementation, and any C-READY indication or C-ROLLBACK indication user data fields received by the JTM ASE include "accounting-info", the procedures of clause 3.15 shall be invoked, with the nominated bit the "accounting-data" bit and the "event-identification" of any "Single-report" created by that clause set to the value
accounting-data
{text text ,
accounting-information a }
where text is human-readable text generated MF1 and a is a SET OF "Charging-information" containing "Charging-information" from the "accounting-info" on the CCR primitives received. If several "Charging-information" are received, it is an implementation option whether "Charging-information" are accumulated into a SET of several members, or whether clause 3.15 is invoked repeatedly, provided in either case, each "Charging-information" is passed to the procedures of clause 3.15 only once. The "accounting-info" shall not be passed on to the superior.
The osi-job-local-reference shall be returned as the value of the J-INITIATE confirm parameter.
NOTE -- Issue of this primitive may, but need not, occur, if a J-ROLLBACK indication is provided. The sequencing requirements do not determine whether it is issued immediately or after the processing of clause 3.4.
This clause is applicable to the receipt of a work specification as the result of a P-DATA indication in the "ISO JTM Basic Class Application-context" or "ISO JTM Full Application-context" within a CCR atomic action.
NOTES
- An implementation supporting a source, sink, or execution agency is required to accept incoming application-association attempts as specified in section 5. The mechanisms for establishing the necessary application and presentation-contexts are subject to local scheduling, and are specified in section 5.
- Section 5 requires the open system wishing to send a work specification to take the initiative in establishing the JTM association and necessary presentation-contexts, and the receiver to play a passive role.
3.3.1 The acceptor of an application-association in "ISO JTM Basic Class Application-context" or "ISO JTM Full Application-context" shall await a C-BEGIN indication followed by a P-DATA indication (or a C-RECOVER indication). (See also the note to 3.3.7.)
3.3.2 Should a C-BEGIN (or C-RECOVER) not be received in a time acceptable to the implementation, or should some other incoming event occur, then the implementation shall issue an A-ABORT with parameters as specified in section 5.
3.3.3 Syntactic and semantic correctness of the C-BEGIN user data parameter (as specified in section 2) shall be checked. If this check fails, then a C-ROLLBACK indication shall be issued, with a JTM diagnostic code of
"sf-protocol-error"
and with the human-readable text set by the local management function MF1; the procedures of CCR govern all further action.
3.3.4 When a P-DATA indication appears, the calling address information and lower layer procedures shall be used with the local management function MF8 to determine one of the following states:
NOTE — The directory functions and connection establishment procedures used to produce the classification
UNKNOWN
KNOWN
AUTHENTICATED
are not in the scope of this International Standard. Where this International Standard is used before the establishment of an International Standard in this area, enterprise-specific mechanisms can be used prior to establishment of the "ISO JTM Basic Class Application-context" or "ISO JTM Full Application-context".
3.3.5 The local management function MF9 shall determine whether calls in each of these categories with specific JTM-names are to be progressed or not (NO RETRY). Progression of the call may also depend on the total number of JTM calls in progress, or on the total number of incoming calls, or on the total number of incoming calls from the identified open system, or on all three, as determined by the local management function MF19. If such limits are exceeded, this is a RETRY LATER rollback .
3.3.6 If the local management function MF9 determines that the call is never to be progressed, then the following error procedure shall be invoked:
If MF19 determines that it is not to be progressed now, a C-ROLLBACK specifying RETRY-LATER shall be issued. A retry-time shall be specified if the local management function MF19 makes one available. The JTM diagnostic code shall be "rl-incoming-concurrency-limit".
NOTE -- It is desirable for the implementation to hold the transfer pending if progression is likely to become possible shortly , rather than to give an immediate rollback with RETRY LATER.
3.3.7 If the transfer is to be progressed and is using "ISO JTM Basic Class Application-context", one of the following situations occurs:
If the transfer is to be progressed and is using "ISO JTM Full Application-context", one of the following situations occurs :
NOTE -- For both application-contexts, should the transfer fail to progress in a time which is acceptable to the receiver, the receiver may, as an implementation option, issue C-ROLLBACK with a JTM diagnostic code of "rl-timeout" (if C-READY has not yet been issued), or A-ABORT. The handling of the CCR atomic action identifier and bound data proceeds in accordance with the rules of CCR.
3.3.8 The first presentation data value in the first (or only) P-DATA shall be interpreted as a "Transfer-element", using the transfer syntax established for the JTM presentation-context by the Presentation Layer. If the application context is "ISO JTM Basic Class Application-context", a subsequent presentation data value shall be interpreted as a document. If the application context is "ISO JTM Full Application-context", subsequent presentation data values in the same or following P-DATA shall be interpreted, without regard for the P-DATA boundaries, as the first of a sequence of documents, separated by a presentation data value in JTM presentation-context that is an instance of the datatype "Document-separator". Each document can be in one or several presentation data values, depending on the transfer syntax established for the document type and the presence of checkpointing. The transfer element and the documents shall be processed as specified in 3.3.8.1 to 3.3.8.8, completing the procedures of this subclause.
NOTES
- Subclause 3.3.8.8 references clause 3.4 for further processing.
- it is an implementor's option whether, when using "ISO JTM Full Application-context", the procedures of 3.3.8.1 to 3.3.8.8 are initiated as soon as the first presentation data value containing the "Transfer-element" is complete. Similarly, 3.3.8.8 may be initiated as soon as the "Transfer-element" and any documents required for a particular procedure are received.
The fields of the work specification that are not transferred shall be set as specified in 3.2.1.
3.3.8.1 Syntactic and semantic correctness of the "Transfer Element" (as specified in section 2) shall be checked. If this check fails, then a C-ROLLBACK request shall be issued, with a JTM diagnostic code of
"sf-not-supported"
the human-readable text shall be set by the local management function MF1. The check can also fail because the size or complexity of the work specification exceeds the total implementation's capabilities. In this case the actions shall be the same, but with a JTM diagnostic code of "sf-too-large". The procedures of CCR govern all further action.
If the syntactic and semantic check succeeds, the procedures of 3.3.8.2 to 3.3.8.8 are applied.
3.3.8.2 The last element of the audit trace has "status unknown" (for a correct transfer element). If the sending "JTM-name" provided in 3.3.4 is "unknown", this element shall not be changed. If the "JTM-name" is "known" or "authenticated", then the "JTM-name" in the last element of the "audit-trace" shall be compared with the sending "JTM-name". If a match occurs, the "status" of the "audit-trace" element shall be changed to that of the sending "JTM-name". If no match occurs, the error procedure of 3.3.6 (NO RETRY) shall be invoked. Finally, a new element shall be added to the end of the audit-trace, set to
{a, unknown}
where a is provided by the local management function "Local-name" MF2.
3.3.8.3 Each authorisation-element and account-element shall be examined and the procedures of 3.2.2.3.2, 3.2.2.3.4 , 3.2.3 and 3.2.10 shall be carried out where they produce authorisation or permission elements which differ from ones already present.
NOTE -- The checks of 3.3.8.1 have ensured that there is no checked-index greater than the length of the original audit-trace.
3.3.8.4 The local management function MF11 determines whether, for input from this calling address, authorisation is only required for outgoing transfers or access to certain agencies, or whether it is always required. If it is required for all JTM activity or for the sending of JTM reports, then the procedures of 3.3.8.4.1 and 3.3.8.4.2 shall be invoked.
3.3.8.4.1 The local management function MF12 determines the user identification authorities which may provide authorisation for the activity. An authorisation element for one or more of these authorities, with both the following properties, may or may not exist:
If such an element is found, the activity is authorised. If it is not found, the activity is not authorised.
NOTE -- In the Basic Class, authorisation elements are also used to determine an account to be charged for the activity, where accounting is implemented.
3.3.8.4.2 If the activity is not authorised, a C-ROLLBACK indication shall be issued. The JTM diagnostic code shall be either
"ue-unauthorised-access"
or "ue-unauthorised-reports"
according to the requirements returned by MF11. The human-readable text is set by the local management function MF1.
3.3.8.5 In an extended implementation, the local management function MF11 also determines whether account identification is to be supplied if it is available. If it is to be supplied for all JTM activity or for the sending of JTM reports, the procedures of 3.3.8.4.1 shall be invoked, but applying to account elements. If a usable account element is found, it is used for account identification. If no usable account element is found, the account identity is inferred from the authorisation.
3.3.8.6 The <hold state> for the work specification shall be set to NOT-HELD.
If the implementation supports full work-manipulation, the procedures of clause 3.19 shall be applied to the work specification.
NOTE -- This may change the <hold state> to HELD.
3.3.8.7 If any bit in the "report-selector" in the "primary-monitoring-specification" is set, and the "monitor-system-name" "JTM-name" is different from the local "JTM-name" MF2, the local directory management function MF16 shall be used to determine the availability of the addressing and other information needed to establish an association in "ISO JTM Basic Class application-context". If the directory search fails, a C-ROLLBACK request shall be issued with a "JTM-code" of
"ue-monitor-site-unknown"
and including the faulty "JTM-name" in the human-readable text.
3.3.8.8 The information in the "Transfer-element" and (if present) the document, constituting a work specification, shall be further processed as specified in clause 3.4. This completes the procedures of this clause.
This clause is referenced by 3.2, 3.3, 3.10.7, 3.14, 3.15.1, 3.16.1, 3.20 and 3.21. It provides for processing a work specification before the JTM entity has taken responsibility for it.
Any work specification to which this clause is applied shall be made visible for the procedures of 3.10.2.
The issue of a J-INITIATE request (see clause 3.2), a P-DATA indication in "ISO JTM Basic Class Application-context" or "ISO JTM Full Application-context" (see clause 3.3), the occurrence of spawning (see clause 3.14), of report generation (see clauses 3.15 and 3.16) or the specified circumstances in transfer-control processing (see clauses 3.20 and 3.21) produces a new work specification as specified in those clauses. This shall be processed as specified in 3.4.1 to 3.4.10 below, completing the procedures of this clause.
3.4.1 If the <hold state> of the work specification is NOT-HELD or the implementation does not support full work-manipulation, processing shall continue with 3.4.3. If the implementation does support full work-manipulation and the <hold state> is HELD, the minimum required commitment level shall be examined. If this is level 1, the procedures of 3.4.2 shall be followed. Where the minimum required commitment level exceeds 1, a no-retry CCR diagnostic with JTM-code
and human-readable text MF1 shall be passed to the superior.
3.4.2 The work specification shall be stored as secure data, and commitment offered to the superior. The procedures of clause 3.5 shall be applied to the work specification when the <hold state> has been changed by the procedures of 3.19.9, invoked either by 3.10.10 or by 3.19.8.
3.4.3 The implementation shall initially perform all the procedures of 3.4.8, 3.4.9 and 3.4.10, following the procedures of ISO/IEC 9805 for a CCR sub-master. Where the processing requires the issue of further J-service or P-service primitives, these shall be progressed as part of the same atomic action.
3.4.4 The following cases can arise from the processing specified in 3.4.8 and 3.4.10:
3.4.5 In case 3.4.4 a), commitment shall be offered to the superior, and the procedures of ISO/IEC 9805 (CCR) determine all further actions.
3.4.6 In case 3.4.4 b), the C-service no-retry diagnostics shall be passed to the superior.
3.4.7 In case 3.4.4 c), the minimum required commitment level shall be examined. Where this is level 1, 3.4.7.1 and the clauses it references shall be applied. Where the minimum required commitment level exceeds 1, 3.4.7.3 shall be applied.
3.4.7.1 If the work specification has been produced by the issue of a P-DATA indication in "ISO JTM Full Application-context" the procedures of clause 3.16 shall be invoked with the nominated bit the "transfer" bit and the "event-identification" of any "Single-report" created by that clause set to the value
transfer
{text text ,
target-list t ,
hold-state h }
where text is set by MF1, t is copied from the "relays" and "target" of the original work specification and h is {not-held NULL} if the <hold state> is NOT-HELD and {held NULL} if the <hold state> is HELD. If the procedures of clause 3.16 are not invoked, or are null or produce an offer of commitment, 3.4.7.2 shall be applied. If the procedures of clause 3.16 result in a rollback with a retry-later diagnostic, 3.4.7.3 shall be applied. If they result in rollback with a no-retry diagnostic, 3.4.6 shall be applied.
NOTE -- A retry-later rollback to the transfer report forces the main action to be rolled back with retry-later.
3.4.7.2 The work specification shall be stored as secure data and commitment at commitment level 1 shall be offered to the superior. The procedures of clause 3.5 shall be applied to the work specification in conformance with 3.5.3.
3.4.7.3 The C-service retry-later diagnostics shall be passed to the superior.
NOTE -- The timer values in this diagnostic are normally derived from any timer values made available by the responses from subordinates.
3.4.8 If the work specification has a "sub-job-type" (in its outermost "sub-job-specification") of "document-movement", then the procedures of clause 3.6 shall be carried out for that "sub-job-specification", followed by the procedures of 3.4.9 and 3.4.10 below.
NOTE -- The procedures of clause 3.6 are null for a Basic Class work specification obtained from a Transfer Element.
3.4.9 If the "relays" are empty the procedures of 3.4.10 shall be carried out. Otherwise the first JTM-name in the "relays" shall be examined. If this is the local JTM-name specified by the local management function MF2, the item shall be removed from the "relays" and the procedures of this subclause shall be applied again. If the first "JTM-name" in the "relays" is not the local JTM-name, the procedures of clause 3.7 shall be invoked to attempt to send the work specification to the open system that corresponds to the first "JTM-name" in the "relays".
3.4.10 If the "target" is not the local JTM-name specified by the local management function MF2, the procedures of clause 3.7 shall be invoked to attempt to send the work specification to the open system that corresponds to the "target". Otherwise procedures shall be invoked as follows:
document-movement subjob type 3.8 report-movement subjob type 3.9 work-manipulation subjob type 3.4.10.1 report-manipulation subjob type 3.4.10.2 tcr-manipulation subjob type 3.4.10.3
3.4.10.1 If the "work-manipulation-operations" is a "Basic-work-manipulation-operations", or the implemention supports full work-manipulation, the procedures of clause 3.10 shall be invoked. Otherwise a CCR no-retry diagnostic shall be generated containing a JTM-code of
"sf-not-supported"
and human-readable text generated by MF1. The diagnostic shall be returned to the superior, completing the procedures of this clause in this case.
3.4.10.2 If the implemention supports monitor point storage, the procedures of clause 3.11 shall be invoked. Otherwise a CCR no-retry diagnostic shall be generated containing a JTM-code of
"ue-monitor-point-storage-not-supported"
and human-readable text generated by MF1. The diagnostic shall be returned to the superior, completing the procedures of this clause in this case.
3.4.10.3 If the "transfer-manipulation" in the "transfer-manipulation-operations" is the CHOICE "set" or the CHOICE "display", then:
"sf-transfer-control-not-supported"
and human-readable text generated by MF1. The diagnostic shall be returned to the superior, completing the procedures of this clause in this case.
If the "transfer-manipulation" in the "transfer-manipulation-operations" is the CHOICE "check", then:
"sf-transfer-manipulation-not-supported"
and human-readable text generated by MF1. The diagnostic shall be returned to the superior, completing the procedures of this clause in this case.
This clause is referenced by 3.4.7.2 and 3.19.11, and is applicable to work specifications which were secured by the JTM service provider as specified in 3.4.7.2 or 3.4.2, following provider acceptance commitment.
3.5.1 Where a work specification is retained following provider acceptance, it shall be made visible for the actions specified in clause 3.10.
3.5.2 Further processing may not be possible for one of four reasons:
NOTE -- An implementation failing to progress a work specification because repeated RETRY-LATER responses are received for a considerable, implementation-dependant period may follow the procedures of 3.5.11.
A work specification that is held, and to which any of the other reasons, a) to c) applies, is considered to be held. The held work specification will remain held until all the "Hold-element"s with "hold-location" equal to the local JTM-name MF2 have been removed, either by work-manipulation activity (clause 3.10) or when the "release-time" is reached (clause 3.19).
NOTE -- A work specification may be waiting for several resources. Many work specifications may be waiting for the same or a different resource. Queuing strategy and queue visibility for resources is an implementor's option and is not constrained by this International Standard. Queueing strategy should, however, normally give priority to report movement and work manipulation work specifications, and can also take account of the "urgency", <estimated size> and <time waiting>.
3.5.3 Where progress of a work specification that is not held, requires resources which are all available for any continuous period of time T, then an attempt shall be made to progress the work specification during the period T. T shall be specified in the product specification, but is not constrained by this International Standard. The work specification shall be progressed using the procedures of 3.4.8 to 3.4.10 , with the JTM ASE as a CCR commitment master.
NOTE -- It is expected that T will vary during the life of a work specification, probably on an exponential basis.
3.5.4 When progressing a work specification as a CCR commitment master, a unique atomic action identifier shall be generated, a commitment level of one shall be requested and the CCR diagnostic code indicator shall be set from the <CCR parameters> field of the work specification.
If the implementation is an extended implementation, and any C-READY indication or C-ROLLBACK indication user data fields received by the JTM ASE include "accounting-info", the procedures of clause 3.15 shall be invoked, with the nominated bit the "accounting-data" bit and the "event-identification" of any "Single-report" created by that clause set to the value
accounting-data
{text text ,
accounting-information a }
where text is human-readable text generated MF1 and a is a SET of containing "Charging-information" from the "accounting-info" on the CCR primitives received. If several "Charging-information" are received, it is an implementation option whether "Charging-information" are accumulated into a SET of several members, or whether clause 3.15 is invoked repeatedly, provided in either case, each "Charging-information" is passed to the procedures of clause 3.15 only once.
If an offer of commitment is received from all subordinates, 3.5.8 shall be applied. If a retry-later diagnostic indication is received, 3.5.2 and 3.5.3 shall be applied.
NOTE -- It is an implementation option whether to retain certain resources when others are unavailable, or to order rollback in relation to the available resources and attempt the entire processing from the beginning later.
3.5.5 If one or more no-retry diagnostics are received, and the work specification has a subjob type of "report-movement", then rollback shall be ordered. Further progress is not determined by this International Standard.
NOTE -- It is recommended that human management be informed of a failure to progress report-movement subjobs.
3.5.6 If one or more no-retry diagnostics are received, and the "subjob- type" is not "report-movement",then
3.5.6.1 The procedures of clause 3.15 shall be applied, with the nominated bit the "abnormal-termination" bit and the "event-identification" of any "Single-report" created by that clause set to the value
abnormal-termination
{text text ,
spawn-count s ,
errors
{generator-details g ,
diagnostics d } }
where text is human-readable text generated MF1, s is an integer, the sum of the <times spawned> for all the top-level proformas in this work specification and d is the "no-retry<CCR-diagnostics". The entity that the diagnostic was received from shall determine the value g according to:
The main atomic action shall be rolled back and the work specification shall be discarded. Securing (and optionally processing) any report-movement work specification created by the procedures of clause 3.15 shall commit when the main atomic action rolls back.
3.5.6.2 A "Hold-element" shall be added to the "holds" of the outermost "subjob specification" with the following value :
{location n ,
diagnostic-info
{generator-details g ,
diagnostics d } ,
release-time
{time-interval m } }
where n is the local JTM-name from MF2, d is the "no-retry<CCR-diagnostics", g is set as specified in 3.5.6.1 and m is copied from the integer in the "error-action". The procedures of clause 3.19 shall be invoked for the work specification, changing the <hold state> to HELD.
The "error-action" shall be changed to "terminate".
The procedures of clause 3.15 shall be applied, with the nominated bit the "no-progress" bit and the "event-identification" of any "Single-report" created by that clause set to the value
no-progress
{text text ,
errors
{generator-details g ,
diagnostics d } }
where text is human-readable text generated by MF1 and g and d shall be identical to the values in the added "Hold-element".
The main atomic action shall be rolled back. Further processing of the held work specification is as specified in 3.5.2.
3.5.7 If any CCR "Warning diagnostics" are received and the implementation is not a Basic Class implementation, 3.5.7.1 shall be applied. If the implementation is a Basic Class implementation, any CCR "Warning diagnostics" shall be discarded. 3.5.8 shall be applied.
3.5.7.1 The procedures of clause 3.16 shall be invoked for this work specification with the nominated bit the "warning-report" bit and, the "event-identification" of any "Single-report" created by that clause set to the value
warning-report
{text text ,
errors
{generator-details g ,
diagnostics d } }
where text is human-readable text generated MF1, g is set as specified for g in 3.5.6.1 and d is the received "warning<CCR-diagnostics".
If these procedures produce an offer of commitment, 3.5.8 shall be applied. If a retry-later diagnostic is received, 3.5.2 and 3.5.3 shall be applied. If a no-retry diagnostic is received, 3.5.6 is applied.
3.5.8 Offers of commitment shall produce a commit order. The work specification shall be deleted after issue of the commit order and before deletion of the CCR atomic action data when the confirmation of commitment is received.
3.5.9 Application or communication failures occurring prior to the ordering of commitment shall be treated as receipt of retry-later diagnostics — 3.5.2 and 3.5.3 shall be applied, the subsequent attempt shall be made in a new atomic action. Application or communication failures occuring after the ordering of commitment shall be recovered using the CCR recovery procedures as specified in ISO/IEC 9804.
3.5.10 Progress of one work specification shall not be prevented by an inability to progress other work specifications, unless the work specifications concerned require access to a common agency, or a transfer to a common site.
3.5.11 Human management should be informed of the repeated retry-later responses, and may be required to determine whether to proceed with this subclause, or to continue to apply 3.5.2 and 3.5.3. The most-recent retry-later diagnostic shall be converted to a no-retry diagnostic by the removal of any retry-timer and the addition of an element with "generator" set by MF2, a "code" of "sf-repeated-retries" and "text" set by MF1. The procedures of 3.5.5 and 3.5.6 are applied.
This clause shall only be applied to a top-level "sub-job-specification" in a work specification with a "subjob-type" of "document-movement". It is referenced by 3.4.8. The work specification may have activity ids for execution agencies associated with it, where 3.4.8 was invoked by the procedures of clause 3.14.
NOTE -- In the Basic Class, this clause is only invoked to access the JTM service provider for a work-display document, or to access an execution agency (with an "activity id" available) for a single output document.
3.6.1 The procedures of 3.6.2 shall be carried out for each "Single-form Document-pointer" which is a "single-document-reference" CHOICE with the "action-open-system" set to the local "JTM-name" returned by the local management function MF2, and with the "state" set to "not-attempted".
The procedures of 3.6.7 shall be carried out for each "Document-block" which is a "Multiple-form" with the "action-open-system" set to the local "JTM-name" returned by MF2.
3.6.2 If the "source" in the "single-document-reference" is "provider", the "single-document-reference" is processed by the procedures of 3.6.3. If the "source" is "jtm-source", the "single-document-reference" is processed by the procedures of 3.6.4 and 3.6.5. If the "source" is "ftam-source", the procedures of 3.6.6 are applied.
3.6.3 The "document-name" in the "doc-name" in the "single-document-reference" has the value
{s}
where s is a "GraphicString". The JTM service provider has available (in relation to the work specification from which this work specification is being spawned) documents generated as specified in 3.10.8 or 3.10.9. If the s does not match against the name, y, of any of the documents, then 3.6.3.1 shall be carried out. If s does match the name of a document, then if the "access-parameter" has the value "move NULL", the document shall be marked for deletion on commitment and the procedures of 3.6.3.2 shall be carried out for the document.
NOTE -- In Basic Class there is only one document with name "DISPLAY" and the "access-parameter" always has the default value "move NULL".
3.6.3.1 A CCR no-retry diagnostic shall be constructed, with "generator" set to the "JTM-name" returned by MF2, "code" set to
"ue-no-document"
and "reason" set by MF1 to text which shall contain s above.
The "embed-diagnostics" field of the "Document-pointer" shall be examined. If this is "EMBED" then 3.6.3.1.1 shall be applied, if it is "ERROR" then 3.6.3.1.2 shall be applied.
NOTE -- In Basic Class, "embed-diagnostics" always has the default value "EMBED"
3.6.3.1.1 The "single-document-reference" shall have the "state" changed to "failed". The "Time-stamp" shall be set to the current time if this is available, or else shall be set to the choice "not-available NULL". The "diagnostics" shall be set to the CCR no-retry diagnostic specified in the procedure that referenced this subclause. The procedures of clause 3.16 shall be invoked for this work-specification with the nominated bit the "error-diagnostics" bit and, the "event-identification" of any "Single-report" created by that clause set to the value
error-diagnostic
{text text ,
errors {e} }
where text is generated by MF1, and e is a "Diagnostic information", in which the "generator-details" are "provider" if the "Source-identification" in the "single-document-reference" is provider, and is the "Source-identification" otherwise, "when" is null or the current time and "diagnostics" contains the CCR no-retry diagnostic. If these procedures are null or produce and offer of commitment, commitment shall be offered to the superior. This completes the procedures of this clause for this "Document-pointer" in this case.
3.6.3.1.2 Rollback shall be sent to the superior, using the CCR no-retry diagnostics specified in the procedure that referenced this subclause. This completes the procedures of this clause in this case.
3.6.3.2 Where a document is obtained, the document shall be added to the "documents for transfer" in the work specification, following the i<^>th document, where i is the number of "embedded" references in the transfer element before the "Document-pointer" being processed. The "Document-pointer" shall be changed to the CHOICE
embedded NULL
and commitment shall be offered to the superior. This completes the procedures of this clause in this case.
3.6.4 The "source-name", and the human-readable text containing b. If it is an execution agency, and these procedures are not being invoked as part of spawning (see clause 3.14), the procedure of 3.6.3.1 shall be carried out, but with a "code" set to
and the human-readable text containing b. Otherwise, if it is found, then a J-GIVE commitment group shall be initiated to that agency as part of the atomic action causing this processing. The parameters are set as specified in 3.6.4.1 to 3.6.4.6 below. The processing of the J-GIVE response is specified in 3.6.5.
3.6.4.1 The local management function MF15 determines whether this agency requires an authorisation element, and if so, which user identification authority it recognises. If none is required, the <user authority> shall be set to NOT-KNOWN. If one is required, then it shall be set, in order of preference, to
from an authenticated authorisation element, or to
if an authenticated one cannot be found or to
if there is no element for the required user identification authority.
3.6.4.2 The local management function MF15 also determines whether account information can be supplied to this agency, and if so, which user identification authority it recognises. If none can be supplied, the <user account> shall be set to NOT-KNOWN. If one can be supplied, then it shall be set, in order of preference, to
from an authenticated account element, or to
if an authenticated account element cannot be found or to
if there is no account element for the required user identification authority.
3.6.4.3 The <additional authorisations> shall be set from the "additional-authorisations" in the "source" if this are present, otherwise the <additional authorisations> shall be null.
3.6.4.4 The <agency parameter> shall be copied from the "agency-parameter" in the "source".
3.6.4.5 If a value is present for the "access-parameter" in the "Document-source-reference", the <source access parameter> in the <document source reference> shall be set from it. If no value present, and the <source access parameter> shall be MOVE if the agency is an execution agency, and COPY if the agency is a source agency. The <name-list> in the <document source reference> shall be set from the list of strings 3.6.4.6 The <document type> shall be set to the "document type" of the "Document-movement" containing the document pointer.
3.6.4.7 If the agency is a source agency, the <document group> shall be set to PERMANENT.If the agency is an execution agency and these procedures are being invoked as part of task-end spawning (see clause 3.13) the <document group> shall be set to <activity end group> using the agency activity id for this agency and the "agency-activity-id" in the "Source-identification". If the agency is an execution agency and these procedures are being invoked as part of demand spawning (see clause 3.18) the <document group> shall be set to <proforma group> using the name of the proforma being spawned and the agency activity id for this agency and the "agency-activity-id" in the "Source-identification". If more than one agency activity id is available for the agency, the "agency activity label", if present, shall b
3.6.4.8 This completes the definition of the parameters of the J-GIVE indication.
3.6.5 The J-GIVE response carries a document, or there is a C-ROLLBACK specifying NO-RETRY or there is a C-ROLLBACK specifying RETRY-LATER. In the first case the procedure of 3.6.3.2 shall be carried out to complete the procedures of this clause. Any CCR Warning-diagnostic shall be returned to the commitment master (unless a higher-severity error occurs). In the second case, the diagnostic shall have been formulated by the agency to contain a "JTM-name" assigned to this open system (or to the open system accessed by non-standard protocols), a "code" of
and a "reason" obtained by MF1. The procedures of 3.6.3.1 shall be carried out, but with the "no-retry<CCR-diagnostics" set to the diagnostic returned by the agency. In the third case, a similar diagnostic shall have been formulated, but with a "code" of
and, optionally, a retry timer. Clauses 3.4 and 3.5 specify the subsequent procedures.
3.6.6 If the implementation does not support ftam access, the procedures of 3.6.3.1 shall be carried out, with a "code" set to
and "reason" set by MF1. Otherwise the "ftam-read-data" from the "Document-source-reference" shall be passed as part of the atomic action, in an implementation-dependant manner, to an FTAM initiator. If any "action-result" in the "ReadTransferOutcome" returned by the FTAM initiator is "permanent-error", the procedures of 3.6.3.1 shall be followed, but with the code in the diagnostic set to
and "ftam-outcome" set to the "ReadTransferOutcome" returned by the FTAM initiator. If any "action-result" is "transient error", a retry-later CCR diagnostics shall be passed to the commitment superior, ending the procedures of this clause. If all "action-result"s are "success", and there are any "diagnostic"s in the "WriteTransferOutcome" a warning CCR diagnostic shall be formulated, with the JTM-code
"w-ftam-warning"
and "ftam-outcome" set to the "WriteTransferOutcome". The procedures of 3.6.3.2 shall be followed.
3.6.7 The "source-name" 3.6.7.1 A CCR no-retry diagnostic shall be constructed, with "generator" set to the "JTM-name" returned by MF2, "code" set to
and "reason" set by MF1 to text which shall contain b above.
The "embed-diagnostics" field of the "Document-pointer" shall be examined. If this is "EMBED" then 3.6.7.2 shall be applied using the above CCR diagnostic, if it is "ERROR" then 3.6.3.1.2 shall be applied using the above CCR diagnostic.
3.6.7.2 The "Multiple-form" "document-block" shall be replaced by a "Single-form" "document-block" with the following value. Fields copied from the corresponding field of the original "Multiple-form" "document-block" are indicated by the word COPIED.
where c is set from the "doc-se-skeleton" of the "Multiple-form" and e is set from the "doc-source-skeleton" of the "Multiple-form". time shall be set to the current time if this is available, otherwise is shall be set to the choice "not-available NULL". nrd shall be set to the CCR no-retry diagnostic specified in the procedure that referenced this subclause.
The procedures of clause 3.16 shall be invoked for this work-specification with the nominated bit the "error-diagnostics" bit and, the "event-identification" of any "Single-report" created by that clause set to the value
where text is generated by MF1, a is the agency name, time is null or the time of the J-GIVE indication and nrd is the CCR no-retry diagnostic returned by the agency. If these procedures are null or produce an offer of commitment, commitment shall be offered to the superior. This completes the procedures of this clause for this "Document-movement".
3.6.7.3 A J-ENQUIRE commitment group shall be initiated to the agency as part of the atomic action causing this processing. The parameters are set as specified in 3.6.4.1 to 3.6.4.4, 3.6.7.3.1, 3.6.7.3.2, 3.6.4.6 and 3.6.4.7. The processing of the J-ENQUIRE response is specified in 3.6.8.
3.6.7.3.1 If a value is present for the "access-parameter" in the "doc-source-skeleton", the <source access parameter> in the <document source skeleton> shall be set from it. If no value is present, the <source access parameter> shall be MOVE if the agency is an execution agency, and COPY if the agency is a source agency. The <partial name-list> in the <document source skeleton> shall be set from the list of strings 3.6.7.3.2 The <document selector> shall be set from the "document-selector" in the "Multiple-form".
3.6.8 The J-ENQUIRE response carries a non-empty list of <name-list>s, or there is a J-ROLLBACK specifying NO-RETRY or there is a J-ROLLBACK specifying RETRY-LATER. In the first case the procedure of 3.6.8.1 shall be carried out for each name-list in the list on the J-ENQUIRE response. Any CCR Warning-diagnostic shall be returned to the commitment master (unless a higher-severity error occurs). If commitment is offered for all the name-lists in the collection, 3.6.8.2 shall be carried out. In the second case, the diagnostic shall have been formulated by the agency to contain a "JTM-name" assigned to this open system (or to the open system accessed by non-standard protocols), a "code" of
and a "reason" obtained by MF1. The procedures of 3.6.7.1 shall be carried out, but with the "no-retry<CCR-diagnostics" set to the diagnostic returned by the agency. In the third case, a similar diagnostic shall have been formulated, but with a "code" of
and, optionally, a retry timer. Clauses 3.4 and 3.5 specify the subsequent procedures. with a diagnostic.
3.6.8.1 A J-GIVE commitment group shall be initiated to the agency as part of the atomic action causing this processing. The parameters are set as specified in 3.6.4.1 to 3.6.4.4, 3.6.8.1.1, 3.6.4.6 and 3.6.4.7. The processing of the J-GIVE response is specified in 3.6.8.1.2.
3.6.8.1.1 If a value is present for the "access-parameter" in the "doc-source-skeleton", the <source access parameter> in the <document source reference> shall be set from it. If no value present, the <source access parameter> shall be MOVE if the agency is an execution agency, and COPY if the agency is a source agency. The <name-list> in the <document source reference> shall be set by appending the name-list returned by the J-ENQUIRE to the list of strings 3.6.8.1.2 The J-GIVE response carries a document. Any CCR Warning-diagnostic shall be returned to the commitment master.
A new "Document-movement" is added to the work-specification immediately before the "multiple-form" "Document-movement", with the following value. Fields copied from the corresponding field of the original "Document-movement" containing the "Multiple-form" "document-block" are indicated by the word COPIED.
where dse is produced by appending this <name-list> returned on the J-ENQUIRE to the end of the "document-name" in the "doc-se-skeleton" of the "Multiple-form". The document obtained by the J-GIVE shall be added to the "documents-for-transfer" in the work specification, following the ith document, where i is the number of "embedded" references in the transfer element before the "Document-movement" just added.
This completes the processing for this name-list on the J-ENQUIRE response.
3.6.8.2 The "Multiple-form" "Document-pointer" shall be removed from the work specification and commitment offered to the superior, completing the procedures of this clause.
This clause is applicable to any work specification which is to be sent, using the "Transfer-element" syntax, to another open system. It is referenced by 3.4.9 and 3.4.10.
3.7.1 If the local management function MF16 specifies that authorisation is required for transmission activity, then the implementation shall determine the user identification authority required and seek an authorisation element containing an authenticated user identification for that authority. If this is not found, or if the user identification has not been given the necessary authorisation, then the action shall be as if the transmission attempt had failed, with JTM-code set to
and human-readable text set by the local management function MF1. The diagnostic shall be returned to the superior, completing the procedures of this clause in this case.
3.7.2 If the local management function MF16 specifies that account identification can be supplied for transmission activity, then the implementation shall determine the user identification authority required and seek an account element containing an authenticated user identification for that authority. If this is not found, no account identification is supplied (any required is deduced from the authorisation identification).
3.7.3 The local management directory function MF16 shall be used to determine the addressing and other information needed to establish a connection in "ISO JTM Basic Class Application-context" or "ISO JTM Full Application-context" to the "target", if the "relays" is empty, or otherwise to the first component in "relays".
If the directory search fails, the action shall be as if the transmission attempt had failed with JTM-code set to
and including the faulty "JTM-name" in the human-readable text (MF1). The diagnostic shall be returned to the superior, completing the procedures of this clause in this case.
If the directory search determines that connection is only possible in "ISO JTM Basic Class Application-context" and the work specification exceeds the Basic Class restrictions, the action shall be as for a failed directory search, but with the JTM-code set to
3.7.4 If the implementation supports TRANSFER-CONTROL and the ASE has stored a transfer-control record in which the <recipient> is equal to the "JTM-name" in the first component of the "relays", or if "relays" is empty, the <recipient> is equal to the "JTM-name" in the "target", the procedures of 3.7.4.1 shall be followed. Otherwise the procedures of 3.7.4.1 shall be omitted and processing continued with 3.7.5.
3.7.4.1 If the <control spec> in the transfer control record is UNCONTROLLED, or the "subjob-type" of the work-specification is "tcr-manipulation", the procedures of this subclause are null and processing continues with the procedures of 3.7.5.
If the number of work specifications that are currently being transferred to the <recipient> is equal to the number of "selector"s in the <control spec> and the work specification under consideration is does not have a "subjob-type" of "tcr-manipulation", or if the number of work specification being transferred is greater than the number of "selector"s in the <control spec>, the implementation shall generate a retry-later CCR-diagnostic and proceed as specified in clauses 3.4 and 3.5. If the "subjob-type" is "tcr-manipulation" and the number of work-specifications being transferred is exactly equal to the number of "selector"s in the <control spec>, the procedures of 3.7.5 shall be applied.
Otherwise (there being at least one more "selector" in the <control spec> than there are work-specifications being transferred), and an assignment can be found, such that each work specification being transferred and the work specification being considered is assigned to a different "selector", and each work-specification is selected, as specified in 3.10.5, by the "selector" assigned to it, the procedures of 3.7.5 shall be applied. If no such assignment of "selector"s to work-specifications is possible, the implementation shall generate a retry-later CCR-diagnostic and proceed as specified in clauses 3.4 and 3.5.
3.7.5 If there is sufficient authorisation, and if the directory search succeeds, and the procedures of 3.7.4.1 permit a transmission-attempt, then the local management function MF21 shall be used to either
The procedures for use in establishing a new association are specified in section 5.
3.7.6 If MF21 indicates a no-retry failure, then the action shall be as if the transmission attempt had failed, with JTM-code set to
and human-readable text set by the local management function MF1. The diagnostic together with any diagnostic returned by MF21 (see 5.1.3) shall be returned to the superior, completing the procedures of this clause.
If MF21 indicates a retry-later failure, then the implementation shall either
If MF21 supplies an association in "ISO Basic Class Application-context", and the work specification exceeds the Basic Class restrictions (other than by the presence of "accounts"), then the action shall be as if the transmission attempt had failed, with JTM-code set to
and human-readable text set by the local management function MF1 including the "JTM-name" to which the association was established. The diagnostic shall be returned to the superior. The procedures of 3.7.10 shall be carried out.
3.7.7 If MF21 supplies an association in "ISO JTM Basic Class Application-context" and the work specification meets the Basic Class restrictions, other than the presence of "accounts", then the implementation shall issue a C-BEGIN on the application-association, as a branch of this atomic action, and shall then issue a P-DATA containing the following values:
Transfer parameters are specified in section 5.
C-PREPARE shall not be used, the atomic action being delimited by the end of the single P-DATA.
The procedures of 3.7.9 and 3.7.10 are applied.
The concatenations of C-COMMIT+C-BEGIN and C-ROLLBACK+C-BEGIN, specified in ISO/IEC 9805 shall not be used on an association with application context "ISO JTM Basic Class Application-context".
3.7.8 If MF21 supplies an association in "ISO JTM Full Application-context", then the implementation shall issue a C-BEGIN on the application association, as a branch of this atomic action, and shall then issue P-DATA containing the following values:
The implementation shall then issue a C-PREPARE on the application association, delimiting the atomic action.
Transfer parameters are specified in section 5.
The procedures of 3.7.9 and 3.7.10 are applied.
The concatenations of C-COMMIT+C-BEGIN and C-ROLLBACK+C-BEGIN, specified in ISO/IEC 9805 shall not be used on an association with application context "ISO JTM Full Application-context".
3.7.9 The resulting C-READY or C-ROLLBACK indications are used as the result of this branch of the atomic action, and are processed as specified in clauses 3.4 and 3.5.
3.7.10 Following completion of the atomic action, the application-association becomes available for other outgoing JTM transfers (see MF21), or may be relinquished using A-RELEASE with parameters as specified in 5.2. This completes the procedures for this clause.
This clause is invoked by 3.4.10. It is applied to transfer elements with an outermost "subjob-type" of "document-movement" ,with "relays" empty and the "target" equal to the local open system MF2.
3.8.1 The procedures of 3.8.2 to 3.8.6 shall be applied in turn to each "document movement" in the outermost "document-movement-operations" SEQUENCE. 3.8.7 shall then be applied, completing the procedures of this clause.
3.8.2 A check shall be applied to the document-movement that each "Document-pointer" is the CHOICE "embedded" or has "state" "failed". If the check fails, then a CCR no-retry diagnostic shall be generated for each such failure with a JTM-code of
and human text provided by the local management function MF1. The text shall contain the document name from the reference. This branch of the atomic action shall fail, returning the diagnostic to the superior. This completes the procedures of this clause in this case.
3.8.3 If the "Se-identification"s in the "ses" are the CHOICE "jtm-se", 3.8.4 shall be applied to each. If the "Se-identification" are "ftam-se", 3.8.5 shall be applied.
3.8.4 The "Agency-name" in each "Se-identification" in the "ses" SEQUENCE shall be checked by the management function containing the list of local sink and execution agencies MF15. If it is not found, then a CCR no-retry diagnostic shall be issued with the JTM-code
and human-readable text MF1 containing the agency name. This is returned to the superior completing the procedures of this clause in this case. If the checks succeed the procedures of 3.8.6 shall be followed.
3.8.5 If the implementation does not support ftam access, a CCR no-retry diagnostic shall be issued with the JTM-code
and human-readable text generated by MF1. This is returned to the superior completing the procedures of this clause in this case. If the implementation does support ftam the procedures of 3.8.8 shall be followed.
3.8.6 A J-DISPOSE indication shall be initiated to the "Se-identification" checked in 3.8.4 as part of the atomic action causing this processing. The parameters shall be set as specified in 3.8.6.1 to 3.8.6.8. The J-DISPOSE response shall be processed as specified in 3.8.7.
3.8.6.1 A provider activity id shall be generated, distinct from any current activity, and different for each J-DISPOSE which has not proceeded to completion.
3.8.6.2 The procedures of 3.6.4.1 and 3.6.4.2 shall be invoked to generate authorisation and account parameters.
3.8.6.3 The <agency parameter> shall be set from the "agency-parameter" in the "Se-identification".
3.8.6.4 The <additional authorisations> shall be set from the value in the "additional-authorisations" in the "Se-identification" if this is present, otherwise the <additional authorisations> shall be null.
3.8.6.5 The <document se reference> shall be set from the value in the "Single-form document block". If the "access-parameter" is not present, the <se access parameter> shall be NORMAL.
3.8.6.6 The <document type> shall be set to the "type" in the "document-movement" SEQUENCE.
3.8.6.7 Where the agency cannot accept the document name in the <document se reference>, it shall generate a local name which differs from that of any other local document, and shall, if it offers commitment, return a warning CCR diagnostic with JTM-code
and human-readable text MF1 which contains both the old and the new names.
3.8.6.8 The <disposal document> shall be the documents in the work specification corresponding to any "embedded" "Document-pointer"s in the document-movement. If more than one "embedded" is present, they shall be concatenated, using the concatenation rules specified for the document, in the order defined by the SEQUENCE OF "Document-pointers". The <errors> shall consist of one <diagnostic information> for each "Document-pointer" with "state" "failed", in the order defined by SEQUENCE OF "Document-pointers". In each <diagnostic information>, the <generator details> shall be set from the "Source-identification" and the "Document-source-reference" of the "Document-pointer", and the <time stamp> and <CCR-diagnostics> shall be taken from the "failed" "state".
If the <agency parameter> is STORE, and the agency is both a sink and source agency, the agency shall ensure that a subsequent J-GIVE response will return a <document> identical to the <disposal document> if the J-GIVE indication carries the same <document type>, <agency parameter> as were present on the J-DISPOSE and if the <document source reference> is as specified in a) or b) below.
If the <agency parameter> is NULL, the agency shall convert all document types and <errors> into a suitable local syntax. In this case it is not required that the original information in a document should be fully recoverable by a J-GIVE.
This completes the specification of the J-DISPOSE parameters.
3.8.7 Each J-DISPOSE commitment group produces either
An extended implementation shall ensure that an execution agency shall not offer COMPLETION commitment unless either
If any J-ROLLBACK requests are received, 3.8.9 shall apply. If all J-READY requests offer COMPLETION commitment, 3.8.10 shall apply. If any J-READY request offers AGENCY ACCEPTANCE, 3.8.11 shall apply.
3.8.8 The "ftam-write-data" from the "Document-se-reference" and the document as specified in 3.8.6.8 shall be passed, as part of the atomic action, in an implementation-dependant manner, to an FTAM initiator. If any "action-result" in the "WriteTransferOutcome" returned by the FTAM initiator is "permanent error", the procedures of 3.8.9 shall be followed, but with the code in the diagnostic set to
and "ftam-outcome" set to the "WriteTransferOutcome". If any "action-result" is "transient error", a retry-later CCR diagnostics shall be passed to the commitment superior, ending the procedures of this clause. If all "action-result"s are "success", and there are any "diagnostic"s in the "WriteTransferOutcome" a warning CCR diagnostic shall be formulated, with the JTM-code
and "ftam-outcome" set to the "WriteTransferOutcome". The procedures of 3.8.10 shall apply.
3.8.9 The CCR diagnostic shall be passed to the superior, completing the procedures of this clause. The CCR diagnostic from the agency shall have been formulated to contain an "JTM-name" assigned to the open system (or to the open system accessed by non-standard protocols), and
3.8.10 The spawning procedures of clause 3.14 shall be invoked as part of the atomic action and with the same requested commitment level to spawn any proformas with "spawning-control-data" any of the CHOICEs "acceptance", "completion" or "conditional". Commitment shall, in this case not be offered to the superior of this activity until the spawning procedures of clause 3.14 are complete.
The procedures of clause 3.16 shall be applied with the same requested commitment level as the main atomic action, with the nominated bit the "normal-termination" bit and the "event-identification" of any report created by that clause set to the value
where text is human-readable text generated by MF1 and n is an integer, the sum of the <times spawned> for the top-level proformas in the original work specification. If the procedures of clause 3.16 produce rollback, 3.8.9 shall apply, otherwise commitment shall be offered to the superior.
This completes the procedures of this clause in this case.
3.8.11 The spawning procedures of clause 3.14 shall be invoked as part of the atomic action to spawn any proformas with "spawning-control-data" the CHOICE "acceptance". The commitment level requested shall be that of the main atomic action. If these procedures produce a rollback, 3.8.9 shall apply.
A new work specification shall be created and secured as part of the main atomic action, as specified in 3.8.12.
The procedures of clause 3.16 shall be applied with a requested commitment level equal to that of the main atomic action, with the nominated bit the "agency-acceptance" bit and the "event-identification" of any report created by that clause set to the value
where text is human-readable text generated by MF1. If these procedures produce rollback, 3.8.9 shall apply, otherwise commitment shall be offered to the superior, completing the procedures of this clause. The work specification is progressed further as part of the J-END-SIGNAL procedures specified in clause 3.13.
3.8.12 The new work specification is a copy of the old work specification with the following changes:
The new work specification shall be made visible for the procedures of 3.10.2.
This clause is invoked by 3.4.10. It is applied to transfer elements with a "subjob-type" of "report-movement" , with "relays" empty and the "target" equal to the local open system.
3.9.1 The "JTM-name" in the "monitor-system-name" in each "Monitoring-specification" in the "primary-monitoring-specification" and the "secondary-monitoring-specification" shall be compared with the local open-system-name MF2. If a "monitor-system-name" matches the local open-system-name, the procedures of 3.9.1.1 and 3.9.1.2 shall be applied for that "Monitoring-specification".
If none of the "Monitoring-specification"s have a "monitor-system-name" that matches the local open-system-name, then a CCR no-retry diagnostics shall be generated with the JTM-code
with the human-readable text (MF1) including all the distinct "JTM-name"s in the "monitor-system-name" fields tested. The diagnostic shall be returned to the superior, completing the procedures of this clause in this case.
If none of the components of the "report-movement-operation" contain "monitor-indices" that include the index of a "Monitoring-specification" in which the "monitor-system-name" matches the local open-system-name, then a CCR no-retry diagnostics shall be generated with the JTM-code
with the human-readable text set by MF1. The diagnostic shall be returned to the superior, completing the procedures of this clause in this case.
3.9.1.1 The "monitor-indices" in each component of the "report-movement-operation" shall be examined. If the "monitor-indices" SEQUENCE includes the index of this "Monitoring-specification", which shall be zero if it is the "primary-monitoring-specification" or the ordinal of its position in the "secondary-monitoring-specification" SEQUENCE, the "Single-report" in that component shall be included in the further procedures of this clause for this "Monitoring-specification".
3.9.1.2 If the "disposal-instructions" in the "Monitoring-specification" is the CHOICE "disposal-data", 3.9.2 shall be applied. If it is the CHOICE "keep NULL", 3.9.8 shall be applied.
3.9.2 The Agency-name in the Se-identification shall be checked by the local management function (MF15) containing the list of local sink agencies. If it is not found, then a CCR no-retry diagnostic shall be generated with JTM diagnostic code
and human-readable text (MF1) including the incorrect name. The diagnostic shall be returned to the superior, completing the procedures of this clause in this case.
If it is found and the procedures of 3.9.1.1 determined that at least one "Single-report" was to be included in the processing for this "Monitoring-specification", then a J-DISPOSE commitment group shall be initiated to the agency, as part of the atomic action causing this processing. The parameters of the J-DISPOSE indication shall be set as specified in 3.9.2.1 to 3.9.2.6.
If it is found and the procedures of 3.9.1.1 determined that no "Single-report"s were to be included in the processing for this "Monitoring-specification", the procedures for this "Monitoring-specification" are complete.
3.9.2.1 A <provider activity id> shall be generated, distinct from that of any current activity.
3.9.2.2 The procedures of 3.6.4.1, 3.6.4.2 and 3.8.6.4 shall be invoked to generate authorisation and account parameters.
3.9.2.3 The <agency parameters> shall be set from the "agency-parameter" in the "Se-identification".
3.9.2.4 The <document-se-reference> shall be set from the "Document-se-reference" in the "disposal-instructions". If the "access-parameters" is not present, the <se access parameter> shall be ADD.
3.9.2.5 The <document> shall be a <JTM-report-display> containing all the "Single-report"s that were determined by the procedures of 3.9.1.1 to be included in the processing for this "Monitoring-specification". Each "single-report" shall become a <report>, the <OSI job monitor system> shall be set by MF2, and the <time stamp> shall be the time of the J-DISPOSE.
3.9.2.6 The <errors> parameter shall be an empty list.
This completes the specification of the parameters of the J-DISPOSE indication.
3.9.3 The J-DISPOSE commitment group produces either
3.9.4 If a J-ROLLBACK request is issued for the J-DISPOSE group, then the diagnostic shall be passed to the superior, completing the procedures of this clause.
3.9.5 If COMPLETION commitment is offered, this shall be returned to the superior, completing the procedures for this clause.
3.9.6 If the agency is offering only AGENCY ACCEPTANCE, the procedures of 3.8.11 and 3.8.12 shall apply.
3.9.7 The agency shall format the <JTM-report-display> into human-readable text. The format is not standardised. Any no-retry diagnostic issued by the agency shall have a "code" of "ue-disposal-error". Any retry-later diagnostic issued by the agency shall have a code of "rl-document-disposal".
3.9.8 If the implementation supports the procedures of 3.9.8.2, these shall be applied. If the implementation does not support the procedures of 3.9.8.2, the procedures of 3.9.8.1 shall be applied.
3.9.8.1 A CCR no-retry diagnostic shall be generated with the JTM-code
and with human-readable text generated by MF1. The diagnostic shall be passed to the superior, completing the procedures of this clause.
3.9.8.2 All the "single-report"s and all the "permissions" in the work specification shall be stored and commitment offered to the superior. They shall be retained after commitment has been ordered for at least the length of time returned by management function MF27 and shall, for that period be accessible to the procedures of clause 3.11. The stored "permissions" shall be associated with the "single-report"s to enable conformance with the procedures of 3.11.3. If rollback is ordered for the procedures of this clause the stored "single-report"s and "permissions" are deleted.
This is invoked by 3.4.10.
This clause is invoked by 3.4.10. It is applied to work specifications with an outermost "subjob-type" of "work-manipulation", with "relays" empty and with the "target" equal to the local open system MF2.
The procedures of the appropriate subclause from 3.10.5 to 3.10.10 are applied in turn to each "work-operation" in the outermost "Work-manipulation-operations" SEQUENCE. The procedures of 3.10.11 and 3.10.12 are then applied.
A "Work-operation" with the CHOICE "select" selects work specifications and proformas as specified in 3.10.5. These work specifications and proformas then remain selected for the application of the procedures 3.10.6 to 3.10.10 to any following "Work-operations" in the "Work-manipulation-operation" SEQUENCE, until a following "Work-operation" with CHOICE "select",if any, or the end of the "Work-manipulation-operation" SEQUENCE.
3.10.1 Each work specification which is visible to these procedures (as specified in clauses 3.4, 3.5, 3.8 and 3.9) is in one of three categories determined by the procedures of 3.10.2 to 3.10.4. These categories are:
3.10.2 A work specification is modifiable if it is not currently involved in any commitment group for which commitment has been offered by this JTM entity and if any of the following conditions hold (note - "permission elements" are taken from the work specification which is a candidate for modification, "authorisation elements" are taken from the work specification which contains the "work-operation"):
3.10.3 A work specification is displayable if either:
3.10.4 A work specification is untouchable otherwise.
3.10.5 A "Work-operation" of
selects work specifications and proformas as specified in the procedures of 3.10.5.2. Each subclause of 3.10.5.2 specifies the selection made by "Selection" x, dependent on the CHOICE of "selector-form". Each subclause of 3.10.5.2 references 3.10.5.3 to specify the evaluation of the "Header-test" in x.
if and only if
3.10.5.1 The procedures for selection are specified using "headers", which are conceptual information objects. For each work specification that is made visible to the procedures of this clause, there is a list of headers containing one header corresponding to each "Subjob-specification" in the work specification - one corresponding to the outermost subjob and one corresponding to each proforma, at any level of nesting in the work specification.
A header contains some fields global to the work specification, which are present and identical in all headers in the list, and some which are copied from the specific "Subjob-specification".
Fields in headers are referenced in these procedures by using the names of the standard syntactic representation of a header, specified in 2.7. The use of this notation, and the use of the model of header and header-list does not constrain the implementation as to the way the information is held.
A header has the following value. Fields global to and copied from the corresponding work specification are indicated by the word GLOBAL. Fields copied from the corresponding "Subjob-specification" are indicated by the word SUBJOB, and are null if no subjob is present. The word CONCATENATED indicates a value formed from the "Subjob-specification" by copying all the components of the appropriate data type, in their order in the abstract syntax definition of the "Subjob-specification", into a single SEQUENCE.
In the first header in the list the "subjob-name-list" is identical to that in the work-specification. In a header corresponding to a proforma, the "subjob-name-list" contains the components in the "subjob-name-list" in the work-specification, followed by one component for each nested proforma if any, down to the the proforma corresponding to the header. Each component representing a proforma has the "proforma-name" set from the "proforma-name" of the Proforma and a "qualifying-integer" of zero.
3.10.5.2 The "selector-form" in a "selector" determines the which work specifications or proformas are selected on the basis of the application of the "header-test" to the header-list for the work-specification, as specified in 3.10.5.2.1 to 3.10.5.2.6.
A work specification may be directly selected, by the application of a selector to its header-list, or indirectly selected, if a selector selects a nested proforma, but not the outermost subjob specification. Throughout the procedures of this clause, and of other clauses that reference this one, the term 'selected work specification' unless further qualified, includes both directly and indirectly selected work specifications.
3.10.5.2.1 A work specification is directly selected by a selector with "selector-form" CHOICE of "first-header-is" if and only if the application of the procedures of 3.10.5.3 using the "header-test" in the selector produce a SUCCESS result for the header corresponding to the outermost subjob in the work specification.
3.10.5.2.2 A work specification is directly selected by a selector with "selector-form" CHOICE of "contains-header" if and only if the application of the procedures of 3.10.5.3 using the "header-test" in the selector produce a SUCCESS result for at least one header corresponding to a proforma in the work specification.
3.10.5.2.3 A work specification is directly selected by a selector with "selector-form" CHOICE of "does-not-contain-header" if it contains no proformas or if the application of the procedures of 3.10.5.3 using the "header-test" in the selector produce a FAIL result for every header corresponding to a proforma in the work specification.
3.10.5.2.4 A work specification is directly selected by a selector with "selector-form" CHOICE of "header-is" if and only if the application of the procedures of 3.10.5.3 using the "header-test" in the selector produce a SUCCESS result for the header corresponding to the outermost subjob in the work specification.
3.10.5.2.5 A work specification is indirectly selected by a selector with "selector-form" CHOICE of "header-is" if and only if the application of the procedures of 3.10.5.3 using the "header-test" in the selector produce a FAIL result for the header corresponding to the outermost subjob in the work specification and produces a SUCCESS result for at least one header corresponding to a proforma.
3.10.5.2.6 A proforma is selected by a selector with "selector-form" CHOICE of "header-is" if and only if the application of the procedures of 3.10.5.3 using the "header-test" in the selector produce a SUCCESS result for the header corresponding to the proforma.
3.10.5.3 A "header-test" shall produce a SUCCESS or FAILURE value as specified in the appropriate subclause of 3.10.5.3.1 to 3.10.5.3.6
3.10.5.3.1 A "header-test" which is the CHOICE "field-test" shall produce a result as specified in 3.10.5.4
3.10.5.3.2 A "Header-test" which is the CHOICE "and-clause" shall produce a SUCCESS result if both "header-one" and "header-two" "Header-test"s produce a FAIL result.
3.10.5.3.3 A "Header-test" which is the CHOICE "or-clause" shall produce a FAIL result of both "header-one" and "header-two" "Header-test"s produce FAIL results, otherwise it shall produce a SUCCESS result.
3.10.5.3.4 A "Header-test" which is the CHOICE "not-clause" shall produce a SUCCESS result if the contained "Header-test" produces a FAIL result, and shall produce a FAIL result if the contained "Header-test" produces a SUCCESS result.
3.10.5.3.5 A "Header-test" which is the CHOICE "success" shall produce a SUCCESS result.
3.10.5.3.6 A "Header-test" which is the CHOICE "fail" shall produce a FAIL result.
3.10.5.4 A "Field-test" produces a SUCCESS result for a header if one of the conditions 3.10.5.4.2 to 3.10.5.4.44 is true, and produces a FAIL result otherwise. These conditions use the term 'matches', which is defined in 3.10.5.4.1.
3.10.5.4.1 There is a 'match' between a value in a header and the corresponding value in a Field-test if at least one of the following conditions applies.
3.10.5.4.2 The "Field-test" CHOICE is "osi-job-submission-system-equals" and the "osi-job-submission-system" in the header is equal to the "JTM-name" in the "Field-test".
3.10.5.4.3 The "Field-test" CHOICE is "initiating-identification-equals" and the "initiating-identification" in the header matches the "Identification" in the "Field-test".
3.10.5.4.4 The "Field-test" CHOICE is "osi-jobname-equals" and the "osi-jobname" in the header is equal to the "Graphic String" in the "Field-test".
3.10.5.4.5 The "Field-test" CHOICE is "primary-monitor-equals" and the "primary-monitoring-specification" in the header matches the "Monitoring-spec-value" in the "Field-test".
3.10.5.4.6 The "Field-test" CHOICE is "secondary-monitors-equals" and the "secondary-monitoring-specification" in the header matches the SET OF "Monitoring-spec-value" in the "Field-test".
3.10.5.4.7 The "Field-test" CHOICE is "secondary-monitor-contains" and at least one "Monitoring-specification" in the "Secondary-monitoring-specification" in the header matches the "Monitoring-spec-value" in the "Field-test".
3.10.5.4.8 The "Field-test" CHOICE is "authorisation-equal" and the "authorisation" in the header matches the SET OF "Authorisation-value" in the "Field-test".
3.10.5.4.9 The "Field-test" CHOICE is "authorisations-contain" and at least one "Authorisation-element" in the "authorisations" in the header matches the "Authorisation-value" in the "Field-test".
3.10.5.4.10 The "Field-test" CHOICE is "accounts-equal" and the "accounts" in the header matches the SET OF "Account-value" in the "Field-test".
3.10.5.4.11 The "Field-test" CHOICE is "accounts-contain" and at least one "Account-element" in the "accounts" in the header matches the SET OF "Account-value" in the "Field-test".
3.10.5.4.12 The "Field-test" CHOICE is "permissions-equal" and the "permissions" in the header matches the SET OF "Permission-value" in the "Field-test".
3.10.5.4.13 The "Field-test" CHOICE is "permissions-contain" and at least one "Permission-element" in the "permissions" in the header matches the SET OF "Permission-value" in the "Field-test".
3.10.5.4.14 The "Field-test" CHOICE is "security-parms-equal" and the "security-parameters" in the header matches the "security-parameter-value" in the "Field-test".
3.10.5.4.15 The "Field-test" CHOICE is "subjob-name-list-equals" and the "subjob-name-list" in the header matches the SEQUENCE of "subjob-name-list-component-value" in the "Field-test".
3.10.5.4.16 The "Field-test" CHOICE is "subjob-name-list-first-of-list" and the first component in the "subjob-name-list" in the header matches the "subjob-name-list-component-value" in the "Field-test".
3.10.5.4.17 The "Field-test" CHOICE is "relays-equal" and the "relays" in the header match the SEQUENCE OF "JTM-name-value" in the "Field-test".
3.10.5.4.18 The "Field-test" CHOICE is "relays contain" and at least one of the "JTM-name"s in the "relays" in the header matches the "JTM-name" in the "Field-test".
3.10.5.4.19 The "Field-test" CHOICE is "relays-first-of-list" and the first "JTM-name" in the "relays" in the header matches the "JTM-name" in the "Field-test".
3.10.5.4.20 The "Field-test" CHOICE is "relays-last-of-list" and the last "JTM-name" in the "relays" in the header matches the "JTM-name" in the "Field-test".
3.10.5.4.21 The "Field-test" CHOICE is "target-equals" and the "target" in the header matches the "JTM-name" in the "Field-test".
3.10.5.4.22 The "Field-test" CHOICE is "urgency-equals" and the "urgency" in the header matches the "Urgency" in the "Field-test".
3.10.5.4.23 The "Field-test" CHOICE is "holds-contains" and at least one "Hold-element" in the "holds" in the header matches the "Hold-element-value" in the "Field-test".
3.10.5.4.24 The "Field-test" CHOICE is "holds-equals" and the "holds" in the header matches the SET OF "Holds-element-value" in the "Field-test".
3.10.5.4.25 The "Field-test" CHOICE is "subjob-type-equals" and the "subjob-type" in the header matches the "Subjob-type" in the "Field-test".
3.10.5.4.26 The "Field-test" CHOICE is "se-lists-equal" and the "se-lists" in the header matches the SEQUENCE OF "se-identification-value" in the "Field-test".
3.10.5.4.27 The "Field-test" CHOICE is "se-lists-contain" and at least one of the "se-identification" in the "se-lists" in the header matches the "Se-identification-value" in the "Field-test".
3.10.5.4.28 The "Field-test" CHOICE is "se-ref-lists-equal" and the "se-ref-lists" in the header matches the SEQUENCE OF "Doc-se-reference-value" in the "Field-test".
3.10.5.4.29 The "Field-test" CHOICE is "se-ref-list-contain" and at least one of the "Document-se-reference" in the "se-ref-lists" in the header matches the "Doc-se-reference-value" in the "Field-test".
3.10.5.4.30 The "Field-test" CHOICE is "source-lists-equal" and the "source-lists" in the header matches the SEQUENCE OF "Source-identification-value" in the "Field-test".
3.10.5.4.31 The "Field-test" CHOICE is "source-lists-contain" and at least one of the "source-identification" in the "source-lists" in the header matches the "source-identification-value" in the "Field-test".
3.10.5.4.32 The "Field-test" CHOICE is "source-ref-lists-equal" and the "source-ref-lists" in the header matches the SEQUENCE OF "Doc-source-ref-value" in the "Field-test".
3.10.5.4.33 The "Field-test" CHOICE is "source-ref-lists-contain" at least one of the "Document-source-reference" in the "Source-ref-lists" in the header matches the "Doc-source-ref-value" in the "Field-test".
3.10.5.4.34 The "Field-test" CHOICE is "error-action-equals" and either the "error-action" in the header is equal to the "Error-action" in the "Field-test" or the "error-action" in the header is the CHOICE "hold" and the "Error-action" in the "Field-test" is the value
3.10.5.4.35 The "Field-test" CHOICE is "time-waiting equals" and the "time-waiting" in the header is equal to the integer in the "Field-test".
3.10.5.4.36 The "Field-test" CHOICE is "time-waiting-gt" and the "time-waiting" in the header is greater than the integer in the "Field-test".
3.10.5.4.37 The "Field-test" CHOICE is "time-waiting-ge" and the "time-waiting" in the header is greater than or equal to the integer in the "Field-test".
3.10.5.4.38 The "Field-test" CHOICE is "time-waiting-lt" and the "time-waiting" in the header is less than the integer in the "Field-test".
3.10.5.4.39 The "Field-test" CHOICE is "time-waiting-le" and the "time-waiting" in the header is less than or equal to the integer in the "Field-test".
3.10.5.4.40 The "Field-test" CHOICE is "estimated-size-equals" and the "estimated-size" in the header is equal to the integer in the "Field-test".
3.10.5.4.41 The "Field-test" CHOICE is "estimated-size-gt" and the "estimated-size" in the header is greater than the integer in the "Field-test".
3.10.5.4.42 The "Field-test" CHOICE is "estimated-size-ge" and the "estimated-size" in the header is greater than or equal to the integer in the "Field-test".
3.10.5.4.43 The "Field-test" CHOICE is "estimated-size-lt" and the "estimated-size" in the header is less than the integer in the "Field-test".
3.10.5.4.44 The "Field-test" CHOICE is "estimated-size-le" and the "estimated-size" in the header is less than or equal to the integer in the "Field-test".
3.10.6 A "work-operation" of
shall cause the procedures of 3.10.6.1 to 3.10.6.4 to be performed (if and only if the manipulation commits) on each work specification which is both selected by the preceding "select" "Work-operation" in the "work-manipulation-operations" as specified in 3.10.5 and modifiable. Such a "work-operation" shall cause the procedures of 3.10.14 to be performed on each work specification that is selected but is not modifiable , unless it fails to be modifiable as specified in 3.10.3 b).
3.10.6.1 Any commitment groups initiated by the procedures of 3.6.4 (J-GIVE and J-ENQUIRE), 3.7.7 (Transfer), 3.8.6 (J-DISPOSE), and 3.9.2 (J-DISPOSE) shall be rolled back.
3.10.6.2 Any commitment groups initiating the procedures of clauses 3.4 (J-INITIATE), 3.3 (Transfer), 3.13 ,3.18 (Spawning), and 3.17 (J-MESSAGE), for this work specification, shall be rolled back with a retry-later diagnostic returned to the superior. This shall contain a "code" of "rl-manipulation-in-progress".
3.10.6.3 Any sink or execution agencies which have given ACCEPTANCE completion shall be issued with a J-STOP primitive group as part of the manipulation atomic action.
3.10.6.4 The procedures of clause 3.16 shall be invoked for this work specification with the nominated bit the "modification" bit and with the "event-identification" of in any "Single-report" created by the procedures of clause 3.16 set to the value
where text is set by MF1 and t is copied from the "relays" and "target" of this work specification. The procedures of clause 3.16 shall be invoked as part of the atomic action doing the manipulation but with a commitment level of one, and shall commit if and only if the manipulation commits.
This completes the procedures of this subclause for this "Work-operation".
3.10.7 A "work-operation" of
shall cause the procedures of 3.10.7.1 to 3.10.7.5 to be performed (if and only if the manipulation commits) on each work specification which is both selected by the preceding "select" "Work-operation" in the "work-manipulation-operations" as specified in 3.10.5 and modifiable. Such a "work-operation" shall cause the procedures of 3.10.14 to be performed on each work specification that is so selected but is not modifiable , unless it fails to be modifiable as specified in 3.10.3 b).
3.10.7.1 Any commitment groups initiated by the procedures of clauses 3.6.4 (J-GIVE), 3.7.7 (Transfer), 3.8.6 (J-DISPOSE), and 3.9.2 (J-DISPOSE) shall be rolled back.
3.10.7.2 Any commitment groups initiating the procedures of clauses 3.4 (J-INITIATE), 3.3 (Transfer), 3.13 ,3.18 (Spawning), and 3.17 (J-MESSAGE), for this work specification, shall be rolled back with a no retry diagnostic containing a JTM diagnostic code of
and human readable text produced by MF1.
3.10.7.3 Any sink or execution agencies which have given AGENCY ACCEPTANCE completion shall be issued with a J-KILL primitive group as part of the manipulation atomic action. The <agency activity id> for the J-KILL is obtained from the work specification.
3.10.7.4 The work specification being manipulated shall be discarded when the manipulation commits.
3.10.7.5 The procedures of clause 3.16 shall be invoked for the work specification being discarded with the nominated bit the "manipulation-termination" bit and with the "event-identification" of in any "Single-report" created by the procedures of clause 3.16 set to the value
where text is human-readable text generated by MF1 and d is an integer, the sum of the <times spawned> for all the top-level proformas in the work specification being discarded. The procedures of clause 3.16 shall be invoked as part of the atomic action doing the manipulation but with a commitment level of one, and shall commit if and only if the manipulation commits.
This completes the procedures of this clause for this "work-operation".
3.10.8 A "Work-operation" of
shall produce a document named y (by the procedures of 3.10.8.1 to 3.10.8.3), associated with the work specification, and collectable by the procedures of 3.6.3. The document is collected as specified in 3.10.11.
The procedures of 3.10.14 shall be performed on each work specification that is selected but is not displayable.
If a document named y has already been produced by the application of this subclause or of 3.10.9 to another "Work-operation" in the "Work-manipulation-operations" SEQUENCE, the new document shall be concatenated to the existing one.
3.10.8.1 The document shall be a "Work-display-doc" with a single SEQUENCE consisting of
3.10.8.2 The "Brief-display" shall be set as follows:
3.10.8.2.1 Where a commitment group initiated by the procedures of 3.6.4 (J-GIVE), 3.7.6 (Transfer), 3.8.6 (J-DISPOSE), and 3.9.2 (J-DISPOSE) is in progress (or awaiting restart), the status shall be set to "in-progress", and the "destination" shall be set to the agency involved, or the recipient open system for the commitment group initiated by the procedures of 3.7.6 (Transfer). "time" shall be set to null or to the time when the C-BEGIN or J-BEGIN for the atomic action was issued.
3.10.8.2.2 Where a sink or execution agency has given ACCEPTANCE completion and not yet issued J-END-SIGNAL, the status shall be set to "accepted" and the "destination" shall be set to the sink or execution agency ("se-agency"). "time" shall be set to null or to the time when the J-READY was issued by the agency giving ACCEPTANCE commitment.
3.10.8.2.3 Where it can be determined (MF20 and MF21) that progress is held up for lack of the ability to access a sink, source, or recipient (via a J-DISPOSE, J-GIVE, or P-DATA) a "waiting" shall be included, with the "destination" set to the resource which is needed. There may be more than one such entry. "time" shall be set to null or to the time at which access to that resource (by MF20 or MF21) was first attempted.
3.10.8.3 The "Message" in "status" shall carry text whose form is not standardised for "in-progress" and "waiting", but which should carry human-readable information from MF1. For "accepted", the Message shall contain text obtained by issuing a J-STATUS primitive to the agency, and awaiting the J-STATUS response. This shall be issued as part of the manipulation atomic action.
3.10.8.3.1 J-STATUS shall be issued with the appropriate <agency activity id> from the work specification being manipulated, and with the diagnostic code indicator of the manipulating work specification. The "Message" in the J-STATUS response shall conform to the character sets identified by that parameter.
3.10.8.3.2 The "Message" returned by MF1 shall conform to the character sets identified by the diagnostic code indicator.
3.10.9 A "Work-operation" of
shall produce a document named y (by the procedures of 3.10.9.1 to 3.10.9.3), associated with the work specification, and collectable by the procedures of 3.6.3. The document is collected as specified in 3.10.11.
The procedures of 3.10.14 shall be performed on each work specification that is selected but is not displayable.
If a document named y has already been produced by the application of 3.10.8 or of this 3.10.9 to another "Work-operation" in the "Work-manipulation-operations" SEQUENCE, the new document shall be concatenated to the existing one.
3.10.9.1 The document shall be a "Work-display-doc" with a single SEQUENCE consisting of
3.10.9.2 The "Full-display" for a work specification shall be set as follows:
3.10.9.3 The "Full-display" for a proforma shall be set as follows:
3.10.10 A "Work-operation" of
shall cause the procedures of 3.10.10.1 to 3.10.10.9 to be performed (if and only if the manipulation commits) on each work specification which is both selected, directly or indirectly, by the preceeding "select" "Work-operation" in the "Work-manipulation-operations" and is modifiable. It shall cause the procedures of 3.10.10.10 to 3.10.10.19 to be performed (if and only if the manipulation commits) on each directly selected and modifiable work specification and on each selected proforma which is in a modifiable work specification. It shall cause the procedures of 3.10.14 to be performed (if and only if the manipulation commits) on each work specification that is selected, or one of whose proformas is selected, but which is not modifiable, unless the work specification only fails to be modifiable as specified in 3.10.3 b.
The procedures of 3.10.13 shall be performed on each work specification that is modified, or whose proformas are modified, by any of the procedures of 3.10.10.1 to 3.10.10.19.
3.10.10.1 If the CHOICE in 3.10.10.1.1 If the "authorisations" in the work specification performing the manipulation contains an "Authorisation-element" with a "checked-index" validation where the "checked-index" satisfies the conditions of 3.3.8.4.1 and with an "open-system<Identification" with a "JTM-name" which matches the "osi-job-submission-system" in the work specification which is the subject of the manipulation, the procedures of 3.10.10.1.2 shall be applied. If no such "Authorisation-element" is present in the the manipulating work specification, the procedures of 3.10.14 are performed for the selected work specification.
3.10.10.1.2 The "primary-monitoring-specification" in the selected work specification is replaced by the "Monitoring-specification" in 3.10.10.2 If the CHOICE in u is "secondary-monitors-set-to" the "secondary-monitoring-specification" in the selected work specification is set to the SEQUENCE OF "Monitoring-specification" in 3.10.10.3 If the CHOICE in u is "secondary-monitors-add", and the "Monitoring-specification" is not the same as any "Monitoring-specification" in the "secondary-monitoring-specification" in the selected work specification, the "Monitoring-specification" in 3.10.10.4 If the CHOICE in u is "secondary-monitors-remove", any "Monitoring-specification"s in the "secondary-monitoring-specification" in the subject work specification that match the "Monitoring-spec-value" in 3.10.10.5 If the CHOICE in u is "authorisations-add", and the "Authorisation-element" in If an "Authorisation-element" is added, the procedures of 3.2.2.3.2 shall be applied for it.
3.10.10.6 If the CHOICE in u is "permissions-add", and the "Permission-element" in 3.10.10.7 If the CHOICE in u is "permissions-remove" the "authorisations" in the work specification performing the manipulation containing "Authorisation-element"s with a "checked-index" validation where the "checked-index" satisfies the conditions of 3.3.8.4.1 shall be compared with the "Permission-element" in then any "Permission-element"s in the "permissions" in the subject work specification that match the "Permission-element" in u shall be removed.
If neither of the above conditions are true, a CCR no-retry diagnostic containing a JTM diagnostic code of
and human readable text produced by MF1 shall be returned to the superior, completing the procedures of this clause in this case.
3.10.10.8 If the CHOICE in u is "accounts-add", and the "Account-element" in If an "Account-element" is added, the procedures of 3.2.2.3.2 shall be applied for it.
3.10.10.9 If the CHOICE in u is "error-action-set-to" the "error-action" in the selected work specification is set to the "Error-action" "JTM-name" in 3.10.10.10 If the CHOICE in u is "relays-set-to" the "relays" in the selected "Subjob-specification" is set to the SEQUENCE OF "JTM-name" in 3.10.10.11 If the CHOICE in u is "target-set-to" the "target" in the selected "Subjob-specification" is set to the "JTM-name" in 3.10.10.12 If the CHOICE in 3.10.10.12.1 If the "authorisations" in the work specification performing the manipulation contains an "Authorisation-element" with a "checked-index" validation where the "checked-index" satisfies the conditions of 3.3.8.4.1 and with an "open-system<Identification" with a "JTM-name" which matches the "osi-job-submission-system" in the work specification which is the subject of the manipulation, the procedures of 3.10.10.12.2 shall be applied. If no such "Authorisation-element" is present in the the manipulating work specification, the procedures of 3.10.14 are performed for the selected work specification.
3.10.10.12.2 The "urgency" in the selected "Subjob-specification" is set to the "Urgency" in 3.10.10.13 If the CHOICE in u is "holds-add", the "Hold-element" in 3.10.10.14 If the CHOICE in u is "holds-remove" and the "Hold-element-value" in 3.10.10.14.1 The procedures of 3.10.10.14.2 shall be applied if one of the following conditions a) to d) is true for the matched "Hold-element" (an `authenticated "Authorisation-element"' is an "Authorisation-element"s in the "authorisations" of the manipulating work specification with a "checked-index" validation where the "checked-index" satisfies the conditions of 3.3.8.4.1) :
If none of the conditions above are true, the procedures of 3.10.10.14.3 shall be applied.
3.10.10.14.2 The "Hold-element" shall be removed from the "holds" in the selected "Subjob-specification". If the selected subjob is the outermost subjob, the procedures of clause 3.19 shall be applied to the selected work specification.
3.10.10.14.3 The procedures of 3.10.14 shall be performed for the selected work specification.
3.10.10.15 If the CHOICE in 3.10.10.15.1 The conditions a) to d) specified in 3.10.10.14.1 shall be applied to each "Hold-element" in the "holds" in the selected "Subjob-specification". If for any of the "Hold-elements", all of the conditions are false, and the "Hold-element" is not identical to one in the SEQUENCE OF "Hold-element" in 3.10.10.15.2 The "holds" in the selected "Subjob-specification" shall be set to the SEQUENCE OF "Hold-element" in u. If the selected subjob is the outermost subjob and the procedures of clause 3.19 shall be applied.
3.10.10.16 If the CHOICE in u is "se-lists-set-to" and there are exactly the same number of "Se-identification" in and human readable text generated by MF1, completing the procedures of this clause in this case.
3.10.10.17 If the CHOICE in u is "se-ref-lists-set-to" and there are exactly the same number of "Document-se-reference" in and human readable text generated by MF1, completing the procedures of this clause in this case.
3.10.10.18 If the CHOICE in u is "source-lists-set-to" and there are exactly the same number of "Source-identification" in and human readable text generated by MF1, completing the procedures of this clause in this case.
3.10.10.19 If the CHOICE in u is "source-ref-lists-set-to" and there are exactly the same number of "Document-source-reference" in and human readable text generated by MF1, completing the procedures of this clause in this case.
3.10.11 Spawning (see clause 3.14) shall be initiated when all documents created by the procedures of 3.10.8 and 3.10.9 are complete. Spawning hall be initiated as part of the original atomic action, with the original commitment level. Commitment shall not be offered on the manipulation until the procedures of clause 3.14 are complete.
3.10.12 The procedures of clause 3.16 shall be invoked for the work specification performing the manipulation, as part of this atomic action with the same requested commitment level, and with the nominated bit the "normal-termination" bit and with the "event-identification" in any "Single-report" created by that clause set to the value
where text is human-readable text generated by MF1 and d is an integer, the sum of the <times spawned> for all the top-level proformas in this work specification. Commitment shall not be offered to the superior of this activity until the procedures of clause 3.16 offer commitment or are null. If these procedures produce rollback, the rollback shall be propagated to the superior.
This completes the procedures for this clause.
3.10.13 The modified work specification shall be checked for syntactic and semantic correctness as if it were a newly arrived Transfer-element. If this check fails, a CCR no-retry diagnostic shall be returned to the superior with the JTM-code
and human readable text generated by MF1, completing the procedures of this clause in this case.
The procedures of clause 3.16 shall be invoked for the modified work specification, with the nominated bit the "modification" bit and with the "event-identification" in any "Single-report" created by those procedures set to the value
where text is human-readable text generated by MF1, t is copied from the "relays" and "target" of the outermost subjob in the work specification, or is absent if there is no "Subjob-specification" other than those in proformas. h is "not-held NULL" if the work specification is not held or is "held NULL" if the work specification is held. The procedures of clause 3.16 shall be invoked as part of the atomic action doing the manipulation, but with a commitment level of one, and shall commit if and only if the manipulation commits.
3.10.14 The procedures of clause 3.15 shall be invoked for the work specification that has been selected but is not modifiable or not displayable.The procedures shall be invoked with the nominated bit the "violation-attempt" bit and with the "event-identification" of in any "Single-report" created by the procedures of clause 3.15 set to the value
where text is human-readable text generated by MF1, a is a SEQUENCE OF "Audit-element" copied from the "audit-trace" in the work-manipulation work specification and s is a "Subjob-identification" copied from the corresponding fields of the work-manipulation work specification. The procedures of clause 3.15 shall be invoked as part of the atomic action doing the manipulation but with a commitment level of one.
This clause is invoked by 3.4.10. It is applied to transfer elements with an outermost "subjob-type" of "report-manipulation", with "relays" empty and with the "target" equal to the local open system name MF2.
The procedures of 3.11.1 and the clauses it references are applied to the "Report-manipulation" in the outermost "subjob-specification". The procedures of 3.11.5 and 3.11.6 are then applied to the work-specification.
3.11.1 The "Report-manipulation" either has a value (a):
or a value (b):
where rs is a "Report-selection", and doc is a "GraphicString".
If the "Report-manipulation" value is as in (a), the procedures of 3.11.3 shall be applied, otherwise the procedures of 3.11.4 shall be applied.
In both cases, all "Single-report"s that are stored at this JTM ASE by the procedures of 3.9.8.2 are selected, if and only if, they are selected, as specified in 3.11.2, by each component of the the "Report-selection" SEQUENCE rs. Components of the datatype "Report-selection" that are not present in rs are treated as if all "Single-report"s were selected by the missing component.
3.11.2 A "Single-report" is selected by
A bit in a "Report-selector" corresponds to an "event-identification" with the same name.
3.11.3 For each selected report, the "permissions" If one of these "Authorisation-elements" is
the selected report shall be cease to be stored by this JTM ASE following commitment.
If no such match is made, no further action is taken for the selected report for this "report-manipulation".
3.11.4 A document named 3.11.4.1 The document shall be a "Report-display-doc" consisting of
3.11.5 Spawning (see clause 3.14) shall be initiated when all documents created by the procedures of 3.11.1 are complete. Spawning shall be initiated as part of the original atomic action, with the original commitment level. Commitment shall not be offered on the report-manipulation until the procedures of clause 3.14 are complete.
3.11.6 The procedures of clause 3.16 shall be invoked for the work specification performing the manipulation, as part of the original atomic action with the same requested commitment level, and with the nominated bit the "normal-termination" bit and with the "event-identification" in any "Single-report" created by that clause set to the value
where text is human-readable text generated by MF1 and d is an integer, the sum of the <times spawned> for all the top-level proformas in this work specification. Commitment shall not be offered to the superior of this activity until the procedures of clause 3.16 offer commitment or are null. If these procedures produce rollback, the rollback shall be propagated to the superior.
This completes the procedures for this clause.
This clause is invoked by 3.4.10. It is applied to transfer elements with an outermost "subjob-type" of "tcr-manipulation", with "relays" empty and with the "target" equal to the local open system name MF2.
The procedures of 3.12.1 and the clauses it references are applied to the "Transfer-manipulation" in the outermost "subjob-specification". The procedures of 3.12.5 and 3.12.6 are then applied to the work-specification.
3.12.1 If the "Transfer-manipulation" is the CHOICE "set", the procedures of 3.12.2 shall be applied. If it is the CHOICE "check", the procedures of 3.12.3 shall be applied. If it is the CHOICE "display", the procedures of 3.12.4 shall be applied.
3.12.2 The "Tcr-set" has the value :-
where s is a "JTM-name", r is a "JTM-name" other than MF2 and c is a "control-specification". If the "authorisations" include an "authorisation-element" with an "open-system<Identification" which matches s and a "checked-index" validation where the "checked-index" satisfies the conditions of 3.3.8.4.1, and, if s is distinct from r, a similar "Authorisation-element" for r, the procedures of 3.12.2.1 shall be applied. If such "Authorisation-element"(s) are not present, a CCR no-retry diagnostic shall be generated with "JTM-code"
and human-readable text generated by MF1. The diagnostic shall be passed to the superior. This completes the procedures of this clause in this case.
3.12.2.1 The transfer control record held at this ASE for controlling transfers to where COPIED means the value is set from the "Tcr-set" value.
It is an implementation option whether the <time stamp> in the transfer control record is set to the time of receipt of the transfer manipulation.
3.12.3 The "Tcr-check" has the value :-
where cq and cr are "JTM-name"s (possibly the same) and cc is a "control-specification".
If the "authorisations" include an "authorisation-element" with an "open-system<Identification" which matches cq and a "checked-index" validation where the "checked-index" satisfies the conditions of 3.3.8.4.1, the procedures of 3.12.3.1 shall be applied. If no such "Authorisation-element" is not present, a CCR no-retry diagnostic shall be generated with "JTM-code"
and human-readable text generated by MF1. The diagnostic shall be passed to the superior. This completes the procedures of this clause in this case.
3.12.3.1 If this JTM ASE has available a transfer control record that it has previously sent or attempted to send to the open-system where ss is the local "JTM-name" MF2, sr is a "JTM-name" identical to cr and cs is a "control-specification", the "control-specification" cc shall be compared with the "control-specification" sc. If these have the same values, no further action shall be taken. If the values differ, the procedures of clause 3.20 shall be invoked, as a separate atomic action, to send a "Transfer-manipulation" work specification containing the "Tcr-set" specified earlier in this subclause to the open-system cq.
If this JTM ASE does not have available a copy of the transfer control record for controlling transfers from cq to cr, no further action shall be taken for this "Transfer-manipulation".
3.12.4 The "Tcr-display" has either a value :
or a value
In the first case, a document named doc shall be produced by the procedures of 3.12.4.1, and in the second case a document name doc shall be produced by the procedures of 3.12.4.2. In either case, the document shall be associated with the work specification, and is collectable by the procedures of 3.6.3. The document is collected as specified in 3.12.5. If a document named doc has already been produced by the application of this subclause to another "Transfer-manipulation" in the "Transfer-manipulation-operations" SEQUENCE, the new document shall be concatenated to the existing one.
3.12.4.1 The document shall be a "Tcr-display-doc" consisting of
If this JTM ASE holds a transfer control record in which the <recipient> matches dr, then dc is a SEQUENCE containing a single value of "Transfer-control-record" set from it. If there is no such transfer control record at this JTM ASE, dc shall be an empty SEQUENCE.
3.12.4.2 The document shall be a "Tcr-display-doc" consisting of
3.12.5 Spawning (see clause 3.14) shall be initiated when all documents created by the procedures of 3.12.4 are complete. Spawning shall be initiated as part of the original atomic action, with the original commitment level. Commitment shall not be offered on the Transfer-manipulation until the procedures of clause 3.14 are complete.
3.12.6 The procedures of clause 3.16 shall be invoked for the work specification performing the manipulation, as part of the original atomic action with the same requested commitment level, and with the nominated bit the "normal-termination" bit and with the "event-identification" in any "Single-report" created by that clause set to the value
where text is human-readable text generated by MF1 and d is an integer, the sum of the <times spawned> for all the top-level proformas in this work specification. Commitment shall not be offered to the superior of this activity until the procedures of clause 3.16 offer commitment or are null. If these procedures produce rollback, the rollback shall be propagated to the superior.
This completes the procedures for this clause.
This clause is applied on receipt of a J-END-SIGNAL request from an agency which has given AGENCY ACCEPTANCE completion. It is referenced by 3.1 and by 3.8.11 and 3.9.6. The implementation shall ensure that the master's address parameter and atomic action identifier are unambiguous, and that the agency specifies a commitment level of one. The diagnostic code indicator shall be the same as on the corresponding J-DISPOSE. The implementation shall also ensure that following an application failure:
3.13.1 The work specification producing the corresponding J-DISPOSE shall be identified from the provider's activity id supplied on the J-END-SIGNAL request.
If more than one AGENCY ACCEPTANCE completion was given for this work specification by agencies (see 3.8.7), the procedures of this clause shall not proceed until J-END-SIGNAL request have been received for all the outstanding activities. When all J-END-SIGNAL requests have been received, they shall be processed as if they were a single atomic action.
If the <hold state> in the work specification is HELD, the procedures of this clause shall not proceed until the <hold state> changes.
3.13.2 The procedures of clause 3.14 shall be invoked as part of the J-END-SIGNAL atomic action, to spawn proformas with "spawning-control-data" either of the CHOICEs "completion" or "conditional".
3.13.3 If the implementation is an extended implementation, and any C-READY indication or C-ROLLBACK indication user data fields received by the JTM ASE include "accounting-info", the procedures of clause 3.15 shall be invoked, with the nominated bit the "accounting-data" bit and the "event-identification" of any "Single-report" created by that clause set to the value
where text is human-readable text generated MF1 and a is a SET of containing "Charging-information" from the "accounting-info" on the CCR primitives received. If several "Charging-information" are received, it is an implementation option whether "Charging-information" are accumulated into a SET of several members, or whether clause 3.15 is invoked repeatedly, provided in either case, each "Charging-information" is passed to the procedures of clause 3.15 only once.
The "accounting-info" shall not be passed on to the superior.
3.13.4 If the implementation is an extended implementation, and any J-READY or C-READY indication user data fields received by the JTM ASE include "warning<CCR-diagnostic", but no higher-level CCR-diagnostic, the procedures of clause 3.15 shall be invoked, with the nominated bit the "warning-report" bit and, the "event-identification" of any "Single-report" created by that clause set to the value
where text is human-readable text generated by MF1, and g is set as specified in 3.5.6.1 and d is the received "warning<CCR-diagnostics".
The "warning<CCR-diagnostics" shall not be passed on to the superior.
3.13.5 The agency shall mark a document as deleted when commitment is offered for a J-GIVE with <agency parameter> MOVE which collects it. Any documents which are not marked when commitment is offered on the J-END-SIGNAL shall be disposed according to the local management function MF18.
3.13.6 If a J-ROLLBACK is issued to the agency as a result of 3.10.7.2, then the agency shall dispose of all available documents in accordance with MF18.
3.13.7 The agency shall order commitment on J-END-SIGNAL if it is offered.
3.13.8 The procedures of clause 3.16 shall be invoked with the nominated bit the "normal-termination" bit and the "event-identification" of any report created by that clause set to the value
where text is human-readable text generated by MF1 and n is an integer, the sum of the <times spawned> for all the top-level proformas in the original work specification. If the procedures of clause 3.16 produce a no-retry diagnostic, those branches of the atomic action shall rollback, discarding any new report work specification and the main atomic action shall proceed to commitment.
3.13.9 When J-END-SIGNAL commits, the work specification shall be discarded, and the <provider activity id>s in it become reusable.
This clause is applied to generate new work specifications from the top-level proformas in a work specification. It is invoked by 3.13.2, 3.10.11 and by 3.8.10. Each of these references specifies one or more of the "spawning-control-data" CHOICEs. A proforma is only spawned by the procedures of this clause if it has a "spawning-control-data" CHOICE matching one of those referenced. It has available a work specification, together with the agency activity id for any execution agency on which there is an activity produced by the procedures of clause 3.8.
3.14.1 The procedures of 3.14.2 to 3.14.6 shall be invoked for each proforma in the proforma list which has "spawning-control-data" which is one of the CHOICEs specified in the reference to this clause. The procedures of 3.14.2 to 3.14.6 shall not be invoked for a subsequent proforma in the proforma list until offers of commitment or rollback with a no-retry diagnostic have been received for any J-ENQUIRE or J-GIVE commitment groups to agencies initiated as a result of processing an earlier proforma in the list.
3.14.2 The <times spawned> for the proforma shall be incremented by one.
3.14.3 A work specification shall be formed as follows (COPIED refers to outermost fields in the original transfer element):
where i in the additional sequence in the subjob-name-list is an integer which shall be set to the value of the <times spawned> for the proforma, after its incrementation by 3.14.2.
The proforma-list is COPIED from the proforma, with any top-level "proforma-reference" CHOICE replaced by the "Proforma-specification" COPIED from the "proforma-list" of the parent work specification.
The <time waiting> shall contain the time in seconds from the formation of this new work specification.
The <estimated size> shall contain the estimated size of the Transfer-element plus all the document values in kilo-octets.
For the <documents> field, any documents corresponding to "embedded" "Document-pointers" in the proforma are copied. There are no such "Document-pointers" in a Basic Class proforma.
3.14.4 Checks for syntactic and semantic correctness of the new work specification (corresponding to the specification in section 2) shall be made. If these checks fail, the top-level subjob specification of the work specification shall be removed and the procedures of 3.14.9 followed by 3.14.11 shall be applied, otherwise the procedures of 3.14.5 followed by 3.14.6 shall be applied.
3.14.5 The <hold state> for the work specification shall be set to NOT-HELD.
If the implementation supports FULL WORK-MANIPULATION, the procedures of clause 3.19 shall be applied to the work specification.
3.14.6 The procedures of clause 3.4 shall be applied to the new work specification. The <agency activity id> for the execution agency is available to these procedures for the collection of documents from the agency.
If these produce offers of commitment, the procedures of 3.14.7 and 3.14.9 are carried out. If rollback with a no-retry diagnostic is received the procedures of 3.14.7 and 3.14.8 shall be applied.
3.14.7 If the "spawning-control-data" in the proforma is "conditional NULL" and the work specification is not held and the procedures of clause 3.6 did not produce any documents from agencies at this open system, the new work specification shall be discarded and the <times spawned> reset to its previous value. Commitment shall not be prevented by any rollback received in processing this proforma. Any CCR diagnostics received in the processing of the spawned work specification shall be discarded, completing the processing for this proforma in this case.
3.14.8 If a rollback has been received and the commitment level requested when this clause was invoked is higher than PROVIDER-ACCEPTANCE, the diagnostic shall be passed to the commitment superior, completing the procedures of this clause (for all proformas).
If a no-retry diagnostic is received and the commitment level requested when this clause was invoked was PROVIDER-ACCEPTANCE, the procedures of 3.14.9 and 3.14.10 shall be applied.
3.14.9 The procedures of clause 3.16 shall be invoked for the new work specification, as part of this atomic action with the same requested commitment level, with the nominated bit the "spawning" bit and the "event-identification" of any "Single-report" created by that clause set to the value
where text is set by management function MF1 and rt is copied from the "relays" and "target" of the work specification described in 3.14.3 and h is {not-held NULL} if the <hold state> is NOT-HELD and is {held NULL} if the <hold state> is HELD. If these procedures produce a no-retry diagnostic and the requested commitment level is PROVIDER-ACCEPTANCE, the report work-specification that caused the rollback and the diagnostic shall be discarded. If these procedures, and all others invoked for this proforma offer commitment, the procedures for this proforma are complete.
3.14.10 The newly-spawned work specification shall be secured by the JTM entity. Any existing actions arising from the application of the procedures of clause 3.4 to this work specification shall be rolled back. (but not report generation invoked by 3.14.9 nor the incrementing of <times spawned>). The secured (but erroneous) work specification shall be processed according to 3.5, resulting in a JTM-event (possibly causing a report to be created) and discarding of the work specification. Spawning from any other proformas in the proforma-list for shall not be affected, and commitment shall be offered to the superior, subject to the result of these procedures for the other proformas.
3.14.11 The procedures of clause 3.15 shall be invoked for the newly-spawned (and erroneous) work specification with the nominated bit the "not-supported" bit and the "event-identification" of any report created by that clause set to the value
where text is human-readable text generated by MF1. The newly-spawned work specification shall then be discarded. Spawning from any other proformas in the proforma-list for shall not be affected, and commitment shall be offered to the superior, subject to the result of these procedures for the other proformas.
This clause is referenced by 3.2.10, 3.5.4, 3.5.6, 3.10.14, 3.13.3, 3.14.11 and 3.19.10 when, in the processing of a work specification, a JTM event occurs which potentially requires reports to be generated which are to be processed as a separate atomic action. Each reference to this clause specifies which bit (the nominated bit) in the "report-selector" of the "Monitoring-specification" is to be examined and specifies the value of the "event-identification" in the any report work specification created by the procedures of this clause.
3.15.1 If the "subjob-type" of the work specification is "report-movement", the procedures of this clause are null (no further report is generated). Otherwise 3.15.2 shall be applied. Any report-movement work specifications created by these procedures shall be secured as part of the original atomic action and may be processed either in the original or in a separate atomic action. The values shall be set as specified in 3.15.4 to 3.15.7 and the report-movement work specification(s) processed as specified in clause 3.4 (with a commitment level of 1).
3.15.2 The nominated bit in the "report-selector" in the "primary-monitoring-specification" and in each "Monitoring-specification" in the "secondary-monitoring-specification" is examined. For each "Monitoring-specification" in which the nominated bit is set, the procedures of 3.15.3 shall be applied.
3.15.3 If the present invocation of 3.15.1 has already invoked this subclause for another "Monitoring-specification" which has the same values for "monitor-relays" and "monitor-system-name" as this "Monitoring-specification", it is an implementor's option whether to apply the procedures of 3.15.4 or 3.15.7, otherwise 3.15.4 shall be applied.
3.15.4 If, as a result of an earlier invocation of this clause, for this work specification, there is, at this JTM ASE, a report movement work specification with "relays" equal to the "monitor-relays" and "target" equal to the "monitor-system-name" in this "Monitoring-specification", it is an implementor's option whether to apply the procedures of 3.15.5 or 3.15.6. If no such report movement work specification is held by this JTM ASE, 3.15.5 shall be applied.
3.15.5 A report movement work specification shall be created with the following value. Fields copied from the original work specification are indicated by the work COPIED. Where these field are part of a "Subjob-specification", the outermost shall be used.
where r is the "monitor-relays" from the "Monitoring-specification", t is the "monitor-system-name" from the "Monitoring-specification", and i is zero if the "Monitoring-specification" is in the "primary-monitoring-specification", otherwise it is the ordinal index of the "Monitoring-specification" in the "secondary-monitoring-specification" . a is the local "JTM-name" provided by the local management function MF2, time is null or the time of creation of this report movement work specification and e is specified in the clause of this section that references this clause.
3.15.6 A further component shall be added to the "report-movement-operations" SET with the value
where i, a, time and e have values as defined in 3.15.5.
3.15.7 If the earlier invocation of 3.15.4 in turn invoked 3.15.5, then 3.15.7.1 is applied. If the earlier invocation of 3.15.4 invoked 3.15.6, then 3.15.7.2 is applied.
3.15.7.1 The index for this "Monitoring-specification" shall be added to the "monitor-indices" in the single component of the "actions" of the report-movement work specification created by the earlier invocation of 3.15.5 . If the "Monitoring-specification" is in the "primary-monitoring-specification" the index is zero, otherwise it is the ordinal of the "Monitoring-specification" in the "secondary-monitoring-specification".
3.15.7.2 The index for this "Monitoring-specification" shall be added to the "monitor-indices" in the component of the "actions" of the report-movement work specification which was added by the earlier invocation of 3.15.6. If the "Monitoring-specification" is in the "primary-monitoring-specification" the index is zero, otherwise it is the ordinal of the "Monitoring-specification" in the "second<->ary-moni<->tor<ª>ing-specif<->ica<->tion".
This clause is referenced by 3.2.9, 3.4.7.1, 3.5.7.1, 3.6.3.1.1, 3.6.7.2, 3.8.10, 3.8.11, 3.10.6.4, 3.10.7.5, 3.10.12, 3.10.13, 3.11.6, 3.12.6, 3.13.8, 3.14.9 and 3.17.2 when in the processing of a work specification a JTM event occurs which potentially requires reports to be generated as part of the same atomic action. Each reference to this clause specifies which bit (the nominated bit) in the "report-selector" of the "Monitoring-specification" is to be examined and specifies the value of the "event-identification" in any "Single-report" created by the procedures of this clause.
3.16.1 If the "subjob-type" of the work specification is "report-movement", the procedures of this clause 3.16 are null (no further report is generated). Otherwise 3.16.2 shall be applied. Any report-movement work specifications created by these procedures shall be produced and progressed as part of the main atomic action. The values shall be set as specified in 3.16.4 to 3.16.7 and the report-movement work specification(s) processed as specified in clause 3.4.
3.16.2 The nominated bit in the "report-selector" in the "primary-monitoring-specification" and in each "Monitoring-specification" in the "secondary-monitoring-specification" is examined. For each "Monitoring-specification" in which the nominated bit is set, the procedures of 3.16.3 shall be applied.
3.16.3 If the present invocation of 3.16.1 has already invoked this subclause for another "Monitoring-specification" which has the same values for "monitor-relays" and "monitor-system-name" as this "Monitoring-specification", it is an implementor's option whether to apply the procedures of 3.16.4 or 3.16.7, otherwise 3.16.4 shall be applied.
3.16.4 If, as a result of an earlier invocation of this clause 3.16, for this work specification, there is, at this JTM ASE, a report movement work specification with "relays" equal to the "monitor-relays" and "target" equal to the "monitor-system-name" in this "Monitoring-specification", it is an implementor's option whether to apply the procedures of 3.16.5 or 3.16.6. If no such report movement work specification is held by this JTM ASE, 3.16.5 shall be applied.
3.16.5 A report movement work specification shall be created with the following value. Fields copied from the original work specification are indicated by the work COPIED. Where these field are part of a "Subjob-specification", the outermost shall be used.
where r is the "monitor-relays" from the "Monitoring-specification", t is the "monitor-system-name" from the "Monitoring-specification", and i is zero if the "Monitoring-specification" is in the "primary-monitoring-specification", otherwise it is the ordinal index of the "Monitoring-specification" in the "secondary-monitoring-specification" . a is the local "JTM-name" provided by the local management function MF2, time is null or the time of creation of this report movement work specification and e is specified in the clause of this section that reference this clause 3.16.
3.16.6 A further component shall be added to the "report-movement-operations" SET with the value
where i, a, time and e have values as defined in 3.16.5.
3.16.7 If the earlier invocation of 3.16.4 in turn invoked 3.16.5, then 3.16.7.1 is applied. If the earlier invocation of 3.16.1 invoked 3.16.6, then 3.16.7.2 is applied.
3.16.7.1 The index for this "Monitoring-specification" shall be added to the "monitor-indices" in the single component of the "actions" of the report-movement work specification created by the earlier invocation of subclause 3.16.5 . If the "Monitoring-specification" is in the "primary-monitoring-specification" the index is zero, otherwise it is the ordinal of the "Monitoring-specification" in the "secondary-monitoring-specification".
3.16.7.2 The index for this "Monitoring-specification" shall be added to the "monitor-indices" in the component of the "actions" of the report-movement work specification which was added by the earlier invocation of subclause 3.16.6 . If the "Monitoring-specification" is in the "primary-monitoring-specification" the index is zero, otherwise it is the ordinal of the "Monitoring-specification" in the "secondary-monitoring-specification".
This clause is applied on receipt of a J-MESSAGE request, either from an agency processing a J-DISPOSE indication, or from an agency which has given AGENCY ACCEPTANCE on such an indication but has not yet given a J-END-SIGNAL request. The implementation shall ensure that the J-MESSAGE atomic action is a branch of the J-DISPOSE atomic action in the former case. In the latter case, it shall ensure that the master's address parameter and atomic action identifier are unambiguous. The diagnostic code indicator shall be the same as on the corresponding J-DISPOSE. In the case following AGENCY ACCEPTANCE, and following an application-failure the implementation shall ensure that:
3.17.1 The work specification producing the corresponding J-DISPOSE shall be identified from the <provider's activity id> supplied on the J-MESSAGE request.
3.17.2 The procedures of clause 3.16 shall be invoked as part of the J-MESSAGE atomic action with the nominated bit the "user-message" bit and the "event-identification" of any "Single-report" created by that clause set to the value
where text is the <message> in the J-MESSAGE request.
This clause is applied on receipt of a J-SPAWN request, either from an agency processing a J-DISPOSE indication,or from an agency which has given AGENCY-ACCEPTANCE on such an indication but has not yet given a J-END-SIGNAL request. The implementation shall ensure that the J-SPAWN atomic action is a branch of the J-DISPOSE atomic action in the former case. In the latter case, it shall ensure that the master's address parameter and atomic action identifier are unambiguous. The diagnostic code indicator shall be the same as on the corresponding J-DISPOSE. In the case following AGENCY ACCEPTANCE, and following an application-failure the implementation shall ensure that:
3.18.1 The work specification producing the J-DISPOSE shall be identified from the <provider activity id> supplied on the J-SPAWN request. If the <hold state> in the work specification is HELD, the procedures of this clause shall not proceed until the <hold state> changes. The procedures of 3.18.2 shall be followed for each and every top-level proforma in the the work-specification that contains a "Demand-spawn-handle" in the "demand-spawning-handles" that is equal to the <demand spawn handle> on the J-SPAWN request. If no proforma with a matching "Demand-spawn-handle" is present, the procedures of 3.18.3 shall be followed.
3.18.2 The procedures of 3.14.2 to 3.14.6 shall be invoked, as part of this atomic action, to spawn the proforma identified in 3.18.1. This completes the procedures for this proforma.
3.18.3 A no-retry CCR diagnostic shall be generated with JTM-code
and human-readable text MF1 which contains the <Demand spawn handle> on the J-SPAWN request and passed to the commitment superior.
This clause is invoked when the "holds" in the outermost "Subjob-specification" are changed by by 3.10.10 or 3.5.6.2, and when they become effective by 3.2.6, 3.3.8.6 or 3.14.5.
3.19.1 The existing <hold state> of the work specification is noted.
3.19.2 The procedures of 3.19.4 to 3.19.6 shall be applied to each "Hold-element" in the outermost "Subjob-specification", in which the "location" is equal to the local JTM-name returned by MF2 and which contains a "release-time".
3.19.3 If any "Hold-element" with "location" equal to the local "JTM-name" is present in the "holds" of the outermost "Subjob-specification" after application of 3.19.6, the <hold state> of the work specification is HELD, otherwise it is NOT-HELD. If the <hold state> is consequently changed from HELD to NOT-HELD, the procedures of 3.19.11 shall be applied. If the <hold state> is changed from NOT-HELD to HELD, the procedures of 3.19.7 shall be applied.
3.19.4 If the "release-time" is
the "release-time" shall be changed to the "date-time" corresponding to the next time that the local time of day is hh hours and mm minutes.
3.19.5 If the "release-time" is
the "release-time" shall be changed to a "date-time" corresponding to the current time plus i minutes.
3.19.6 If the "release-time" (possibly changed by 3.19.4 or 3.19.5) is
and the time t is later than the current time, the procedures of 3.19.8 shall be followed for the work specification, as a separate, future atomic action, and the processing of this "Hold-element" is completed for this atomic action in this case. If the time t is earlier than the current time, the "Hold-element" shall be removed from the "holds".
3.19.7 Any commitment groups initiated by agencies for this work specification shall be rolled back with a retry-later diagnostic.
Any sink or execution agencies which have given ACCEPTANCE completion shall be issued with a J-HOLD primitive group as part of main atomic action. The <agency activity id> shall be taken from the work specification.
3.19.8 If the implementation is active at time t, the procedures of 3.19.9 shall be invoked for the work specification after the time 3.19.9 If the "Hold-element" containing the "release-time" of
has already been removed from the "holds" in the outermost work-specification , no further action is taken. Otherwise it is is removed from the "holds".
If there are now no "Hold-element"s in the "holds" that have "location" equal to the local "JTM-name" from MF2, the procedures of 3.19.10 are followed. If such "Hold-element"s are still present, the <hold state> remains HELD and no further action is taken.
3.19.10 The <hold state> of the work specification is changed to NOT-HELD.
The procedures of clause 3.15 shall be invoked for the work specification with the nominated bit the "modification" bit and with the "event-identification" in any "Single-report" created by the procedures of clause 3.15 set to the value
where text is set by MF1 and t is copied from the the "relays" and "target" of the outermost "Subjob-specification". The procedures of clause 3.15 shall be invoked as a new atomic action with a commitment level of PROVIDER-ACCEPTANCE.
The procedures of 3.19.11 shall be followed.
3.19.11 Any sink or execution agencies which have given ACCEPTANCE completion, and to which J-HOLD primitive groups were earlier issued by the procedures of 3.19.7 shall now be issued with a J-RELEASE primitive group as part of the main atomic action. The <agency activity id> shall be taken from the work specification.
The further processing of the work specification follows the procedures of 3.5 in conformance with 3.5.3 .
This clause is referenced by 3.12.3.1. It is invoked to initiate the transfer of a transfer-control manipulation work-specification to set a transfer-control record at another open-system after a tcr-check has indicated that the other open-system has an inappropriate transfer-control record.
There exists at this JTM ASE a copy of a "control-spec" cs of a transfer control record that is to be used to control the transfers from the open-system corresponding to "JTM-name" t to the open-system r.
3.20.1 A work specification shall be created as specified below, and shall then be processed in accordance with clause 3.4. The JTM ASE is the CCR commitment master and the requested commitment level shall be COMPLETION. If the procedures of clause 3.4 do not offer commitment, the work specification shall be discarded. Commitment shall be ordered if it is offered.
3.20.2 Fields of the new work-specification shall be set as follows
3.20.2.1 The "authorisations" shall include an "Authorisation-element" with an "open-system<Identification" for the local JTM-name MF2 and a "checked-index" "validation" of 1.
If the "JTM-name" r is distinct from the local JTM-name MF2, the "authorisations" shall include an "Authorisation-element" with an "open-system<Identification" for r and a "validation" supplied by MF7.
3.20.2.2 The "permissions" shall contain "Permission-element"s corresponding to the "Authorisation-element"s in the "authorisations".
The procedures of this clause shall be invoked following an implementation failure for each transfer control record stored by the implementation.
The transfer control record has the value
3.21.1 A work specification shall be created as specified below, and shall then be processed in accordance with clause 3.4. The JTM ASE is the CCR commitment master and the requested commitment level shall be COMPLETION. If the procedures of clause 3.4 do not offer commitment, the work specification shall be discarded. Commitment shall be ordered if it is offered.
3.21.2 Fields of the new work-specification shall be set as follows
3.21.2.1 The "authorisations" shall include an "Authorisation-element" with an "open-system<Identification" for the local JTM-name MF2 and a "checked-index" "validation" of 1.
3.21.2.2 The "permissions" shall contain "Permission-element"s corresponding to the "Authorisation-element"s in the "authorisations".
"ue-agency-unknown"
"ue-no-agency-activity"
NOTE -- In Basic Class, MF15 returns only execution agencies and these procedures are only invoked by task-end spawning.
<identification> = "Identification"
<authorisation element> = "Authorisation-element"
NOT-KNOWN
<identification> = "Identification"
<account element> = "Account element"
NOT-KNOWN
NOTE -- In a Basic Class implementation, the <user account> will always be set to NOT-KNOWN.
NOTE -- In a Basic Class implementation, the <additional authorisations> will always be null.
NOTE -- In Basic Class, these procedures are only invoked as part of task-end spawning, for a J-GIVE indication to be issued to an execution agency.
"ue-no-agency-document"
"rl-access-to-agency-document"
"ue-ftam-not-supported"
"ue-no-ftam-document"
"ue-agency-unknown"
{doc-name c ,
docs
{single-document-reference
{action-open-system COPIED ,
source COPIED ,
doc-name e ,
embed-diagnostics EMBED NULL ,
state failed
{time time ,
diagnostics nrd }}}}
error-diagnostic
{text text ,
errors
{{source-details a ,
when time ,
diagnostics nrd }}}
"ue-no-agency-document"
"rl-access-to-agency-document"
{type COPIED ,
ses COPIED ,
document-block Single-form
{doc-name
{document-name dse ,
access-parameter COPIED },
docs {embedded} }}
3.7 Procedures for transmission of work specifications
"ue-no-authorisation-for-transfer"
"ue-site-unknown"
"ue-site-basic-class-only"
NOTE -- It is an implementor's option whether in an extended implementation, MF16 distinguishes between "ISO JTM Basic Class Application-context" and "ISO JTM Full Application-context", and whether the implementation attempts to establish "ISO JTM Full Application-context" when the work specification meets the Basic Class restrictions.
"sf-transmission-failure"
"ue-site-basic-class-only"
NOTE -- In an extended implementation, a value for "accounts" will possibly have been added by the JTM ASE as specified in 3.2.4, potentially extending a Basic Class work specification beyond the restrictions.
3.8 Document movement procedures
NOTE -- In Basic Class there is a single "document movement"
"ue-document-reference-not-satisfied"
"ue-agency-unknown"
"ue-ftam-not-supported"
NOTE -- In a Basic Class implementation,the <additional authorisations> will always be null.
"w-document-name-changed"
NOTE -- The warning diagnostic is discarded when the master is a Basic Class JTM ASE.
NOTE -- In the Basic Class, there is only one "Document-pointer", and either <disposal document> or <errors> are null.
NOTE -- Other values of the <document source reference> may also produce the same document.
NOTE -- For example, character set mappings may not be completely reversible; binary documents may be padded to a multiple of eight bits, and so on.
"ue-ftam-disposal-error"
"w-ftam-warning"
"ue-document-already-exists"
and human-readable text obtained by MF1 including the name of the document; or
"ue-document-does-not-exist"
and human-readable text obtained by MF1 including the <document se reference>; or
"ue-disposal-error"
and human-readable text obtained by MF1; or
"rl-document-disposal"
and human-readable text obtained by MF1.
normal-termination
{text text ,
spawn-count n }
agency-acceptance
{text text }
NOTE -- The "Subjob-specification" is retained only as a place-holder in case a work-manipulation places a "Hold-element" in the "holds". If the implementation does not support FULL WORK-MANIPULATION, deletion of the "Subjob-specification" is equivalent.
3.9 Report movement procedures
"sf-incorrect-report-routing"
"sf-incorrect-report-routing"
"sf-incorrect-monitor-name"
"sf-not-supported"
3.10 Work manipulation procedures
NOTE — A work specification is involved in a commitment group if either
NOTE -- The classification is time-dependent, as atomic actions are continuously starting and ending. Implementations may choose to wait for completion of an interfering atomic action (subject to the atomic action timer on the manipulation). There is no requirement for the state of all work specifications at an open system to be examined at the same instant of time. It can happen that a work specification is changed by other actions during a manipulation in such a way that it is selected twice. Implementors are not required to prevent this.
select x
NOTE — A work specification is selected by the Basic-selector
{selector-form first-header-is NULL,
test and-clause
{header-one osi-job-submission-system-equals p,
header-two and-clause
{header-one osi-job-name-equals q,
header-two subjob-type-equals r}}}
NOTE -- A null, top-level subjob occurs following the procedures of 3.8.12 and a proforma contains no subjob when it contains the CHOICE "proforma-reference".
osi-job-submission-system GLOBAL
initiating-identification GLOBAL
initiating-time GLOBAL
osi-job-name GLOBAL
osi-job-local-reference GLOBAL
audit-trace GLOBAL
primary-monitoring-specification GLOBAL
secondary-monitoring-specification GLOBAL
authorisations GLOBAL
permissions GLOBAL
accounts GLOBAL
security-parameters GLOBAL
time-waiting GLOBAL
estimated-size GLOBAL
subjob-name-list see below
relays SUBJOB
target SUBJOB
urgency SUBJOB
holds SUBJOB
error-action SUBJOB
type SUBJOB
se-lists CONCATENATED
se-ref-lists CONCATENATED
source-lists CONCATENATED
source-ref-lists CONCATENATED
NOTE -- There may be more than one way of making such a match.
hold 0
NOTE -- This variation to the normal pattern permits a match to an "Error-action" of "hold" regardless of the hold time specified.
stop NULL
NOTE -- In order to satisfy this requirement, the JTM entity cannot order commitment for the processing of any work specification which is being stopped by a manipulation for which commitment has been offered.
NOTE -- It is recommended that a retry time of about five minutes be specified.
modification
{text text ,
target-list t ,
hold-state {not-held NULL} ,
stop-signal {stopped NULL} }
NOTE -- Failure of the branch of the atomic action delivering the report does not result in failure of the manipulation.
kill NULL
NOTE -- In order to satisfy this requirement, the JTM entity cannot offer commitment for the processing of any work specification which is being killed by a manipulation for which commitment has been offered.
"ua-killed-by-manipulation"
NOTE -- The J-KILL atomic action cannot be rolled back by the (subordinate) agency.
manipulation-termination
{text text ,
spawn-count d }
NOTE -- Failure of the branch of the atomic action delivering the report does not result in failure of the manipulation.
brief-display y
"displaying-system"
the local JTM-name MF2;
"time"
Null, or the time the display document is created;
"display"
a SEQUENCE of "Brief-display", one for each work specification which is directly selected by the preceeding "select" "Work-operation" in the "Work-manipulation-operations" as specified in 3.10.5 and is displayable, and one for each proforma that is so selected and is in a displayable work specification.
NOTE -- It is an implementor's option whether the time is null or set to the time.
"details"
COPIED from the corresponding fields of the header corresponding to the work specification or proforma being displayed.
"status"
there shall be one Destination-status for each of the identifiable situations in 3.10.8.2.1 to 3.10.8.2.3 below.
"time"
this shall be null or the time at which the reported state was entered, as specified in 3.10.8.2.1 to 3.10.8.2.3 below.
NOTE -- It is recommended that the text should carry sufficient information to indicate when further progress is likely, and should indicate whether any hold-up is due to lack of local resources or to repeated RETRY-LATER rollbacks on transfer attempts. If a retry-later rollback has been received on an earlier attempt to progress the work specification being displayed, the "retry-later<CCR-diagnostic" from that rollback shall be included in the "waiting" "status".
full-display y
"displaying-system"
the local JTM-name MF2;
"time"
Null, or the time the display document is created;
"display"
a SEQUENCE of "Full-display", one for each work specification which is directly selected by the preceeding "select" "Work-operation" in the "Work-manipulation-operations" as specified in 3.10.5 and is displayable, and one for each proforma that is so selected and is in a displayable work specification.
NOTE -- It is an implementor's option whether the time is null or set to the time.
"header-list"
set from the header-list for the work specification, starting with the header corresponding to the top-level subjob and followed by the header corresponding to all the proformas within it, at any level of nesting. The headers corresponding to proformas shall be in the order of the proformas in the abstract syntax definition of a transfer element.
NOTE -- This is "depth-first" ordering.
"status"
there shall be one Destination-status for each identifiable situation in 3.10.8.2.1 to 3.10.8.2.3 above.
"header-list"
set from the header-list of the parent work specification, starting with the header corresponding to the selected proforma followed by only those headers corresponding to proformas nested within the selected proforma. The headers corresponsing to nested proformas shall be in the order of the proformas in the abstract syntax definition of the proforma in a transfer-element.
"status"
shall be a SEQUENCE of zero components.
modify u
"ue-no-authority-to-remove-permission"
"ue-wrong-number-se-lists"
"ue-wrong-number-se-ref-lists"
"ue-wrong-number-source-lists"
"ue-wrong-number-source-ref-lists"
NOTE -- These requirements mean that if a J-INITIATE-WORK-MAN request specifies AGENCY ACCEPTANCE commitment, the agency receiving the display (typically the same device as the one performing the J-INITIATE), offers commitment to receipt of the document prior to receiving an offer of commitment for the J-INITIATE. If PROVIDER ACCEPTANCE was specified, the request for manipulation may be secured and performed at a later time.
normal-termination
{text text ,
spawn-count d }
"ue-invalid-modification"
modification
{text text ,
target-list t ,
hold-state h ,
stop-signal {modified NULL} }
NOTE -- Failure of the branch of the atomic action delivering the report does not result in failure of the manipulation.
violation-attempt
{text text ,
security-data
{ a ,
s }}
3.11 Report-manipulation operations
{delete rs }
{display
{selection rs ,
docname doc }
"monitor-system"
the local JTM-name MF2;
"time"
Null, or the time the display document is created;
a SEQUENCE of "Single-report", containing all selected "Single-report"s, in the order the reports were received by the JTM ASE.
NOTE -- It is an implementor's option whether the time is null or set to the time.
NOTE -- These requirements meant that if a J-INITIATE-REPORT-MAN request specifies a commitment level of AGENCY-ACCEPTANCE or higher, the agency receiving the display (typically the same device as the one performing the J-INITIATE), offers commitment to receipt of the document prior to receiving an offer of commitment for the J-INITIATE. If PROVIDER-ACCEPTANCE was specified, the request for manipulation may be secured and performed at a later time.
normal-termination
{text text ,
spawn-count d }
3.12 Transfer-control manipulation operations
{set-by s ,
recipient r ,
control-spec c }
"ue-no-tcr-authorisation"
set-by COPIED
recipient COPIED
time-stamp Null, or the current time
control-spec COPIED
NOTE -- Setting the transfer control record such that the currently active transfers would not be permitted does not disrupt those transfers.
{checking-by cq ,
recipient cr ,
control-spec cc }
"ue-no-tcr-authorisation"
{set-by ss ,
recipient sr ,
control-spec sc }
{recipient dr ,
docname doc }
{all NULL ,
docname doc }
"displaying-system"
the local JTM-name MF2;
"time"
Null, or the time the display document is created;
"controls"
dc
NOTE -- It is an implementor's option whether the time is null or set to the time.
"displaying-system"
the local JTM-name MF2;
"time"
Null, or the time the display document is created;
"controls"
a SEQUENCE of "Transfer-control-record", containing one value set from each transfer control record held at this JTM ASE in which the "control-spec" is not "uncontrolled NULL". If there are no such transfer control records, the SEQUENCE shall be empty.
NOTE -- It is an implementor's option whether the time is null or set to the time.
normal-termination
{text text ,
spawn-count d }
3.13 Action on J-END-SIGNAL requests
NOTE -- Special attention is needed to this area where a user program is used as an execution agency.
accounting-data
{text text ,
accounting-information a }
warning-report
{text text ,
errors
{generator-details g ,
diagnostics d } }
normal-termination
{text text ,
spawn-count n }
3.14 Spawning procedures
osi-job-submission-system COPIED
initiating-identification COPIED
initiating-time COPIED
osi-job-name COPIED
osi-job-local-reference COPIED
subjob-name-list COPIED
with an additional SEQUENCE
{proforma-name COPIED,
i }
audit-trace COPIED
primary-monitoring-specification COPIED
secondary-monitoring-specification COPIED
authorisations COPIED
permissions COPIED
accounts COPIED
security-parameters COPIED
sub-job-specification COPIED from the proforma;
proforma-list see below
<times spawned> Set to zero for all top-level proformas.
<time waiting> see below
<estimated size> see below
<agency activity parameters> COPIED
<CCR parameters> COPIED
<documents> see below
NOTE -- In Basic Class, this integer will always have the value one.
NOTE -- This may change the <hold state> to HELD.
NOTE -- In a proforma that is held when spawned, "conditional" and "completion" "spawning-control-data" are equivalent.
NOTE — It is a matter for individual implementation whether failure to immediately forward a transfer element produced by spawning
This distinction is visible externally by the work manipulation procedures, the original work specification remaining visible in case a), and the new one in case b). It also affects both the ease of implementation and the service provided. Option b) is generally to be preferred, but if forwarding of the transfer element is not possible, it requires the use of pointers to spooled material in execution agencies or of "double-spooling".
spawning
{text text ,
target-list rt ,
hold-state h }
not-supported
{text text ,
spawn-count 0 }
3.15 Procedure for report generation as a separate atomic action
NOTE -- In a Basic Class implementation, references in the procedures that specify a nominated bit other than "abnormal-termination" can be ignored.
{osi-job-submission-system COPIED ,
initiating-identification COPIED ,
initiating-time COPIED ,
osi-job-name COPIED ,
osi-job-local-reference COPIED ,
subjob-name-list COPIED ,
audit-trace COPIED ,
primary-monitoring-specification COPIED ,
secondary-monitoring-specification COPIED ,
authorisations COPIED ,
permissions COPIED ,
accounts COPIED ,
relays r ,
target t ,
type report-movement NULL ,
actions report-movement
{{monitor-indices {i} ,
{name-of-reporter a ,
time time ,
osi-job-submission-system COPIED ,
initiating-identification COPIED ,
initiating-time COPIED ,
osi-job-name COPIED ,
osi-job-local-reference COPIED ,
subjob-name-list COPIED ,
type COPIED ,
event-identification e }}}
NOTE -- It is an implementor's option whether to insert time as null.
{monitor-indices {i} ,
{name-of-reporter a ,
time time ,
osi-job-submission-system COPIED ,
initiating-identification COPIED ,
initiating-time COPIED ,
osi-job-name COPIED ,
osi-job-local-reference COPIED ,
subjob-name-list COPIED ,
type COPIED ,
event-identification e } }
3.16 Procedure for report generation as part of same atomic action
NOTE -- In a Basic Class implementation, references in the procedures that specify a nominated bit that is not one of "normal-termination", "manipulation-termination" or "user-message" can be ignored.
NOTE -- Implementations have the option of creating report-movement work specifications with several reports, and/or with several values in the "monitor-indices", or of creating a new report work specification for each event and for each "Monitoring-specification" that selects the event.
{osi-job-submission-system COPIED ,
initiating-identification COPIED ,
initiating-time COPIED ,
osi-job-name COPIED ,
osi-job-local-reference COPIED ,
subjob-name-list COPIED ,
audit-trace COPIED ,
primary-monitoring-specification COPIED ,
secondary-monitoring-specification COPIED ,
authorisations COPIED ,
permissions COPIED ,
accounts COPIED ,
relays r ,
target t ,
type report-movement NULL ,
actions report-movement
{{monitor-indices {i} ,
{name-of-reporter a ,
time time ,
osi-job-submission-system COPIED ,
initiating-identification COPIED ,
initiating-time COPIED ,
osi-job-name COPIED ,
osi-job-local-reference COPIED ,
subjob-name-list COPIED ,
type COPIED ,
event-identification e }}}
NOTE -- It is an implementor's option whether to insert time as null.
{monitor-indices {i} ,
{name-of-reporter a ,
time time ,
osi-job-submission-system COPIED ,
initiating-identification COPIED ,
initiating-time COPIED ,
osi-job-name COPIED ,
osi-job-local-reference COPIED ,
subjob-name-list COPIED ,
type COPIED ,
event-identification e }}
3.17 Action on J-MESSAGE requests
user-message
{text text }
3.18 Action on J-SPAWN requests
"ue-proforma-not-present"
3.19 Holding and releasing work specifications
time-of-day "hhmm"
time-interval i
date-time t
NOTE -- The J-HOLD action cannot be rolled back by the (subordinate) agency.
NOTE -- 4.4.19 requires that the documentation for an implementation state what is the maximum period that may elapse, if the implementation is active, between time t and the invocation of the procedures of 3.19.9. It is recommended that this time be not more than five minutes.
date-time t
modification
{text text ,
target-list t ,
not-held NULL ,
modified NULL }
3.20 Provider initiation of tcr-setting
NOTE -- It is an implementation option whether the procedures of this clause are invoked following other events, such as an attempted transfer to this JTM ASE from another open system when such an attempt should have been prevented by transfer-control.
NOTE -- It is an implementation choice as to whether, and with what scheduling, the procedures of this clause are re-invoked after an unsuccesful attempt to transfer the "transfer-manipulation" work specification.
osi-job-submission-system
Set from MF2
initiating-identification
"open-system<Identification", set from local management function MF2
initiating-time
Set to the current local time or "not-available NULL".
NOTE -- It is an implementation option whether the "initiating-time " is set to the local time or to null.
osi-job-name
Set by MF28
osi-job-local-reference
Set as specified in 3.2.1
subjob-name-list
Set to { }
audit-trace
Set as specified in 3.2.1
primary-monitoring-specification
Set as specified in 3.2.1
secondary-monitoring-specification
Set to { }
authorisations
See 3.20.2.1 below
permissions
See 3.20.2.1 and 3.20.2.2 below
accounts
Set to { }
Subjob-specification
- relays
Set to { }
- target
Set to "JTM-name" t
- urgency
Set by MF28
- holds
Set to { }
- error-action
Set to "terminate NULL"
- type
Set to "tcr-manipulation"
- actions
a SEQUENCE containing a single "Transfer-manipulation" with the CHOICE "set", with
set-by
set from MF2
recipient
the "JTM-name" r
control-spec
the "control-specification" cs
proforma-list
Set to { }
documents for transfer
Set to { }
<time waiting>
Set as specified in 3.2.1
<estimated size>
Set as specified in 3.2.1
<agency activity parameters>
Set as specified in 3.2.1
<CCR parameters>
Set by MF28
3.21 Provider initiation of tcr-check
NOTE -- It is an implementation option whether the procedures of this clause are also invoked following other events, or after a transfer control record has been stored for a considerable time.
{set-by s ,
recipient r ,
time-stamp time ,
control-spec cs }
osi-job-submission-system
Set from MF2
initiating-identification
"open-system<Identification", set from local management function MF2
initiating-time
Set to the current local time or "not-available NULL".
NOTE -- It is an implementation option whether the "initiating-time " is set to the local time or to null.
osi-job-name
Set by MF28
osi-job-local-reference
Set as specified in 3.2.1
subjob-name-list
Set to { }
audit-trace
Set as specified in 3.2.1
primary-monitoring-specification
Set as specified in 3.2.1
secondary-monitoring-specification
Set to { }
authorisations
See 3.21.2.1 below
permissions
See 3.21.2.1 and 3.21.2.2 below
accounts
Set to { }
Subjob-specification
- relays
Set to { }
- target
Set to "JTM-name" s
- urgency
Set by MF28
- holds
Set to { }
- error-action
Set to "terminate NULL"
- type
Set to "tcr-manipulation"
- actions
a SEQUENCE containing a single "Transfer-manipulation" with the CHOICE "check", with
checking-by
set from MF2
recipient
the "JTM-name" r
control-spec
the "control-specification" cs
proforma-list
Set to { }
documents for transfer
Set to { }
<time waiting>
Set as specified in 3.2.1
<estimated size>
Set as specified in 3.2.1
<agency activity parameters>
Set as specified in 3.2.1
<CCR parameters>
Set by MF28