From owner-sc22wg5 Fri Aug 10 11:28:25 2001 Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id LAA86629 for ; Fri, 10 Aug 2001 11:28:24 +0200 (CEST) (envelope-from dnagle@erols.com) Received: from 66-44-55-5.s259.tnt1.lnhva.md.dialup.rcn.com ([66.44.55.5] helo=pscsws) by smtp01.mrf.mail.rcn.net with smtp (Exim 3.32 #2) id 15V8ac-0007Kk-00 for sc22wg5@dkuug.dk; Fri, 10 Aug 2001 05:28:23 -0400 From: Dan Nagle To: WG5 Mailing List Subject: Re: (SC22WG5.2175) Named Scratch Files in Fortran 2000 - Rationale Date: Fri, 10 Aug 2001 05:28:06 -0400 Organization: Purple Sage Computing Solutions, Inc. Message-ID: References: <200108091200.OAA82583@dkuug.dk> <200108100046.CAA85311@dkuug.dk> In-Reply-To: <200108100046.CAA85311@dkuug.dk> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by dkuug.dk id LAA86630 Hello, Aborting the program if a named scratch file exists when the open is executed is a bad idea, I think, as it eliminates the possibility of preallocating a named scratch file which may be important for i/o performance on some processors. Also, this means that name collisions, which are much more likely if the user is choosing names than if the i/o library is choosing names, will unnecessarily (in many cases) stop execution. I have to admit that I didn't see the line Craig references below, in 01-007r2 it's moved down to about line 9-10. -- Cheers! Dan Nagle Purple Sage Computing Solutions, Inc. On Thu, 09 Aug 2001 19:44:47 -0500, Craig Dedo wrote: >Dear WG5 Members: > From my reading of J3/97-193r1 and the current Fortran 2000 draft, it appears that J3 decided this issue on August 12, 1997. If a >program opens an existing unconnected file with STATUS="SCRATCH", that is an error, just like any other error in the OPEN statement. > > The issue of what happens if a program opens an existing file with STATUS=SCRATCH should be settled. In the edits in paper J3/97-193r1, >which passed unanimously on August 12, 1997, there is this edit: >[140:13+] Add the following text: > "If an existing file is not connected, execution of an OPEN statement that connects that file with a STATUS of SCRATCH is prohibited." > > There is similar language in the Technical Specification, although that part of the paper never was debated or voted on by J3 at its >meetings in May or August 1997. The relevant sentence from the Technical Specification is: >" It is illegal to open a scratch file with the same name as an existing file that is not open." > > Tonight I found the relevant sentence in the current edition of the Fortran 2000 draft. It is at [171:3-4], immediately before rule >R904: >"If an existing file is not connected, execution of an OPEN statement that connects that file with a STATUS of SCRATCH is not permitted." > > Issue 2 in WG5/N1454 says, in part: >"At [174:18], it is not specified what happens if STATUS='SCRATCH' and FILE=... are both specified, and the file exists." >It is not specified at [174:18] because it already has been specified at [171:7-8]. > > Is this sufficient to answer Issue 2 in WG5/N1454 or is there something else that needs to be decided? Do we need to add the text of >[171:7-8] to [174:18]? > >Dan Nagle wrote: > >> Hello, >> >> At the risk of stirring things up more than they need to be... >> >> The discussion of the rationale for named scratch files >> misses the point of the objection raised at WG5 last week. >> >> The design flaw found is that by using the status= with >> a value of scratch, the programmer can't inform the processor >> what to do regarding an existing file of the same name >> (which would have been conveyed by old, new or replace). >> >> To wit, should the processor treat an existing file >> of the same name by: >> >> 1. aborting the program, or >> 2. overwriting the file, or >> 3. using the old file, or >> 4. following a processor dependent action, or >> 5. none of the above (please specify your preferred action). >> >> We (j3) need to answer this question in order to retain >> named scratch files, IMHO. >> >> At least, this is my understanding of the discussion.