Home/Compilers

Ada Validation Procedures, Version 4.2
September 1996

FINAL

Prepared by:
National Institute of Standards and Technology (NIST)
Information Technology Laboratory
Conformance Testing Group
Building 820NN, Room 517
Gaithersburg, Maryland 20899
USA

Table of Contents

Executive Summary Appendix A. Declaration of Conformance
1. Introduction Appendix B. Implementer Dispute Format
2. Glossary of Terms Appendix C. Test Dispute and Resolution Process
3. Organizations and Responsibilities Appendix D. Registration Request
4. The Ada Compiler Validation Capability Appendix E. Points of Contact
5. Validation by Testing Appendix F. References
6. Registration of Derived Implementations Appendix G. Sample Certificate of Validation

Table of Contents

Executive Summary

1. Introduction

2. Glossary of Terms

3. Organizations and Responsibilities

3.1 National Institute of Standards and Technology (NIST)
3.2 Ada Validation Facilities (AVFs)
3.3 ACVC Reviewers
3.4 Fast-Reaction Team (FRT)
3.5 Customers
3.6 NIST TMCC

4. The Ada Compiler Validation Capability

4.1 Versions
4.2 Applicability of ACVC Test Programs
4.3 Test Modifications
4.4 Test Withdrawal
4.5 Customization
4.6 Availability

5. Validation By Testing 5.1 Step One: Validation Agreement
5.2 Step Two: Prevalidation
5.2.1 Customer Testing
5.2.2 Submission of Results
5.2.3 Test Modifications
5.2.4 Test Issues
5.2.5 Test Issue Resolution
5.2.6 Grading Rules for Representation Clause Tests
5.2.7 Incomplete Prevalidations
5.2.8 Successful Prevalidation
 5.3 Step Three: Validation Testing
5.4 Step Four: Declaration of Conformance
5.5 Step Five: Validation Summary Report (VSR)
5.5.1 VSR Production
5.5.2 VSR Availability
 5.6 Step Six: Validation Certificate
5.7 Provisional Validation
5.8 Advertising Validated Status

6. Registration of Derived Implementations

6.1 Registration Request
6.2 Evaluation
6.3 Registration
6.4 Expiration of Validated Status
6.5 Challenges
6.6 Challenge Mark
6.7 Challenge Test

Appendix A. Declaration of Conformance

Appendix B. Implementer Dispute Format

Appendix C. Test Dispute and Resolution Process

Appendix D. Registration Request

Appendix E. Points of Contact

Appendix F. References

Appendix G. Sample Certificate of Validation

Executive Summary

The purpose of this executive summary is to provide an overview of the Ada compiler validation process. Anyone who obtains services from the Ada certification body must understand the definitions of terms and follow the specific rules provided in the body of this document.

This Version (4.2) of Ada Compiler Validation Procedures has been updated to reflect changes in responsibility for administration of the Ada Certification System. Beginning October 1, 1996, the National Institute of Standards and Technology (NIST) will serve as the point of contact for Ada Certification issues.

Version 4.1 of the Ada Compiler Validation Procedures was to reflect the release and use of ACVC 2.0.1 during the transition period when compiler vendors will incorporate the features provided by the revised Ada language standard, ANSI/ISO/IEC 8652:1995 and FIPS 119-1. The transition period is from February 1995, when Ada 95 was published as an approved standard, until March 31, 1997, when the Ada 95 Ada Compiler Validation Capability (ACVC) version 2.1 is required for use in the validation process. During the transition period, two (2) ACVC versions will be "current" versions used for validation testing - ACVC 1.11 for Ada 83 and ACVC 2.0.1 for Ada 95. During the transition period compiler vendors may choose to earn a certificate for either Ada 83 or Ada 95. The mandatory criteria for obtaining an Ada 95 certificate using ACVC 2.0.1 require the passing all applicable Ada 9X Basic tests and either all "OOP" or all "real-time" tests. ACVC 2.0.1 is in use from March 31, 1996 until March 31, 1997. Certificates issued for compilers tested with ACVC 1.11 or 2.0.1 will expire March 31, 1998. ACVC 2.1 will be available for public review three months before it becomes the official Ada 95 ACVC version on March 31, 1997.

Certification System

The Ada certification body consists of the National Institute of Standards and Technology (NIST), the Test Method Control Committee (TMCC), and NIST recognized Ada Validation Facilities (AVFs). The NIST issues the Ada validation certificates, maintains the Ada Compiler Validation Capability (ACVC), reviews all Validation Summary Reports (VSRs), reviews and adjudicates with assistance of the TMCC all disputes regarding the Ada test instrument, and maintains current operating agreements with the AVFs (see Appendix E for points of contact).

The NIST has the responsibility for establishing and maintaining a certification system for the Federal Information Processing Standards (FIPS).

Ada Compiler Validation Capability (ACVC)

The ACVC is designed to demonstrate the compliance of an Ada implementation with the Ada programming language. Some test programs may contain test objectives that are irrelevant for a particular Ada implementation and may be declared inapplicable, in whole or in part, for that implementation. A test program may be withdrawn from the ACVC by the NIST when it is found that it is based on assumptions that need not hold true for all Ada implementations or that the test program does not meet its test objective. Any interested party may dispute a test program to the NIST. An AVF customer must dispute a test program only through the AVF providing validation services. (See Sections 4.4, 5.2.4, 5.2.5 and Appendices B and C for discussion of the dispute process and formats for submitting a dispute.) The AVF customizes an ACVC for each Ada implementation that is validated by an AVF.

An Ada implementation passes a given ACVC version if it processes each test of the customized ACVC version according to grading criteria for individual tests and the test result profile matches the passing requirement for a specific ACVC version. During the transition period, there are three exceptions to previous procedures for establishing the applicability of ACVC test programs. These exceptions are:

a. For an Ada 83 validation, a failure of an ACVC version 1.11 test program may be judged inapplicable when the failure is caused by a correct but partial implementation of Ada 95.

b. For an Ada 95 validation with ACVC version 2.0.1, the mandatory criteria for obtaining a certificate is that all applicable Ada 9X Basic tests must be passed and either all tests labeled "OOP" or all tests labeled "real-time" must be passed. The Ada 9X Basic tests, OOP tests, and real-time tests are identified in the ACVC Version 2.0.1 User's Guide.

For Ada 95 validations, ACVC test programs for Specialized Needs Annexes will not be processed unless the AVF customer requests that they be processed. The result of these tests will not affect the issuance of a certificate for the core language.

Validation Testing

The validation testing process involves interaction between the AVF customer and the Ada certification body. The testing process consists of well defined steps, concluding with the issuance of a validation certificate when the test results indicate zero non-conformities or the issuance of a Registered Validation Summary Report when one or more non-conformities are indicated by the test results. In either case, a Validation Summary Report (VSR) is issued to document the validation effort. The steps in the testing process are:

