Section 4 : Basic Class

4.1 Primitive groups and document types for Basic Class

4.1.1 Service primitive groups

The following groups of primitives are available:

          J-INITIATE-WORK
          J-INITIATE-WORK-MAN
          J-DISPOSE
          J-GIVE
          J-END-SIGNAL
          J-STATUS
          J-KILL
          J-STOP
          J-MESSAGE

A Basic Class implementation can support any combination of the following sets of service primitives:

1. J-INITIATE-WORK
2. J-INITIATE-WORK-MAN
3. J-DISPOSE (to a sink or execution agency), with completion commitment on the J-READY
4. J-GIVE (for the activity end group)
5. J-DISPOSE (to a sink or execution agency), with agency acceptance commitment on the J-READY
       J-END-SIGNAL
       J-STATUS
       J-MESSAGE
       J-KIL­L
       J-STOP

A Basic Class system does not support the value COMPLETION for the commitment level on a C-BEGIN or J-BEGIN. It may, however, return such a value or accept such a value on a C-READY or a J-READY.

4.1.2 Document types

Basic Class systems do not necessarily support a full range of document types. ISO/IEC 8832 defines three document types named by ASN.1 ObjectDescriptor values (see ISO/IEC 8824) of

          "Simple ISO text document"
          "Simple ISO print document"
          "Simple ISO binary document"

For brevity, these are referred to in this section only as text (1), print (2), and binary (3) respectively.

In addition, the following document types (see 3.5) are used in Basic Class:

          "JTM work-display document"
          "JTM report-display document"

For brevity, these are referred to in this section only as work-display (4) and report-display (5) (but see also 4.2.1).

The following document types are supported by Basic Class implementations claiming to be general purpose:

     in J-INITIATE-WORK
               text (1)
               print (2)

     in the proforma in J-INITIATE-WORK
               print (2)

     in the proforma in J-INITIATE-WORK-MAN
               work-display (4)  (Brief only)

     in J-GIVE
               print (2)

     in J-DISPOSE
               text (1)
               print (2)
               report-display (5)
               work-display (4)  (Brief only)

Note that other document types are not necessarily supported by a JTM Basic Class implementation.

4.2 Conceptual datastructures for Basic Class

This clause defines the subset of the datastructures (defined in clauses 3.3, 3.4, and 3.5) which are used in the Basic Class. Clause 4.3 defines additional Basic Class restrictions related to the parameters of service primitives.

NOTE -- Where the parameters of the Basic Class J-INITIATE request (defined in clause 4.3) are more restricted than the corresponding fields of the Basic Class conceptual datastructure defined in this clause, the general case defined here only occurs when a Basic Class implementation is interworking with an implementation posessing functionality exceeding that required for Basic Class.

4.2.1 Reports

Basic Class reports are generated by Basic Class implementations. A Basic Class monitor point can only handle Basic Class reports.

These reports are a subset of the reports defined in 3.3.2, as follows:

     <report>::=     <name of reporter>
          <time stamp>
          <subjob identification>
          <event identification>
          <event parameters>

<subjob identification> has the full range of values specified in 3.3.2.

     <event identification>::=     ( NORMAL-TERMINATION | MANIPULATION-TERMINATION |
            ABNORMAL-TERMINATION | USER-MESSAGE )

Other events are not recognised in Basic Class. Reports of other events are not handled by Basic Class Monitor Points. Requests (in a <report selector>) for reporting of other events cause a work specification to be refused by a Basic Class system.

The only <event parameters> supported are <number spawned>, <text>, and <diagnostic>.

4.2.1.1 Diagnostic information

The <diagnostic information> in reports received by Basic Class monitor points can have the full form defined in 3.3.3 with the following exceptions.

The <source details> and <se details> fields do not refer to FTAM activity, and the <CCR diagnostics> do not contain an <FTAM outcome>.

4.2.1.2 Accounting information

Accounting information is not generated by Basic Class systems. If it is passed to such systems on a C-READY or C-REFUSE it is ignored.

4.2.2 Work specifications

A Basic Class implementation supports a restricted form of work specification. Work specifications are created on a Basic Class system as the result of an incoming transfer, or (if an initiation agency is supported) a J-INITIATE (see clause 4.3). Such work specifications contain only the information defined below. An attempt to transfer a more complex work specification to a Basic Class system results in refusal and a CCR diagnostic.

     <work specification>::=     <OSI job parameters>
          <subjob specification>
          <proforma list>
          <local fields>
          <document list>

