(j3.2006) (SC22WG5.5425) WG5 straw ballot on N2040

[Malcolm Cohen]

3) No, for the following reasons.

(a) I agree with Robert Corbett's vote.  My recommendation is that the transfer 
of control to the END TEAM statement should be available only for access to 
failed image data from within the CHANGE TEAM construct itself.

(a2) 5.9 states
  "Otherwise, the executing image resumes execution at the END TEAM statement of 
the construct"

"the construct" lacks definition.  There can be many CHANGE TEAM constructs, and 
more than one of them can be active.  Presumably what is meant is either
   (i) the innermost such construct
or
   (ii) the innermost such construct whose END TEAM statement has a STAT= 
specifier.
This needs to be explicitly stated.  I note that in the case of executing code 
outside (but called from) a CHANGE TEAM construct, "innermost" has no meaning.

(b) The TS has merely scratched the surface of the semantics that are being 
specified for stalled image handling; much more work needs to be done to clarify 
what is supposed to happen (e.g. which variables become undefined, etc.).  Even 
for failed images some additional work appears to be needed...

(c) I do not agree with the syntax for specifying a team variable in an 
image-selector, as we use double colons following type-specs and other related 
attributes, which this is certainly not.  A single colon would be acceptable.

(d) FAIL IMAGE is insufficiently specified.

- The syntax is "FAIL IMAGE <stop-code>".  I see no purpose in using the 
<stop-code> BNF rule here.

- "Execution of a FAIL IMAGE statement causes the executing image to behave as 
if it has failed."
I think that should be "...become a failed image."

- " No further statements are executed by that image."

I think it would be clearer to state explicitly that image termination is not 
initiated by this statement, e.g.
  " Neither normal nor error termination is initiated, but no further statements 
are executed by that image."

- "When an image executes a FAIL IMAGE statement, its stop code, if any, is made 
available in a processor-dependent manner."

This is not only completely useless, but also missing any useful recommendation; 
e.g. for STOP and ERROR STOP we recommend "formatted output to [ERROR_UNIT]".

(e) Clause 1 states
  "This Technical Specification does not specify formal data consistency or 
progress models. Some level of asynchronous progress is required to ensure that 
the examples in clauses 6 and 7 are conforming."

- point 1: there are no examples in clause 6;

- point 2: I found no useful examples in clause 7, by which I mean any that are 
bigger than 1 statement and that make any use of data consistency or 
asynchronous progress;

- point 3: were there useful examples the question would not be whether they 
were conforming, but whether they WORKED on any conforming implementation of the 
TS.

(f) Clause 1 continues
  "Developing the formal data consistency and progress models is left until the 
integration of these facilities into ISO/IEC 1539-1."

We need to get started on this straightaway, not leave it to the last minute.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.