end of file before real end

end of file before real end

Hello. I have recently started using Visual Fortran, after having programmed in Fortran on VAXes for over 20 years.

I am in the process of taking old data sets that were originally on 9 track tapes, then transferred to optical disks on the VAX. These data sets (actually, only one for now) have now been ftped to a laptop running Windows 98. My goal is to be able to perform the same type of analysis I was previously doing on the VAX.

So far, I have discovered that probably in the ftp process some extra characters were inserted into the data set, but I am able to program around that by doing a simple character read of the data. In fact, my program seems to be running correctly (YAY!) except for one thing. I know that where the Visual Fortran program is finding end of file is not the true end of file. The data should go to about 380 sec and it stops at 361 seconds. Also, when I first open the file to read, I do an inquire and it tells me there should be 132,422 blocks (of 512 bytes) but prgram execution ends at 131,881 blocks.

I have been trying to figure out if there is some way to override or force it to read beyond end of file. I would appreciate any help anyone can give me.


15 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

What does Windows think the actual size of the file is in bytes? Does that match what you think the length is? CVF considers the EOF to be where Windows says it is.


Retired 12/31/2016

Hi. Windows lists the file size as 66,211 KB, which if I multiply that number by 2, is the value being returned by the inquire statement.


Dear Steve,

I received notification that you had posted a reply to my message (I have a watch set for this topic), but I have yet to see your reply show up on the forum.

However, to answer your questions:

1) I mispoke, the file size is not coming from the inquire statement, but rather from a small subroutine given me by a friend that gets file properties.

2) When I right click on the file and get properties, it tells me that the size is 67,799,642 bytes, with 67,801,088 used.

3) The number of records supposed to be in the file, as told to me from the subroutine mentioned above, is 132,421, with a size of 512 bytes.

However, as I just posted in reply to James, there is definitely something else going on, and it may just be a bug in my program, and not something more complex.

Thanks so much for you help!


I had started to reply, but cancelled when I realized that what I had to say wasn't applicable.

What I don't see in here is how the file is opened - in particular, what the RECORDTYPE is.

My calculator tells me that 132,421 records of 512 bytes each should be 67,799,552 bytes, but you say that Windows reports the size as 67,799,642, a difference of 90 bytes. Assuming these are fixed-length records, the sizes should match exactly. I'm left to conclude that the file did not transfer properly. (though I note that the Windows size is larger!)

You may want to put the file in a ZIP archive on the VMS system, then copy the ZIP file to the PC and expand it there, to see if anything changes.


Retired 12/31/2016

Dear Steve,

This is the open statement used:


The 90 byte discrepancy is not really a problem. When I first started working on this task, I was unable to read the data set. A friend had written a "VMS dumpfile" simulation program to use on his laptop, and gave it to me to see if I could figure out what exactly was happening with the data set in the transfer process. I found that I was able to read the data set if I read it in 512 bytes at a time into a character buffer. This totally ignores the original tape blocks and record lengths, because they were unrecognizable to VF, despite my trying many combinations of settings and keywords.

I have to do a crude byte by byte scan of the data as it is read in, and convert it with internal reads to get what I need, but it does work. However, since I am reading in 512 bytes at a time, I expected that I would lose some small number of bytes at the end of the file due to ignoring the original blocking. The 90 bytes is not enough to explain the time discrepancy, but my investigation continues - something else might be going on with the data.

I will look into the zip option you suggest and see if that changes anything.



I read the entire thread but I didn't see your OPEN statement, so I don't know whether the data are binary or text, (formatted or unformatted). Also, you mention records, but is ACCESS="SEQUENTIAL" or "DIRECT"?

I'm asking that because CR/LF terminators can be an issue in direct-access to ASCII files; you should count them in in RECL. Also, I don't know how VAX terminates records.
If there's CR/LF and the file is ASCII and ACCESS="DIRECT" you should put RECL=512+2.
Numbers you mention (131,881) suspiciosly differ by about 0,4% (=2/512, i.e. 2 bytes per record) from expected (132,422). Are you sure you're reading totally correct data? If my suspicion is on the track,
you should read data gradually shifted by a byte or two.

Even if it's not CR/LF issue, I'd carefully examine VAX file format, which may contain additional record tags/hints.


Dear Jugoslav,

I pasted the open statement I am using into a reply I just posted. When reading the data on the VAX, it was sequential access.

There definitely was a problem with reading the data set after transfer, which my friend described as the file being interpreted with UNIX record tags after being transferred to the laptop. Yes indeed, there is a gradual shifting of the data, due to the different record tagging, and that is part of the reason I am reading the data in as 512 bytes sections, and then scanning the data looking for the UNIX tags.

I tried using RECL, but even with numerous combinations of keywords, settings, etc, I was not able to get the program to read in anything recognizable, so that is why I resorted to my current technique.

However, at this point I am starting to think that the file is being read correctly, and there is some other problem in my program, as was suggested by James.

Thanks for your suggestions.


Patti, july 14 I first read this discussion. Still problems ? Then notice that VAX RMS (edit)files mostly are in the list-format: a 2 byte recordlength preceding each record, you'll see them in a filedump. In VAX-Fortran open statement you'll specify carriagecontrol='list'. You did FTP the file binary, so did you transfer these list-bytes too ? davinci

Make sure you are in binary mode when you use ftp to transfer the files. ASCII mode will screw up the end-of-record and end-of-file marks.

Hi. I did use binary mode when I did the ftp.


Write yourself a little test program, all it should do is open and read the whole file. Use the OPEN and READ statements used by your current program. Perhaps you will find that an error unrelated to end-of-file is terminating your program, or perhaps an ERR= or non-zero IOSTAT value is popping up in that particular block, which would tell you why you are terminating prior to the end-of-file.


Hi James. This may seem like a stupid question, but I am not sure how your suggestion is different than what I am already doing. The read statement I am using has an end= branch. Should I remove that from the test program?



Creating a simplified example often helps catch any logic errors and provides a small program you can post here if needed. For example (untested):

program read_file ! cvf only
integer count
character*512 buffer
do while (.true.)
  read(1, end=99) buffer
  count = count + 1
end do
99 close (1)
type *, count, ' blocks read'

Replace YOURFILENAME and tell us what the results are.


Dear James,

I took your suggestion, made a couple of modifications, and ran the program. As you suspected, there must be something else going on, since the test program read the correct number of blocks. I am now trying to figure out where in the longer program this is not working properly.

Thanks so much for your help and patience!


Leave a Comment

Please sign in to add a comment. Not a member? Join today