(j3.2006) 16-150

[Bill Long]

On Jan 26, 2016, at 12:58 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:

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

Similar to the problem with 16-126:

"Neither a parent nor child data transfer statement shall be asynchronous.?

ID= is only relevant for asynchronous I/O. 

Cheers,
Bill

> 
> 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."
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101