From owner-sc22wg5 Thu Aug 9 14:00:12 2001 Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id OAA82572 for ; Thu, 9 Aug 2001 14:00:12 +0200 (CEST) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id NAA15496 for ; Thu, 9 Aug 2001 13:00:11 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id NAA29960 for SC22WG5@dkuug.dk; Thu, 9 Aug 2001 13:02:22 +0100 (BST) Date: Thu, 9 Aug 2001 13:02:22 +0100 (BST) From: John Reid Message-Id: <200108091202.NAA29960@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: (SC22WG5.2169) Named Scratch Files in Fortran 2000 - Rationale MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ----- Begin Included Message ----- From: Dan Nagle X-Sequence: SC22WG5@dkuug.dk 2169 Errors-To: SC22WG5-request@dkuug.dk To: SC22WG5@dkuug.dk Subject: (SC22WG5.2169) Named Scratch Files in Fortran 2000 - Rationale Date: Thu, 09 Aug 2001 07:00:24 -0400 Organization: Purple Sage Computing Solutions, Inc. References: <200108080821.KAA77047@dkuug.dk> In-Reply-To: <200108080821.KAA77047@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 NAA82361 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. -- Cheers! Dan Nagle Purple Sage Computing Solutions, Inc. On Wed, 8 Aug 2001 09:23:42 +0100 (BST), Craig Dedo wrote: > >----- Begin Included Message ----- > >Date: Tue, 07 Aug 2001 20:04:02 -0500 >From: Craig Dedo >X-Sequence: SC22WG5@dkuug.dk 2164 >Errors-To: SC22WG5-request@dkuug.dk >Organization: Elmbrook Computer Services, Inc. >X-Mailer: Mozilla 4.72 [en] (WinNT; U) >X-Accept-Language: en >MIME-Version: 1.0 >To: WG5 Mailing List >Subject: (SC22WG5.2164) Named Scratch Files in Fortran 2000 - Rationale >Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6029FACF5E13856E37D4215D" > >This is a cryptographically signed message in MIME format. > >--------------ms6029FACF5E13856E37D4215D >Content-Type: text/plain; charset=us-ascii >Content-Transfer-Encoding: 7bit > >Dear WG5 Members: > Today I learned that at the recent meeting, WG5 asked why we >included named scratch files in Fortran 2000. According to J3/01-299 >(below), there was no knowledge of a rationale. > > I was the champion for this issue. J3 considered Named Scratch >Files at meetings 141 and 142 in May and August 1997. The relevant >papers are: > * 97-162r2 - May 15, 1997 > * 97-193r1 - August 12, 1997 >Both of these papers are on the J3 Web site. > > According to the minutes of meetings 141 and 142, these papers were >considered at their respective meetings. J3 never did debate or vote on >either the Rationale or the Technical Specification in either of these >papers. J3 did debate and vote on the edits at both meetings. At >Meeting 141, 97-162r2 was withdrawn for technical reasons. At meeting >142, paper 97-193r1 passed unanimously (edits only). > > Here is a copy of the Rationale from both papers. >[Begin Rationale] >Rationale > Currently, the Fortran standard does not allow the user to name >scratch files. Not allowing the user to name scratch files is an >unnecessary irregularity. A named scratch file would be the only kind >of named file which would be automatically deleted when the file is >closed or execution terminates. > > Allowing Fortran programmers to give names to scratch files would >have several advantages. These advantages include: >* This feature would allow the programmer to protect against >accidentally overwriting existing files. This could happen if the >processor generates a file name which is the same as the name of an >existing file. >* This feature would allow the programmer to specify a location for >the scratch file which has enough space for the scratch file's contents. > >* The programmer could look at a scratch file's contents during >execution. > > If the processor does not delete scratch files if the program >crashes, this feature would allow the programmer to do some post-mortem >analysis. >[End of Rationale] > > Please feel free to contact me if you have any questions or >concerns. > >[Begin J3/01-299] > J3/01-299 >Date: 06 August 2001 >To: J3 >From: Dan Nagle >Subject: Sj Response to a WG5 comment (named scratch files) > >One of the comments made by WG5 members at the recent London meeting >expressed a concern regarding named scratch files. The criticism >was that we hadn't thought this through very well. Fortran supports >named and unnamed files, unnamed files are made by specifying a >status of scratch. Named files are not. A specific question was >asked regarding the proper reaction of a program to a named scratch >file when the file name already exists. J3 members present were >unable to provide a good answer to this question. WG5 expressed >its desire to remove named scratch files from the draft. This >paper is a vehicle for removing named scratch files from the draft >should J3 decide to do so, or alternatively, for replying to WG5 >with our reasons why named scratch files should be kept in the draft. > >To remove named scratch files from the draft: >(Yes, I know I need to provide line numbers. >Let's see what JoR says before I do it. My pdf >version doesn't seem to have line numbers, >at least, I haven't found the switch.) > >EDITS > >(Restore the normative paragraph discussing the OPEN statement.) >[171: (paragraph after the constraints)] Add after the first sentence >"If the STATUS= specifier has the value SCRATCH, the FILE= specifier >shall not be present." > >(Restore note in discussion of STATUS=.) >[174: (after the second paragraph under STATUS=)] Add the Note >"SCRATCH shall not be specified with a named file." >[End of J3/01-299] ----- End Included Message -----