I am progressing with my attempt to update a legacy Fortran 77 solution to use some of the newer Fortran capabilities (as least those that I think I somewhat understand :-)) and have run into my latest problem being a runtime error 37:
This solution is a Fortran DLL called by a Fortran exe and was working until some recent modifications. The EXE runs to completion when run through the Visual Studio IDE in Debug or Release; however, when I copy the DLL and EXE to a separate folder the error is produced. The EXE is actually a batch processor that processes multiple files through the DLL, and the first file executes to completion with error 37 being produced on the second file. From what I have read error 37 indicates that an attempt was made to open a direct access file without specifying a record length. I have set the runtime library setting to Multithread DLL on both the EXE and DLL projects. Although my program does use a unit 14, I don't think this is the actual problem as another user in the forum also had unit 14 show up several years ago, and it sounded like his fix was in the runtime library setting.
You have omitted so much information it's painful. Does the (cut off here) file name in the message match a name you expect to be used on unit 14? I have never heard of a unit number appearing at random in an error message.
Does the EXE open the file and then call the DLL? If so, the EXE must be linked to the same Intel and MS run-time DLLs as your DLL.
Error 37 is quite straightforward. My guess is that you have an uninitialized variable or data corruption somewhere. Since you control both the EXE and the DLL you can add diagnostic code to determine what is going wrong.
None of the cut off file names are associated with the subroutine that opens unit 14. The EXE is a small driver program containing a loop that repeatedly opens an input file from a list of about 150 test files and calls the DLL for processing the file data and continues until the list has been completely processed. I have tried turning on all of the runtime checking (using both Debug and Release versions) and found several problems that, while I'm very glad they were caught, did not solve the error 37. I reviewed this forum topic: https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/475951 which I guess by coincidence also had a problem with unit 14. The code for opening unit 14 looks like this:
RLF is defined elsewhere as a parameter of 4, yielding RECL of 1152. JROT has the SAVE attribute assigned to it. I tried using RECL=1152 and still had error 37 when run outside of the Visual Studio IDE; it works fine inside VS IDE and all test files run to completion through the EXE-DLL interaction process. Unit 14 (as well as all open units) are closed at the conclusion of the DLL. I just tried adding write statements at line 44 and 49 of the code above and see the following in the results of the first file of the list:
The second file where the error 37 occurs never reached the line 44 write statement, so I don't think the problem is here. I may have a data corruption somewhere, as I don't know it I ever really solved the corruption problem noted in my previous forum post, although variable DSTMOM is behaving now :-) at least per comparison with saved test file results. Problems can be very difficult to find if they are not an explicit catch by the compiler.
Your narrative of #3 suggests to me that there is one item to check. Do you use the /assume:byterecl option when you compile and build inside Visual Studio, but forgot to specify it in the other situation?
What are the settings for Fortran > Libraries > Use Run-Time Library in each project? Don't guess, don't say it's "like" something - show us. You can even attach the .vfproj files from both projects (in fact, please do that.)
I have attached the vfproj files. This is the CVF converted project version. I tried copying the Debug version EXE and DLL files instead of Release, and the first file ran OK, but the second got caught in the error 37.
Regarding mecej4's comment, the use Bytes as RECL = Unit for Unformatted File is set to NO. That is a great question, as it seems it should be set to YES. I tried changing this and although it did not solve the error 37, should this be set to YES? What does it do with NO?
With Bytes as RECL= set to No, any RECL= in an unformatted file open is multiplied by 4. Since you're already multiplying by 4, Yes is the correct choice here. You have it set to No in both projects. Change it to Yes in both and rebuild.
The run-time libraries are correctly specified. Make sure, however, that you don't mix Release and Debug configurations between the two when running the program.
Thank you Steve and mecej4 for your assistance! I have tried many things on this error 37, but today the most basic was to go back to a saved dll that ran OK previously. I typically periodically save the test file results as well as the dll and source code that produced them. I copied the dll from the 07/30/19 folder into the test folder and the run now ended in error 37. Very strange since it ran previously...
The byte setting was a good catch, thanks! I have revised that setting and have only reviewed results on a couple of files and results on these are the same. I am not sure if in the instance of unit 14 with the setting set to no, the record was being written to the first 1152 bytes and the remaining 3456 bytes are uninitialized garbage or not, but results seem unaffected. Final test of this item to be made if I can get past error 37!
At this point I suggest trying to create a minimal, reproducible example that demonstrates the problem. The process of doing so might lead you to discover the solution, but if not, you can then show us the complete example and we can take a look. I don't think we can take this any farther here without that.
>>still had error 37 when run outside of the Visual Studio IDE; it works fine inside VS IDE and all test files run to completion
This usually indicates either:
a) Environment variable is different between runtime (from IDE or from CMD window/ShortCut)
b) Any DLL loaded is different due to a)
also>> JROT has the SAVE attribute assigned to it.
Show how you define it as 0