Fortran code error: forrtl: severe (66)

  • Context: Fortran 
  • Thread starter Thread starter nox13
  • Start date Start date
  • Tags Tags
    Code Error Fortran
Click For Summary

Discussion Overview

The discussion revolves around troubleshooting a Fortran code error encountered while executing a program that was originally written in the 1970s. The error message indicates an output statement overflow related to a specific file unit. Participants are exploring potential causes and solutions, focusing on debugging techniques and code analysis.

Discussion Character

  • Technical explanation
  • Debugging
  • Exploratory
  • Debate/contested

Main Points Raised

  • One participant describes receiving a "forrtl: severe (66): output statement overflows record" error when running the Fortran code.
  • Another participant inquires about the source code and suggests checking the part of the code that writes to unit 10.
  • A different participant shares a link to a resource that may help with understanding the error.
  • One participant proposes two possible issues: a mismatch between input and output types or invalid calls to unit 10.
  • Another participant speculates that the error may be due to writing data that exceeds the fixed record size specified by the "RECL" keyword in the open statement.
  • One participant shares a snippet of the code that opens unit 10 and performs read/write operations, noting that the write to unit 12 may be problematic if it hasn't been opened.
  • Another participant suggests that the error could be related to changes in variable sizes on different machines affecting the record size.
  • A participant expresses a need for alternatives to the carriage return command in Digital Fortran, indicating issues with formatting output.
  • One participant questions the necessity of using "ACCESS='DIRECT'" and "recl=81", suggesting a review of READ/WRITE knowledge.

Areas of Agreement / Disagreement

Participants have not reached a consensus on the specific cause of the error, and multiple competing views on potential solutions and debugging strategies remain. The discussion is ongoing and unresolved.

Contextual Notes

Participants have noted the potential for variable size changes affecting record sizes, as well as the importance of ensuring that all file units are properly opened before writing to them. There are also mentions of specific Fortran commands and formatting issues that may not be recognized in certain compilers.

nox13
Messages
4
Reaction score
0
Hi everybody,

I have old Fortran code, originally written in the mid 1970's for an Elmer system. The code has been adapted through the years, last run successfully in 2009.

The code has now landed on my lap after having been "retired" due to obsolescence. I am a pure Fortran beginner.

I have managed to recompile everything using Visual Fortran and MS Development Studio. However, when running certain executables I get the following error:


********************************************************
* EXECUTING GENERATE ! *
* *
* This program may be executed several times *
* *
********************************************************

1 file(s) copied.
Enter date - YYYYMMDD
20120404
forrtl: severe (66): output statement overflows record, unit 10, file C:\IMPALA2
\FATIMP1M


Is there anybody out there that can assist with solving this problem? If you need further information, please let me know.

Thanks in advance!
 
Technology news on Phys.org
do YOU have any idea where the problem could be?
do you have the source code?
the part where it tries to write to unit 10?
have YOU trie to do ANY kind of debugging?
 
Fortran... oh such memories...

Google does wonders in cases like this. Hope this helps:
http://www.hpc.unimelb.edu.au/doc/f90lrm/dfum_033.html
 
Last edited by a moderator:
Thanks for the replies so far.

Using my limited knowledge and Google, I deduced that it could be one of 2 problems.

1) The input received (read command - type, length) did not match the output (write command - type length)

2) Calls to and from Unit 10 are invalid

I am starting to run through the code, line by line and trace where the calls come from and go to.

I have the source code available. The program compiles without any errors.
 
Hi, nox13,
if I'm reading correctly the error list I linked to (and if I remember correctly),

my guess is that your program is trying to write a file in fixed-sized records (the record size being determined possibly by a "RECL" keyword in the open statement), and the "write" instruction is trying to write data that results in more bytes that the given record size.

Maybe posting part of your code would help (at least the opening of the file on unit 10, and the write statements on it).
 
The code for the part of the program calling unit 10:

**************

OPEN MAIN FILE
OPEN(UNIT=10,FILE=mainfile,STATUS='OLD',ACCESS='DIRECT', !hl1
*recl=81,FORM='FORMATTED' ) !hl1
c *COUNTBY='RECORD',FORM='FORMATTED',IOSTAT=ISTAT)
C
C READ LAST DATE FROM MAIN FILE, INPUT DATE FROM CARDS, CALCULATE NO.
C OF DAYS BETWEEN RUNS
READ(10,900,REC=1)LDATE
NEXFLR=2
!sh01
! WRITE(6,*)' ENTER DATE - YYMMDD' !hl1
WRITE(6,*)' Enter date - YYYYMMDD'
!
READ(5,910)IDAY

