This form contains a series of questions that need to be answered. As you go about answering the questions, please keep the following things in mind:

• While it is not required that each question be answered at this time, all questions must have answers before the response is submitted to The Open Group for review and publication.
• Press the "Save" button at any time to save work in progress. Once the work has been saved, there is the option to continue editing if required.
• Many questions have instructions to assist in development of answers. They are marked with the indicator. Please look at the instructions carefully.
• Although HTML markup can be included in answers, this is not recommended apart from basic tags such as <p> and <br>, since incorrect markup could effect the format of other items in the document.
• Questions on this system should be addressed to the Conformance Statement manager at The Open Group.

Enter the name of the Organization that produced the implementation and the name of the author of the Conformance Statement.

1. CORBA

Product Information

Environment Specification

Product registration applies to software products operating in a specific hardware or hardware/software environment.

A product may be registered in all members of a binary-compatible family of products on the basis of a single test report.

Answer the questions for each binary-compatible family. Alternately, provide the answers in the Appendix at the end of this document.

	Testing Environment	Binary-compatible Family	Portability Environment	Indicator of Compliance	Compliance Details
			None.	Select from this list Test Report from Test Suite	Test Suite: Test Report:
			None.	Select from this list Test Report from Test Suite	Test Suite: Test Report:
			None.	Select from this list Test Report from Test Suite	Test Suite: Test Report:
			None.	Select from this list Test Report from Test Suite	Test Suite: Test Report:
			None.	Select from this list Test Report from Test Suite	Test Suite: Test Report:

Temporary Waivers

1.1 CORBA Core

1.1.1 OMG IDL Syntax and Semantics

Question 1: Does the product interpret or ignore pragmas for RepositoryID formats?

Response

Pragma	Product Behavior
ID Interpreted ?	Interpreted   Ignored
prefix Interpreted ?	Interpreted   Ignored
version Interpreted ?	Interpreted   Ignored

Rationale

These directives must be interpreted (yes) or ignored (no).

Reference

Common Object Request Broker Architecture and Specification, Section 7.6.4.

Question 2: Does the product require interface-specific pragmas to precede an Interface body?

Response

If no pragmas are required, enter "No" below. If pragmas are required, enter a description of the requirements.

Rationale

Implementations are allowed to require such pragmas.

Reference

Common Object Request Broker Architecture and Specification, Section 3.5.2.

Question 3: Does the product require interface-specific pragmas to precede an operation declaration?

Response

If no pragmas are required, enter "No" below. If pragmas are required, enter a description of the requirements.

Rationale

Implementations are allowed to require such pragmas.

Reference

Common Object Request Broker Architecture and Specification, Section 3.10.

1.1.2 Object Adapters

Question 4: Which object adapters does the product supply?

Response

Adapter	Supported
Basic Object Adapter (BOA)
Yes   No
Portable Object Adapter (POA)
Yes   No

Rationale

This information is of use to server developers.

Reference

Common Object Request Broker Architecture and Specification, Section 2.1.11. Object adapters are expected to be present in an implementation.

1.1.3 DII Routines

Question 5: Do DII routines return a status code?

Response

Enter No for CORBA:Status is defined as a void type, OR , Enter Yes for CORBA:Status is defined as an unsigned long type

Yes   No

Rationale

Conforming CORBA implementations are not required to return this status code. Conforming implementations are required to specify which Status behavior is supported.

Reference

Common Object Request Broker Architecture and Specification, Section 4.1.3.

1.1.4 Name Space Partitioning

Question 6: Does the product use the period character to partition the name space?

Response

Yes   No

Rationale

Implementations are allowed to use the period (.) for partitioning the name space.

Reference

Common Object Request Broker Architecture and Specification, Section 3.10.4.

1.1.5 Interface Repository

Question 7: Does this implementation support the Interface Repository?

Response

Yes   No

Rationale

The implementation is required to document this optional behavoir.

Reference

The Open Group CORBA Product Standard

1.2 Language Mappings

Question 8: Which language mappings does the product support?

Response

Mapping	Supported
C
Yes   No
C++
Yes   No
Java
Yes   No
Smalltalk
Yes   No
Cobol
Yes   No
Ada
Yes   No

Rationale

A product registered as conformant to the CORBA Product Standard must offer one or more conforming language mappings.

Reference

The Open Group CORBA Product Standard.

1.3 C++ Mapping

Question 9: Can the implementation take advantage of templates if they are supported by the target environment?

Response

Select one of the following alternatives

Not Applicable Yes No

Rationale

Use of templates is not required, nor is it disallowed.

Reference

Common Object Request Broker Architecture and Specification, Section 18.1.1.

Question 10: Can the implementation's IDL-to-C++ translator support 64-bit integer types?

