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. Software Administration

Product Information

Environment Specification

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.	None.
				None.	None.
				None.	None.
				None.	None.
				None.	None.

Temporary Waivers

1.1 General Compliance Category

Question 1: Is the implementation a "Conforming POSIX.7.2 Implementation" or a "Limited Conformance POSIX.7.2 Implementation"?

Response

Conforming POSIX.7.2 Implementation Limited Conformance POSIX.7.2 Implementation

Rationale

An implementation registered as conformant to this Product Standard definition must meet one or other of the set of implementation conformance requirements specified in IEEE Std. 1387.2:1995:

• Section 1.3.1.1: Conforming POSIX.7.2 Implementation
• Section 1.3.1.2: Limited Conformance POSIX.7.2 Implementation.

Reference

Software Administration Product Standard Definition.

IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration), Sections 1.3.1.1 and 1.3.1.2.

1.2 Non-standard Extensions

Question 2: If the implementation provides non-standard extensions, do those extensions conform to Clause 2.10.2 of the POSIX.2 standard?

Response

Yes   No

Rationale

An implementation that provides non-standard extensions should provide those extensions in conformance with Clause 2.10.2 (utility syntax guidelines) of the POSIX-2 standard. Use of the word "should" in IEEE Std. 1387.2:1995 indicates that this is a recommendation to implementors but is not a mandatory requirement.

Reference

IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration), Section 1.3.1.1.

ISO/IEC 9945-2:1993, Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities, Clause 2.10.2.

Question 3: If the implementation provides non-standard extensions, what general operating instructions are required to enable a "Strictly Conforming POSIX.7.2 Distribution" to be operated upon and yield the behaviour specified in IEEE Std. 1387.2:1995?

Response

If the implementation has no non-standard extensions, indicate that. Otherwise, enter a description of the steps needed to get the implementation into a mode where the behavior is as specified in the standard. Alternately, provide a reference that uniquely identifies the product documentation and the place within that documentaiton, where these operating instructions can be found. ("Uniquely identifies" means give the document title, and the appropriate combination of version number, date, reference number, etc. such that the document is uniquely identified and can be obtained by the reader of this conformance statement.)

Rationale

An implementation that provides non-standard extensions shall define an execution environment (that is, shall provide general operating instructions) in which a "Strictly Conforming POSIX.7.2 Distribution" may be operated upon and yield the behaviour specified in IEEE Std. 1387.2:1995.

Reference

IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration, Section 1.3.1.1.

1.3 Reliance on Other than POSIX.1 or POSIX.2 Functionality

Question 4: If the implementation meets all the criteria of a Conforming POSIX.7.2 Implementation (or of a Limited Conformance POSIX.7.2 Implementation) except with respect to those features of the standard that depend on the existence of conforming implementations of either POSIX-1 or POSIX-2, what are the details of any differences in functional behaviour?

Response

Enter your response in the text area, using as many lines as necessary, or state that "All features are fully supported as defined in this standard".

Alternatively, insert a reference that uniquely identifies the product documentation, and the place within that documentation, where the information can be found. ("uniquely identifies" means give the document title, and the appropriate combination of version number, date, reference no., etc. such that the document is uniquely identified and can be obtained by the reader of this conformance statement.)

Rationale

A conformant implementation shall be a "Conforming POSIX.7.2 Implementation" if all the criteria for such are met, with the exception of those features that depend on the existence of conforming implementations of either POSIX-1 or POSIX-2. In this case, the Conformance Statement for the "Conforming POSIX.7.2 Implementation" shall describe the behaviour of the implementation of all features of the implementation, or of a "Strictly Conforming POSIX.7.2 Distribution", that depend (in IEEE Std. 1328.2:1995) on the function of POSIX-1 or POSIX-2.

Reference

IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration, Sections 1.3.1.1, 1.3.1.3 (paragraphs 6 and 7), 2.3.1 and 2.3.2.

ISO/IEC 9945-2:1993, Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language] and Part 2: Shell and Utilities.

1.4 Media Types Supported

