Inconsistent Record Length identified in an X64 Build

[Groundsel]

I am in the process of converting a large "solution" with 95 projects from a Win32 build under Windows XP to Windows 7.  The first step was to perform a Win32 build on the same solution but on a Windows 7 machine.  That went without a hitch.  However, looking ahead, we would also like to do an X64 build of the same software.  There were run-time errors when I tried this.  The ones I have noted so far - and which have so far stopped me cold - feature fixed record length, binary direct access files.  The error message is Severe (37) "Inconsistent record length in unit xxx".  When I look up severe (37), I read "An attempt was made to open a direct access file without specifying a record length"

My first thought was that the 64 bit words were overflowing.  However, in one write statement where this comes up, the firxed record length is set to 7 and what is written is an integer, a CHARACTER(6) variable followed by three reals.  The default KIND's for INTEGER and REAL declarations were unchanged from 4 for the X64 build.  So there is room in the record for the content written.  (And I stress that it works fine with the Win 32 build on the same machine).

I haven't noted this issue coming up for anyone else.  Has the compiler simply become stricter in identifying the length of a record being written?  By my reckoning, there is a little emply space at the end of the one I describe here.  But that has never been an issue before.  

[TimP]

Did you leave unset /assume:byterecl consistently?  ifort now considers this as a standards compatibility issue, although the default is to measure RECL in 32-bit words, as was done by DEC Fortran, and as you appear to expect.

[Groundsel]

Good suggestion, Tim,

I had indeed not made that setting and for a moment, you had my hopes up.  However, when I recompiled with setting /assume: byterecl, I got the same message.  However, I looked at it (generated in the Debug mode) a little more carefully and noticed that it identified the "inconsistent" record length in unit 14 as belonging to ....\fort.14 the generic name given when it opens a new file without an OPEN statement.  In fact, unit 14 should be attached to a new permanent file name generated by a dll before the routine in question is called.  So the program is losing track of unit 14 already opened.   I checked to see if the filename attached to unit 14 was indeed created and found it was.  So is there something new I need to do to make sure it stays open or to make the program retain memory of it?

[Steven_L_Intel1]

Are you calling a Fortran DLL from a Fortran main program? If so, the main program must be linked to the DLL form of the Fortran run-time libraries. If you don't do this, then the main program and the DLL won't see the same I/O contexts.

[Groundsel]

Thanks, Steve,

That was it.  I failed to duplicate that detail of my Win32 build.  I created a new box and was thinking inside it!

Cheers!
Tom