a. A formal validation agreement is established between the customer and an AVF for validation services (see Section 5.1).

b. Prevalidation is completed (see Section 5.2).

c. Validation testing is performed by an AVF at a mutually agreed upon site. That is, the AVF performs an on-site witness testing (see Section 5.3).

d. A Declaration of Conformance is completed and signed by the customer not later than at the on-site AVF validation testing. A validation certificate will not be issued until a Declaration of Conformance has been completed (see Section 5.4 and Appendix A).

e. A VSR is completed by the AVF to document the validation by testing (see Section 5.5).

f. The NIST issues a validation certificate for a successfully tested Ada implementation (see Section 5.6).

An Ada implementation that fails one (1) to ten (10) ACVC test programs will not receive a Validation Certificate but will receive a Registered Validation Summary Report (RVSR). That RVSR has an expiry date of not more than 12 months after completion of on-site testing, by which date the failing Ada implementation must be retested by the AVF and must pass the ACVC to obtain a validation certificate (See Section 5.7.) Ada compilers that receive a RVSR will be listed separately from those Ada compilers with a Validation Certificate in the NIST Validated Products List. Ada compilers which earn a RVSR receive a Provisional Validation Status (PVS).

Registration of a Derived Ada Implementation

An Ada implementation that has been derived from an implementation that has been validated by testing (a base implementation) may be given validated status by registration, if certain conditions are true (see Section 6). These conditions form the test for determining whether to register a derived implementation or to proceed with validation by testing. A registration request must be submitted to the NIST in the form provided in Appendix D. If the NIST accepts a registration request, the information may be included in the list of validated Ada implementations.

Appendices

Appendix A contains three versions of the Declaration of Conformance statement. Version Al is for Ada 83 compilers that are not being incrementally changed to incorporate Ada 95 features. A2 is for Ada 83 compilers that are being incrementally changed but are being validated with ACVC 1.11. A3 is for Ada 95 compilers being validated with an ACVC version based upon Ada 95.

Appendix B gives the format for submitting a test dispute.

Appendix C describes the dispute resolution process.

Appendix D gives the format for a request to register a derived Ada implementation.

Appendix E gives names and addresses for points of contact who participate in the Ada compiler certification body or who provide information about validated products.

Appendix F is a list of references used in this document.

Appendix G is a sample Certificate of Validation.

1. Introduction

The United States Department of Defense (DoD) sponsored the development of the Ada programming language and established the Ada Joint Program Office (AJPO) as part of an effort to support recognized principles of software engineering for a wide range of applications. In view of the well known benefits of standardization, the AJPO established a certification system to prevent the proliferation of dialects of the Ada programming language and to encourage Ada implementations which conform to [Ada 83] or to [Ada 95].

Effective October 1, 1996, the NIST operates the Ada certification system.

The Ada certification system rules of procedure and management in this document address the validation of Ada implementations by testing and by registration. These rules form an operational description of a validated Ada compiler. This version 4.2 addresses the validation process during the transition from [Ada 83] to [Ada 95]. Where the validation procedures for transition differ from past procedures, these differences are explained in appropriate sections. These procedures (version 4.2) will be updated before the end of the transition period, March 31, 1997.

The principals of the certification body of the Ada certification system consist of the NIST for overall direction, the Test Method Control Committee (TMCC) for guidance to NIST from industry on Ada conformance testing issues, and the Ada Validation Facilities (AVFs) for performing validations. The NIST is responsible for establishing and maintaining a certification system for the Federal Information Programming Standards (FIPS), FIPS 119 (for Ada 83), and FIPS 119-1 (for Ada 95).

It is important to note the scope and intent of validation. Users of an Ada implementation are cautioned that the purpose of validation is to encourage conformity of Ada implementations with the standard and that characteristics other than those specified by the standard, such as performance or suitability for a particular application, are outside the scope of Ada validation. Moreover, users are cautioned that the yardstick of conformity testing is the collection of test programs contained in the ACVC. Thus, conformity is measured only within the limitations of these tests.

A glossary of terms used in this document is provided in Section 2. Terms defined in the glossary are signified in the body of the document by bold print. Appendices to this document provide examples of documents used in validation, a description of the test dispute and resolution process, current points of contacts, and references.

2. Glossary of Terms

3. Organizations and Responsibilities

This section specifies the roles of organizations that form the certification body and of customers who receive service from them.

3.1 National Institute of Standards (NIST)

The NIST provides direction for the certification system by:

a. setting validation standards to be followed by all AVFs;

b. establishing the conditions for issuance, the life, and the scope of a validation certificate;

c. establishing the schedule for issuing versions of the ACVC;

d. approving the release of an ACVC version;

e. establishing members of the TMCC;

f. resolving issues that may arise during validation when these issues cannot be resolved through the best efforts of the AVF;

g. maintaining the official list of validated Ada implementations;

h. advising the AVFs concerning requirements for modification to the validation procedures;

i. reviewing all validation summary reports (VSRs) prepared by AVFs;

j. the issuance of validation certificates for Ada implementations validated by testing (see Section 5) and the registration of derived implementations (see Section 6);

k. overseeing the ACVC quality control and configuration management process;

l. deciding on the withdrawal of test programs from the ACVC version that is being used for validation; and

m. convening meetings of the members of the TMCC at appropriate intervals to discuss the process and to evaluate practices.

3.2 Ada Validation Facilities (AVFs)

An AVF is chartered by the NIST to conduct validation by:

a. adhering to validation procedures approved by the NIST;

b. producing the VSR;

c. forwarding unresolved test issues to the NIST for review and analysis, with final resolution to be provided by the NIST, if necessary;

d. providing advice on a customer's registration request for a derived Ada implementation; and

e. striving to satisfy national accreditation criteria.

The NIST may issue an AVF charter to an organization that has been recognized as an accredited testing laboratory by the U.S. Department of Commerce, National Institute of Standards and Technology (NIST). The NIST may issue a charter to an organization located in a country that has a Memorandum of Understanding (MoU) with the U.S. government covering the chartering of AVFs, according to the rules specified in the MoU. An AVF charter shall remain in effect for the duration specified in the charter; however, a charter can be revoked by the NIST, at any time, for due cause. The NIST may direct an impartial body to conduct an audit at any time or prior to issuing an AVF charter. Audits are conducted in accordance with procedures established by the NIST at the time of the audit and are tailored to reflect the purpose of the audit.

3.3 ACVC Reviewers

The ACVC reviewers, previously chartered by the AJPO, was the group which to addressed the quality and configuration management issues of the ACVC test programs by:

a. assisting in refining overall testing philosophy and priorities for test coverage;