Question 5: What media types are supported for the transmission and receipt of software distributions?

Response

Enter your response in the text area, using as many lines as necessary, or state that "All features are fully supported as defined in this standard".

Alternatively, insert a reference that uniquely identifies the product documentation, and the place within that documentation, where the information can be found. ("uniquely identifies" means give the document title, and the appropriate combination of version number, date, reference no., etc. such that the document is uniquely identified and can be obtained by the reader of this conformance statement.)

Examples of supported media types are ISO 9960 CD-ROM, 1.44 mbyte high-density diskette and specific magnetic tape-formatting standards.

Rationale

A conformant implementation shall describe the media types by which conformant software distributions may be transmitted and received.

Reference

Software Administration Product Standard Definition.

1.5 Communication and Interoperability

Question 6: If the implementation is a "Conforming POSIX.7.2 Implementation", by what protocol stacks does it communicate with other systems as part of a distributed software administration system?

Response

Enter your response in the text area, using as many lines as necessary, or state that it is a limited conformance POSIX.7.2 implementation, not a conforming POSIX.7.2 implementation.

Alternatively, insert a reference that uniquely identifies the product documentation, and the place within that documentation, where the information can be found. ("uniquely identifies" means give the document title, and the appropriate combination of version number, date, reference no., etc. such that the document is uniquely identified and can be obtained by the reader of this conformance statement.)

Rationale

A "Conforming POSIX.7.2 Implementation" shall identify the complete protocol stacks by which it communicates with other systems as part of a distributed software administration system.

Reference

Software Administration Product Standard Definition.

Question 7: If the implementation is a "Conforming POSIX.7.2 Implementation", with what systems (platforms and operating systems) has interoperability for the purposes of processing software distributions as defined in IEEE Std. 1387.2:1995 been tested?

Response

Enter your response in the text area, using as many lines as necessary.

Alternatively, insert a reference that uniquely identifies the product documentation, and the place within that documentation, where the information can be found. ("uniquely identifies" means give the document title, and the appropriate combination of version number, date, reference no., etc. such that the document is uniquely identified and can be obtained by the reader of this conformance statement.)

Rationale

A "Conforming POSIX.7.2 Implementation" shall identify the systems (platforms and operating systems) with which interoperability has been tested for the purpose of processing software distributions as part of a distributed software administration system.

Reference

Software Administration Product Standard Definition.

1.6 Other Applicable Standards

Question 8: What software standards, and applicable characteristics of those standards, does the implementation use that are approved by ISO/IEC, by any ISO/IEC member body, or by government bodies?

Response

Enter your response in the text area, using as many lines as necessary, or enter "None" or "Not applicable" as appropriate.

Alternatively, insert a reference that uniquely identifies the product documentation, and the place within that documentation, where the information can be found. ("uniquely identifies" means give the document title, and the appropriate combination of version number, date, reference no., etc. such that the document is uniquely identified and can be obtained by the reader of this conformance statement.)

Rationale

The Conformance Statement may list software standards approved by ISO/IEC, or any ISO/IEC member body, that are available for use by a "Conforming POSIX.7.2 Implementation" or by a "Conforming POSIX.7.2 Distribution". Applicable characteristics where documentation is required by one of these standards, or by standards of government bodies, may also be included.

Reference

IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration), Section 1.3.1.3.

1.7 Implementation-defined Features

Question 9: What are the details of the implementation's standard features that are provided in an implementation-defined manner?

Response

Enter your response in the text area, using as many lines as necessary.

Alternatively, insert a reference that uniquely identifies the product documentation, and the place within that documentation, where the information can be found. ("uniquely identifies" means give the document title, and the appropriate combination of version number, date, reference no., etc. such that the document is uniquely identified and can be obtained by the reader of this conformance statement.)

Rationale

A conformant implementation includes a number of standard features that are provided in an implementation-defined manner. The Conformance Statement for the implementation concerned must describe the behaviour of all such implementation-defined features. This requirement is met by listing the features concerned and providing either specific references to the system documentation or the full syntax and semantics of these features.

