Hi!

My program reads some ASCII-file. The formatted file is opened, but
until today I never rewound it. I just had problems with my program
and found out that re-winding the file before reading its content,
solved the problem. I don't like to have to scan through al my code
and add rewind-statements. Therefore, I would like to know if a
freshly opened file should be automatically be rewound (so that I can
defer the error to someone else ;-) ), or (like I was used to do in
PASCAL), if in principle you have to rewind freshly opened files
yourself.

Regards,


Arjan

Arjan wrote:
> Hi!
>
> My program reads some ASCII-file. The formatted file is opened, but
> until today I never rewound it. I just had problems with my program
> and found out that re-winding the file before reading its content,
> solved the problem. I don't like to have to scan through al my code
> and add rewind-statements. Therefore, I would like to know if a
> freshly opened file should be automatically be rewound (so that I can
> defer the error to someone else ;-) ), or (like I was used to do in
> PASCAL), if in principle you have to rewind freshly opened files
> yourself.

most compilers will rewind a file when opening, but i don't believe that 
this behaviour is guaranteed by the fortran standard.  if want to be 
certain, use the position specifier.  eg.

open (unit=10, file='data.txt', position='rewind')

> So, is it possible the file was already open?


The following segment of my code exhibits the behaviour explained:


   CLOSE(ScratchFile)
 40 CONTINUE
[...]
     Commando = 'grep ":d=" '//TRIM(Puff_Temp)//'/shortdump | head -2
> '//TRIM(Puff_Temp)//'/dump2 2>&1'
     CALL RunMyCommand(Commando,CrashOnError,DoSilent)
     OPEN(ScratchFile,FILE=TRIM(Puff_Temp)//'/dump2',FORM='FORMATTED')
     REWIND(ScratchFile) ! <------- WITHOUT THIS STATEMENT, THE FIRST
LINE IN THE FILE IS SKIPPED!
     READ(ScratchFile,'(A)') ALine
     IF (DebugLevel.GT.1) WRITE(*,'(A)') 'ALine1 = "'//
TRIM(ALine)//'"'
     READ(ScratchFile,'(A)') ALine
     IF (DebugLevel.GT.1) WRITE(*,'(A)') 'ALine2 = "'//
TRIM(ALine)//'"'
     CLOSE(ScratchFile)


The line [...] represents a bunch of (to my opinion) irrelevant code
lines. As you can see, file handle "ScratchFile" (=17) is handed back
to the system, before I use it again to read file "dump2". Routine
"runmycommand" uses SYSTEM() to make the actual call.

Unfortunately, the write-statement including "Aline1=" prints the
second line if I don't rewind. Adding a READ-statement after the
system call, in order to allow the system to finish potentially
unfinished business from RunMyCommand, made no change.

Suggestions?

Regards,


Arjan

Les Neilson wrote:
>
> "Arjan" <arjan.van.dijk@rivm.nl> wrote in message
> news:6bd0daf1-c105-4e40-aee7-a67bda2d7938@k24g2000yqb.googlegroups.com...
>> Hi!
>>
>> My program reads some ASCII-file. The formatted file is opened, but
>> until today I never rewound it. I just had problems with my program
>> and found out that re-winding the file before reading its content,
>> solved the problem. I don't like to have to scan through al my code
>> and add rewind-statements. Therefore, I would like to know if a
>> freshly opened file should be automatically be rewound (so that I can
>> defer the error to someone else ;-) ), or (like I was used to do in
>> PASCAL), if in principle you have to rewind freshly opened files
>> yourself.
>>
>> Regards,
>>
>>
>> Arjan
>
> "If an OPEN statement is executed for a unit that already exists, the
> following occurs:
> If FILE is not specified, or FILE specifies the same file name that
> appeared in a previous OPEN statement, the current file remains connected.
> If the file names are the same, the values for the BLANK,
> CARRIAGECONTROL, CONVERT, DELIM, DISPOSE, ERR, IOSTAT, and PAD
> specifiers can be changed. Other OPEN specifier values cannot be
> changed, and * the file position is unaffected *" (emphasis mine)
>
> So, is it possible the file was already open?

this sounds possible - try using the opened specifier in an INQUIRE.

"Arjan" <arjan.van.dijk@rivm.nl> wrote in message 
news:6bd0daf1-c105-4e40-aee7-a67bda2d7938@k24g2000yqb.googlegroups.com...
> Hi!
>
> My program reads some ASCII-file. The formatted file is opened, but
> until today I never rewound it. I just had problems with my program
> and found out that re-winding the file before reading its content,
> solved the problem. I don't like to have to scan through al my code
> and add rewind-statements. Therefore, I would like to know if a
> freshly opened file should be automatically be rewound (so that I can
> defer the error to someone else ;-) ), or (like I was used to do in
> PASCAL), if in principle you have to rewind freshly opened files
> yourself.
>
> Regards,
>
>
> Arjan

"If an OPEN statement is executed for a unit that already exists, the 
following occurs:
If FILE is not specified, or FILE specifies the same file name that appeared 
in a previous OPEN statement, the current file remains connected.
If the file names are the same, the values for the BLANK, CARRIAGECONTROL, 
CONVERT, DELIM, DISPOSE, ERR, IOSTAT, and PAD specifiers can be changed. 
Other OPEN specifier values cannot be changed, and    * the file position is 
unaffected *"    (emphasis mine)

So, is it possible the file was already open?

Les