b. providing expert technical review of the test objectives and test programs during their development;

c. ensuring that advances in the interpretation of the Ada programming language are reflected appropriately in the test objectives and test programs;

d. providing liaison between the certification system and the ISO Working Group for the Ada Standard (i.e. ISO-IEC/JTC1/SC22/WG9);

e. reviewing and acting upon comments received from compiler vendors and other interested parties; and,

f. establishing the configuration baseline for a proposed change to an ACVC version.

The functions provided by this group will be provided by the NIST TMCC.

3.4 Fast-Reaction Team (FRT)

The fast-reaction team, previously sponsored by the AJPO, is a small group of Ada language experts who in the past have provided advice on complex test issues by:

a. assisting the AJPO to issue a decision to the customer and AVF in a timely manner; and

b. contributing to ISO Working Group 9 language issue resolution.

The functions provided by this group are assigned to the NIST TMCC.

3.5 Customers

Customers are serviced by the Ada certification body in matters concerning Ada validation. In requesting services of the Ada certification body, customers are to provide accurate and complete information to perform validation, to register derived implementations, or to obtain other services.

3.6 NIST TMCC

The NIST TMCC serves as an advisory body to the NIST and has two basic activities:

a. the TMCC policy activity which advises the NIST on matters relating to Ada validation policies and procedures;

b. the TMCC technical activity which advises the NIST on matters relating to the test suite maintenance and enhancement, and in the resolution of technical issues arising from validation testing.

The NIST wants active members for its TMCC who will regularly participate in discussions related to Ada issues. The NIST is responsible for establishing and maintaining the membership of the TMCC. All matters to be resolved by the TMCC shall be determined by consensus with the understanding that the TMCC serves in an advisory capacity to the NIST. It is expected that most TMCC matters will be resolved by correspondence (e.g. electronic mail) rather than by meetings requiring the physical presence of the TMCC members in one location.

4. The Ada Compiler Validation Capability

The ACVC is designed to demonstrate the conformity of an Ada implementation with the standard. The ACVC is distributed as a collection of test programs, support programs which facilitate processing the tests, and an ACVC User's Guide that explains the criteria for evaluating the results. During the transition to [Ada 95], the last test suite for [Ada 83], ACVC 1.11, and the second version of the test suite for [Ada 95], ACVC 2.0.1, will be in use until March 31, 1997. Compiler vendors may choose to obtain an [Ada 83] validation certificate or an [Ada 95] validation certificate until March 31, 1997 when the third version of the [Ada 95] ACVC (version 2.1) becomes the only test suite for use in Ada validation.

4.1 Versions

A new ACVC version is released periodically according to a schedule which is determined by the NIST. Each new version incorporates changes to the ACVC as determined necessary by the NIST. These changes are made in order to reflect a revision of the standard, to incorporate ISO WG9 interpretations, or to address implementer or user comments. The test objectives and test programs for each new ACVC version are available for public review and comment before that version is issued for use in validation.

Ada validation related questions or comments on test objectives, or test programs should be submitted by e-mail to

ada-comment@speckle.ncsl.nist.gov
or by mail:
Dr. William H. Dashiell
NIST
Building 820NN, Room 517,
Gaithersburg, Maryland 20899 USA
Email: dashiell@speckle.ncsl.nist.gov
Fax: 301/948-6213

4.2 Applicability of ACVC Test Programs

Each ACVC test program has one or more test objectives which are described in a comment in the test program. Some test objectives might address language features that are not required to be supported by every Ada implementation (e.g., "check floating-point operations for digits 18"). These test programs generally contain an explicit indication of their applicability and the expected behavior of Ada implementations for which they do not apply. The determination of applicability is made according to the grading criteria in the ACVC or as a ruling by the NIST. All applicable test programs must be processed and passed according to the specified grading criteria.

During the transition period, there are three exceptions to previous criteria for passing an ACVC version. These exceptions are:

a. For an [Ada 83] validation, a failure of an ACVC version 1.11 test program may be judged inapplicable when the failure is caused by a correct but partial implementation of [Ada 95].

