5.5.5.3 Tests for the Distributed Systems Annex

The ACATS tests for the Distributed Systems Annex are applicable only to implementations that wish to test this SNA. Not all of these tests apply to all implementations, since the annex includes some implementation permissions that affect the applicability of some tests.

The principal factors affecting test applicability are: 

An implementation may test for the annex without providing a PCS. In order to test for the Distributed Systems Annex, an implementation must allow a body for System.RPC to be compiled.

Ada allows explicit message-based communication between active partitions as an alternative to RPC [see Ada E.2.3(20)]. If an implementation does not support the Remote_Call_Interface pragma then the following tests are not applicable:

An implementation is not required to provide a PCS [see Ada E.5(27)] in order to test the Distributed Systems Annex. If no PCS is provided then the following tests are not applicable:

Two tests provide a body for System.RPC, and a third test checks the specification of System.RPC. An alternative declaration is allowed for package System.RPC [see [Amend1] E.5(27.1/2)]. If an alternative declaration is used for System.RPC, the following tests are not applicable:

Many implementations that support the Distributed Systems Annex will also support the Real-Time Annex. Test cxe4003 is designed to take advantage of Real-Time Annex features in order to better test the Distributed Systems Annex.

For implementations that do not support the Real-Time Annex, test cxe4003 must be modified. This modification consists of deleting all lines that end with the comment --RT.

Some Distributed Systems Annex tests require multiple partitions to run the test, but no more than two partitions are required for running any of them. All multi-partition tests contain a main procedure for each of the two partitions. The two partitions are referred to as "A" and "B" and the main procedures for these partitions are named <test_name>_A and <test_name>_B respectively. Each test contains instructions naming the compilation units to be included in each partition. Most implementations will be primarily concerned with the main procedure and RCI packages that are to be assigned to each partition; the remainder of the partition contents will be determined by the normal dependency rules. The naming convention used in multi-partition tests aid in making the partition assignments. If the name of a compilation unit ends in "_A<optional_digit]>" then it should be assigned to partition A. Compilation units with names ending in "_B<optional_digit>" should be assigned to partition B.

The following tests require that two partitions be available to run the test:

(*) Tests cxe2001 and lxe3002 contain a Shared_Passive package and two active partitions. They may be configured with either two or three partitions. The two-partition configuration must have two active partitions and the Shared_Passive package may be assigned to either one of the active partitions. The three-partition configuration consists of two active partitions and a single passive partition, and the passive partition will contain the single Shared_Passive package.

All of the multi-partition tests include the package Report in both of the active partitions. In order for the test to pass, both partitions must produce a passed message (except for lxe3002 - see special instructions for that test). If either partition produces a failed message, or if one or both partitions do not produce a passed message, the test is graded "failed".

When running the multi-partition tests it is not important which partition is started first. Generally, partition A acts as a server and partition B is a client, so starting partition A first is usually best.

In the event a test fails due to the exception Communication_Error being raised, it is permissible to rerun the test.