Arjan wrote:
> Hi!
>
> My program reads some ASCII-file. The formatted file is opened, but
> until today I never rewound it. I just had problems with my program
> and found out that re-winding the file before reading its content,
> solved the problem. I don't like to have to scan through al my code
> and add rewind-statements. Therefore, I would like to know if a
> freshly opened file should be automatically be rewound (so that I can
> defer the error to someone else ;-) ), or (like I was used to do in
> PASCAL), if in principle you have to rewind freshly opened files
> yourself.

which compiler are you using? (i seem to remember that a compiler on 
linux didn't automatically rewind opened files - maybe it was pathscale?).

> which compiler are you using? (i seem to remember that a compiler on
> linux didn't automatically rewind opened files - maybe it was pathscale?).


I tried both gfortran and g95 on a virtual linux machine (one that I
had not used before...).
I'll check the INQUIRE suggestion!

A.

Arjan wrote:

>>So, is it possible the file was already open?
....

> The following segment of my code exhibits the behaviour explained:
> 
> 
>    CLOSE(ScratchFile)
>  40 CONTINUE
> [...]

....
>      OPEN(ScratchFile,FILE=TRIM(Puff_Temp)//'/dump2',FORM='FORMATTED')
....


> Unfortunately, the write-statement including "Aline1=" prints the
> second line if I don't rewind....



   OPEN(ScratchFile,FILE=TRIM(Puff_Temp)//'/dump2',FORM='FORMATTED',
STATUS='REPLACE')

By default STATUS = 'UNKNOWN' so if you ever have run a debugging 
session or for other reason already created the file and didn't delete 
it, there may well have been a previous copy on the disk.

The default for the POSITION specifier is 'ASIS' so when combined w/ the 
above, that could easily be the expected behavior.

You could use the POSITION='REWIND', too, but w/ STATUS='REPLACE' it 
would be superflous.

Check the documentation or a Fortran text for more details on OPEN and 
the various defaults of the values of the specifiers no explicitly provided.

--

"Arjan" <arjan.van.dijk@rivm.nl> wrote in message 
news:4a7dd368-5552-475a-a703-ac0d08170cd6@x3g2000yqj.googlegroups.com...
|> So, is it possible the file was already open?
|
|
| The following segment of my code exhibits the behaviour explained:
|
|
|   CLOSE(ScratchFile)
| 40 CONTINUE

What brances to this statement?
Is the file already open?
Should the CLOSE (ScratchFile) statement come here?

| [...]
|     Commando = 'grep ":d=" '//TRIM(Puff_Temp)//'/shortdump | head -2
| > '//TRIM(Puff_Temp)//'/dump2 2>&1'
|     CALL RunMyCommand(Commando,CrashOnError,DoSilent)
|     OPEN(ScratchFile,FILE=TRIM(Puff_Temp)//'/dump2',FORM='FORMATTED')
|     REWIND(ScratchFile) ! <------- WITHOUT THIS STATEMENT, THE FIRST
| LINE IN THE FILE IS SKIPPED!
|     READ(ScratchFile,'(A)') ALine
|     IF (DebugLevel.GT.1) WRITE(*,'(A)') 'ALine1 = "'//
| TRIM(ALine)//'"'
|     READ(ScratchFile,'(A)') ALine
|     IF (DebugLevel.GT.1) WRITE(*,'(A)') 'ALine2 = "'//
| TRIM(ALine)//'"'
|     CLOSE(ScratchFile) 

Arjan wrote:

>>which compiler are you using? (i seem to remember that a compiler on
>>linux didn't automatically rewind opened files - maybe it was pathscale?).
>>
> 
> 
> I tried both gfortran and g95 on a virtual linux machine (one that I
> had not used before...).
> I'll check the INQUIRE suggestion!


See my response just posted...

In short, what you're missing is the proper STATUS specifier in the OPEN

--

> this sounds possible - try using the opened specifier in an INQUIRE.

I used INQUIRE and found that the file is already open before the
system call! The bug is caused by the second line in my code segment:
the statement with label 40. This is the location to jump to in case
of a read failure on file "dump2" before the given segment. In such a
case, the file is not closed. I had the order of the continue-
statement and the close statement interchanged...

Thanks for helping me out!

Arjan

Arjan <arjan.van.dijk@rivm.nl> wrote:
> 
> I used INQUIRE and found that the file is already open before the
> system call! The bug is caused by the second line in my code segment:
> the statement with label 40. This is the location to jump to in case
> of a read failure on file "dump2" before the given segment. In such a
> case, the file is not closed. I had the order of the continue-
> statement and the close statement interchanged...

But notice that even for a file that is not already open the standard
does not guarantee that the file will automatically start out rewound
unless you either specify that with the POSITION specifier or rewind the
file yourself after the open.

If you have not been in the habit of doing one or the other, then your
programs are buggy. That's a bug that might hide for a long time because
I think almost all current compilers open almost all files in a rewound
position anyway. But the standard does not specify that and there
certainly have been exceptions.

It sounds like that might not have been your problem in this particular
case, but you should be aware that it is also an issue.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

> If you have not been in the habit of doing one or the other, then your
> programs are buggy. That's a bug that might hide for a long time because
> I think almost all current compilers open almost all files in a rewound
> position anyway. But the standard does not specify that and there
> certainly have been exceptions.
>
> It sounds like that might not have been your problem in this particular
> case, but you should be aware that it is also an issue.


Agree! I immediatelly modified all of my code accordingly!
I was lucky that I had coded most I/O via dedicated, generic routines,
collected in separate modules...

A.

In article <1k2w8rq.sj34y4slm34cN%nospam@see.signature>,
Richard Maine <nospam@see.signature> wrote:
>
>But notice that even for a file that is not already open the standard
>does not guarantee that the file will automatically start out rewound
>unless you either specify that with the POSITION specifier or rewind the
>file yourself after the open.

The most widespread compiler that gratuitously started reading
files at the end was f2c, which I had hoped was dead and buried.
It did it deliberately, to point out a defect of the standard.

>If you have not been in the habit of doing one or the other, then your
>programs are buggy. That's a bug that might hide for a long time because
>I think almost all current compilers open almost all files in a rewound
>position anyway. But the standard does not specify that and there
>certainly have been exceptions.

I agree with Stu Feldman that this was a bug in the standard and
should have been fixed.  It could not simply have been defined to
be the start because of various system facilities that force the
position elsewhere, but simply leaving it undefined was insane.
Modern versions of the standard are better, but it's still a mess.

And, no, requiring POSITION isn't a solution.

Don't get me started on the much worse mess that C and C++ make
of this area :-(


Regards,
Nick Maclaren.

In article <itb0l5$koa$1@online.de>,
Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de> wrote:
>In article <1k2w8rq.sj34y4slm34cN%nospam@see.signature>,
>nospam@see.signature (Richard Maine) writes: 
>
>> But notice that even for a file that is not already open the standard
>> does not guarantee that the file will automatically start out rewound
>> unless you either specify that with the POSITION specifier or rewind the
>> file yourself after the open.
>
>Right.  In Fortran 77, only the latter was possible within the standard.

And what this thread misses is was that even that wasn't!  There 
are and always have been many files which can be read normally,
but where rewinding them causes chaos.  For example, really, but
REALLY, don't do it on a FIFO (including both pipes and sockets)
in any problem that is intended to be either reliable or portable,
let alone both.  IBM MVS had lots of such examples, too.

POSITION also gets this wrong.  Unless the program knows whether
it has an 'ordinary file' (in the Unix sense) or a stateful device
like a FIFO, it can't specify POSITION='REWIND'.  An implementation
SHOULD reject that on a FIFO that has already been part read or
written, as it is unimplementable.  And POSITION='ASIS' is an
unspecified position for existing but not connected files.

You're shafted, good and proper.


Regards,
Nick Maclaren.

In article <1k2w8rq.sj34y4slm34cN%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes: 

> But notice that even for a file that is not already open the standard
> does not guarantee that the file will automatically start out rewound
> unless you either specify that with the POSITION specifier or rewind the
> file yourself after the open.

Right.  In Fortran 77, only the latter was possible within the standard.

> If you have not been in the habit of doing one or the other, then your
> programs are buggy. That's a bug that might hide for a long time because
> I think almost all current compilers open almost all files in a rewound
> position anyway. But the standard does not specify that and there
> certainly have been exceptions.

Right.

A common behaviour was to automatically REWIND if the first statement 
was READ but not if the first statement was WRITE.  But of course one 
shouldn't depend on this.

In article <itb3mv$9i8$1@dont-email.me>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>Richard Maine <nospam@see.signature> wrote:
>
>> But notice that even for a file that is not already open the standard
>> does not guarantee that the file will automatically start out rewound
>> unless you either specify that with the POSITION specifier or rewind the
>> file yourself after the open.
> 
>> If you have not been in the habit of doing one or the other, then your
>> programs are buggy. That's a bug that might hide for a long time because
>> I think almost all current compilers open almost all files in a rewound
>> position anyway. But the standard does not specify that and there
>> certainly have been exceptions.
>
>Well, one exception might be OS/360 and, I believe still in MVS
>and z/OS.
>
>In the OS/360 days there was no OPEN, and positioning depends
>on the DISP field of the DD card.
>
>DISP=NEW  A new file (data set) is created.  Error (abend) if
>          it already exists.
>
>DISP=OLD  Open an existing data set, which better exist, positioned
>          at the beginning.  (Usually for reading, but write also.)
>          Abend if it doesn't exist.
>
>DISP=SHR  Open an existing data set for input, without exclusive
>          access, positioned at the beginning.  (Output might be
>          allowed, but no protection against multiple writes.)
>          Abend if it doesn't exist.
>
>DISP=MOD  If it doesn't exist, create it.  If it does, position
>          at the end for appending.

Now, try the last for PDS members, or various of the above for
unit record devices, or .... :-)


Regards,
Nick Maclaren.

Richard Maine <nospam@see.signature> wrote:

(snip)
> But notice that even for a file that is not already open the standard
> does not guarantee that the file will automatically start out rewound
> unless you either specify that with the POSITION specifier or rewind the
> file yourself after the open.
 
> If you have not been in the habit of doing one or the other, then your
> programs are buggy. That's a bug that might hide for a long time because
> I think almost all current compilers open almost all files in a rewound
> position anyway. But the standard does not specify that and there
> certainly have been exceptions.

Well, one exception might be OS/360 and, I believe still in MVS
and z/OS.

In the OS/360 days there was no OPEN, and positioning depends
on the DISP field of the DD card.

DISP=NEW  A new file (data set) is created.  Error (abend) if
          it already exists.

DISP=OLD  Open an existing data set, which better exist, positioned
          at the beginning.  (Usually for reading, but write also.)
          Abend if it doesn't exist.

DISP=SHR  Open an existing data set for input, without exclusive
          access, positioned at the beginning.  (Output might be
          allowed, but no protection against multiple writes.)
          Abend if it doesn't exist.

DISP=MOD  If it doesn't exist, create it.  If it does, position
          at the end for appending.

Note that MOD is the only one that allows for data sets that may
or may not already exist.

-- glen

On 06/15/2011 09:42 AM, nmm1@cam.ac.uk wrote:
> In article<1k2w8rq.sj34y4slm34cN%nospam@see.signature>,
> Richard Maine<nospam@see.signature>  wrote:
>>
>> But notice that even for a file that is not already open the standard
>> does not guarantee that the file will automatically start out rewound
>> unless you either specify that with the POSITION specifier or rewind the
>> file yourself after the open.
>
> The most widespread compiler that gratuitously started reading
> files at the end was f2c, which I had hoped was dead and buried.
> It did it deliberately, to point out a defect of the standard.

Among the perceived defects of the f77 standard was the lack of other 
suitable means to append to a file, while open and rewind would 
accomplish the usual task.
>

Arjan <arjan.van.dijk@rivm.nl> writes:

> My program reads some ASCII-file. The formatted file is opened, but
> until today I never rewound it. I just had problems with my program
> and found out that re-winding the file before reading its content,
> solved the problem. I don't like to have to scan through al my code
> and add rewind-statements. Therefore, I would like to know if a
> freshly opened file should be automatically be rewound (so that I can
> defer the error to someone else ;-) ), or (like I was used to do in
> PASCAL), if in principle you have to rewind freshly opened files
> yourself.

Over 25 years ago (so we're talking about the FORTRAN 77 days), I
started a new job that had a computer with a different FORTRAN
compiler from the one I had been using previously.  I tried to
compile and run a bunch of existing programs on that computer, and
they didn't work.  I eventually traced the problem to the fact that
the default file positioning for an opened sequential access file
was at the end.  All of my programs assumed that the file was
positioned at its beginning, which was the default behavior for the
compiler I had been using up until then.  That's when I learned
that file positioning was "processor dependent", and one of the
things that caused me to buy a copy of the FORTRAN 77 standard and
learn what standard FORTRAN really was.

The argument in favor of having the default position at the end
was that it was trivial to append to a file, and if you wanted it
at the beginning, it was a simple, single REWIND statement that
accomplished it.  Meanwhile, with the other choice of default,
namely at the beginning, it was trivial to read from the beginning
of the file, but if you wanted to add something to the end of it,
you needed to write a bunch of extra code to accomplish that task.
As the saying goes, Your Mileage May Vary.

But it was annoying because it broke so much of my existing code,
written in an era before I learned what was and was not standard
FORTRAN.  Of course, the file system conventions for that BSD UNIX
machine were already different from the CP/M and RSX11 machines
that I had previously used, so my code was broken anyway.

In article <itb7dd$h2$1@speranza.aioe.org>,  <tholen@antispam.ham> wrote:
>
>The argument in favor of having the default position at the end
>was that it was trivial to append to a file, and if you wanted it
>at the beginning, it was a simple, single REWIND statement that
>accomplished it.  Meanwhile, with the other choice of default,
>namely at the beginning, it was trivial to read from the beginning
>of the file, but if you wanted to add something to the end of it,
>you needed to write a bunch of extra code to accomplish that task.
>As the saying goes, Your Mileage May Vary.

The principle that the default position a newly-opened file should
be is at the beginning was established long before Fortran 77,
and even before Fortran 66.  Indeed, my reading of the latter is
that it is gratuitously perverse to assume anything else, but
it doesn't actually require it.

God alone knows where the Fortran 77 committee got their insane
file model from, but it bore little relationship to any system that
I have ever heard of - least of all IBM's - and I believe that this
aberration about positioning dated from then.  I think that I know
how it got started, but won't say in case I am blaming innocent
parties.



Regards,
Nick Maclaren.

"Richard Maine" <nospam@see.signature> wrote in message news:1k2w8rq.sj34y4slm34cN%nospam@see.signature...
| Arjan <arjan.van.dijk@rivm.nl> wrote:
| >
| > I used INQUIRE and found that the file is already open before the
| > system call! The bug is caused by the second line in my code segment:
| > the statement with label 40. This is the location to jump to in case
| > of a read failure on file "dump2" before the given segment. In such a
| > case, the file is not closed. I had the order of the continue-
| > statement and the close statement interchanged...
|
| But notice that even for a file that is not already open the standard
| does not guarantee that the file will automatically start out rewound
| unless you either specify that with the POSITION specifier or rewind the
| file yourself after the open.

Do you suppose that the standard input file, opened for keyboard input,
will be opened at the end?  Or the standard output, for the screen / printer? 

On Jun 15, 2:50=A0pm, n...@cam.ac.uk wrote:
> In article <itb7dd$h...@speranza.aioe.org>, =A0<tho...@antispam.ham> wrot=
e:
>
> >The argument in favor of having the default position at the end
> >was that it was trivial to append to a file, and if you wanted it
> >at the beginning, it was a simple, single REWIND statement that
> >accomplished it. =A0Meanwhile, with the other choice of default,
> >namely at the beginning, it was trivial to read from the beginning
> >of the file, but if you wanted to add something to the end of it,
> >you needed to write a bunch of extra code to accomplish that task.
> >As the saying goes, Your Mileage May Vary.
>
> The principle that the default position a newly-opened file should
> be is at the beginning was established long before Fortran 77,
> and even before Fortran 66. =A0Indeed, my reading of the latter is
> that it is gratuitously perverse to assume anything else, but
> it doesn't actually require it.
>
> God alone knows where the Fortran 77 committee got their insane
> file model from, but it bore little relationship to any system that
> I have ever heard of - least of all IBM's - and I believe that this
> aberration about positioning dated from then. =A0I think that I know
> how it got started, but won't say in case I am blaming innocent
> parties.

Elements of Fortran's I/O model predate the FORTRAN 66 standard by
almost a decade.  The key to understanding Fortran's model of
sequential-access I/O is to think how it would work for open-reel
magnetic tape before blocking was introduced.  Recall that in the days
of open-reel tape, the initial "file position" would be established,
not by the operating system or the run-time library, but by the
operator who mounted the tape on the tape drive.  Also, there could
be multiple files on a single tape, and the operator was responsible
for positioning the tape to the correct file.

For IBM 7xx and 7xxx systems, the mapping from unit number to I/O
device was a direct map.  Units 0 through 4 were the tape drives
(not all of which were necessarily present), unit 5 was the card
reader, unit 6 was the line printer, and unit 7 was the card punch.
One of the "advanced" features of the tape drives was that the unit
numbers were "logical."  The unit number of a drive was determined
by a device shaped like a cylinder.  Instead of swapping the tapes
in two drives, the operator could swap their drive numbers.

Bob Corbett

robert.corbett@oracle.com wrote:

....


> For IBM 7xx and 7xxx systems, the mapping from unit number to I/O
> device was a direct map.  Units 0 through 4 were the tape drives
> (not all of which were necessarily present), ...


Oh, the memories... :)

The first mainframe I saw out of uni was the Philco 2000 at B&W NPGD 
with its 27 7-track drives.  It's been so long I've forgotten the 
limitations in the FORTRAN compiler on how many were allowed to be 
accessed; I remember used 13 routinely for the nuclear cross-section 
multi-group energy weighting computational code in computing the 
few-group constants.

--

<nmm1@cam.ac.uk> wrote:

> In article <itb0l5$koa$1@online.de>,
> Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de> wrote:
> >In article <1k2w8rq.sj34y4slm34cN%nospam@see.signature>,
> >nospam@see.signature (Richard Maine) writes: 
> >
> >> But notice that even for a file that is not already open the standard
> >> does not guarantee that the file will automatically start out rewound
> >> unless you either specify that with the POSITION specifier or rewind the
> >> file yourself after the open.
> >
> >Right.  In Fortran 77, only the latter was possible within the standard.
> 
> And what this thread misses is was that even that wasn't!  There 
> are and always have been many files which can be read normally,
> but where rewinding them causes chaos.  For example, really, but
> REALLY, don't do it on a FIFO (including both pipes and sockets)
> in any problem that is intended to be either reliable or portable,
> let alone both.  IBM MVS had lots of such examples, too.

If I recall correctly, the card input deck on CDC machines was a case
where rewinding would have possibly unexpected results. I seem to recall
that you could find yourself reading the control cards, or possibly the
program source code, instead of the part of the deck that was meant to
be the input data.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 6/16/2011 11:24 AM, Richard Maine wrote:
> <nmm1@cam.ac.uk>  wrote:
>
>> In article<itb0l5$koa$1@online.de>,
>> Phillip Helbig---undress to reply<helbig@astro.multiCLOTHESvax.de>  wrote:
>>> In article<1k2w8rq.sj34y4slm34cN%nospam@see.signature>,
>>> nospam@see.signature (Richard Maine) writes:
>>>
>>>> But notice that even for a file that is not already open the standard
>>>> does not guarantee that the file will automatically start out rewound
>>>> unless you either specify that with the POSITION specifier or rewind the
>>>> file yourself after the open.
>>>
>>> Right.  In Fortran 77, only the latter was possible within the standard.
>>
>> And what this thread misses is was that even that wasn't!  There
>> are and always have been many files which can be read normally,
>> but where rewinding them causes chaos.  For example, really, but
>> REALLY, don't do it on a FIFO (including both pipes and sockets)
>> in any problem that is intended to be either reliable or portable,
>> let alone both.  IBM MVS had lots of such examples, too.
>
> If I recall correctly, the card input deck on CDC machines was a case
> where rewinding would have possibly unexpected results. I seem to recall
> that you could find yourself reading the control cards, or possibly the
> program source code, instead of the part of the deck that was meant to
> be the input data.
>

Four well-dressed men sitting together at a vacation resort.
Michael Palin: Ahh.. Very passable, this, very passable.
Graham Chapman: Nothing like a good glass of Chateau de Chassilier wine, 
ay Gessiah?
Terry Gilliam: You're right there Obediah.
Eric Idle: Who'd a thought thirty years ago we'd all be sittin' here 
drinking Chateau de Chassilier wine?
MP: Aye. In them days, we'd a' been glad to have the price of a cup o' tea.
GC: A cup ' COLD tea.
EI: Without milk or sugar.
TG: OR tea!
MP: In a filthy, cracked cup.
EI: We never used to have a cup. We used to have to drink out of a 
rolled up newspaper.
GC: The best WE could manage was to suck on a piece of damp cloth.
TG: But you know, we were happy in those days, though we were poor.
MP: Aye. BECAUSE we were poor. My old Dad used to say to me, "Money 
doesn't buy you happiness."
EI: 'E was right. I was happier then and I had NOTHIN'. We used to live 
in this tiiiny old house, with greaaaaat big holes in the roof.
GC: House? You were lucky to have a HOUSE! We used to live in one room, 
all hundred and twenty-six of us, no furniture. Half the floor was 
missing; we were all huddled together in one corner for fear of FALLING!
TG: You were lucky to have a ROOM! *We* used to have to live in a corridor!
MP: Ohhhh we used to DREAM of livin' in a corridor! Woulda' been a 
palace to us. We used to live in an old water tank on a rubbish tip. We 
got woken up every morning by having a load of rotting fish dumped all 
over us! House!? Hmph.
EI: Well when I say "house" it was only a hole in the ground covered by 
a piece of tarpaulin, but it was a house to US.
GC: We were evicted from *our* hole in the ground; we had to go and live 
in a lake!
TG: You were lucky to have a LAKE! There were a hundred and sixty of us 
living in a small shoebox in the middle of the road.
MP: Cardboard box?
TG: Aye.
MP: You were lucky. We lived for three months in a brown paper bag in a 
septic tank. We used to have to get up at six o'clock in the morning, 
clean the bag, eat a crust of stale bread, go to work down mill for 
fourteen hours a day week in-week out. When we got home, out Dad would 
thrash us to sleep with his belt!
GC: Luxury. We used to have to get out of the lake at three o'clock in 
the morning, clean the lake, eat a handful of hot gravel, go to work at 
the mill every day for tuppence a month, come home, and Dad would beat 
us around the head and neck with a broken bottle, if we were LUCKY!
TG: Well we had it tough. We used to have to get up out of the shoebox 
at twelve o'clock at night, and LICK the road clean with our tongues. We 
had half a handful of freezing cold gravel, worked twenty-four hours a 
day at the mill for fourpence every six years, and when we got home, our 
Dad would slice us in two with a bread knife.
EI: Right. I had to get up in the morning at ten o'clock at night, half 
an hour before I went to bed, (pause for laughter), eat a lump of cold 
poison, work twenty-nine hours a day down mill, and pay mill owner for 
permission to come to work, and when we got home, our Dad would kill us, 
and dance about on our graves singing "Hallelujah."
MP: But you try and tell the young people today that... and they won't 
believe ya'.
ALL: Nope, nope..

On 6/15/2011 8:02 AM, Richard Maine wrote:
> Arjan<arjan.van.dijk@rivm.nl>  wrote:
>>
>> I used INQUIRE and found that the file is already open before the
>> system call! The bug is caused by the second line in my code segment:
>> the statement with label 40. This is the location to jump to in case
>> of a read failure on file "dump2" before the given segment. In such a
>> case, the file is not closed. I had the order of the continue-
>> statement and the close statement interchanged...
>
> But notice that even for a file that is not already open the standard
> does not guarantee that the file will automatically start out rewound
> unless you either specify that with the POSITION specifier or rewind the
> file yourself after the open.
>
> If you have not been in the habit of doing one or the other, then your
> programs are buggy. That's a bug that might hide for a long time because
> I think almost all current compilers open almost all files in a rewound
> position anyway. But the standard does not specify that and there
> certainly have been exceptions.
>
> It sounds like that might not have been your problem in this particular
> case, but you should be aware that it is also an issue.
>

Years ago I got burned by a compiler (on the Elxsi as I recall) that 
assumed files were positioned at the EOF when opened.  Took me several 
days to sort out why my programs that I was porting over from a CDC no 
longer ran correctly.

baf <baf@nowhere.net> wrote:

> Years ago I got burned by a compiler (on the Elxsi as I recall) that 
> assumed files were positioned at the EOF when opened.  Took me several
> days to sort out why my programs that I was porting over from a CDC no
> longer ran correctly.

I don't think I recall the Elxsi acting like that. But I'll grant that I
could have forgotten. Bob already posted to this thread once. I'm sure
he would know and I'd trust what he says a lot more than I'd trust my
memory on the point.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

In article <f92ea93b-5403-4a95-8923-071e83d8c408@dq9g2000vbb.googlegroups.com>,
 <robert.corbett@oracle.com> wrote:
>>
>> God alone knows where the Fortran 77 committee got their insane
>> file model from, but it bore little relationship to any system that
>> I have ever heard of - least of all IBM's - and I believe that this
>> aberration about positioning dated from then. =A0I think that I know
>> how it got started, but won't say in case I am blaming innocent
>> parties.
>
>Elements of Fortran's I/O model predate the FORTRAN 66 standard by
>almost a decade.

Sorry, but that's irrelevant.  I said the file model and I meant
the file model - introduced in Fortran 77, not Fortran II.  I knew
that it was insane when I first saw it, and a third of a century
of experience hasn't changed my view one iota.

Fortran's basic I/O model wasn't insane when it was invented, but
the passage of time has shown that it wasn't a good direction.
But language-defined I/O was just being invented, and prescience
is a rare skill.  Fortran 90 and 2003 have improved some aspects,
many more could be improved, but others are insoluble without
providing a new, alternative mechanism.

>The key to understanding Fortran's model of
>sequential-access I/O is to think how it would work for open-reel
>magnetic tape before blocking was introduced.  Recall that in the days
>of open-reel tape, the initial "file position" would be established,
>not by the operating system or the run-time library, but by the
>operator who mounted the tape on the tape drive.  Also, there could
>be multiple files on a single tape, and the operator was responsible
>for positioning the tape to the correct file.

Er, I do go back to those days, and earlier, you know :-)  The
file model doesn't make any more sense on that than on anything
else.  I was closely involved with IBM's attempt to make sense of
it for MVS, incidentally, and can assure you that implementing it
for open-reel tapes under both MVS and Unices is diabolically
difficult.  Which is why so many vendors get it wrong :-(

That and other issues are why the standard cannot simply state
that the initial position is at the start, but making a mess of
that was simply a wording matter.  The real insanities were to
do with STATUS, the lack of ACTION and the (continuing) lack of
an initial direction.  Don't get me started on how they conflict
with open-reel tapes :-(


Regards,
Nick Maclaren.

"Gib Bogle" <g.bogle@auckland.ac.nz> wrote in message 
news:itbu76$1kg$1@speranza.aioe.org...
> On 6/16/2011 11:24 AM, Richard Maine wrote:
>> <nmm1@cam.ac.uk>  wrote:
>>
>>> In article<itb0l5$koa$1@online.de>,
>>> Phillip Helbig---undress to reply<helbig@astro.multiCLOTHESvax.de> 
>>> wrote:
>>>> In article<1k2w8rq.sj34y4slm34cN%nospam@see.signature>,
>>>> nospam@see.signature (Richard Maine) writes:
>>>>
>>>>> But notice that even for a file that is not already open the standard
>>>>> does not guarantee that the file will automatically start out rewound
>>>>> unless you either specify that with the POSITION specifier or rewind 
>>>>> the
>>>>> file yourself after the open.
>>>>
>>>> Right.  In Fortran 77, only the latter was possible within the 
>>>> standard.
>>>
>>> And what this thread misses is was that even that wasn't!  There
>>> are and always have been many files which can be read normally,
>>> but where rewinding them causes chaos.  For example, really, but
>>> REALLY, don't do it on a FIFO (including both pipes and sockets)
>>> in any problem that is intended to be either reliable or portable,
>>> let alone both.  IBM MVS had lots of such examples, too.
>>
>> If I recall correctly, the card input deck on CDC machines was a case
>> where rewinding would have possibly unexpected results. I seem to recall
>> that you could find yourself reading the control cards, or possibly the
>> program source code, instead of the part of the deck that was meant to
>> be the input data.
>>
>
> Four well-dressed men sitting together at a vacation resort.
> Michael Palin: Ahh.. Very passable, this, very passable.
> Graham Chapman: Nothing like a good glass of Chateau de Chassilier wine, 
> ay Gessiah?
> Terry Gilliam: You're right there Obediah.
> Eric Idle: Who'd a thought thirty years ago we'd all be sittin' here 
> drinking Chateau de Chassilier wine?
> MP: Aye. In them days, we'd a' been glad to have the price of a cup o' 
> tea.
> GC: A cup ' COLD tea.
> EI: Without milk or sugar.
> TG: OR tea!
> MP: In a filthy, cracked cup.
> EI: We never used to have a cup. We used to have to drink out of a rolled 
> up newspaper.
> GC: The best WE could manage was to suck on a piece of damp cloth.
> TG: But you know, we were happy in those days, though we were poor.
> MP: Aye. BECAUSE we were poor. My old Dad used to say to me, "Money 
> doesn't buy you happiness."
> EI: 'E was right. I was happier then and I had NOTHIN'. We used to live in 
> this tiiiny old house, with greaaaaat big holes in the roof.
> GC: House? You were lucky to have a HOUSE! We used to live in one room, 
> all hundred and twenty-six of us, no furniture. Half the floor was 
> missing; we were all huddled together in one corner for fear of FALLING!
> TG: You were lucky to have a ROOM! *We* used to have to live in a 
> corridor!
> MP: Ohhhh we used to DREAM of livin' in a corridor! Woulda' been a palace 
> to us. We used to live in an old water tank on a rubbish tip. We got woken 
> up every morning by having a load of rotting fish dumped all over us! 
> House!? Hmph.
> EI: Well when I say "house" it was only a hole in the ground covered by a 
> piece of tarpaulin, but it was a house to US.
> GC: We were evicted from *our* hole in the ground; we had to go and live 
> in a lake!
> TG: You were lucky to have a LAKE! There were a hundred and sixty of us 
> living in a small shoebox in the middle of the road.
> MP: Cardboard box?
> TG: Aye.
> MP: You were lucky. We lived for three months in a brown paper bag in a 
> septic tank. We used to have to get up at six o'clock in the morning, 
> clean the bag, eat a crust of stale bread, go to work down mill for 
> fourteen hours a day week in-week out. When we got home, out Dad would 
> thrash us to sleep with his belt!
> GC: Luxury. We used to have to get out of the lake at three o'clock in the 
> morning, clean the lake, eat a handful of hot gravel, go to work at the 
> mill every day for tuppence a month, come home, and Dad would beat us 
> around the head and neck with a broken bottle, if we were LUCKY!
> TG: Well we had it tough. We used to have to get up out of the shoebox at 
> twelve o'clock at night, and LICK the road clean with our tongues. We had 
> half a handful of freezing cold gravel, worked twenty-four hours a day at 
> the mill for fourpence every six years, and when we got home, our Dad 
> would slice us in two with a bread knife.
> EI: Right. I had to get up in the morning at ten o'clock at night, half an 
> hour before I went to bed, (pause for laughter), eat a lump of cold 
> poison, work twenty-nine hours a day down mill, and pay mill owner for 
> permission to come to work, and when we got home, our Dad would kill us, 
> and dance about on our graves singing "Hallelujah."
> MP: But you try and tell the young people today that... and they won't 
> believe ya'.
> ALL: Nope, nope..


Ah those were the days.
We were so poor we thought knives and forks were jewelry.  (with thanks to 
Les Dawson)

Les 

On 6/15/11 6:24 PM, Richard Maine wrote:
> <nmm1@cam.ac.uk>  wrote:
>
>> In article<itb0l5$koa$1@online.de>,
>> Phillip Helbig---undress to reply<helbig@astro.multiCLOTHESvax.de>  wrote:
>>> In article<1k2w8rq.sj34y4slm34cN%nospam@see.signature>,
>>> nospam@see.signature (Richard Maine) writes:
>>>
>>>> But notice that even for a file that is not already open the standard
>>>> does not guarantee that the file will automatically start out rewound
>>>> unless you either specify that with the POSITION specifier or rewind the
>>>> file yourself after the open.
>>>
>>> Right.  In Fortran 77, only the latter was possible within the standard.
>>
>> And what this thread misses is was that even that wasn't!  There
>> are and always have been many files which can be read normally,
>> but where rewinding them causes chaos.  For example, really, but
>> REALLY, don't do it on a FIFO (including both pipes and sockets)
>> in any problem that is intended to be either reliable or portable,
>> let alone both.  IBM MVS had lots of such examples, too.
>
> If I recall correctly, the card input deck on CDC machines was a case
> where rewinding would have possibly unexpected results. I seem to recall
> that you could find yourself reading the control cards, or possibly the
> program source code, instead of the part of the deck that was meant to
> be the input data.
>
$IN was special cased and a rewind (or series of backspaces) would 
position the file after the control cards (and their separator card). 
Normally that would be at the start of the source code.  I guess the 
theory was that the compiled program could check its input source to see 
if it was compiled correctly?

Dick Hendrickson

Dick Hendrickson <dick.hendrickson@att.net> schrieb:

> $IN was special cased and a rewind (or series of backspaces) would 
> position the file after the control cards (and their separator card). 
> Normally that would be at the start of the source code.  I guess the 
> theory was that the compiled program could check its input source to see 
> if it was compiled correctly?

Can a program determine if it was compiled correctly?  That question
could have interesting implications for the halting problem :-)

On Jun 15, 11:00=A0pm, nos...@see.signature (Richard Maine) wrote:
> baf <b...@nowhere.net> wrote:
> > Years ago I got burned by a compiler (on the Elxsi as I recall) that
> > assumed files were positioned at the EOF when opened. =A0Took me severa=
l
> > days to sort out why my programs that I was porting over from a CDC no
> > longer ran correctly.
>
> I don't think I recall the Elxsi acting like that. But I'll grant that I
> could have forgotten. Bob already posted to this thread once. I'm sure
> he would know and I'd trust what he says a lot more than I'd trust my
> memory on the point.

Elxsi's two UNIX implementations worked that way when I joined the
company.  They did not work that way long after I began working on
Elxsi's UNIX implementations.  The UNIX implementations were ports
of the AT&T UNIX and BSD UNIX implementations.

Bob Corbett

<robert.corbett@oracle.com> wrote:

> On Jun 15, 11:00 pm, nos...@see.signature (Richard Maine) wrote:
> > baf <b...@nowhere.net> wrote:
> > > Years ago I got burned by a compiler (on the Elxsi as I recall) that
> > > assumed files were positioned at the EOF when opened.  Took me several
> > > days to sort out why my programs that I was porting over from a CDC no
> > > longer ran correctly.
> >
> > I don't think I recall the Elxsi acting like that. But I'll grant that I
> > could have forgotten. Bob already posted to this thread once. I'm sure
> > he would know and I'd trust what he says a lot more than I'd trust my
> > memory on the point.
> 
> Elxsi's two UNIX implementations worked that way when I joined the
> company.  They did not work that way long after I began working on
> Elxsi's UNIX implementations.  The UNIX implementations were ports
> of the AT&T UNIX and BSD UNIX implementations.

Ah. Makes sense. I was thinking of the compiler under Embos.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

In article <127f27ae-8c1c-4c42-b704-1557ba78a4ce@z37g2000vbl.googlegroups.com>,
 <robert.corbett@oracle.com> wrote:
>On Jun 15, 11:00=A0pm, nos...@see.signature (Richard Maine) wrote:
>> baf <b...@nowhere.net> wrote:
>> > Years ago I got burned by a compiler (on the Elxsi as I recall) that
>> > assumed files were positioned at the EOF when opened. =A0Took me severa=
>l
>> > days to sort out why my programs that I was porting over from a CDC no
>> > longer ran correctly.
>>
>> I don't think I recall the Elxsi acting like that. But I'll grant that I
>> could have forgotten. Bob already posted to this thread once. I'm sure
>> he would know and I'd trust what he says a lot more than I'd trust my
>> memory on the point.
>
>Elxsi's two UNIX implementations worked that way when I joined the
>company.  They did not work that way long after I began working on
>Elxsi's UNIX implementations.  The UNIX implementations were ports
>of the AT&T UNIX and BSD UNIX implementations.

If I recall, those were precisely the two systems that started the
lunacy.  I certainly can't remember any Fortran system before them
that did, and there was already a LOT of history!


Regards,
Nick Maclaren.