<local fields> are as in 3.4.1, except that <time waiting> and <estimated size> are not present, and the <agency activity parameters> identify at most one agency activity.

     <subjob specification>::=     <OSI subjob parameters>
          <JTM action parameters>
          <error action>

     <error action>::=     TERMINATE

     <proforma list>::=     [<proforma>]*L

     <document list>::=     [<document>]*L

The <proforma list> for any work specification with a Basic Class <target> contains at most a single top-level proforma. Any proforma lists within this proforma are handled transparently. Work specifications produced at a Basic Class system by spawning, and targeted at some other system, contain a transparent proforma list.

NOTE -- Proforma lists only occur within a proforma if the original work specification was created on an implementation with a functionality exceeding that required for Basic Class.

A Basic Class work specification contains at most a single <document>, referenced by the top-level subjob.

4.2.2.1 OSI job parameters

Basic Class restrictions on these parameters apply to the whole OSI job. Any OSI job which is to make use of a Basic Class system for the processing of any of its OSI subjobs is subject to the restrictions of this clause.

     <OSI job parameters>::=     <OSI job submission system>
          <initiating identification>
          <initiating time>
          <OSI job name>
          <OSI job local reference>
          <audit trace>
          <primary monitoring specification>
          <authorisations>
          <permissions>
          <CCR parameters>

Note that <secondary monitoring specification>s, <accounts> and <security parameters> are not present.

NOTE -- Interworking between an extended implementation requiring <accounts> and a Basic Class implementation is not possible. For this reason, extended implementations are required to be able to operate without <accounts>.

The fields of the <OSI job parameters> have the full form and meaning defined in 3.4.2, with the exceptions given below.

A Basic Class system can choose to ignore the <authorisations> and to perform authorisation using data contained in the <documents> being sent to sink or execution agencies.

NOTE -- Basic Class systems are not required to support source agencies. Authorisation for J-GIVE is therefore not required, as access is only to an execution agency activity established by an ealier J-DISPOSE. The linkage between the two primitives is the agency activity id.

The <primary monitoring specification> does not contain any <relay>, and the <disposal instructions> do not have the value KEEP.

The <report selector> contains only the following event categories:

          NORMAL-TERMINATION
          MANIPULATION-TERMINATION
          ABNORMAL-TERMINATION
          USER-MESSAGE

4.2.2.2 OSI subjob parameters

     <OSI subjob parameters>::=     <subjob name-list>
          <target list>
          <urgency>
          <subjob type>

The <target list> contains only <target> for any work specification transferred to a Basic Class system or generated there by spawning or by J-INITIATE. The <holds> is also absent from such subjobs.

These restrictions do not apply in proformas which remain transparent to the Basic Class system (are not spawned) (see 4.2.7).

The <subjob type> is one of

          REPORT-MOVEMENT
          DOCUMENT-MOVEMENT
          WORK-MANIPULATION

Other <subjob type> values appear only in proformas which remain transparent.

4.2.3 Document movement operations

The following restrictions apply to any subjob whose <target> is a Basic Class system. They do not apply where a proforma is handled transparently (see 4.2.7).

There is a single <document movement>, and a single <se identification>. The <document block> is a <single form>.

The <se identification> is not the <FTAM se> form. It has no <additional authorisations>, the <agency parameter> is NULL, and the <se prefix> is empty.

The <document se reference> is not the <FTAM write-data> form, and the <se access parameter> is NORMAL.

There is a single <document pointer> which, on arrival at a Basic Class target system, has the value EMBEDDED, or contains a single <single document reference> with <state> FAILED.

In the latter case, the <source identification> is <JTM source>, there are no <additional authorisations>, and the <document source reference> is <JTM read-data>. The <CCR diagnostics> has the form defined in 4.2.1.1 above.

Where the <document movement operations> are in a top-level subjob produced at a Basic Class system by spawning, a <single document reference> with state NOT-ATTEMPTED can be present. If the <action open system> is the local system, the <source identification> is either PROVIDER or a <JTM source> which is an execution agency, and there is an <agency parameter> of NULL, and a <source access parameter> of MOVE.

4.2.4 Work manipulation operations

Work manipulation operations in a subjob targeted at a Basic Class system have the following restrictions.