The following standard features are implementation-defined:

1. The handling of case for either the name or value of an attribute where the underlying host does not allow for the distinction of case.
2. Behaviour when circular definitions are encountered in fileset prerequisites.
3. Implementation-defined values of extended options supported by utilities.
4. The way in which swinstall, swcopy and swpackage handle multiple volumes for sources and targets.
5. Overwriting or merging existing serial-format target data with the source distribution during swlist, swcopy and swpackage.
6. Location of the Defaults File.
7. Error handling procedures.
8. Logging of events.
9. Whether Event Code SW_SOC_IS_REMOTE has an Event Status of SW_ERROR or SW_NOTE.
10. The policy for loading remote files.
11. Verification of user privileges when invoking commands.
12. Interactive support for media change with Event Code SW_NEED_MEDIA_CHANGE.
13. Transitioning from the corrupt state during fileset state transition.
14. Means of removing software using swremove while maintaining the catalog information.
15. Recovery procedures used to restore from the transient state to another state.
16. Consequences of errors on software objects contained in multiple targets.
17. Failure during the analysis phases of swcopy and swinstall.
18. Loading of remote files during swcopy and swinstall.
19. Behaviour of swinstall when two file sets have exrequisites on each other.
20. Location of files moved, and their method of removal, because they cannot be updated during swinstall.
21. Where files are saved during swinstall when autorecover = true.
22. Default value for, and processing of, postkernel scripts during swinstall.
23. Target host reboot procedure after swinstall.
24. Additional recovery behaviour after failure during swinstall.
25. Removing an object (software, fileset or subproduct) using swremove when a referring object (bundle, subproduct) exists that has not itself been specified for removal.

Reference

The following sections of IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration:

1. Section 3 on Page 29.
2. Section 3.9.1 on Page 44.
3. Section 3.11.1 on Page 46, Section 4.1.5.2 on Pages 64, 66 & 67, and Section 4.5.7.3.4 on Page 112
4. Section 4.1.3.1 on Page 54.
5. Section 4.1.4.2 on Page 60, Section 4.4.4 on Page 99, Section 4.6.4 on Page 118, and Section 4.8.4 on Page 124.
6. Section 4.1.5.1 on Page 60.
7. Section 4.1.5.2 on Page 65, Section 4.2.7.2 on Page 94, Section 4.3.7.3.2 on Page 98, Section 4.4.7.2 on Page 101, Section 4.4.7.3.1 on Page 102, Section 4.5.7.1 on Pages 106 & 107, Section 4.5.7.2 on Pages 107 & 108, Section 4.5.7.3 on Page 110, Section 4.5.7.3.2 on Page 110, Section 4.5.7.3.3 on Page 112, Section 4.5.7.3.5 on Page 113, Section 4.5.7.3.6 on Page 113, Section 4.9.7.1 on Page 129, Section 4.9.7.2 on Pages 129 & 130, Section 4.9.7.3.1 on Page 131, and Section 4.9.7.3.3 on Page 132.
8. Section 4.1.6.5 on Page 75.
9. Section 4.1.6.5 on Page 78.
10. Section 4.1.7.1 on Page 82.
11. Section 4.1.7.1.1 on Page 83.
12. Section 4.1.7.1.2 on Page 84.
13. Section 4.1.7.3.1 on Page 89.
14. Section 4.1.7.3.1 on Page 90.
15. Section 4.1.7.3.1 on Page 90.
16. Section 4.1.9 on Page 91.
17. Section 4.4.7.2 on Page 101, Section 4.5.7.2 on Page 107.
18. Section 4.4.7.3.1 on Page 102, Section 4.5.7.3.3 on Page 112.
19. Section 4.5.7.1 on Page 106.
20. Section 4.5.7.3.3 on Page 112.
21. Section 4.5.7.3.3 on Page 112.
22. Section 4.5.7.3.6 on Page 113 & on Page 114.
23. Section 4.5.7.3.6 on Page 114, Section 4.5.7.3.7 on Page 114.
24. Section 4.5.7.3.8 on Page 114.
25. Section 4.9.7.2 on Page 130.

