From owner-sc22wg5 Fri Aug 10 18:37:07 2001 Received: from fgusap1402.abbott.com (viper.abbott.com [130.36.44.77]) by dkuug.dk (8.9.2/8.9.2) with SMTP id SAA88576 for ; Fri, 10 Aug 2001 18:36:54 +0200 (CEST) (envelope-from Craig.Dedo@abbott.com) From: Craig.Dedo@abbott.com Received: from viper.abbott.com ([130.36.44.77]) by fgusap1402.abbott.com via smtpd (for ptah.dkuug.dk [195.215.30.66]) with SMTP; 10 Aug 2001 16:36:54 UT Received: from fgusap1402d0.abbott.com (mx1.abbott.com [207.243.27.1]) by viper.abbott.com (Switch-2.1.3/Switch-2.0.1) with SMTP id f7AGacv19353; Fri, 10 Aug 2001 11:36:39 -0500 (CDT) Received: from no.name.available by fgusap1402d0.abbott.com via smtpd (for viper.abbott.com [130.36.44.77]) with SMTP; 10 Aug 2001 16:36:22 UT Received: from abtapn55.cmis.abbott.com (localhost [127.0.0.1]) by abtmr1.abbott.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f7AGaMO24466; Fri, 10 Aug 2001 11:36:22 -0500 (CDT) Subject: Re: (SC22WG5.2177) Named Scratch Files in Fortran 2000 - Rationale To: Richard Maine , WG5 Mailing List X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Fri, 10 Aug 2001 10:13:34 -0500 X-MIMETrack: Serialize by Router on ABTAPN55/ESVR/ABBOTT(Release 5.0.5 |September 22, 2000) at 08/10/2001 11:36:21 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Dear WG5 Members: I must respectfully disagree with my esteemed colleague from NASA. IIRC, the intent at the time we debated and approved these edits was that if the program tried to open an existing file with STATUS="SCRATCH", it would generate an error condition. This is similar to the behavior of the OPEN statement with any other kind of error condition, e.g., trying to open an existing file with STATUS="OLD" and the file is not found. What happens after the error condition occurs depends on what kind of defenses the programmer put in place on that OPEN statement, according to the rule of Fortran for handling any error condition on OPEN. If IOSTAT is in the OPEN statement, the IOSTAT variable gets assigned a positive integer value. If there is an ERR=label, then the program branches to ther label specified in ERR=. The possibilities that Richard mentioned are characteristic of "processor dependent", NOT "is not permitted" (the current language). BTW, if these possibilities occur when something "is not permitted", can they also occur if some other behavior on OPEN (or any other I/O statement) "is not permmitted"? There is another situation that "is not permitted" immediately preceding the relevant sentence. From my point of view, it is clearly defined what happens if a program tries to open an existing file with STATUS="SCRATCH". It is an I/O error condition and the Fortran processor must handle it just like any other I/O error condition. Sincerely, Craig T. Dedo, VMS Consultant Dept. 30G, Building AP34-2 Abbott Diagnostics Division Abbott Laboratories, Inc. 200 Abbott Park Road Abbott Park, IL 60064-3537 Voice Phone: (847) 938-0144 Fax Phone: (847) 935-5395 E-mail: Craig.Dedo@abbott.com Richard Maine Sent by: cc: owner-sc22wg5@dkuu Subject: (SC22WG5.2177) Named g.dk Scratch Files in Fortran 2000 - Rationale 08/10/2001 09:45 Dan Nagle writes: > Aborting the program if a named scratch file exists > when the open is executed is a bad idea, I think, I think you misread the implications of the existing draft wording. Its worse than you are reading it. The existing wording doesn't say that the program aborts. Not does it say that this would be an error condition (potentially catchable via iostat). It just says that it is "prohibitted". That means that a program that does such is non-conforming and the compiler can do anything in that situation (WWIII, etc.). This leaves open quite realistic possibilities that the compiler might abort, might overwrite the existing file, might automatically choose a new name, whatever. In other words, it basically is unspecified what happens. We just wimped out and avoided that question. For a feature that has "protection against name collisions" as it's first-listed justification, this doesn't seem like very good protection. I ought to be surprised that we didn't catch this before. Probably just illustrates that we didn't really do a good job of reviewing and thinking through the details of the proposal. Myself included in the "we". -- Richard Maine | Good judgment comes from experience; maine@altair.dfrc.nasa.gov | experience comes from bad judgment. | -- Mark Twain