To:      J3                                        J3/14-113r1
From:    John Reid & Bill Long
Subject: Restrictions on assignments of team variables
Date: 2014 February 12
References: N1996, N1999, J3/14-112r2

Discussion:
~~~~~~~~~~~

The initial team is formed before program execution begins. Any other
team is formed by collective execution of a FORM TEAM statement on the
non-failed images of the current team.  Each participating image has a
local variable of type TEAM_TYPE that is defined with a value by the
FORM TEAM execution.  The collection of these values is used by the
processor to coordinate execution of team-wide actions such as CHANGE
TEAM and SYNC TEAM. Correct actions depend on using variables on each
image that have the values produced by the FORM TEAM statement for the
teams involved. The actual variables do not need to be the same as the
variables used in the FORM TEAM statement as long as the variables
that are used have the same values.

Two basic approaches are available to address this requirement.

1) Restrictive approach: Require that the variable used in a CHANGE
TEAM or SYNC TEAM statement, or in an enhanced image selector, be the
same variable that was defined in FORM TEAM, or a clone of the
variable created by argument association or GET_TEAM.  Other ways of
defining a variable of TEAM_TYPE are disallowed.

2) Liberal approach: The programmer is responsible for using variables
in CHANGE TEAM, SYNC TEAM, or an image selector that have the correct
values. The values can be assigned to new variables and pointers can
be associated with variables of TEAM_TYPE.

The liberal approach provides more flexibility in naming and allows the
same CHANGE TEAM or SYNC TEAM statement to be used by different teams
at different times during program execution. Edits are provided for
the liberal approach.

Edits for N1996:

[9:22-23] In 5.2 TEAM_TYPE, delete paragraph "A procedure
... subcomponent of type TEAM_TYPE."
{Remove restriction that was needed for C502 and C503 that are
deleted.}

[9:24-33] In 5.2 TEAM_TYPE, delete constraints C501, C502, and C503.
{Remove restriction on defining a variable of type TEAM_TYPE.}

[9:34] In 5.2 TEAM_TYPE, delete paragraph "The team variable ... shall
not be deallocated."
{Remove restriction on deallocating a variable of type TEAM_TYPE.}

[10:20] In 5.3 CHANGE TEAM, replace "or by a reference to the intrinsic
subroutine GET_TEAM (7.4.13)" with "or be the value of a team variable
for the initial team".
{GET_TEAM does not establish these values, it just assigns already
existing values to a new variable. A separate edit in 14-112r2 adds
the requirement that a compatible set of values be used.}

[10:21] In 5.3 CHANGE TEAM, replace "specified by the <team-variable>"
with "specified by the value of the <team-variable>".

[10:21] In 5.3 CHANGE TEAM, at the end of the paragraph add a new
sentence:

"The current team is not changed by a redefinition of the team
variable during execution of the CHANGE TEAM construct."
{Allow definition of the team variable inside the construct.}

[10:22-23] In 5.3 CHANGE TEAM, delete paragraph "The team variable
specified ... CHANGE TEAM construct."
{Remove restriction on defining the team variable.}

[12:10-11] In 5.6 SYNC TEAM, replace ", or by a call to the intrinsic
subroutine GET_TEAM (7.4.13)" with "or be the value of a team variable
for the intital team"
and insert a new sentence:
"The values of the <team-variable>s on the images of the team shall be
those defined by execution of the same FORM TEAM statement on the all
images of the team."
{GET_TEAM does not establish these values, it just assigns already
existing values to a new variable. Require a compatible set of values
to be used.}

[31:9-12] Delete all of 8.8 Edits to clause 12.
{No longer needed if interface requirement is removed.}