1.8 Control Scripts

Question 10: When a command is run in preview mode, does the implementation run the control scripts associated with the selection and analysis phases of the command being previewed?

Response

Yes   No

Rationale

When running a command in preview mode (-p option), an implementation should run any control scripts that are executed as part of the selection or analysis phase of the command being previewed. Use of the word "should" in IEEE Std. 1387.2:1995 indicates that this is a recommendation to implementors but is not a mandatory requirement.

Reference

IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration, Section 4.1.3 on Page 52.

Question 11: Does the implementation ensure that each software_collection_spec contained in the value of the targets option is the same between invocations of commands?

Response

Yes   No

Rationale

An implementation should ensure that each software_collection_spec contained in the value of the targets option is the same between invocations of commands. This will help ensure that any per-target information stored by the request script can be located by the subsequent scripts. Use of the word "should" in IEEE Std. 1387.2:1995 indicates that this is a recommendation to implementors but is not a mandatory requirement.

Reference

IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration, Section 4.1.6.1 on Page 73.

1.9 Support for Serial-format Target Distributions

Question 12: Does the implementation support target distributions in the serial format for swverify, swremove and swmodify?

Response

Yes   No

Rationale

A conformant implementation need not support target distributions in the serial format for swverify, swremove and swmodify.

Reference

IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration, Section 4.1.4.2 on Page 60, Section 4.7.4 on Page 121, Section 4.9.4 on Page 128, and Section 4.10.4 on Page 134.

1.10 Version Identifiers

Question 13: What additional Version Identifiers are supported in software specifications?

Response

Enter your response in the text area, using as many lines as necessary, or state that there are no additional version identifiers.

Alternatively, insert a reference that uniquely identifies the product documentation, and the place within that documentation, where the information can be found. ("uniquely identifies" means give the document title, and the appropriate combination of version number, date, reference no., etc. such that the document is uniquely identified and can be obtained by the reader of this conformance statement.)

Rationale

An implementation may support additional software specification version identifiers beyond the base set of:

r

revision

a

architecture

v

vendor_tag

l

location

q

qualifier

Reference

IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration, Section 4.1.4.1 on Pages 56 and 57.

1.11 Event Definitions for Access and Concurrency Control Errors

Question 14: What event definitions does the implementation support in the event of access and concurrency control errors?

Response

NONE SW_ERROR: SW_ACCESS_DENIED SW_ERROR: SW_CONFLICTING_SESSION_IN_PROGRESS SW_WARNING: SW_CONFLICTING_SESSION_IN_PROGRESS SW_ERROR: SW_SOC_LOCK_FAILURE

Rationale

A conformant implementation may optionally generate the following events when access and concurrency control errors occur:

SW_ERROR: SW_ACCESS_DENIED
SW_ERROR: SW_CONFLICTING_SESSION_IN_PROGRESS
SW_WARNING: SW_CONFLICTING_SESSION_IN_PROGRESS
SW_ERROR: SW_SOC_LOCK_FAILURE

Reference

IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration, Section 4.1.5.6 on Page 71.

1.12 Environment Variable - LC_TIME

Question 15: Do the implementation's utilities use the LC_TIME variable when displaying dates and times in stdout, stderr and logging?

Response

Yes   No

Rationale

The IEEE Std. 1387.2:1995 recommends that implementations should use the LC_TIME variable when displaying dates and times in stdout, stderr and logging. Use of the word "should" in IEEE Std. 1387.2:1995 indicates that this is a recommendation to implementors but is not a mandatory requirement.

Reference

IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration, Section 4.1.5.7 on Pages 71 and 72.

1.13 Script Return Codes

Question 16: Does the implementation provide additional script return codes and, if so, what is the behaviour of those codes?

Response

Enter "yes" or "No" in the area below. If the answer is "yes", also describe the behavior of the script return codes concerned, using as many lines as necessary.

