Subject: SC22 N2579 - WG22 Record of Responses on Defect Reports 01 through 18 - PCTE - AND LETTER BALLOT

From: "william c. rinehuls" <[email-masked]>
Date: Tue, 2 Sep 1997 17:22:54 -0400 (EDT)

____________________ beginning of title page ___________________________
ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat:  U.S.A.  (ANSI)

ISO/IEC JTC 1/SC22
N2579

TITLE:
WG22 Record of Responses for Defect Reports 01 through 18 for: ISO/IEC
13719-1 - Information technology - Portable Common Tool Environment
(PCTE), Part 1; ISO/IEC 13719-2 - Information technology - Portable Common
Tool Environment (PCTE), Part 2; and ISO/IEC 13719-3 - Information
technology - Portable Common Tool Environment (PCTE0, Part 3 AND LETTER
BALLOT

DATE ASSIGNED:
1997-09-02

SOURCE:
Secretariat, ISO/IEC JTC 1/SC22

BACKWARD POINTER:
N/A

DOCUMENT TYPE:
Record of Responses for Defect Reports

PROJECT NUMBER:
JTC 1.22.47.1

STATUS:
In accordance with SC22 N1236, non-responses to the letter ballot will be
considered as agreement with the proposed record of responses.

ACTION IDENTIFIER:
ACT

DUE DATE:
1998-01-07

DISTRIBUTION
Text

CROSS REFERENCE:
SC22 N2425, N2426, N2427

DISTRIBUTION FORM:
Open

Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
William C. Rinehuls
8457 Rushing Creek Court
Springfield, VA 22153 USA
Telephone:  +1 (703) 912-9680
Fax:  +1 (703) 912-2973
email:  [email-masked]

____________________ end of title page; beginning of letter ballot _____

                                                Attachment to
                                                JTC 1/SC22 N 2579

                                      Circulation Date:  09-22-97

                           LETTER BALLOT

FROM THE MEMBER BODY OF:  ______________________________

On WG22 Proposed Record of Responses to Defect Reports 01 through 18 to:
ISO/IEC 13719-1 - Information technology - Portable Common Tool
Environment (PCTE), Part 1; ISO/IEC 13791-2 - Information technology -
Portable Common Tool Environment (PCTE), Part 2; and ISO/IEC 13791-3 -
Information technology - Portable Common Tool Environment (PCTE), Part 3

This Letter Ballot is to be returned by each "P" Member Body to the
Secretariat of JTC 1/SC22 by JANUARY 7, 1998

------------------------------------------------------------

____ We agree with the Record of Responses

                     or

____ We agree with the Record of Responses with the attached comments

                     or

____ We do not agree with the Record of Responses for the technical
     reasons attached to this ballot 

                     or

____ We abstain from voting

      ("P" Member Bodies have an obligation to vote.)

*  CHECK WHICHEVER APPLIES.

Name (please print) __________________

Signature (if mailed) ________________   Date:  _________________

____________ end of letter ballot; beginning of record of responses ___

Record of Response

Issue 1

ISO/IEC JTC1/SC22/WG22 Defect Reports DR-001 to DR-018 inclusive

-----------------------------------------------------------------------

Information technology - Portable Common Tool Environment (PCTE)

ISO/IEC 13719 : 1995

August 1997

-----------------------------------------------------------------------

Introduction
------------

This document contains the responses to defects reported in the PCTE 
Standard ISO/IEC 13719, parts 1, 2, and 3, which led to no normative 
changes.  The responses reflect the technical opinion of the experts of 
ISO-IEC/JTC1/SC22/WG22: PCTE, in conjunction with ECMA TC33.  The full 
set of all comments with discussions and resolutions are in document 
SC22/WG22 N133.

References to the parts of ISO/IEC 13719 are by paragraph number within 
subclause, as '(12)'.  The notation 'EP-xxxx' (or EP-xxxx[y]) identifies 
the comment (and part of comment) in SC22/WG22 N133.

-----------------------------------------------------------------------
Defect Report DR-001 (EP-4227)

SUBJECT: Pcte_time almost unusable

REFERENCES: ISO/IEC 13719-2/8.2.5

QUESTION:
Paragraph (5) effectively makes the type Pcte_time a private type; 
however, the functions described are NOT provided by the Binding, thus 
making it impossible to set attributes to 'real' dates, or to read 
attribute values as 'real' dates.

The definition of type Pcte_time as the type time_t is in itself 
somewhat suspect, as it has implications that the values are actually 
encoded as the number of seconds from some reference point, and hence 
that the standard C library functions timegm, gmtime, etc., may be used 
to manipulate values of this type.

However, if this approach is used, a problem arises. The C/UNIX 
reference time is 1970-01-01T00:00:00Z (UTC), defined as a time_t value 
of 0, whereas the PCTE reference time is 1980-01-01T00:00:00Z, defined 
as the implementation-defined constant Pcte_reference_time.  This means 
that if Pcte_times are converted into C times (by addition/subtraction 
of a suitable bias) so that the standard C functions can be used, the 
latest date which can be handled (given the use of 32-bit ints by C) is

   1970-01-01T00:00:00Z  +  2 ** 31 - 1 seconds

which is 2038-01-19T03:14:07Z.  This date is earlier than 
MAX_TIME_ATTRIBUTE, which is defined as being no earlier than 2044-12-
31T24:00:00Z.

A suggested resolution is to make Pcte_time an implementation-defined 
type, and provide a set of operations upon it, comparable to those 
provided by the Ada Binding package PCTE.CALENDAR.  The PCTE user should 
not be required to worry about the trivia (e.g. leap years, leap 
seconds, etc.) of converting between 'real' dates and Pcte_time values.

RESPONSE:
This is too difficult a change for the advantages gained.
-----------------------------------------------------------------------
Defect Report DR-002 (EP-4348)

SUBJECT: Missing errors in SDS_CREATE_DESIGNATION_LINK_TYPE

REFERENCES: ISO/IEC 13719-1/10.2.5

QUESTION:
In SDS_CREATE_DESIGNATION_LINK_TYPE:
[1] Should the error LIMIT_WOULD_BE_EXCEEDED be raised when too many 
key_types are provided?
[2] Should the error PCTE_LINK_TYPE_CATEGORY_IS_BAD be raised when the 
link to be  created is not of category DESIGNATION?

RESPONSE:
[1] There is no limit and has been no limit to the number of key 
attributes that can be defined for a link.
[2] No parameter specifies the category, since it is implied by the 
operation name.
-----------------------------------------------------------------------
Defect Report DR-003 (EP-4350, EP-4401[11-16])

SUBJECT: Missing errors in SDS_CREATE_OBJECT_TYPE

REFERENCES: ISO/IEC 13719-1/10.2.11

QUESTION:
In SDS_CREATE_OBJECT_TYPE:
[1] Should the error NO_PARENTS be raised when no parent is specified?
[2] Should the error PARENT_TYPES_ARE_MULTIPLE be raised when a parent 
type occurs more than once in types?

RESPONSE:
[1] The case of no parents is covered by the error 
OBJECT_TYPE_WOULD_HAVE_NO_PARENT_TYPE (10.2.11(14)).
[2] Multiple elements are specifically allowed in sequences representing 
unbounded sets in both the Ada and the C bindings - see 8.1.3(3) in both 
bindings.
-----------------------------------------------------------------------
Defect Report DR-004 (EP-4351)

SUBJECT: Missing errors in SDS_CREATE_RELATIONSHIP_TYPE

REFERENCES: ISO/IEC 13719-1/10.2.12

QUESTION:
In SDS_CREATE_RELATIONSHIP_TYPE should the error LIMIT_WOULD_BE_EXCEEDED 
be raised when too many key_types are provided?

RESPONSE: there is no limit to the number of key attributes that can be 
defined for a link. (There is an effective limit implied by other 
constraints, but no explicit limit.)
-----------------------------------------------------------------------
Defect Report DR-005 (EP-4357)

SUBJECT: Questions on SDS_REMOVE_TYPE

REFERENCES: ISO/IEC 13719-1/10.2.23

QUESTION:
In SDS_REMOVE_TYPE:
[1] Can all access errors be implemented with a scope ATOMIC?
[2] If the type object is to be actually deleted, can no security checks 
be performed on the related type objects (i.e. the parent types in case 
of a deleted object type, the key attribute types in case of a deleted 
link type and the enumeral types in case of an enumeration attribute 
type)?

RESPONSE:
[1] No, this implementation is wrong.  DELETE is a composite permission.
[2] No, these security checks must be observed.
-----------------------------------------------------------------------
Defect Report DR-006 (EP-4358)

SUBJECT: SDS Usage Operations

REFERENCES: ISO/IEC 13719-1/10

QUESTION:
The sds_xxx functions return full type name instead of a local name in 
output parameters.  The sds_xxx functions accept full type names as 
input parameters provided that the SDS name part of the full type names 
designates the same SDS than the "sds" parameter. 

RESPONSE:
This is an implementation issue and does not affect the Standard.
-----------------------------------------------------------------------
Defect Report DR-007 (EP-4369[2])

SUBJECT: Limit checks in PROCESS_CREATE

REFERENCES: ISO/IEC 13719-1/13.2.1

QUESTION:
Can the operation PROCESS_CREATE not check that the limits 
MAX_PROCESSES_PER_USER and MAX_PROCESSES are not exceeded?

RESPONSE
No, this would be a significant change, and would mean that the limits 
MAX_PROCESSES and MAX_PROCESSES_PER_USER need not be observed by an 
implementation, which is undesirable.
-----------------------------------------------------------------------
Defect Report DR-008 (EP-4374)

SUBJECT: Discretionary checks in PROCESS_WAIT_FOR_ANY_CHILD

REFERENCES: ISO/IEC 13719-1/13.2.17

QUESTION:
Need the operation PROCESS_WAIT_FOR_ANY_CHILD check the discretionary 
permission WRITE_ATTRIBUTES on the terminated child process?

RESPONSE
Yes, this is an essential check, and there seems no reason to omit it.
-----------------------------------------------------------------------
Defect Report DR-009 (EP-4375)

SUBJECT: Redundant errors in PROCESS_WAIT_FOR_CHILD

REFERENCES: ISO/IEC 13719-1/13.2.18

QUESTION:
In PROCESS_WAIT_FOR_CHILD the errors PROCESS_HAS_NOT_GOT_REQUIRED_STATUS 
(if status of the specified process is READY) and PROCESS_IS_NOT_CHILD 
(if the specified process is not a child process of the caller) are
returned instead of PROCESS_IS_NOT_TERMINABLE_CHILD.  According to its 
definition, the error PCTE_IS_NOT_TERMINABLE_CHILD could be replaced by 
both errors PROCESS_IS_NOT_CHILD and 
PROCESS_HAS_NOT_GOT_REQUIRED_STATUS. The request have been made only in 
order to reduce the general number of error codes and I have no more 
strong argument in favour of its comments (in fact it is not a problem 
if the comment is rejected).

RESPONSE:
The only reason for the change would be to reduce the number of errors, 
and it is now too late to do this.  For reasons of backward 
compatibility the error code values in the interface should not now 
change.  Eliminating an error code will not enable it to be re-used, or 
to change the values of the errors which follow in the list in Part 2, 
25.1.  Any new errors should be placed at the end of the list.
-----------------------------------------------------------------------
Defect Report DR-010 (EP-4377)

SUBJECT: Resetting the working schema in PROCESS_SET_USER

REFERENCES: ISO/IEC 13719-1/13.3.7

QUESTION:
Must PROCESS_SET_USER reset the working schema of the caller to empty?

RESPONSE:
Yes, this has long been agreed and no counter-arguments have been made.
-----------------------------------------------------------------------
Defect Report DR-011 (EP-4378, EP-4379)

SUBJECT: Discretionary check in process operations

REFERENCES: ISO/IEC 13719-1/13.5.1, 13.5.2, 13,5,5

QUESTION:
Should the operations PROCESS_ADD_BREAKPOINT, PROCESS_CONTINUE, and 
PROCESS_REMOVE_BREAKPOINT check the discretionary permission 
WRITE_ATTRIBUTES on the specified child process (instead of 
WRITE_CONTENTS)?

RESPONSE:
WRITE_CONTENTS is closer to what is intended 
-----------------------------------------------------------------------
Defect Report DR-012 (EP-4380, EP-4381)

SUBJECT: Questions on PROCESS_PEEK and PROCESS_POKE

REFERENCES: ISO/IEC 13719-1/13.5.3, 13.5.4

QUESTION:
[1] Can the operations PROCESS_PEEK and PROCESS_POKE only accept a 
process_data_size equal to sizeof(Pcte_integer)?
[2] Should the operations PROCESS_PEEK and PROCESS_POKE check the 
discretionary permission WRITE_ATTRIBUTES on the specified child process 
(instead of READ_CONTENTS and WRITE_CONTENTS respectively)?

RESPONSE:
[1] We take it this is a C binding problem; however PROCESS_PEEK and 
PROCESS_POKE are meant to handle very small pieces of data, a byte or a 
word at a time, and the actual size returned by PROCESS_PEEK was 
determined in an implementation-defined way.
[2] READ_CONTENTS and WRITE_CONTENTS are closer to what is intended 
-----------------------------------------------------------------------
Defect Report DR-014 (EP-4384)

SUBJECT: Message queue concepts

REFERENCES: ISO/IEC 13719-1/14.1

QUESTION:
Is it allowed for the position numbers given to messages in message 
queues to be assigned on a per-PCTE server basis in a monotonically 
increasing way starting from 1 each time the PCTE server is started, 
i.e. the counter is not persistent across PCTE termination (even if the 
message queue objects are)?

RESPONSE:
Message queue contents are not persistent across workstation 
termination, see 18.1.6(14).
-----------------------------------------------------------------------
Defect Report DR-015 (EP-4390[2], EP-4391[2])

SUBJECT: Redundant error in CONTENTS_COPY_FROM_FOREIGN_SYSTEM

REFERENCES: ISO/IEC 13719-1/18.3.1, 18.3.2

QUESTION:
In CONTENTS_COPY_FROM_FOREIGN_SYSTEM and CONTENTS_COPY_TO_FOREIGN_SYSTEM 
why are the errors FOREIGN_SYSTEM_IS_INACCESSIBLE (both operations) and 
FOREIGN_EXECUTION_IMAGE_IS_BEING_EXECUTED (latter operation only) needed 
- why not return the error FOREIGN_OBJECT_IS_INACCESSIBLE if the failure 
is due to a problem with/on the foreign system, whatever the problem is?

RESPONSE:
While the distinction between FOREIGN_SYSTEM_IS_INACCESSIBLE and 
FOREIGN_OBJECT_IS_INACCESSIBLE seems fairly clear, and one could argue 
that a foreign system may be accessible, but an object ostensibly 
residing on that system may not be accessible, and these two situations 
are distinguishable, on the other hand.it was felt that we cannot 
legislate for the behaviour of a foreign system and so should only have 
one error, which should be FOREIGN_OBJECT_IS_INACCESSIBLE.
-----------------------------------------------------------------------
Defect Report DR-016 (EP-4394, EP-4395, EP-4396, EP-4397)

SUBJECT: Question on PROGRAM_GROUP_ADD_MEMBER

REFERENCES: ISO/IEC 13719-1/19.3.4, 19.3.5, 19.3.8, 19.3.9

QUESTION:
In PROGRAM_GROUP_ADD_MEMBER, PROGRAM_GROUP_ADD_SUBGROUP, 
USER_GROUP_ADD_MEMBER, and USER_GROUP_ADD_SUBGROUP, can the key of the 
"program_member_of", "program_subgroup_of", "user_member_of", and 
"user_subgroup_of" link (respectively) be the group identifier (key of 
the "known_security_group" link from the security directory to group)?

RESPONSE:
Yes, this is an implementation choice.
-----------------------------------------------------------------------
Defect Report DR-017 (EP-5006)

SUBJECT: LINK_REFERENCE_SET

REFERENCES: ISO/IEC 13719-1/23.3.8

QUESTION:
In LINK_REFERENCE_SET, error 
LINK_NAME_AND_EVALUATION_POINT_ARE_INCONSISTENT(link_name, point) has 
been omitted.  The error needs to be added to Appendix C. The text is:

'Link name /link_name/ has one of the forms A.B., A.1. or A.1 which 
require a preferred link type which is unavailable to this operation, 
and evaluation point /point/ is NOW.'

RESPONSE:
An internal link reference is only pre-evaluated.  This is made clear by 
23.1.2.3(18) and (23), which show that the error 
PREFERENCE_DOES_NOT_EXIST can occur during evaluation of an internal 
link reference.
-----------------------------------------------------------------------
Defect Report DR-018 (EP-5026)

SUBJECT: Identical errors

REFERENCES: ISO/IEC 13719-1/C.4

QUESTION:
OBJECT_TYPE_IS_NOT_VISIBLE is defined as the same as 
OBJECT_TYPE_IS_UNKNOWN.  Only the latter is used as far as I can see in 
operations which have object type references (nominators).  For 
consistency only the former should be used and all places where 
OBJECT_TYPE_IS_UNKNOWN occurs it should simply be deleted.

RESPONSE:
One error refers to references, the other to nominators.

____________________ end of SC22 N2579 ______________________________