b. For an [Ada 95] validation with ACVC version 2.0.1 all applicable Ada 9X Basic tests and either all tests labeled as "OOP" or all tests labeled "real-time" must be passed. (The ACVC 9X Basic tests, "OOP" tests, and "real-time" tests are identified in the ACVC version 2.0.1 User's Guide.)

For [Ada 95] validations, ACVC test programs for special needs annexes will not be processed unless the AVF customer requests that they be processed. The result of these tests will not affect the issuance of a certificate for the core language but shall be made available as part of the public record of the Ada validation effort.

4.3 Test Modifications

The certification body strives to apply the ACVC as uniformly as practical to all Ada implementations. In order to apply common test objectives that depend on implementation dependent characteristics (e.g., line lengths and numeric types), many test programs must be adjusted to a given implementation following the procedures given in the ACVC User's Guide. These adjustments consist of the insertion of implementation dependent values in certain test programs at places prescribed by the ACVC User's Guide.

In addition to the anticipated test modifications, other changes may be required in order to remove conflicts between a test program and implementation-dependent characteristics (e.g., the algorithm for recovering from syntax errors). The allowable changes for each Ada implementation are determined by an AVF after consultation with the NIST, except in the case of error-recovery problems which an AVF may address without consultation.

4.4 Test Withdrawal

In any ACVC version, it is possible that a test program is based on assumptions that need not hold true for all Ada implementations or that a test program does not meet its objective. In these cases, the NIST may issue a correction to the evaluation criteria in the ACVC User's Guide or the test program may be withdrawn from that version of the test suite. Any interested party may challenge a test program by sending a rationale for the challenge to NIST. When an AVF customer is preparing for validation, the customer must challenge a test program only through an AVF by asking for a review of its evaluation criteria or for its withdrawal. The form for submitting a challenge is provided in Appendix B.

4.5 Customization

A customized test suite is produced by the AVF for each Ada implementation that is a candidate for validation. This customization always consists of removing withdrawn tests and in making required modifications to test and support programs; and, it may include removal of some inapplicable tests as allowed by the ACVC User's Guide.

4.6 Availability

The ACVC is available to the general public from an AVF or from the NIST on the Internet:

For those with a modem and NO World Wide Web browser:

Type: ftp speckle.ncsl.nist.gov (Internet address is 129.6.59.74)
Login as user: ftp
Password: (type your email address)
Type: cd ada-testing/test-suites/ACVC201
Type: binary
Type: get

[Note: The Ada test suite files are in UNIX tar format and are compressed (.Z) and therefore require the UNIX utility, compress, to uncompress them. When possible, the files will be available in DOS compressed format. Always read the README file.]

5. Validation by Testing

There are six steps that must be completed by a customer and the certification body so that the customer obtains a validation certificate with a VSR or a Registered Validation Summary Report. The same ACVC version must be used to complete the steps described in this section. The NIST announces the in-use and end-use period for each ACVC version. The AVF must begin on-site, witness, validation testing of the Ada implementation at the customer's site before the current ACVC version expires or else validation with that ACVC version will not be allowed. Anyone intending to obtain a validation certificate should contact an AVF without delay for advice on the handling of the ACVC, on interpretation of the test grading criteria, and on the operational details of that AVF's management practices.

5.1 Step One: Validation Agreement

In order to obtain services from the certification body, an interested party must become a customer of an AVF by reaching a formal agreement. This agreement should address the following topics:

a. identification of the Ada implementation to be tested and the ACVC version to be used;

b. a statement of work, including analysis of prevalidation testing, validation, and preparation of the VSR;

c. the format of data to be exchanged;

d. a schedule of events and the site of validation;

e. financial arrangements;

f. retention of records;

g. AVF liability; and

h. confidentiality of validation information.

The schedule for events, deliverables, and payments should take into account the fact that certain steps in the validation process require interaction with other members of the certification body (e.g., NIST). The AVF will put forth its best effort to keep confidential a customer's intent to obtain a validation certificate and the projected schedule for validation. This confidentiality will not be allowed to interfere with the normal review procedures of validation. If the customer requests confidentiality for reasons of national security or procurement sensitivity, the customer will provide to the AVF an official, written statement describing the request and the reason(s) for the request. The AVF will obtain further guidance from the NIST.

5.2 Step Two: Prevalidation

The requirements of this step are discussed separately so that the customer understands the interaction that is required with an AVF.

5.2.1 Customer Testing

After entering into a formal agreement, the customer prepares a customized test suite. The customer then processes all the tests in this customized test suite using the candidate Ada implementation or another Ada implementation that produces the same result. If the implementation provides for options in the way programs are processed, then the same set of options must be chosen for all test programs, with the possible exception of an option controlling the production of information output. Any other exception constitutes a test issue that must be resolved with the AVF (see Section 5.2.5). Test issues should be sent to the AVF for analysis as soon as they are known. The customer must provide (unless explicitly waived by the AVF) the prevalidation materials in a timely manner or by the agreement requirements between the customer and the AVF. Prevalidation materials include as a minimum the processing of an appropriately customized test suite by the customer, a customer supplied Declaration of Conformance, and any disputed ACVC tests.

5.2.2 Submission of Results

Upon completion of testing, the customer delivers the complete set of results in the agreed format to the AVF. These results are accompanied by the following information:

a. a list of test programs that the customer claims are inapplicable, together with a rationale for inapplicability;

b. a list of test programs that are disputed (see Section 4.4) together with rationale (see Appendix B for format);

c. the necessary information for the AVF to prepare the customized test suite;

d. an annotated sample command script;

e. the complete set of option settings used for processing the customized test suite, including the default settings; and

f. complete and current documentation for implementation-dependent characteristics as required in Appendix F of [Ada 83] or Annex M of [Ada 95].

5.2.3 Test Modifications

In order to comply with the test objective it maybe required to modify the test source code, the test processing method, or the test evaluation method. Modifications are allowable because at the time of test writing not all possible execution environments of the test and the capabilities of the compiler could be foreseen. Only NIST shall make the decision to use any of the following Test Modification. Possible kinds of modification are:

  • Test Modification: The source code of the test is change. Examples for test modifications are the insertion of a pragma, the insertion of a representation clause, or the splitting of a B-test into several individual tests, if the compiler does not detect all intended errors in the original test.

  • Processing Modification: The processing of the test by the Ada implementation for validation is changed. Examples for processing modification is the change of the compilation order for a test that consists of multiple compilations or the additional compilation of a specific support unit in the library.

  • Evaluation Modification: The evaluation of a test result is changed. An example for evaluation modification is the grading of a test other than the output from REPORT.RESULT indicates. This may be required if the test makes assumptions about implementation features that are not supported by the implementation (e.g. the implementation of a file system on a bare target machine).

5.2.4 Test Issues

A test issue may be any of the following:

a. a missing or incomplete result to a test;

b. a result presented in an inadequate form;

c. a disagreement between the customer and the AVF as to the interpretation of a result;

d. a change in the choice of options to be used during testing;

e. a result that makes the Ada implementation fail the ACVC according to the current grading criteria; or

f. an implementation-dependent characteristic that may affect the conformity of the Ada implementation.

The material submitted by the customer is analyzed by the AVF and test issues are resolved. If the AVF and the customer cannot agree on a way to resolve a test issue, the issue will be referred to the NIST for a resolution (see Section 5.2.5). It may be justified to leave a test issue unresolved at prevalidation. For example, it may be impossible to check the processing of control characters by inspecting printed results. The AVF will note these unresolved issues and describe the results that will be expected during validation testing. It is also possible that the customer information provided for production of the customized test suite (see Section 5.2.1) was insufficient so that corrections to the customized test suite must be made and additional processing will be required.

5.2.5 Test Issue Resolution

A customer may challenge the applicability or correctness of any particular ACVC test program. Such challenges should be presented to the AVF in the test-dispute format (see Appendix B). The AVF will forward challenges to the NIST for resolution; the NIST will strive to rule on the challenge within two weeks of receiving it. The NIST will forward all challenges and rulings to the NIST TMCC. (See Appendix C for a description of the Test Dispute and Resolution Process.)

5.2.6 Grading Rules for Representation Clause Tests

The NIST grading rules for representation clause tests (Annexes C and D) for ACVC Version 2.0.1 are:

a. For Annex C or D validations, ALL tests in the sub-directory of the category of recommended level of support required must be PASSED or judged inapplicable through the dispute process according to the existing validation procedures.

b. For core validation, the representation clause tests that are rejected by the implementation prior to execution are graded as "Unsupported". The results are reported in the Validation Summary Report or the Registered Validation Summary Report or the Validation Certificate for information only.

c. For core validation, the representation clause tests that fail in execution are graded as “Failed” (unless judged inapplicable by the test dispute process). Such a test failure is graded as a failure for the core validation.

5.2.7 Incomplete Prevalidations

The AVF and the customer may agree that, at the customer's risk, parts of the customized test suite need not be processed. The customer must certify that the results from a previous prevalidation submitted to the AVF or validation results obtained by the AVF are identical to those that would have been obtained by the customer. The normal practice is to submit complete prevalidation results.

5.2.8 Successful Prevalidation

Prevalidation testing is successful if the analysis of results and the resolution of test issues show that the candidate Ada implementation passes the customized test suite. Prevalidation is successful with caveats if the results are satisfactory except that they were incomplete or if resolution of some test issues is deferred until validation testing by agreement between the AVF and the customer.

5.3 Step Three: Validation Testing

Upon successful completion of prevalidation, with or without caveats, the AVF witnesses testing of the Ada implementation at the site and time mutually agreed by the AVF and customer. The AVF prepares a customized test suite based upon customer information and any information collected during the resolution of test issues. The customized test suite is installed and processed in the physical presence of an AVF representative. If the AVF determines that the results agree with those obtained from prevalidation and are satisfactory with respect to the caveats, the testing has been successful; otherwise, re-testing will be required, unless the validation attempt is discontinued (See Section 5.7 for Provisional Validation.)

5.4 Step Four: Declaration of Conformance

At the start of the on-site, witness testing of the customer's Ada implementation, the customer will provide to the AVF a completed, dated, and signed declaration of conformance. The customer should provide the information contained in the declaration of conformance to the AVF prior to the on-site testing as part of the prevalidation effort. The declaration of conformance states that the organization that is responsible for the production, maintenance or distribution of the Ada compiler is offering a product that is in conformity with the Ada programming language. The declaration of conformance becomes part of the AVF records and is copied into the VSR. Neither a validation certificate nor a Registered Validation Summary Report will be issued unless a signed declaration of conformance has been provided to the NIST (See Appendix A, for examples of the declaration of conformance that may be used through the transition period.)

5.5 Step Five: Validation Summary Report (VSR)

A VSR is produced for each validation testing effort. A single VSR may cover validation testing of several Ada implementations, provided that they all have the same result profile. The VSR provides the following documentation pertaining to the validation effort:

a. identification of the customer responsible for validation of the Ada implementation;

b. identification of the organization responsible for the production, maintenance, or distribution of the Ada compiler or Ada implementation;

c. identification of the Ada implementation tested;

d. identification of the options used for testing;

e. the inapplicable test programs and implementation-dependent characteristics exhibited by the test programs that established inapplicability;

f. the implementation-dependent characteristics pertinent to the customized test suite;

g. for [Ada 83] validations, description of implementation- dependent characteristics as detailed by Appendix F of [Ada 83]. implementation-dependent characteristics detailed by Annex M of [Ada 95] should be provided in vendor documentation for users but need not be provided in a VSR in the same format and detail called for in Annex M;

h. the test programs graded as unsupported under the transition policy of not requiring that certain [Ada 95] tests be passed;

i. withdrawn test programs;

j. modifications to test programs with an explanation for such modifications; and

k. a description of failed test programs, if applicable. (See Provisional Validation, Section 5.7.)

5.5.1 VSR Production

The VSR is prepared by the AVF but includes material that is produced by the customer, such as Appendix F required by [Ada 83], Annex M required by [Ada 95], or the documented compiler and linker options. A draft of the VSR is sent to the NIST for approval before and always after validation testing. The final version of the VSR is signed by the AVF and the NIST.

5.5.2 VSR Availability

The final version of the VSR is available to the general public from the customer and from the AVF that produced it. The AVF may require payment of a fee for VSR reproduction and mailing costs. The VSR is available on-line whenever possible (see APPENDIX E. POINTS OF CONTACT). There is no cost for VSRs obtained by electronic means.

5.6 Step Six: Validation Certificate

For each successful validation, one certificate is issued by the NIST. During the transition period, each [Ada 95] certificate will include a numerical summary of results for each category of tests. The information on the validation certificate describes the tested Ada implementation; the source of this information is the signed declaration of conformance that describes the tested Ada implementation that the AVF provides to the NIST after completion of testing. The customer will ensure that the information contained on the certificate does not infringe on the rights of third parties and may be required to provide a written statement of consent from any third party involved.

Validation certificates for ACVC 1.11, for ACVC 2.0 and for ACVC 2.0.1 will expire March 31, 1998. An entry in the list of Ada implementations validated by testing will be made for each certificate issued. This entry and all entries for registered validations derived from it will be removed when the certificate expires or is removed.

A sample Certificate of Validation is provided in Appendix G.

5.7 Provisional Validation

When prevalidation testing has been unsuccessful, a customer may petition the NIST to continue with validation by identifying up to ten ACVC test program failures to dispute. The NIST will present the dispute to the TMCC as a petition for validation with test failures. The test program(s) will be processed during validation testing and the compiler behavior will be documented in a Registered Validation Summary Report which shall contain documentation of a non-conforming Ada implementation. Provisional validation status (PVS) will be award for that Ada implementation for a period not to exceed 12 months after the date validation testing was completed. The customer will arrange with the AVF to witness the result of error correction in the base implementation. If the compiler then passes all of the ACVC tests in a successful validation testing (see 5.3), a VC will be issued and the VSR will be revised. The list of PVS Ada implementations will be maintained by the NIST as public information separately from those Ada implementations which have been issued a VC. VSRs for Ada implementations awarded PVS will be plainly marked as being registered with the NIST. These Registered VSRs will be reviewed by the NIST and will be publicly available from the AVF. The NIST may deny repeated petitions from the same customer for provisional validation of an Ada implementation.

5.8 Advertising Validated Status

The customer will not advertise or make public claims that the Ada implementation is validated until after receiving a validation certificate or after receiving formal notification from the AVF that the NIST has issued a validation certificate. A waiver of confidentiality must be signed by a customer who intends to advertise the completion of events that indicate progress toward completion of validation. If a waiver of confidentiality has been signed with the AVF, the AVF will respond to inquiries about the customer's advertisements or public claims by acknowledging receipt of validation materials (i.e., a formal agreement, pre-validation results, or validation testing results) without judgement concerning the success of the validation.

6. Registration of Derived Implementations

It is expected that nearly every Ada implementation that is validated by testing is intended to be representative of a class of implementations that are similar in their defining components of Ada compiler, host machine, and target machine. Such implementations are known as derived implementations. Whereas a validation certificate identifies only the Ada implementation that was tested by the AVF (i.e., the base implementation), the validated status that it conveys is extensible to a range of derived implementations for the life of the certificate. The procedure for extending validated status to a derived implementation is called registration. This section prescribes the requirements for registration.

For any base implementation with a current validation certificate, a derived implementation may obtain validated status by registration when it satisfies all of the following conditions:

a. The Ada compiler was obtained from the Ada compiler of the base implementation by changes that are within the scope of accepted software maintenance practices.

b. The target machine of the base and derived implementation have compatible instruction sets and operating system or kernel.

c. The result profile for the derived implementation is either the same as the base implementation or, if there are differences, these differences are justified as being within the scope of accepted software maintenance practices.

The changes that may be made to an Ada compiler for the purpose of derivation will be within the scope of software maintenance as applied to the domain of compiler construction. Changes must be classified as corrective, adaptive, or perfective. Examples of these changes are the correction of a compiler error, the adaption to an operating system upgrade, the transfer of the compiler to another host machine, the addition of a floating point processor to a small target machine, or the perfection of a garbage collection algorithm.

For the purposes of obtaining validated status by registration, the changes required to render the base Ada compiler fully functional on a different host machine or host operating system are considered adaptive maintenance. However, a change in a target machine may be outside the scope of acceptable maintenance.

For a target machine, common examples of compatible instruction sets and operating systems are two different computer system models in a manufacturer's product line or the computer systems produced by different manufacturers that use the same instruction set and operating systems, or any computer system and a simulated or emulated computer system that are the same instruction set.

6.1 Registration Request

Any interested party may initiate the registration of a derived implementation by sending a registration request to the NIST or to an AVF. A registration request consists of two parts -- a "letter" part and a "supporting information" part. Appendix D specifies both the form and content of the information to be provided in these two parts.

A registration request must contain descriptions of the base and derived implementations, a declaration of conformity to the relevant version of the Ada programming language, compliance with the relevant version of the ACVC, a description of what maintenance and testing was performed, and any appropriate supporting documentation from hardware or software vendors. If any party in addition to the one submitting the request has a legal interest in the derived implementation, this interest will also be documented in the request.

Two Ada implementations have the same result profile when:

a. they use the same customized test suite; and,

b. their output from processing the customized test suite is the same (with the possible exception of the precise content and position of error messages from the compiler).

If the derived implementation has a different result profile than the base implementation, the registration request must describe and justify the differences.

6.2 Evaluation

The AVF will not perform testing on derived implementations. Any AVF may review the registration request for completeness and the plausibility of information and provide advice. The NIST will evaluate all registration requests before adding the derived implementations to the list of validated Ada implementations maintained by the NIST.

6.3 Registration

Registration requests that are acceptable to the NIST will be registered as validated Ada implementations untested by an AVF. A validation certificate will not be issued for these derived implementations. The list of derived implementations and information provided in the registration request will be available to the public.

6.4 Expiration of Validated Status

A derived implementation loses its status of being validated if it is challenged successfully (see Section 6.7), upon expiration of the validation certificate of its base implementation, when registration is revoked by the customer, or when the derived implementation is no longer supported by the supplier.

6.5 Challenges

Any derived implementation may be challenged by any interested party through an AVF. The challenger will pay a challenge fee to the AVF and will submit a challenge request that:

a. identifies the derived implementation being challenged;

b. names one ACVC test from the customized test suite together with its implementation dependent parameters, if any; and

c. describes in what way the implementation will fail this test.

The AVF will send this challenge to the originator of the registration asking for comment. The challenge will be considered settled if the registration is revoked by the registration originator; otherwise, the challenge will be settled as outlined in Section 6.7.

6.6 Challenge Mark

The AVF will inform the NIST that a challenge for a given derived implementation has been received. The derived implementation will then be marked as "challenged" on the list of derived implementations maintained by the NIST. Information pertaining to the challenge may be requested by any interested party and received from the AVF. It should be noted that a challenge mark applies only to the derived implementation that was named and does not indicate any judgement about the conformity of the challenged implementation.

6.7 Challenge Test

The AVF will conclude a formal agreement with the challenger that covers the AVF's cost for performing a challenge test. For challenge testing, the challenged derived implementation will be tested against the named ACVC test. The challenger will provide access to the challenged derived implementation and appropriate expertise to facilitate the AVF test. The NIST will be informed of the test result. Depending on its result, the NIST will settle the challenge by either removing the challenge mark or the derived implementation from the list of validated Ada compilers.

Appendix A. Declaration of Conformance

Al - Ada 83
Declaration of Conformance

Customer:
Certificate Awardee:
Ada Validation Facility:
ACVC Version:
Ada Implementation:
Ada Compiler Name and Version:
Host Computer System:
Target Computer System:

Declaration:

I, the undersigned, declare that I have no knowledge of deliberate deviations from the Ada Language Standard (ANSI/MIL-STD-1815A, ISO 8652:1987, FIPS 119) as tested in this validation and documented in the Validation Summary Report. 

______________________________  __________
Customer Signature / Date
Company
Title

______________________________  __________
Certificate Awardee Signature / Date
Company
Title

A2 - Ada 83 Transitioning
Declaration of Conformance

Customer:
Certificate Awardee:
Ada Validation Facility:
ACVC Version:
Ada Implementation:
Ada Compiler Name and Version:
Host Computer System:
Target Computer System:

Declaration:

I, the undersigned, declare that I have no knowledge of deliberate deviations from the Ada Language Standard (ANSI/MIL-STD-1815A, ISO 8652:1987, FIPS 119) other than modifications necessary to incorporate some features of (ANSI/ISO/IEC 8652:1995) untested by this validation. Any non-conforming characteristics are due to implementation errors. 

______________________________  __________
Customer Signature / Date
Company
Title

______________________________  __________
Certificate Awardee Signature / Date
Company
Title

A3 - Ada 95
Declaration of Conformance

Customer:
Certificate Awardee:
Ada Validation Facility:
ACVC Version:
Ada Implementation:
Ada Compiler Name and Version:
Host Computer System:
Target Computer System:

Declaration:

I, the undersigned, declare that I have no knowledge of deliberate deviations from the Ada Language Standard (ANSI/ISO/IEC 8652:1995, FIPS 119-I) other than the omission of features as documented in the Validation Summary Report. 

______________________________  __________
Customer Signature / Date
Company
Title

______________________________  __________
Certificate Awardee Signature / Date
Company
Title

Appendix B. Implementer Dispute Format

Part A

Implementer:
Configuration: (host & target hardware & operating systems)
ACVC Version:
Pre-Validation Submittal Date: (due date for in-house results)

(Part A will be completed once by each implementer; part B will be completed for each dispute. It is not necessary for a pre-validation date to have been established. Part A information is treated as confidential.)

Part B

Reference: [test name (,test name)]
Summary: (brief description of the dispute)
Discussion: (detailed description of the dispute)

[In this Discussion, arguments should be specified using test line #s and references to pertinent sections of the Ada standard or Commentaries (Al-xxxx). The implementer must describe the behavior of the implementation for the test or tests that are disputed, stating the particular test messages that are produced. It is sufficient for the detailed description to be limited to the particular segment of test code that is disputed. Relevant source code with compiler messages should be included. (For a group of tests that cause much the same behavior, it is sufficient for a detailed description to be given for one of them, with the relevant line numbers given for the like problems in the related tests.)]

If the argument depends upon implementation constraints of hardware or software (e.g., characteristics of the operating system), then these should be specified; the particular computer and operating system should be identified. It is especially important that implementations that fail to pass some test due to capacity limitations be described in enough detail for the NIST to assess the reasonableness of these limitations.

Failure to fully specify the points pertinent to a dispute might result in an adverse decision being made, with the disputer having to further argue the case with a second submittal to the NIST. Yet it is possible that the Summary will suffice to adequately present a dispute.

Appendix C. Test Dispute and Resolution Process

C.1 Introduction

A "dispute" is defined by the ACVC User's Guide as any result from processing an ACVC test program that is not a passed, inapplicable, unsupported result according to the established grading criteria. This intentionally broad definition of a "dispute" is to make certain that compiler implementers bring all deviant test results to the attention of the AVF, without assuming that such results would be accepted without special review. The compiler implementer also provides a rationale for each challenge being made to a particular test program. Disputes are forwarded to the NIST, usually electronically, by the AVF on behalf of their validation customer. For each dispute that is accepted (i.e., when the NIST rules in favor of the dispute), it is likely that some correction is indicated for the disputed tests. The NIST withdraws any test that is found to be incorrect to a degree that makes it unsuitable for validation. The withdrawal of a test consists of including it on a list of tests that are ignored for validations conducted with the current ACVC version. The NIST updates the list of withdrawn tests, and distributes this list to the AVFs and to the NIST TMCC. The NIST also maintains a database consisting of all test disputes and their resolution (NIST rulings) which is periodically provided to the NIST TMCC and other interested parties. The NIST may also recommend that certain resolved disputes be considered further by the ARG/URG.

C.2 Expedited Resolution Process

The NIST resolves disputes by any of three methods: a resolution that was made previously is applied to the current dispute (e.g., the same dispute might be submitted at different times by different petitioners); the resolution can be determined unequivocally based on the Ada standard or Ada Commentaries; or, the resolution is determined based on the deliberations of the NIST TMCC. Although the Ada Compiler Validation Procedures do not set a limit on the length of time for reaching a resolution, the NIST attempts to resolve disputes within two weeks, an informal guideline that was established by the certification body. If a dispute is submitted to the NIST more than two weeks before the scheduled beginning of on-site testing, and the NIST is unable to issue a final resolution of the dispute within the two week period, then the dispute is presumed to have been resolved in the implementer's favor. The disputed tests will be graded as inapplicable and the default resolution will be documented in the VSR. Such a default resolution will not be used as a basis for future disputes of the same test. The NIST also attempts to place priority on resolving disputes for AVF customers who have a firmly scheduled date for validation testing. Implementers should submit disputes well in advance of a scheduled validation testing date. (see Section 5)

On receipt of a dispute, the NIST checks whether the issue matches any that had been previously resolved. If the dispute is new, it is given an initial NIST analysis which involves research using the Ada commentaries in conjunction with the Ada standard and references to previous dispute deliberations. A dispute is referred to the NIST TMCC when questions of interpretation arise and a resolution is not obvious. The NIST presents the dispute and any additional information resulting from an initial analysis to the NIST TMCC by e-mail without disclosing the identity of the petitioner. Deliberation of the dispute proceeds with the exchange of each expert's opinion and analysis. The NIST participates in the deliberation by providing information as requested (e.g., ACVC tests or information from the petitioner), eliciting discussion from the experts, and making or challenging technical points raised in the discussion. In general, where an issue receives support from some members of the NIST TMCC, the dispute is accepted.

There is no prescribed formality to the NIST TMCC deliberations, such as voting procedures or time limits on deliberation. The NIST might extend deliberation when a basis for resolving the dispute has not been made. However, the NIST will give its ruling on the dispute when a sufficient basis has been established, regardless of whether the NIST TMCC discussion continues.

C.3 Types of Resolutions

The resolution of a dispute is either an acceptance or rejection of the petitioner's arguments. Acceptance can result in either withdrawal of the test program from the ACVC or in a "Test, Processing, or Evaluation" modification for validation. A dispute may be rejected if it conflicts with the Ada standard or Ada Commentaries or if it is a test to which previously validated implementations conform and the petitioner has not provided compelling reasons for a deviation. A dispute may lead to the withdrawal of a test program if the test is shown to be incorrect to a degree that wrongly influences implementation. Withdrawn tests have no effect on validation (they are generally not processed). If the dispute shows the affected test program(s) to be incorrect in only a minor, limited degree, generally the NIST will direct that the test(s) be processed with a test modification.

There are three types of test modification: Test, Processing, and Evaluation modifications. A Test Modification is an actual change to the code of the test (e.g., adding a choice to an exception handler). A Processing Modification is a change to the way in which the test is processed (e.g., re-ordering the compilation of component files of a multi-compilation test). And an Evaluation Modification is simply the grading of the observed results by other than the established grading criteria (e.g., interpreting particular intermediate output and a final "failed" result as "passed", according to an understanding of the dispute). All test modifications are documented in the VSR.

C.4 Summary

There is no limit on the number of disputed tests that can be submitted by an implementer. Although there is a risk that a dispute will not be decided in the implementer's favor, that risk can be managed so as to not affect validation by early submission of disputes. The validity of grading criteria for ACVC tests was very important for Ada 83, and will take on even greater importance for Ada 95 usage based tests. Any interested party may dispute an ACVC test and its grading criteria.

Appendix D. Registration Request

A registration request must have two main parts: (1) a letter and (2) an enclosure consisting of specific information to support the request.

Part I - Letter

The request letter should be addressed to the NIST (note: see Appendix E for address) even though the requester does seek advice from an AVF. The mandatory parts of the letter are:

a. Certificate number and description of the Base Implementation,

b. List of derived implementations that were fully tested with the customized ACVC used in the base validation. If this list is less than the list for which registration is requested item d must also be included in this letter.

c. Select the appropriate statement to declare conformity:

1. Ada 83 compiler: I, the undersigned, declare that I have no knowledge of deliberate deviations from the Ada Language Standard [ANSI/MIL_STD-1815A/ISO 8652: 1987/FIPS 119] in the implementation.

2. Ada 83 migrating compiler: I, the undersigned, declare that I have no knowledge of deliberate deviations from the Ada Language Standard [ANSI/MIL-STD-1815A/ISO 8652:1987/FIPS 119] other than modifications necessary to incorporate some features of ANSI/ISO/IEC 8652:1995 untested by a validation. Any non-conforming characteristics are due to implementation errors.

3. ISO 95 compiler: I, the undersigned, declare that I have no knowledge of deliberate deviations from the Ada Language Standard [ANSI/ISO/IEC 8652:1995, FIPS 119-1] other than the omission of features documented in the Validation Summary Report for the base implementation.

d. For the derived implementations that were not fully tested, we declare that, to the best of our knowledge, these implementations will pass the customized ACVC used in the base validation. Any possibly observed deviations are the consequence of implementation errors.

e. If this statement applies, legal interests of (name) are affected by this registration request and their consent is documented in enclosure (number) to this letter.

f. The Ada implementations for which registration is requested may, in fact, be derived according to the rules given in the Ada Validation Procedures.

g. Signature

h. Corporate title

Part 2 - Template for Supporting Information Identification of Base Ada Implementation: 1. Certificate number:
2. Registration requested for:

Note: This registration request pertains to all Ada implementations obtained by taking the Ada compiler and selecting any host and any target from the list below.

Compiler: name and version(s), release number/product(s), range of versions/releases

Host: choose either (a) or (b) --

a. make, specific members of series and/or model numbers (e.g. IBM PS2 model 80-110 & 113)
OR
b. all members of a model series (e.g. IBM PS2 all models, or HP 9000 series 300)

Operating System: name and version, release number(s)

Target: choose (a) or (b) or (c) --

a. make, specific members of series and/or model numbers
OR
b. all members of a model series
OR
c. members of an instruction set architecture and board implementation(s) (e.g. Motorola 68020-MVME133-1 & MVME130COF, Motorola 68030-VME147, Motorola 68030-MilSpec285)

Operating System: choose (a) or (b) or (c) --

a. OS name and version/release number for all target machines listed
OR
b. kernel identifier for all target machines listed
OR
c. none for all target machines listed

Evidence that the Ada implementations listed above should be validated by registration:

1. State the type of software maintenance changes made to the compiler and describe what was done:
  • Corrective - maintenance performed specifically to overcome an existing fault.
  • Perfective - maintenance performed to improve performance or maintainability.
  • Adaptive - maintenance performed to make a software product usable in a changed environment.

2. Which host/target combinations were fully tested with the ACVC? Testing with "customer applications" or other types of tests is not equivalent to running the ACVC. If a sub-set of ACVC tests were run, so state and indicate the sub-set.

3. State whether the result profile is the same or different from the base. If different, list all ACVC test results that are different or exhibit different behavior and explain the difference.

4. What is the authoritative source used to determine the technical compatibility between the derived implementations and the base?

If copies of technical manuals are supplied as the source of this information, give the enclosure number where this information can be found. Do not duplicate a previous submission of identical technical material, just reference its previous submission. If there has been a change in the previously submitted material, submit only the change. If there is no authoritative source of information given, this registration request may be refused.

Appendix E. Points of Contact

Ada Validation Facility Managers

Dr. William Dashiell
National Institute of Standards and Technology
Information Technology Laboratory (ITL)
Building 820NN, Room 517
Gaithersburg, MD 20899 USA
Phone: 301-975-2490
Fax: 301-948-6213
Email: dashiell@speckle.ncsl.nist.gov

Mr. Jon Leigh
The National Computing Centre, Ltd.
Oxford Road
Manchester
England, MI7ED
Phone: +44-61-228-6333
Email: jon@ncc.co.uk

Mr. Michael Tonndorf
IABG, Software-Technologie lTE
Einsteinstr. 20
D-85521 0ttobrunn
Germany
Phone: +49-89-6088-2477
Email: tonndorf@iabg.de

ACVC Team (Ada 95)

ACVC95 (Test Suite Development/Maintenance)

Mr. L. Arnold Johnson
National Institute of Standards and Technology
Information Technology Laboratory (ITL)
Building 820NN, Room 517
Gaithersburg, MD 20899 USA
Phone: 301-975-3247
Email: johnson@speckle.ncsl.nist.gov

Test Method Control Committee (TMCC)

Contact Dr. William H. Dashiell (see above) email comments and/or ACVC dispute issues to ada-comment@speckle.ncsl.nist.gov

Ada Rapporteur Group (ISOWG9)

Dr. Erhard Ploedereder
University of Stuttgart
Institute for Computer Science
Breitwiesenstr. 20-22
D-70565 Stuttgart
Germany
Phone: +49 +711 7816-322
Fax: +49 +711 7816-380
Email: ploedere@informatik.uni-stuttgart.de

Ada Information Clearinghouse (industry and government inquiries)

Ms. Susan Carlson
Standard mail:
AdaIC
PO Box 1866
Falls Church, VA 22041 USA
Phone: 703/681-2466
Fax: 703/681-2869
Email: adainfo@sw-eng.falls-church.va.us
WWW URL: http://sw-eng.falls-church.va.us/

Express mail:
c/o IIT Research Institute
4409 Forbes Boulevard
Lanham, MD 20706-4312 USA

Ada Validation Related Questions

Email: ada-comment@speckle.ncsl.nist.gov
OR
by post to Dr. William H. Dashiell (see above).

ACVC and VSR Distribution

Contact Dr. William H. Dashiell (see above)
OR
to obtain ACVC by ftp:
Type: ftp speckle.ncsl.nist.gov (Internet address is 129.6.59.74)
Login as user: ftp
Password: (type your email address)
Type: cd ada-testing/test-suites/ACVC201
Type: binary
Type: get file_name

[Note: The Ada test suite files are in UNIX tar format and are compressed (.Z) and therefore require the UNIX utility, compress, to uncompress them. When possible, the files will be available in DOS compressed format. Always read the README file.]

Validated Compiler Lists

Mr. L. Arnold Johnson
Standard mail:
National Institute of Standards and Technology
Information Technology Laboratory (ITL)
Building 820NN, Room 517
Gaithersburg, MD 20899 USA
Phone: 301/975-2490
Fax: 301/948-6213
Email: johnson@speckle.ncsl.nist.gov

Online:
WWW URL: ftp://speckle.ncsl.nist.gov/vpl/intro.htm

Appendix F. References

[Ada 95] ANSI/ISO/IEC 8652:1995 Reference Manual for the Ada Programming Language, February 1995 (supersedes Ada 83]
[Ada 83] American National Standards Institute and United States Department of Defense: ANSI/MIL-STD-1815A Reference Manual for The Ada Programming Language, 1983 Note: This standard is identical with ISO/8652:1987 and FIPS 119, 1985.
[ANSI/IEEE 90] American National Standards Institute / Institute of Electrical and Electronic Engineers, Inc., Standard 610.12-1990; "ANSI/IEEE Standard Glossary of Software Engineering Terminology".
[FIPS] Federal Information Processing Standards publications relative to the Ada Programming Language are FIPS 119 and FIPS 119-1
[ISO 74] International Standards Organization: ISO 2382/I-1974 Data Processing - Vocabulary - Section 01: Fundamental Terms.
[ISO/IEC 91] International Standards Organization: ISO/IEC, Guide 2, 6th edition 1991 - General Terms and Their Definitions Concerning Standardization and Related Activities.

Appendix G. Sample Certificate of Validation

(Not included in this ASCII text document.)

Home Webmaster Last Updated: 08/11/98