ISO/IEC JTC1/SC22/WG5 N2055 Response to the WG5 straw ballot on N2048 Bill Long and John Reid This paper contains responses to the comments in the WG5 straw ballot on N2048 (see N2054) and a set of edits to N2048. Reinhold Bader wrote [11:16+] add new paragraph "If STAT= appears in a coarray designator, the variable specified shall not be associated with any other entity that appears in an expression containing a reference to the coindexed object, or in an expression that is the right hand side of an assignment to the coindexed object." Reason: I assume it is not intended that Y = A[i, STAT=status] * status A[i, STAT=status] = Z * status A[i, STAT=status] = B[j, STAT=status] are conforming. Response Agreed, but we think more needs to be said. We suggest this edit: [11:16+] add new paragraph "The denotation of a in an shall not depend on the evaluation of any entity in the same statement. The value of an expression shall not depend on the value of any that appears in the same statement. The value of a in an shall not be affected by the execution of any part of the statement, other than by whether the image specified by the has failed." [11:16+] add new note "NOTE The expression x[i,stat=is(f(n))], where is is an array and f(n) is a function that returns an integer value is an example of the denotation of a in an that depends on the evaluation of an entity in the same statement." ....... Reinhold Bader wrote [11:16+] add new paragraph "If STAT= appears in a coarray designator for a coindexed actual argument, the variable specified is defined * when the invoked procedure completes if the corresponding dummy argument has INTENT (INOUT), INTENT (OUT) or unspecified intent, * when the invoked procedure starts execution if the corresponding dummy argument has INTENT (IN)." Reason: State clearly when the STAT argument becomes defined for this special situation, under the assumption that copying is always needed. Response All that really matters as far as the programmer is concerned is that the variable has been defined before any reference is made to it. The detail of when it is defined should be left to the implementation. We need also to say what value get put in the stat= variable. We suggest this edit. [11:16++] add new paragraph "Execution of a statement containing an with a STAT= specifier causes the to become defined. If the designator is part of an operand that is evaluated, and the object designated is on a failed image, the is defined with the value STAT_FAILED_IMAGE; otherwise, it is defined with the value zero." ....... Reinhold Bader wrote [19:33-34] This seems inconsistent with the way the STAT= in coarray designators are now defined in the TS. If there is a reason why this rule is needed, it should probably be prohibited to specify STAT= in the designator for a coindexed actual argument of an atomic. If not, one might as well delete the separate STAT= argument of the atomics. Response There is no inherent conflict in specifying both a STAT argument and a STAT= specifier in a coindexed actual argument in the same call to an atomic subroutine. Using the same status variable in multiple places in the call is already not allowed. And the STAT argument itself is not allowed to be coindexed. The STAT argument has different semantics from the STAT= specifier in an image selector. If the STAT argument is not present and the called procedure raises an error condition, the program terminates. In contrast, the lack of a STAT= specifier in an image selector does not lead to termination if the specified image failed. ....... Reinhold Bader wrote [38:34+] add sentence "It is processor dependent which images are involved in execution of a SYNC MEMORY statement, beyond the image executing the statement." [44:20+] add bullet "* images involved in execution of SYNC MEMORY, beyond the executing image (8.5.7)." Reason: In N2048 nothing at all is said any more about which images are involved in execution of that statement. Response It is better to disconnect SYNC MEMORY from the concept of involved images in the new text for 8.5.7. We suggest these edits. [38:16] Insert a new sentence at the beginning of paragraph: "If the STAT= specifier appears in a SYNC MEMORY statement and its execution is successful, the specified variable is assigned the value zero." [38:17] delete "SYNC MEMORY" [38:35] after "specifier" add "that is not a SYNC MEMORY statement" ............ Reinhold Bader wrote [48:20-39] Indent executable statements by 2. [48:40] Indent by 4. (Indentation on page 49 seems OK). [52:37+] Add line " IF (NC(I) > 0) THEN" [52:38-39] Add indentation [52:39+] Add line " END IF" Reason: for the case NC(I)==0 [18:15-16] implies that UNTIL_COUNT is 1, causing the program to hang. I already noticed this in an earlier draft, but it didn't make it into the vote. Sorry. Response Agreed. ............. Malcolm Cohen wrote (0a) MAJOR ISSUE: The term "current team" is a poor name. Apart from the fact that the word "current" is frowned upon by ISO, there is no unique "current team", each image has its own "current team". I think that "active team" would be better - it is more understandable that this is per-image. That this is a major issue is demonstrated by the need to talk about the "current current team" vs the "current team at the time of execution of the blah statement", etc. (Yes, the TS does not generally do this, but that's because it is not being rigorous enough to avoid ambiguity.) In the further edits below I am sticking with "current team", this is so as not to conflate other issues with the terminological ones. Response We have not found any advice against the use of the word "current" in the ISO/IEC Directive, part 2. The team to which an image belongs varies during execution, so we think it is entirely appropriate to use the adjective "current". ............ Malcolm Cohen wrote (0b) The term "team identifier" is a poor choice, as there is no expectation of uniqueness and the team thus identified varies dynamically. A better term would be "team number"; that is, it is more like an input/output unit number than it is like a unique identifier. Response Agreed. There is a further problem with "team identifier". It appears as a syntax term in 5.4, where it may be either an integer or a team variable value. We suggest these edits. [5:32-33] Replace by "<> integer value identifying a team within its parent team (5.1)". [11:6], [11:12], [11:15] twice, [19:6], [29:39], [30:8], [30:14], [30:29], [30:33], [31:27], [31:31], [33:19], [35:28], [40:1-1], [40:3+5], [40:3+9], [41:6], [41:8], [41:14], [41:30], [41:35], [45:30], [46:33], [46:36], [48:41] Replace "TEAM_ID" by "TEAM_NUMBER". [11:16+1], [46:30], Replace "team_id" by "team_number". [12:2], [12:4], [12:8], [12:9], [12:12], [12:13], [12:15] Replace "team-id" by "team-number". [9:8], [11:13], [29:40], [30:6], [30:34], [31:32], [40:1-], [41:15], [41:36]. Replace "identifier" by "number". [34:31-32] Replace by "<> integer value identifying a team within its parent team (2.3.4)" ............ Malcolm Cohen wrote (0c) The definition of "established coarray" is confusing, precisely what this term means is also confusing -- no fix proposed. Response We suggest replacing the definitions of "established coarray" as follows [5:17] Replace definition by "(in a team) coarray that is accessible using a coindexed designator (5.1)". [34:5] Replace definition by "(in a team) coarray that is accessible using a coindexed designator (8.1.4a)". ............ Malcolm Cohen wrote (0d) In several contexts the concept of "sub-team" would be useful, in particular it might make some of the wording more accurate and/or less convoluted in places. I think we can just use that word without definition, or we could say something like "The sub-teams of a team are those teams which have that team as a parent team." Response We used to use the word "subteam", see for example N1967, but found it not to be helpful and removed it. ............ Malcolm Cohen wrote (0e) There is a singular occurrence of "associating coarray", and two mentions of coarrays that are or are not an "associating entity" that does not say that these are "associating coarrays". I note that an associate-name can be a coarray, in which case its variable is an associating entity. But that is probably not intended to be an "associating coarray". So some better terminology or use of existing terminology seems to be required. Response We suggest this edit [9:15] Replace "associating coarray" by "coarray that is an associating entity in a of a CHANGE TEAM statement". ............ Malcolm Cohen wrote (1) The definition of "current team" is completely defective; "innermost" is meaningless in this context. Also, it needs to be qualified with "of an image", since each image has its own current team [5:23-24] 3.5.1 current team, replace definition with qualification and text as follows "\termqual{of an image} team specified by the most recently executed CHANGE TEAM statement of an active CHANGE TEAM construct, or initial team if no CHANGE TEAM construct is active". Response Agreed. The corresponding edit is need at [34:22-23]. ............ Malcolm Cohen wrote (2) The term "team identifier" is ambiguously and confusingly described: definition says it is an "integer value identifying a team" according to which, all members of a team must have the same team id, and implicitly if two images have the same team id they belong to the same team; the second of these is clearly false in general. Do we need the definition? Maybe (the term is used in several places); in which case it would seem that a simpler operational definition would work. "value specified by this image as the in the FORM TEAM statement for the current team" Response We think that the edit for [5:32-33] suggested above clarifies this issue. ............ Malcolm Cohen wrote according to the TEAM_ID intrinsic: "If the specified team is the initial team, the result is -1; otherwise, the result value is the team identifier of the invoking image in the specified team." which sounds like a team can have images with differing team identifiers, contradicting the definition. Response The team is specified by the TEAM argument or its absence and it is the number of this team that is required. This edit is needed. [30:6-7] Replace "team identifier ... specified team" by "team number identifying the team of the invoking image within TEAM". ............ Malcolm Cohen wrote There is no statement anywhere which actually says how the team identifier is determined; one might think that FORM TEAM would do that, but it does not. As mentioned above I would prefer a term like "team number", but in any case it needs more careful and not internally contradictory description. Response The FORM TEAM statement does this. See the edit for [12:8-10] below. ............ Malcolm Cohen wrote [5:33] 3.5.4 team identifier, replace definition "integer value identifying a sub-team of a parent team" {See comment above on using "sub-team".} Response We think that the edit for [5:32-33] suggested above is adequate. ............ Malcolm Cohen wrote (3) 5.1p2 regurgitates the definition of "current team", which if we follow the ISO guidelines makes it an empty tautology viz "The team that is specified in the CHANGE TEAM blah blah, is the team that is specified in the CHANGE TEAM blah blah." This should be written as explanation, not as empty consequences. (I note that an alternative approach would be to have the definition of "current team" be the explanatory one, and to specify here how it is changed and what the consequences are.) NOTE: This absolutely needs to be changed because the current text is nonsensical vis-a-vis "innermost". [9:10-11] 5.1 Introduction, p2, replace with "During execution, each image has a current team, which is only changed by execution of CHANGE TEAM and END TEAM statements. Executing a CHANGE TEAM statement changes the current team to the team specified by the , and execution of the corresponding END TEAM statement restores the current team back to its state immediately prior to execution of the CHANGE TEAM statement." {More wordsmithing probably useful, but I think this is better than simply repeating the definition tautologically.} Response We agree with this apart from a small change in the penultimate line. The edit becomes [9:10-11] 5.1 Introduction, p2, replace with "During execution, each image has a current team, which is only changed by execution of CHANGE TEAM and END TEAM statements. Executing a CHANGE TEAM statement changes the current team to the team specified by the , and execution of the corresponding END TEAM statement restores the current team back to that immediately prior to execution of the CHANGE TEAM statement." ............ Malcolm Cohen wrote (4) More FORM TEAM defects. "The FORM TEAM statement defines for a new team. The value of specifies the new team to which the executing image will belong. The value of team-id shall be positive and is the same for all images that are members of the same team." This is at best ambiguous. When FORM TEAM is executed by all active images of the current team, they are all on "the same team" but they are not necessarily giving the same value. Nowhere does it say that the specifies the "team identifier" (which is not unique, but that is a separate issue). Nowhere does it say that is assigns the a value that specifies the team that the image will belong to. [12:8-10] 5.5 FORM TEAM statement, p1, replace with something like: "The FORM TEAM statement creates one or more teams from the active images of the current team. The value of shall be positive. The team identifier of each new team is its unique value. Successful execution of FORM TEAM assigns the on each participating image a value that specifies the new team that the image will belong to." {This could use further wordsmithing, but is a start.} Response This is not quite correct. The value identifies a team within its parent. Here is a suggested revision [12:8-10] 5.5 FORM TEAM statement, p1, replace with: "The FORM TEAM statement creates one or more teams from the active images of the current team. The value of shall be positive and identifies the new team to which the executing image will belong. The team number of each new team within the current team is the value of the FORM TEAM statements executed by its images. Successful execution of a FORM TEAM statement assigns the on each participating image a value that specifies the new team that the image will belong to." ............ Malcolm Cohen wrote Problem: "current team" and "initial team" definitions are circular, in fact "initial team" is completely content-free. I am not convinced that we need a special term for the garden variety English "initial team" at all. Fix: [5:27] 3.5.2 initial team, delete or replace with the following: "team, consisting of all images, that began execution of the program". Response We agree with this edit. It is also needed at [34:26]. ............ Malcolm Cohen wrote Problem: "parent team" definition is wrong (does not only apply to current team) and as the term is hardly used anyway, is unnecessary. Fix: [5:27-29] 3.5.3 parent team, delete. Response The term is needed in several places. We suggest the edit [5:30] Replace by "\termqual{of a team} current team during the execution of the CHANGE TEAM statement that established the team (5.1) Also edit at [34:29]. ............ Malcolm Cohen wrote Problem: "failed image" definition is a regurgitation of the waffle from its subclause, is not properly grammatical, and is at best ambiguous and at worst wrong, since references or definitions of a variable do not fail - in fact they work as specified by the TS, even though the user might think this is somewhat mysterious behaviour. This needs to be replaced by a simpler definition. Fix: [5:36-38] 3.6 failed image, replace definition with "image that has ceased participating in program execution but has not initiated termination" {Just say what we mean without going into the details of what the consequences are.} Response Agreed. The edit is also needed at [34:11-13]. ............ Malcolm Cohen wrote Editorial fixes: ---------------- Many of the terms and definitions have defective definitions; these should all be noun clauses with no article. Also plural should be avoided. [5:6] 3.1 active image "An image" -> "image". [5:9-10] 3.2 asynchronous progress, replace with "ability of an image to reference or define a coarray on another image without waiting for that image to execute any particular statement or class of statement" {"require" is wrong, since that would entail a requirement being imposed by the standard, which is not what is meant here; and it should all be singular} [5:11-14] 3.3 collective subroutine, delete. {This definition is useless and uninteresting.} [6:1] 3.7 stopped image, "an image" -> "image". [9:2] 5.1 "Introduction" -> "Team concepts". {This is introductory matter explaining team concepts, so...} Response Agreed, but these additional edits are needed. [33:35-36] replace with "ability of an image to reference or define a coarray on another image without waiting for that image to execute any particular statement or class of statement" [33:37-34:2] 1.3.30a collective subroutine, delete. [34:8] "An image" -> "image". [34:16] "An image" -> "image". .............. Bill Long wrote As noted by Van, the description of the CRITICAL statement is incomplete. Van's suggested rewording didn't distinguish between executing a CRITICAL statement (several images could have started doing that) and completing execution of the CRITICAL statement (which happens on the image we really care about, the one that starts executing the block). Also, I think it would be better to edit the base standard to put the STAT= and ERRMSG= description in 8.5.7 and have a reference to 8.5.7 in 8.1.5. Other image control statements use that convention. The following alternate wording was proposed by John, and I agree it addresses the issues. Edits to N2048: [16:5-7] Replace the sentence "In the CRITICAL ... execute the construct." by a new paragraph: "If the processor has the ability to detect that an image has failed, when an image completes execution of a CRITICAL statement that has a STAT= specifier and the previous image to have entered the construct failed while executing it, the specified variable becomes defined with the value STAT_FAILED_IMAGE from the intrinsic module ISO_FORTRAN_ENV. Otherwise, when an image completes execution of a CRITICAL statement that has a STAT=specifier, the specified variable becomes defined with the value zero. When an image completes execution of a CRITICAL statement that has an ERRMSG= specifier and assigns a nonzero value to the status variable of a STAT= specifier or would have done so if a STAT= specifier had appeared, the processor shall assign an explanatory message to the specified variable as if by intrinsic assignment." [37:4] Before "}" add 'After para 3, add a new para: "The effect of a STAT= or an ERRMSG= specifier in a CRITICAL statement is explained in 8.5.7."' [38:40] Before "}" add "the following paragraphs, then add the final paragraph of 6.3 CRITICAL construct of this Technical Specification." Response Agreed, with the change given in the response to John Reid. .............. Nick Maclaren wrote No, for the following reasons: Not all objections in previous responses have been addressed (see N2045 and the documents it points to). We do not know if it is possible to specify a well-defined consistency model for either events or collectives when called from within functions. We do not know if it is possible to specify the semantics of a complete program if an image fails. We do not know if it is possible to specify a consistency model for the atomic operations that can be implemented with reasonable efficiency without hardware or operating system assistance. We know that there are differing views of the intent of all of those features, and it is therefore vanishingly unlikely that progress on integrating this TS into the main standard will be fast. It is almost certain that, if we proceed according to the schedule, the above aspects will differ between processors in ways that will make it very hard to write portable, or even reliable, programs. I would change my vote to abstain if this TS were not integrated into the next version of the standard. Response A start has been made on a consistency model, see J3/15-139. We hope that an active discussion of this on the coarray discussion e-mail list will lead to proposals. ............................ John Reid wrote At the Feb. meeting of J3, we did not complete the changes needed for when an image fails while executing a CRITICAL construct. I suggest these edits to N2048. [16:5-7] Replace the sentence "In the CRITICAL ... execute the construct." by a new paragraph: "If the processor has the ability to detect that an image has failed, when an image completes execution of a CRITICAL statement that has a STAT= specifier and the previous image to have entered the construct failed while executing it, the specified variable becomes defined with the value STAT_FAILED_IMAGE from the intrinsic module ISO_FORTRAN_ENV. Otherwise, when an image completes execution of a CRITICAL statement that has a STAT=specifier, the specified variable becomes defined with the value zero. When an image completes execution of a CRITICAL statement that has an ERRMSG= specifier and assigns a nonzero value to the status variable of a STAT= specifier or would have done so if a STAT= specifier had appeared, the processor shall assign an explanatory message to the specified variable as if by intrinsic assignment." [37:4] Before "}" add 'After para 3, add a new para: "The effect of a STAT= or an ERRMSG= specifier in a CRITICAL statement is explained in 8.5.7."' [38:40] Before "}" add "the following paragraphs, then add the final paragraph of 6.3 CRITICAL construct of this Technical Specification." Response Agreed, except that the edit for 16:5-7 should say that the value of the variable in the ERRMSG= specifier is not changed if zero is or would be assigned to the STAT=variable. Change the last sentence of the edit to "When an image completes execution of a CRITICAL statement that has an ERRMSG= specifier, if it assigns a nonzero value to the status variable of a STAT= specifier or would have done so if a STAT= specifier had appeared, the processor shall assign an explanatory message to the specified variable as if by intrinsic assignment; otherwise, the value of the specified variable shall not be changed." ........... Van Snyder wrote As Malcolm pointed out during the previous ballot, use of the term "innermost" at [5:23 3.5.1] and [9:10 5.1] is nonsense. If you don't like Malcolm's words from the previous ballot, develop a term equivalent to the term "dynamically enclosed" in the Ada standard. Response See our response to Malcolm Cohen. ....... Van Snyder wrote Discussion of the CRITICAL statement is wrong. [16:5-7] Replace 6.3p2 with "If the processor detects that an image has failed during execution of a critical construct, the construct is regarded by other images as complete. "When an image executes a CRITICAL statement and the processor has detected that the previous image that entered the construct failed without completing execution of the construct, if the statement has a STAT= specifier the specified variable becomes defined with the value STAT_FAILED_IMAGE from the intrinsic module ISO_FORTRAN_ENV; if the statement has an ERRMSG= specifier the specified variable is assigned an explanatory message, as if by intrinsic assignment. If the previous image completed execution of the construct, the variable specified in the STAT= specifier becomes defined with the value zero, and the value of the variable specified in the ERRMSG= specifier is not changed." Edits to 8.5.7 are necessary as well. Discussion of the STAT= and ERRMSG= specifiers in the CRITICAL statement should refer to 8.1.5. Response We agree that work is needed on the new text for the CRITICAL construct, but the suggested replacement text is unsatisfactory because it is intended that CRITICAL constructs continue to execute on nonfailed images in the presence of failed images. We prefer the edits in the vote of John Reid. ....... Van Snyder wrote There is no definition of "equal" for type logical. 8.4.3 needs either to define it, or use "equivalent". Response We do not need a definition of "equal" for type logical. We are using an ordinary English word. There are just two values: true and false. Two logical variables are equal if they have the same value, that is, they both have the value true or both have the value false. ....... Van Snyder wrote An image index assigned by the processor needs to be required to be unique within the team. [12:15] After "positive" insert ", unique within the team," Response. Agreed. ....... Van Snyder wrote There is no compelling reason that the and entities cannot come in any order. [9:33-34 R502] R502 <> CHANGE TEAM ( \smudge \smudge ) R502x <> <> [10:10+ C504+] C504a (R501) No specifier shall appear more than once in . Response We think it is clearer with the at the end so this change should not be made. ....... Van Snyder wrote There is no compelling reason that named specifiers cannot come in any order. And why is ERRMSG= not allowed? [11:4-5 R624] R624 <> \smudge \smudge [, ] R624x <> <> [11:8+ C509+] C509a (R624) TEAM_ID and TEAM shall not both appear. C509b (R624) No specifier shall appear more than once in . Response There is no need for ERRMSG= because the only possible values of the STAT= variable are 0 and STAT_FAILED_IMAGE. Further, we think it is clearer to have STAT= kept at the end. ....... Van Snyder wrote NOTE 6.2 illustrates why standard input should be available on all images. Either the program can decide which image gets to read it, and never try to read it until that image fails and a different one is chosen, or if several images want to read it, they can do it in critical sections. Response NOTE 6.2 explains why this is not a serious problem. ....... Van Snyder wrote There is no apparent reason why the STAT argument of an atomic or collective procedure should have at least four decimal digits. The only remote clue is the "processor dependent value" described in 8.2p4 and 8.3p5. Statement specifiers to which a processor-dependent value might be assigned, for example in an ALLOCATE statement, do not require at least four digits. Equally mysterious is why the LENGTH and STATUS arguments to the GET_COMMAND, GET_COMMAND_ARGUMENT, and GET_ENVIRONMENT_VARIABLE intrinsic subroutines, and the CMDSTAT argument to the EXECUTE_COMMAND_LINE intrinsic subroutine, require at least four digits, but those are not the topic of N2048. The VALUES argument to the DATE_AND_TIME intrinsic subroutine makes sense because the year is assigned to the first element. Response We see no harm in consistently requiring that STAT arguments in the TS should have at least four decimal digits. Allowing fewer will introduce incompatibilities for existing implementations. ....... Van Snyder wrote There is no apparent reason why the OPERATOR function passed to CO_REDUCE is not allowed to have optional arguments. There is no apparent reason why the OPERATOR function passed to CO_REDUCE is not allowed to have polymorphic arguments or result. Replace the first two sentences [26:10-11] with "shall be a pure function with explicit interface and at least two scalar, nonallocatable, nonpointer arguments of the same declared and dynamic type and type parameters as A. If it has more than two arguments, all arguments after the second argument shall be optional. Its result shall have the same declared and dynamic type and type parameters as A." At [26:12], delete "The arguments and result shall not be polymorphic." Response OPERATOR will never be called FROM CO_REDUCE except with two nonpolymorphic arguments. We think it is sensible to require OPERATOR to match this. For the more general case, the user can write a function with the required properties through which the calls can be made. ....... Van Snyder wrote EVENT_QUERY should be a type-bound function, not an intrinsic function. Response Since it is an atomic subroutine, it seems best to keep it as an intrinsic. ....... Van Snyder wrote "C509x (R624) [13:8] If this is not required to be the same SYNC TEAM statement, replace "executed a" with "executed any". Otherwise, replace "executed a" with "executed the same". Response. The current wording is unambiguous and mirrors the wording for SYNC ALL in the standard. ....... Van Snyder wrote [15:18] Part of the sentence is passive voice and part is active voice. Replace "Execution of" with "Executing". Response. The current wording is clearer. ....... Van Snyder wrote [15:4] Replace the semicolon with a comma. [16:22] After "STAT_UNLOCKED" insert "in that module". [17:13] Insert "of" before "type". [18:25+9 NOTE7.5:2] Specifying "Event variables of EVENT TYPE" implies that there are event variables of other types, to which the note does not apply. Remove "of type EVENT TYPE" because [17:8] defines an event variable to be a variable of EVENT TYPE. [28:5 8.4.16] Move the first sentence "If TEAM ... current team" to the description of the TEAM argument. It has nothing to do with the result value. [29:12 8.4.18] Move the first sentence "If TEAM ... current team" to the description of the TEAM argument. It has nothing to do with the result value. [29:29 8.4.19] Move the first sentence "If TEAM ... current team" to the description of the TEAM argument. It has nothing to do with the result value. [30:5 8.4.20] Move the first sentence "If TEAM ... current team" to the description of the TEAM argument. It has nothing to do with the result value. Response. All agreed. ....... Van Snyder wrote [24:38-39 8.4.11] Delete "It shall ... current team." because it cannot be otherwise. See 8.3p1. [25:22-23 8.4.12] Delete "It shall ... current team." because it cannot be otherwise. See 8.3p1. [26:3-4 8.4.13] Delete "It shall ... current team." because it cannot be otherwise. See 8.3p1. [26:37-38 8.4.14] Delete "It shall ... current team." because it cannot be otherwise. See 8.3p1. Response. For the first three, what about the case where the type is character? In any case, it is clearer to the user to have these part of the descriptions of the subroutines. ....... Van Snyder wrote [44:8-20] Edits to Annex A are needed for the case of a processor-dependent value being assigned to a STAT argument in a reference to an atomic or collective intrinsic procedure. Response. Add edit [44:21+] Add bullet: "the value assigned to a STAT argument in a reference to an atomic or collective intrinsic procedure when there is an error condition (13.1)"