execution differences between 5.5 and 5.7

[guruvar]

A text file created by clipper programs has an eof record at end, usually a CRLF followed by eof marker. Our programs under LF95 5.5, while reading these files, ignored these records. The same program compiled under 5.7 d is picking up these records and bombing out with a GPF in user.exe. Any thoughts on how to fix the program ? we would not like to change the Clipper output. Thanking in Advance

[Lahey Support]

The first thing I would try is to put an IOSTAT keyword into the read statement. You can check the IOSTAT variable to see if an EOF has occurred.
If that doesn't work, maybe send a short example?

[guruvar]

Ok, I have put together a test program with data, it behaves differently when compiled under LF95 5.5j (more forgiving) as compared to when compiled under 5.7d. The attached zip file contains:
1. The program new.f90
2. data file with crlf<eof> marker record is input.bug
3. data file with without the above marker is input.org
4. data file input.txt (you copy one of the other input.* into it for testing)
5. Cnew.bat batch file to compile the code.

path one.
compiled with 5.5j
the program works as expected when either input.bug or input.org is copied to input.txt before running the program.

path two.
compiled with 5.7j
The program works only with input.org copied into input.txt, and get a GPF in user.exe if run after input.bug is copied into input.txt before running the program.

Hope that is enough to explain the problem. Any further information can be requested from ngrover@natmatch.com.

[Lahey Support]

We made a change in the C runtime library used by LF95 at version 5.7. We switched from a Borland runtime to a Microsoft runtime. Evidently, the MS runtime considers the eof marker to be a part of the data, probably because it is written by the application and not the OS.
When the formatted read is attempted using the new runtime, an error condition is generated rather than an eof condition, because Fortran is trying to "read" the eof marker.
This situation can be easily rectified by using an IOSTAT variable to check the read status and prevent an abnormal termination. The following code shows the modification of the read subroutine that should fix the problem. It works with both compiler versions, but gives different IOSTAT values.


subroutine E_A_getdata(cur_unit,nRecs,iRet)
USE IDENT

implicit none

integer(kind=4) :: i, iRet, nRecs, cur_unit, ios
integer(kind=4) :: eof_flag = 0
character(len=80) :: iospec(2)
integer(kind=4) :: EX_APPL = 1
integer(kind=4) :: e_a_MATCH_ID,e_a_USER_ID,E_A_med_school, &
e_a_APP_SEQ_NBR,e_a_AAMC_ID,e_a_PARTNER_USER_ID, &
e_a_PARTNER_SEQ_NBR,e_a_COUPLE_USER_ID
character(len=1) :: e_a_COUPLE_IND
character(256) :: errmsg

DATA IOSPEC /'(I6,I6,I3,I6,I10,I6,I6,I6,A1)', &
'(I6,I6,I6,A9,I3,A1,A1,I3,I3)'/

nrecs = 0

if (eof_flag.eq.0) then
do i=1,MAX_ROWSET_SIZE
read(cur_unit,iospec(EX_APPL),iostat=ios) &
e_a_MATCH_ID,e_a_USER_ID,E_A_med_school, &
e_a_APP_SEQ_NBR,e_a_AAMC_ID,e_a_PARTNER_USER_ID, &
e_a_PARTNER_SEQ_NBR,e_a_COUPLE_USER_ID, &
e_a_COUPLE_IND
if(ios /= 0) go to 120
write(logfile,iospec(EX_APPL)) &
e_a_MATCH_ID,e_a_USER_ID,E_A_med_school, &
e_a_APP_SEQ_NBR,e_a_AAMC_ID,e_a_PARTNER_USER_ID, &
e_a_PARTNER_SEQ_NBR,e_a_COUPLE_USER_ID, &
e_a_COUPLE_IND
nRecs = i
enddo
goto 121
else
iRet = SQL_NO_DATA
return
endif
120 continue
eof_flag = 1
write(logfile,*) "Records read: ",nrecs
write(logfile,*) "I/O error status: ", ios
call iostat_msg(ios,errmsg)
write(logfile,*) trim(errmsg)
121 continue
iRet = SQL_SUCCESS
return
end

[guruvar]

Thank you very much for you timely help. This should do it.:)