(j3.2006) 16-150

[Van Snyder]

16-150 observes that ID= is prohibited in a child data transfer
statement, and asks whether waits ought also to be prohibited.

A wait isn't a data transfer statement, so the wording would need to be
different, and rather messy.  Something like "... for the same unit as
the \cf{unit} argument of a defined input/output procedure, while the
defined input/output procedure or one invoked by it is executing...."

But what is the point of prohibiting ID= anyway?  ASYNCHRONOUS="yes"
isn't prohibited.  The only reason I can think of is that the DIO
subroutines don't have an (optional) ID argument to send the value back
through the I/O statement that got things going, and if it did, and
there were several DIO subroutine invocations in one statement, which ID
value would be reported?  The last one would be good enough because
asynchronous input/output on a single unit is defined to take place in
the same order as synchronous input/out would have done.

As far as I can tell, ID= in a child data transfer statement is
harmless, so the prohibition is just a pointless prohibition that
careful runtime-checking processors would need to check for (does
anybody check it now?).  If one wants to make use of the ID value, one
must use it within the DIO subroutine, or one called by it, or one
called by that one ..., or put the value into a global variable, perhaps
indexed by the unit number.

Is there a deeper problem?  Is it related to DIO being nonadvancing?  I
didn't see a prohibition against ID= or ASYNCHRONOUS="yes" with
ADVANCE="no".

If there's no problem, I'd rather just delete 9.6.2.9p3, with a remark
in the introduction.  Something like "Processors no longer need to check
the pointless prohibition against ID= in a child data transfer
statement."