NRUND = IDAYS(IDAY(1),IDAY(2),IDAY(3))
!sh01
! ldate=ldate
! NLASTD = IDAYS2(LDATE)
NLASTD = IDAYS(LDATE(1),LDATE(2),LDATE(3))
!
NUMDAY = NRUND - NLASTD

C WRITE NEW DATE TO SUMMARY FILE
WRITE(12,920)IDAY

*************
!sh1 refers to changes made to the code to account for Y2K.

The format are as follows:

*************

!sh01
!900 FORMAT(9X,I6)
!910 FORMAT(3I2.2)
!920 FORMAT(1X,3I2.2)
!930 FORMAT(55X,22('*')/55X,'LAST RUN DATE -',I7/55X,22('*')/'1')
900 FORMAT(9X,I4,2I2)
910 FORMAT(I4,2I2)
920 FORMAT(1X,I4,2I2.2)
930 FORMAT(55X,26('*')/55X,'LAST RUN DATE - ',I4,2('/',I2.2)/
+ 55X,26('*')/'1')

*****************
 
Last edited:
Added [ code ] and [ /code ] tags to improve readability.
nox13 said:
The code for the part of the program calling unit 10:

**************
Code:
OPEN MAIN FILE <<< ---- this should be a comment[/color]
      OPEN(UNIT=10,FILE=mainfile,STATUS='OLD',ACCESS='DIRECT',		!hl1
     *recl=81,FORM='FORMATTED' )					!hl1
c     *COUNTBY='RECORD',FORM='FORMATTED',IOSTAT=ISTAT)
C
C READ LAST DATE FROM MAIN FILE, INPUT DATE FROM CARDS, CALCULATE NO.
C OF DAYS BETWEEN RUNS
      READ(10,900,REC=1)LDATE
      NEXFLR=2
!sh01     
!      WRITE(6,*)' ENTER DATE - YYMMDD'                                  !hl1
      WRITE(6,*)' Enter date - YYYYMMDD'
!      
      READ(5,910)IDAY
     
      NRUND = IDAYS(IDAY(1),IDAY(2),IDAY(3))
!sh01      
!      ldate=ldate
!      NLASTD = IDAYS2(LDATE)
      NLASTD = IDAYS(LDATE(1),LDATE(2),LDATE(3))
!       
      NUMDAY  = NRUND - NLASTD

C WRITE NEW DATE TO SUMMARY FILE
      WRITE(12,920)IDAY  <<< --- This code doesn't show unit 12 being opened[/color]

*************
!sh1 refers to changes made to the code to account for Y2K.

The format are as follows:

*************

!sh01
!900   FORMAT(9X,I6)
!910   FORMAT(3I2.2)
!920   FORMAT(1X,3I2.2)
!930   FORMAT(55X,22('*')/55X,'LAST RUN DATE -',I7/55X,22('*')/'1')
  900 FORMAT(9X,I4,2I2)
  910 FORMAT(I4,2I2)
  920 FORMAT(1X,I4,2I2.2)
  930 FORMAT(55X,26('*')/55X,'LAST RUN DATE - ',I4,2('/',I2.2)/
     +       55X,26('*')/'1')
*****************

It looks to me like the problem is the line where the code is attempting to write to unit 12, which might not have been opened.
 
Thanks Mark44. I will implement where possible.

Debugging is slow but progressing.

Having a problem now with the \n carriage return command. This command seems to not be recognized by Digital Fortran...is there an alternative command that I can try? The / command doesn't change the format of the output either in this instance.

Apologies for the noob questions.
 
  • #10
Curiously enough, the error was about output to unit 10, which does not appear to relate to the piece of code you posted. Maybe the faulty code is somewhere forward - look for further writes to unit=10.

Also, I was thinking that a likely possibility for a program that was OK and now fails with this error, is that the variable sizes have changed. Maybe the "recl=81" assumed a certain integer size (16? 32 bits?) and now you are on a machine where integers are larger. When the program tries to write a bunch of those into one record... they won't fit anymore.

Without seeing the actual write(unit=10,...), it's just guessing, of course.
 

Similar threads

  • · Replies 17 ·
Replies
17
Views
7K
  • · Replies 12 ·
Replies
12
Views
3K
  • · Replies 6 ·
Replies
6
Views
3K
  • · Replies 9 ·
Replies
9
Views
2K
  • · Replies 4 ·
Replies
4
Views
3K
  • · Replies 17 ·
Replies
17
Views
7K
  • · Replies 11 ·
Replies
11
Views
2K
Replies
4
Views
8K
  • · Replies 3 ·
Replies
3
Views
5K
  • · Replies 5 ·
Replies
5
Views
3K