Problem reading direct access file

[Horsewood__Jerry]

I have a legacy 32-bit application written in Fortran 77 and currently compiled with Intel Visual Fortran 2018. The current development operating system is Windows 10. The code has executed successfully on Windows operating systems ranging from XP through 10 as well as Windows Server 2008 RT. One of my customers is now attempting to run the code on a system running Windows Server 2012 R2 and is getting an error on a statement attempting to read the first record of a direct access file. The error message from the runtime environment reads "The handle is invalid (SetFilePointer, errno = 6, unit = 3)." Has anyone else experienced this problem or have an idea why it might be happening? Thanks for any help you can provide.

[gib]

Was the file open successful?

[Horsewood__Jerry]

Apparently so. The open statement did not raise an error. The error occurred on the first read. This is confusing since the error message reported an invalid handle, which should cause an error on the open statement as well.

[Steve_Lionel]

Is the file on the local system or is it on a network share? I have seen some cases where a network share file can be opened but some operations don't work. The mention of SetFilePointer is interesting - if I am reading the docs correctly, this is used to reset the "current position" within the file. It might be used on a REWIND or with POSITION= in an OPEN. I don't know for certain that the Intel Fortran I/O library uses this.

Would you be able to show us the actual and complete text of the error message, and perhaps identify which program statement triggered the error. I am a bit puzzled because the message you show doesn't look to me like one that Intel Fortran would display.

[Horsewood__Jerry]

The application and its files are stored on the local machine. Here is the code surrounding the read statement where the exception is raised:

c     Open the DE4xx ephemeris file if not already open
      pathName(1:) = ResourceDir(1:IRcount) // DEfile
      inquire (File = Trim(pathName), Opened = isOpen)
      if (.not. isOpen) then
         Open (Unit = 3, File = ResourceDir(1:IRcount) // DEfile,
     >         Form = 'Unformatted', Access = 'Direct', Recl = 8144,
     >         Status = 'Old')      end if
c     Read constants in the first two records of the file
      Read (3, Rec = 1) Ttl, (Cnam(I), I = 1, 400), Ss, Ncon, Au,	!The error occurs on this read statement
     >      Emrat, ((Ipt(I, J), I = 1, 3), J = 1, 12), NumDE,
     >      (Ipt(I, 13), I = 1, 3), (Cnam(I), I = 401, Ncon)
      Read (3, Rec = 2) (Cval(I), I = 1, Ncon)

The error message was shown in the console window of the application. A screen shot of the window is provided in the attached file.

[mecej4]

The unit for record length may be 1 byte or 4 bytes, depending on whether the compiler option /assume:byterecl has been specified. What is the value of Ncon when the file is being read?

[Steve_Lionel]

That error message and traceback is completely unlike what Intel Visual Fortran puts out. Does the program have its own traceback processing?

[Horsewood__Jerry]

Steve, your comment made me think about the code the customer is running. It turns out it was compiled under a different, earlier compiler. I will ask them to upgrade and then check to see if the problem recurs under the Intel compiler. Thanks for your help.

[Steve_Lionel]

Not only earlier, but not Intel (nor Compaq nor DEC).

[cryptogram]

Definitely look into the byte vs. word possibility, but also be aware that the internal format of direct access files is compiler dependent.  Compaq/Intel binary direct access is about as simple as it can be, but others use different formats.  You won't always be able to read or write a file that was created by another vendors compiler.   I ran into this years ago with Compaq Fortran and Lahey, where I was reading the files from a VB6 program.  The format was almost the same, but the Lahey version tacked some extra bytes at the beginning of the file    And for binary data, you have to be careful about endianness, which has to do with the order in memory, and thus in files, that the bytes of multi-byte number are stored.