The <work specification operations> consist of exactly two <work operation>s. The first <work-operation> is

          SELECT <selector>     (see below)

The second is one of

          KILL
          STOP
          DISPLAY <doc-name> BRIEF

The <selector> consists of three <field test>s combined by <AND clause>s to give a <header test>. The <selector> is then

          FIRST-HEADER-IS
          <header test>

The three <field test>s are tests for equality on the three fields

          OSI-JOB-SUBMISSION-SYSTEM
          OSI-JOB-NAME
          SUB-JOB-TYPE

Use of ANY-ITEM is not supported in Basic Class.

The header list conceptual data structure thus contains only a single header with only these three fields, in Basic Class systems.

Where a work specification contains embedded proformas, these are wholly transparent, and open system names carried in the <target> or <relay>s of these proformas do not provide implicit permissions for manipulation or display of the work specification.

4.2.5 Report movement operations

A <report movement operation> has the full generality specified in 3.4.4.5 except that

1. the monitor index is always zero (primary monitors only); and
2. the <disposal data> is not KEEP; and
3. the restrictions on the form of (se identification> and <document se reference> defined in 4.2.3 apply.

4.2.6 Proformas

The top-level proforma in a Basic Class system has <spawning control data> set to COMPLETION. The proforma name is not used in any proforma reference in any embedded proforma.

4.2.7 Transparency of proformas

A work specification transferred to a Basic Class system has a <target> of that open system.

A work specification created by spawning (or by J-INITIATE) might (the first case) or might not (the second case) have that open system as the <target>.

In the first case, the subjob specified in the work specification has at most one top-level proforma; the main subjob, the top-level proforma, and the subjob specified in the top-level proforma are all subject to the Basic Class restrictions specified in this clause. The proforma-list in the top-level proforma is transparent and unrestricted.

In the second case, the subjob specified in the work specification is subject to the Basic Class restrictions, but the proforma-list in the subjob is transparent and unrestricted.

4.2.8 Transfer control records

Basic Class systems do not recognise the concept of transfer control records, nor do they support TCR-MANIPULATION subjobs.

All transfers made from such systems are scheduled in an implementation-dependent way.

4.2.9 JTM documents

A Basic Class system supports the generation and transfer of JTM work displays containing only <brief display>. It does not support such documents if they contain <full display>.

If the system provides support for generation of J-INITIATE-MAN, it supports the receipt of such documents and their disposal using J-DISPOSE.

If the Basic Class system provides support for a monitor point, it is capable of converting a <report> (but see 4.2.1) into a JTM report display document and disposing of this document using J-DISPOSE to a sink.

JTM TCR display documents are not supported.

A Basic Class system intended for general purpose use supports the document types listed in 4.1.2. It might also support other document types.

4.3 J-INITIATE primitive group parameters for Basic Class

In the Basic Class service, a J-INITIATE primitive group has a subset of the parameters available in the extended JTM service. The following restrictions apply.

The commitment level has only the values PROVIDER-ACCEPTANCE and AGENCY-ACCEPTANCE on J-BEGIN.

There are no <secondary monitoring specification>s. There are no <accounts>. There are no <security parameters>.

Only

          J-INITIATE-WORK
          J-INITIATE-WORK-MAN

are available.

The <subjob specification> for J-INITIATE-WORK is subject to the restrictions specified in clause 4.2, but in addition the following restrictions apply.

4.3.1 Top level parameters

4.3.2 OSI job parameters

4.3.3 OSI subjob parameters

4.3.4 JTM action parameters

These are either <document movement operations> or <work manipulation operations>.

4.3.4.1 Document movement operations

There is a single <document movement> consisting of:

<document type>	This is a document type of text (1) or print (2).
<se agencies>	There is one <se identification> of the <JTM se> form containing
<se name>	A value of a sink name (document type print (2)) or an execution agency name (document type text (1)) at the <target>.
<agency parameter>	This is NULL.
<se prefix>	This is NULL.
<additional authorisations>	None
<document block>	This is a <single form> containing <JTM write-data>:
<se access parameter>	Set to NORMAL.
<name-list>	Set to the name of the document.
one <document pointer>	Set to EMBEDDED.

4.3.4.2 Work manipulation operations

There are two <work manipulation operation>s. The first is a <select operation>, and the second is a KILL, STOP or DISPLAY operation. The <selector> is

     FIRST-HEADER-IS
          AND     OSI-JOB-SUBMISSION-SYSTEM
                         EQUALS <name>
          AND     OSI-JOB-NAME EQUALS <string>
               SUB-JOB-TYPE
                         EQUALS <subjob type>

The DISPLAY operation requests BRIEF, and the <docname> is the string DISPLAY. The <name> is that of the open system where the J-INITIATE-MAN was issued.

4.3.5 Proformas

The single proforma, if present, consists of

<proforma name>

Set to "OUTPUT".

A proforma body with:

<spawning control data>	Set to COMPLETION.
<OSI subjob parameters>	As in 4.3.3, but the subjob type is DOCUMENT-MOVEMENT.
<JTM action parameters>	See below
<proforma list>	Proformas do not appear in proformas in Basic Class J-INITIATE.

The JTM action parameters in the Basic Class proforma consist of a single document movement operation with:

<document type>	Any	A minimal conforming OSI job submission system is capable of setting this field to print (2) (for J-INITIATE-WORK) and to work-display (4) (for J-INITIATE-WORK-MAN), and is not required to support the setting of any other values. Minimal conforming receivers of work specifications are not required to support any value other than those listed above.
<se agency>	There is one <se identification> of the <JTM se form>:
<se name>	An appropriate name for a sink at the proforma target.
<agency parameter>	This is NULL.
<se prefix>	This is NULL.
<document block>	This is a <single form> containing:
<se access parameter>	Set to NORMAL.
<name-list>	A single name.

The <document block> also contains a single <document pointer> which is a <single document reference> giving

<action open system>	This equals the initial <target>.
<source identification>	This is PROVIDER in a proforma in a manipulation, otherwise it is a <JTM source>:
<source name>	This equals the initial <se name>.
<agency parameter>	This is NULL.
<document source reference>	This is <JTM read-data>:
<source access parameter>	This is MOVE.
<name-list>	This is a suitable value for collecting the document from the target.
<embedded diagnostics>	This is EMBED

4.3.6 Summary of information contained in a Basic Class J-INITIATE request

4.3.6.1 J-INITIATE-WORK

The following information is passed to the JTM service provider in this primitive:

1. an initiating identification;
2. an OSI job-name;
3. the name of the target;
4. the name of a sink or execution agency at the target;
5. a user identification and password for use at the target;
6. a text (1) or print (2) document to pass to the execution or sink agency (respectively), and its name;
7. the name of the proforma target (if an execution agency is used);
8. a user identification and password for use at the proforma target if this is required;
9. the name of the resulting print (2) document produced at the initial target;
10. the name of a sink agency at the proforma target for the resulting print (2) document;
11. a name for the resulting print (2) document when passing it to the sink at the proforma target.

All other fields have fixed values.

4.3.6.2 J-INITIATE-WORK-MAN

The following information is passed to the JTM service provider in this primitive:

1. an initiating identification;
2. an OSI job-name for the manipulation;
3. an OSI job-name for the OSI job which is to be manipulated, and its subjob type;
4. the name of the target;
5. a user identification and password for use at the target;
6. whether the manipulation is a request to DISPLAY BRIEF, STOP or KILL the OSI job being manipulated;
7. the name of the proforma target;
8. a user identification and password for use at the proforma target if this is required;
9. a sink name for the work-display (4) document at the proforma target;
10. a name for the work-display (4) document when passing it to the sink at the proforma target.

4.4 Other primitive groups in Basic Class

4.4.1 J-DISPOSE

The full set of parameters defined in 3.6.2 are carried, with the following exceptions.

There are no <additional authorisations>, no <user account>, and the <agency parameter> is NULL. The <diagnostic information> does not contain any <FTAM outcome>.

The <disposal document> is either work-display (4) (Brief), report-display (5), text (1) (for an execution agency), or print (2) (for a sink agency).

4.4.2 J-GIVE

The full set of parameters defined in 3.6.3 are carried, with the following exceptions.

There are no <additional authorisations>, no <user account>, and the <agency parameter> is NULL. The <document group> is <activity end group> and the <document type> is print (2).

4.4.3 Other groups

The remaining primitive groups of Basic Class (J-MESSAGE, J-END-SIGNAL, J-STATUS, J-KILL, J-STOP) carry the full range of parameters defined in 3.6.5, 3.6.7, 3.6.8, and 3.6.9.

4.5 Summary of Basic Class primitives and parameters

A summary appears as table 4.