Home > Archive > Fortran > January 2008 > Is a temporary SCRATCH file formatted or unformatted?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Is a temporary SCRATCH file formatted or unformatted?
|
|
| hermitian 2008-01-23, 4:29 am |
| Hi, everyone:
A temporary SCRATCH file could be created by:
open(unit=10,status="scratch")
But is it a formatted or unformatted file?
Thank you!
| |
| Louis Krupp 2008-01-23, 4:29 am |
| hermitian wrote:
> Hi, everyone:
>
> A temporary SCRATCH file could be created by:
>
> open(unit=10,status="scratch")
>
> But is it a formatted or unformatted file?
By default, you get access='sequential' and form='formatted'.
Louis
| |
| Richard Maine 2008-01-23, 4:29 am |
| Louis Krupp <lkrupp@pssw.nospam.com.invalid> wrote:
> hermitian wrote:
>
> By default, you get access='sequential' and form='formatted'.
But I recommend just explicitly specifying it instead of having to know
that.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| David Flower 2008-01-23, 8:21 am |
| On Jan 23, 9:56=EF=BF=BDam, nos...@see.signature (Richard Maine) wrote:
> Louis Krupp <lkr...@pssw.nospam.com.invalid> wrote:
>
>
>
>
>
> But I recommend just explicitly specifying it instead of having to know
> that.
>
> --
> Richard Maine =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =
=EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD| Good judgement comes from experienc=
e;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD |=
=EF=BF=BD-- Mark Twain
I agree; it saves maintenance programmers having to check with the
manual.
Dave Flower
| |
| Craig Dedo 2008-01-23, 8:21 am |
| "hermitian" <iamwuxin@gmail.com> wrote in message
news:48e92aeb-90ea-42a0-a0f2-b5cfd6fea344@z17g2000hsg.googlegroups.com...
> Hi, everyone:
>
> A temporary SCRATCH file could be created by:
>
> open(unit=10,status="scratch")
>
> But is it a formatted or unformatted file?
>
> Thank you!
A scratch file can be either formatted or unformatted. The values of the
STATUS= and FORM= specifiers are completely independent of each other. All
combinations of the values of the two specifiers are legal.
Unfortunately, you cannot specify a name for a scratch file. Originally,
Fortran 2003 had named scratch files as a feature, but WG5 dropped it late in
the development of Fortran 2003. This means that the location of any scratch
files is out of the control of the programmer and is determined by the Fortran
compiler, run-time library, or operating system. Thus, a scratch file may be on
a device that is too small for the intended uses.
In many cases, it may be better practice to open a file with STATUS="NEW" or
STATUS="REPLACE" or STATUS="UNKNOWN" and the delete the file on closing. That
way, you can explicitly specify the location of the scratch file to be on a
device that is large enough for the task at hand.
--
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423
Brookfield, WI 53008-0423
Voice: (262) 783-5869
Fax: (262) 783-5928
Mobile: (414) 412-5869
E-mail: <cdedo@wi.rr.com> or <craig@ctdedo.com>
| |
| Ron Shepard 2008-01-23, 7:19 pm |
| In article <47974ce1$0$18450$4c368faf@roadrunner.com>,
"Craig Dedo" <cdedo@wi.rr.com> wrote:
> Unfortunately, you cannot specify a name for a scratch file.[...]
For almost all of my applications over the past 30 years, this has
made 'SCRATCH' files useless to me. When trying to use them, I have
filled up disks (or disk partitions) that I did not intend to use, I
have caused programs being run by other users to crash because I
exhausted shared disk space and disk quotas, and other users have
caused my correctly behaving program to crash because they exhausted
shared disk space.
Basically, every time this kind of functionality might be needed
(e.g. a temporary file that I want to be deleted at close or at the
end of the program, no matter what), I have asked myself "What were
they thinking?" about this decision. Not only does the standard
preclude me from specifying the full pathname of such files, it
stops me from being able to specify even the device or the directory
in which such files are placed.
On unix machines, you can open the file in the normal way, and then
immediately unlink it. Your program can then continue working with
the file, and upon a close or upon program termination the filespace
is returned to the file system. The problem with this is that you
cannot tell from doing an "ls" which files are open and being used
or how large such files are at any time.
Of course, many compilers do allow specifying these things as
extensions, but that makes the source code nonportable. What the
committee should have done was to specify the syntax to provide this
common and sometimes necessary functionality, but then left as many
of the details as necessary unspecified and up to the vendor to
implement. Then, at least we could have portable source code, even
if the functionality changes somewhat from compiler to compiler or
from OS to OS.
$.02 -Ron Shepard
| |
| Joseph Huber 2008-01-23, 7:19 pm |
| Ron Shepard wrote:
> In article <47974ce1$0$18450$4c368faf@roadrunner.com>,
> "Craig Dedo" <cdedo@wi.rr.com> wrote:
>
>
> For almost all of my applications over the past 30 years, this has
> made 'SCRATCH' files useless to me. When trying to use them, I have
> filled up disks (or disk partitions) that I did not intend to use, I
> have caused programs being run by other users to crash because I
> exhausted shared disk space and disk quotas, and other users have
> caused my correctly behaving program to crash because they exhausted
> shared disk space.
>
> Basically, every time this kind of functionality might be needed
> (e.g. a temporary file that I want to be deleted at close or at the
> end of the program, no matter what), I have asked myself "What were
> they thinking?" about this decision. Not only does the standard
> preclude me from specifying the full pathname of such files, it
> stops me from being able to specify even the device or the directory
> in which such files are placed.
>
> On unix machines, you can open the file in the normal way, and then
> immediately unlink it. Your program can then continue working with
> the file, and upon a close or upon program termination the filespace
> is returned to the file system. The problem with this is that you
> cannot tell from doing an "ls" which files are open and being used
> or how large such files are at any time.
>
> Of course, many compilers do allow specifying these things as
> extensions, but that makes the source code nonportable. What the
> committee should have done was to specify the syntax to provide this
> common and sometimes necessary functionality, but then left as many
> of the details as necessary unspecified and up to the vendor to
> implement. Then, at least we could have portable source code, even
> if the functionality changes somewhat from compiler to compiler or
> from OS to OS.
A more portable way would be to open the named file with the
status='KEEP', but specify status='DELETE' in the close call.
Of course this leaves the file in case ob abnormal end, but this could
be worked around by a jacket script calling the program.
--
Joseph Huber - http://www.huber-joseph.de
| |
| James Giles 2008-01-23, 7:19 pm |
| Craig Dedo wrote:
....
> Unfortunately, you cannot specify a name for a scratch file.
> Originally, Fortran 2003 had named scratch files as a feature, but
> WG5 dropped it late in the development of Fortran 2003. This means
> that the location of any scratch files is out of the control of the
> programmer and is determined by the Fortran compiler, run-time
> library, or operating system. Thus, a scratch file may be on a
> device that is too small for the intended uses.
The implementor could, of course, provide an extension. An
environment variable that tells where to put scratch files would
suit the purpose. Frankly though, I've never used scratch files
in my own code - though I've actually implemented a run-time
library to support Fortran I/O and know quite well what scratch
files do. Instead I've always followed your advice below.
Perhaps scratch files should be put on the obsolescent list?
> In many cases, it may be better practice to open a file with
> STATUS="NEW" or STATUS="REPLACE" or STATUS="UNKNOWN" and the delete
> the file on closing. That way, you can explicitly specify the
> location of the scratch file to be on a device that is large enough
> for the task at hand.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| James Giles 2008-01-23, 7:19 pm |
| Joseph Huber wrote:
....
> A more portable way would be to open the named file with the
> status='KEEP', but specify status='DELETE' in the close call.
> Of course this leaves the file in case ob abnormal end, but this could
> be worked around by a jacket script calling the program.
Actually there needs to be a systematic way to control the status
of open files when the program abnormally terminates. Perhaps
a DISPOSITION value on the OPEN statement whose value
is either 'KEEP' or 'DELETE'. This disposition would be
overridden by an explicit STATUS on a CLOSE statement.
But if the program terminates without such a CLOSE the
file is kept or not based on DISPOSITION in the OPEN.
It's important that the programmer have such control. For
published code that distributed to large user communities,
most of whom have no idea what to do with left over file
fragments if there's an abend, you want all of them deleted
by default. However, while you're writing or debugging
the code you definitely *don't* want possible clues to your
problems just disappearing. And, if the code is an in-house
production, even your end users (which might include yourself)
want evidence from those files to help in maintenence.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Richard Maine 2008-01-23, 7:19 pm |
| James Giles <jamesgiles@worldnet.att.net> wrote:
> Joseph Huber wrote:
> ...
>
> Actually there needs to be a systematic way to control the status
> of open files when the program abnormally terminates. Perhaps
> a DISPOSITION value on the OPEN statement whose value
> is either 'KEEP' or 'DELETE'. This disposition would be
> overridden by an explicit STATUS on a CLOSE statement.
> But if the program terminates without such a CLOSE the
> file is kept or not based on DISPOSITION in the OPEN.
That would make a lot more sense to me than named scratch files. By the
time you name a scratch file, you have lost pretty much all of the other
points of having a scratch file, so why bother to call it a scratch
file. Named scratch files introduce a whole host of complications in
having to describe various interactions. Ok, they aren't horribly,
horribly complicated, but they are things that need to be addressed, and
they make the proposal about an order of magnitude more complicated than
it seems at first. Fortunately, it seems pretty trivial at first, so an
order of magnitude more complicated still isn't all that bad, but it
gets bad enough that that's basically the reason that Craig's named
scratch file proposal got dropped after initially being accepted for
f2003.
It was just taking a lot of time to fill in all the holes and describe
all the interactions. There would be proposals to do so, but then those
proposals would miss parts, break other things, and otherwise be
inadequate. So eventually it got pulled.
For now, you can always do things like what Joseph describes above.
Plus, many compilers have a way of specifying where scratch files go.
Some of the interactions included things like name conflicts. What
happens if the scratch file name matches a file that already exists?
There are a set of rules for such conflicts, but they would have had to
be significantly redone to accomodate named scratch files. Some of the
attempts to redo those rules turned out to amount to incompatible
changes to the existing rules (which have some oddities in the first
place). Other attempts ended up specifying what seemed like undesireable
behavior. And some just plain failed to cover all cases.
There are extra complications because of "reopens", where you do an open
on an already open file in order to change some of its connection
properties. That's an area where the existing rules are a bit
complicated.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| Dan Nagle 2008-01-23, 7:19 pm |
| Hello,
On 2008-01-23 14:09:54 -0500, "James Giles" <jamesgiles@worldnet.att.net> said:
>
> Actually there needs to be a systematic way to control the status
> of open files when the program abnormally terminates. Perhaps
> a DISPOSITION value on the OPEN statement whose value
> is either 'KEEP' or 'DELETE'. This disposition would be
> overridden by an explicit STATUS on a CLOSE statement.
> But if the program terminates without such a CLOSE the
> file is kept or not based on DISPOSITION in the OPEN.
Something like this was proposed for f08.
It didn't have enough priority to make the final list.
--
Cheers!
Dan Nagle
| |
| Joseph Huber 2008-01-24, 4:34 am |
| James Giles wrote:
> Joseph Huber wrote:
> ...
>
> Actually there needs to be a systematic way to control the status
> of open files when the program abnormally terminates. Perhaps
> a DISPOSITION value on the OPEN statement whose value
> is either 'KEEP' or 'DELETE'. This disposition would be
> overridden by an explicit STATUS on a CLOSE statement.
> But if the program terminates without such a CLOSE the
> file is kept or not based on DISPOSITION in the OPEN.
>
Actually my proposal was only for portability, because the standard
does not provide the DISPOS(E/ITION) parameter in OPEN.
Actually I do my Fortran with a compiler having this extension,
guess which ?
--
Joseph Huber - http://www.huber-joseph.de
| |
| Dan Nagle 2008-01-24, 8:20 am |
| Hello,
On 2008-01-24 03:47:54 -0500, Joseph Huber <joseph.huber@NOSPAM.web.de> said:
<snip>
> Actually my proposal was only for portability, because the standard
> does not provide the DISPOS(E/ITION) parameter in OPEN.
If you want something like this standardized, write a public comment
for Fortran 2008 during the public comment period, and submit it
to INCITS.
If you want your proposal to succeed, do *not* specify the spelling.
Instead, say what functionality you want, and why.
That is, say "I want to be able to specify the default close status
per file on an open statement, because ..."
--
Cheers!
Dan Nagle
| |
| Joseph Huber 2008-01-24, 8:20 am |
| Dan Nagle wrote:
> On 2008-01-24 03:47:54 -0500, Joseph Huber <joseph.huber@NOSPAM.web.de>
> said:
> <snip>
>
> If you want something like this standardized, write a public comment
> for Fortran 2008 during the public comment period, and submit it
> to INCITS.
>
I do not propose to add a disposition to the OPEN statement.
My response to use STATUS='DELETE' on CLOSE was the workaround for the
question how to explicitly place or name SCRATCH files.
--
Joseph Huber - http://www.huber-joseph.de
|
|
|
|
|