Alternatively, insert a reference that uniquely identifies the product documentation, and the place within that documentation, where the information can be found. ("uniquely identifies" means give the document title, and the appropriate combination of version number, date, reference no., etc. such that the document is uniquely identified and can be obtained by the reader of this conformance statement.)

Rationale

A conformant implementation must support script return codes 0-3, with codes 4-31 being reserved for future use by the standard. An implementation that provides additional script return codes (greater than 31) must identify those codes and document the behaviours associated with each of them.

Reference

IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration, Section 4.1.6.1.2 on Page 74.

1.14 Failure Events

Question 17: Which of the optional failure events does the implementation generate?

Response

Enter your response in the text area, using as many lines as necessary. Thge full set of event codes applicable to this question can be found in the rationale section below. You many copy/paste the applicable ones from there.

Alternatively, insert a reference that uniquely identifies the product documentation, and the place within that documentation, where the information can be found. ("uniquely identifies" means give the document title, and the appropriate combination of version number, date, reference no., etc. such that the document is uniquely identified and can be obtained by the reader of this conformance statement.)

Rationale

An implementation may generate the following events at any point in the execution of a command where they are applicable to that implementation:

SW_ERROR: SW_ACCESS_DENIED
SW_ERROR: SW_ILLEGAL_OPTION
SW_ERROR: SW_MEMORY_ERROR
SW_ERROR: SW_RESOURCE_ERROR
SW_ERROR: SW_INTERNAL_ERROR
SW_ERROR: SW_TERMINATION_DELAYED
SW_ERROR: SW_IO_ERROR

An implementation may generate the following events when validating a target where they are applicable to that implementation:

SW_ERROR: SW_SERVICE_NOT_AVAILABLE
SW_WARNING: SW_OTHER_SESSIONS_IN_PROGRESS
SW_ERROR: SW_CONNECTION_LIMIT_EXCEEDED
SW_NOTE: SW_SOC_IS_REMOTE
SW_ERROR: SW_FILESYSTEMS_NOT_MOUNTED
SW_ERROR: SW_FILESYSTEMS_MORE_MOUNTED

An implementation may generate the following events during the analysis or execution phase where they are applicable to that implementation:

SW_ERROR: SW_AGENT_INITIALIZATION_FAILED
SW_ERROR: SW_ILLEGAL_STATE_TRANSITION
SW_ERROR: SW_BAD_SESSION_CONTEXT

An implementation may generate the following events as applicable to the error handling procedures for the implementation:

SW_NOTE: SW_SKIPPED_PRODUCT_ERROR
SW_NOTE: SW_SKIPPED_GLOBAL_ERROR
SW_WARNING: SW_FILE_IS_READ_ONLY

For swinstall and swcopy from a distribution that spans multiple media, an implementation may generate the following events to convey needed media-change information:

SW_ERROR: SW_WRONG_MEDIA_SET
SW_NOTE: SW_NEED_MEDIA_CHANGE
SW_NOTE: SW_CURRENT_MEDIA.

An implementation may generate the following events for software that will not be executed due to analysis results for that software:

SW_NOTE: SW_SELECTION_SKIPPED_IN_ANALYSIS
SW_ERROR: SW_SELECTION_NOT_ANALYZED

Reference

IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration, Section 4.1.7.1.1 on Page 83, Section 4.1.7.1.2 on Pages 87, Section 4.1.7.2 on Page 88, and Section 4.1.7.3 on Page 89.

1.15 Archive Formats Supported for Serial Distributions

Question 18: What archive formats are supported for serial distributions?

Response

Both extended cpio and extended tar archive formats Extended cpio archive format Extended tar archive format

Rationale

When creating a serial distribution, a conformant implementation may support the extended cpio archive format, the extended tar archive format, or both of those formats.

Reference

IEEE Std. 1387.2:1995, Information Technology - Portable Operating System Interface (POSIX) - System Administration - Part 2: Software Administration, Section 4.4.7.3 on Page 102, Section 4.8.7.3 on Page 126.

1.16 Cross-reference Table

2. Appendix

Copyright © 
All rights reserved.

3. Change History