Response

Select one of the following alternatives

Not Applicable Yes No

Rationale

An alternative mapping is defined for integer types in 64-bit environments.

Reference

Common Object Request Broker Architecture and Specification, Section B.1.

Question 11: For which target environment can the implementation's IDL-to-C++ translator provide a mapping for module?

Response

Select one of the following alternatives for each Environment

Environment	Mapping	Supported
namespace is supported	Module is mapped to C++ namespace	Not Applicable Yes No
namespace is not supported, nested classes are supported	Module is mapped to C++ classes	Not Applicable Yes No
namespace and nested classes are not supported	Module is mapped like C mapping	Not Applicable Yes No

Rationale

Several alternative mappings are defined.

Reference

Common Object Request Broker Architecture and Specification, Section B.2.

Question 12: For which exception handling environments can the implementation's IDL-to-C++ translator provide a mapping?

Response

Select one of the following alternatives for each Mapping

Mapping	Supported
Real C++ exception handling is supported	Not Applicable Yes No
Real C++ exception handling is not supported	Not Applicable Yes No

Rationale

Two alternative provisions are defined in the C++ mapping.

Reference

Common Object Request Broker Architecture and Specification, Section B.3.

1.4 Smalltalk Mapping

Question 13: How does the product map the IDL interface construct?

Response

Select one of the following alternatives

Not Applicable. Each interface is mapped to a separate Smalltalk class. All interfaces are mapped to a single Smalltalk class. Arbitrary Smalltalk classes are mapped to IDL interfaces.

Rationale

Conforming implementations are free to use any of these methods.

Reference

Common Object Request Broker Architecture and Specification, Section 19.6.

Question 14: For which IDL types other than union does the product provide an explicit mapping?

Response

Either provide a list of types, or enter "None" or "Not Applicable"

Rationale

Implementations may chose to provide both implicit and explicit mappings for types in addition to union, such as structs and sequences.

Reference

Common Object Request Broker Architecture and Specification, Section 19.6.

1.5 COBOL Mapping

Question 15: Which constant handling environments can the implementation's IDL-to-COBOL translator support?

Response

Select one of the following alternatives for each Environment

Environment	Supported
Constants are supported by the COBOL compiler	Not Applicable Yes No
Constants are not supported by the COBOL compiler (and are propagated by the IDL compiler)	Not Applicable Yes No

Rationale

Constants are not supported in pure ANSI 85 COBOL.

Reference

Common Object Request Broker Architecture and Specification, Section 20.7.

Question 16: Which COBOL environments can the implementation's IDL-to-COBOL translator support for mapping basic data types?

Response

Select one of the following alternatives for each Environment

Environment	Supported
Basic data types are mapped to COBOL Typedefs	Not Applicable Yes No
Basic data types are mapped to COBOL COPY files	Not Applicable Yes No

Rationale

Typedef is an optional extension to ANSI 85 COBOL and may not be supported by all COBOL compilers.

Reference

Common Object Request Broker Architecture and Specification, Section 20.8.

1.6 Ada Mapping

Question 17: What additional rules does the product provide for resolving name space clashes?

Response

Either provide a list of rules, or enter "None" or "Not Applicable" below.

Rationale

The defined mapping defines a set of rules, but they cannot guarantee name clashes will not occur. Implementations may implement additional rules to further resolve clashes.

Reference

Common Object Request Broker Architecture and Specification, Section 21.4.1.

Question 18: Does the implementation use strings associated with Exception_Message and Exception_Information in the package Ada.Exceptions to ``carry'' exception members?

Response

Select one of the following alternatives


Not Applicable Yes No

Rationale

The implementation is required to document this fact.

Reference

Common Object Request Broker Architecture and Specification, Section 21.5.8.

Question 19: Is access to CORBA services tasking-safe?

Response

Select one of the following alternatives


Not Applicable Yes No

Rationale

The implementation is required to document this.

Reference

Common Object Request Broker Architecture and Specification, Section 21.5.11.

Question 20: Does the implementation support tasking-safe operations?

Response

If the answer to the preceding question is "Yes", select "Task" or "Program" below. Otherwise, select "Not Applicable".


Not Applicable Task Program

Rationale

An implementation may support tasking-safe operations, and if it does, the blocking behavior of CORBA operations will be managed at the task or program level. The implementation is required to document support and, if support is present, how it is managed.

Reference

Common Object Request Broker Architecture and Specification, Section 21.5.11.

1.7 Interoperability

Question 21: Conformance with IIOP Version 1.0 is required. Support for IIOP Version 1.1 is optional. Does this implementation support the optional IIOP Version 1.1?

Response

Yes   No

Rationale

The implementation is required to document this optional behavior.

Reference

The Open Group CORBA Product Standard.