Annex C

C.1 Introduction

This annex describes some tests which can be applied to a JTM implementation to establish that it does not conform to this International Standard. This annex does not form a complete specification of tests, but rather provides a framework within which such a specification could be developed. For this reason, it is not part of this International Standard.

This annex describes a set of tests for JTM implementations. An implementation is not required to have been tested, nor can an implementation claim conformance simply because it passes all the listed tests. The tests are to be applied where it is necessary to check an implementation.

C.2 Testing architecture

C.2.1 The lower tester

Provided all applicable standards are known, it is possible to attach suitable test equipment to the physical medium, and to use it to determine the PDUs which are being transmitted, and to generate PDUs. Where the lower layers of the JTM implementation under test are considered to be conforming (they have already been tested by the tests specified for their layer), and the test equipment contains a conforming implementation of the lower layers, it can be used to recognise or to generate conceptual events at the lower boundary of the layer under test (P-DATA indications in JTM context and C-service indications and confirms).

Where there is (unusually) a downwards facing visible interface below the layer under test, but above the physical medium, this provides an alternative means of recognising or generating conceptual events at the lower boundary of the layer.

Finally, events at the lower boundary of the layer under test may also be recognised or generated by exercising a corresponding visible interface in remote equipment. (Issuing P-DATA or C-service requests).

The equipment or set of procedures used to generate and display these events (using any of the above configurations) forms the lower tester. The detailed specification of this equipment or set of procedures is outside the scope of this International Standard.

It is possible to apply a number of tests using the lower tester alone. Such tests can be independent of the details of the implementation, and are therefore generally to be preferred to tests using other interfaces. In general, however, tests at this interface alone are insufficient to detect certain forms of non-conformance.

C.2.2 The upper tester

An implementation of JTM either

1. provides a visible interface for J-service primitives; or
2. specifies a referencing standard which makes use of J-service primitives, and itself provides a visible interface.

A suitable test configuration or procedures can exercise this visible interface, and is necessary to perform any tests concerned with "real" services provided by JTM, such as the successful printing of output. This configuration or set of procedures forms the upper tester; it always contains some features which are dependent on the implementation, as standards do not exist for interfaces (except for the physical medium). Upper and lower testable interfaces are illustrated in figure C.1

Figure C.1 — JTM testing architecture

C.3 Test configuration

C.3.1 The tester shall determine which of the claims in clause 4.2 are made by the implementation.

C.3.2 The tester shall determine that the documentation provides all the information required by this International Standard.

C.3.3 The tester shall identify the externally visible and testable events corresponding to JTM service primitives and shall establish suitable computer programs, devices, and manual procedures to generate and to monitor these events and states.

C.3.4 The tester shall attach equipment to the physical medium interface of the implementation which will verify that state changes caused by the product are in conformance with this International Standard (and the International Standards it references), and which will generate events to test the reaction of the implementation.

NOTE -- The connection need not be direct. Another implementation connected across a network forms a possible lower tester for JTM (see C.2.2).

C.3.5 There shall be no other inputs to the implementation during the tests.

C.4 Management functions

C.4.1 The tester shall verify that the requirements of clause 4.3 are satisfied.

C.4.2 The tester shall verify that the procedures defined in the documentation for configuring management functions are effective.

C.5 Loss of secure data

C.5.1 The tester shall initiate activity from the physical medium, and shall interrupt the mains power to the implementation at a sample of points at which secure data should be changed. The recovery procedure shall be initiated by the tester, following restoration of mains power and any implementation-defined initialisation procedures (see 4.4.13). Correct operation of the implementation in relation to CCR Recovery shall be established.

C.5.2 The tester shall initiate activity by each of the available initiation agencies (if any), and shall proceed as in C.5.1 to verify that secure data is not lost. The tester shall also verify that the implementation does not depend on external inputs (other than those which are part of the implementation-defined initialisation procedures) for the completion of recovery and CCR procedures.

C.6 Initiation agency tests

The following test shall be completed for each initiation agency:

A sample of the Basic Class range of values of J-INITIATE parameters shall be selected by the tester, and the initiation agency shall be activated. Correct operation shall be verified by the test equipment on the physical-medium, including a sample of cases where immediate transfer is not possible.

C.7 Sink agency tests

The following tests shall be completed for each sink agency:

C.7.1 Disposal to the sink shall be activated by the tester by inputting a work specification on the physical medium, and the effect observed for all document types for which support is claimed.

C.7.2 For agencies providing AGENCY-ACCEPTANCE, the tester shall use the physical medium interface to cause acceptance of a series of documents, followed by injection of work specifications causing J-STATUS, J-STOP and J-KILL to be issued, and shall verify correct operation.

C.8 Execution agency test

A test shall be completed for each execution agency by injecting suitable work specifications at the physical medium interface to establish that:

1. normal JTM operation is as specified;
2. DISPLAY, STOP and KILL produce the specified effects.

C.9 JTM activity tests

Tests shall be applied to establish that

C.9.1 failure to transfer a work specification to a particular target does not prevent transfer of other work specifications to other targets.

C.9.2 queues are maintained and serviced without blockage, as specified in 3.5.10.

C.9.3 DISPLAY, STOP and KILL function correctly for work specifications on JTM queues, and for work specifications for which commitment groups are still incomplete.

C.10 Programming language tests

Where a product provides a programming language interface to control or display the effects of an agency, the following tests shall be applied:

C.10.1 A check shall be made that the procedures do not allow one program to use agency names allocated to other programs.

C.10.2 A check shall be made for a sample of cases that a malfunctioning program cannot cause externally visible events which are inconsistent with a correct sequence of primitives.

C.11 Error cases

A sample of erroneous event sequences shall be initiated at the physical medium interface, and correct rejection established. These tests shall include, but are not limited to:

1. a sample of syntactically incorrect transfer elements; and
2. a syntactically correct transfer element requesting facilities outside the Basic Class; and
3. a work specification with no authorisation data for the system under test.

C.12 Masquerade checks

The tester shall attempt to identify failures of the specification to meet the requirements of 4.1.6, 4.1.7 and 4.1.8 in respect of prevention of the use of names, titles and addresses which have not been allocated to the system or program, and shall check that any specified mechanisms function as claimed.

Annex D

The following OBJECT IDENTIFIER and ObjectDescriptor values are used in this International Standard:

OBJECT IDENTIFIER ObjectDescriptor	Clause or annex B reference
{iso standard 8832} "ISO JTM Basic Class Standard"	2.2.5
{iso standard 8832 application-context (1) basic (1)} "ISO JTM Basic Class Application-context"	2.2.5.1
{iso standard 8832 application-context (1) full (2)} "ISO JTM Full Application-context"	2.2.5.1
{iso standard 8832 abstract-syntax (2)} "ISO JTM Abstract Syntax"	2.2.5.2
{iso standard 8832 transfer-syntax (3)} "ISO JTM Transfer Syntax"	2.2.5.3
{iso standard 8832 document (4) text (1)} "ISO JTM simple text document"	JTM-1
{iso standard 8832 document (4) print (2)} "ISO JTM simple print document"	JTM-2
{iso standard 8832 document (4) binary (3)} "ISO JTM simple binary document"	JTM-3
{iso standard 8832 document (4) work-display (4)} "ISO JTM work-display document"	JTM-4
{iso standard 8832 document (4) report-display (5)} "ISO JTM report-display document"	JTM-5
{iso standard 8832 document (4) transfer-display (6)} "ISO JTM transfer-display document"	JTM-6
{iso standard 8832 document-abstract-syntax (5) text (1)} "ISO JTM simple text abstract syntax"	JTM-1
{iso standard 8832 document-abstract-syntax (5) print (2)} "ISO JTM simple print abstract syntax"	JTM-2
{iso standard 8832 document-abstract-syntax (5) binary (3)} "ISO JTM simple binary abstract syntax"	JTM-3
{iso standard 8832 document-transfer-syntax (6) text (1)} "ISO JTM simple text basic transfer syntax"	JTM-1
{iso standard 8832 document-transfer-syntax (6) print (2)} "ISO JTM simple print basic transfer syntax"	JTM-2
{iso standard 8832 document-transfer-syntax (6) binary (3)} "ISO JTM simple binary basic transfer syntax"	JTM-3
{joint-iso-ccitt asn1(1) basic-encoding(1))} "Basic encoding of a single ASN.1 type"	2.2.5.3

Annex E

Figure E.1 shows a typical job transfer activity, with spawning of a proforma to collect output and creation of a normal-termination report at the job execution system. The creation and transmission of the normal-termination report at the job output system are not shown.

Figure E.1 — An example of Job Transfer

Figure E.2 shows a primitive sequence for the activity illustrated in E.1, with provider-acceptance commitment and with no attempt by subordinates to upgrade to a higher commitment level. Figure E.3 shows the corresponding time sequence of the atomic actions.

Figure E.2 — Service primitive sequence for figure E.1 using provider acceptance

Figure E.3 — Time sequence diagram for the atomic actions shown in figure E.2

Figure E.4 shows a primitive sequence for the same activity, with agency-acceptance commitment on the initial atomic action and provider acceptance on the later actions, with no attempt by subordinates to upgrade to a higher commitment level. Figure E.5 shows the corresponding time sequence of the atomic actions.

Figure E.4 — Service primitive sequence for figure E.1 using agency acceptance

Figure E.5 — Time sequence diagram for the atomic actions shown in figure E.4