Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
4 Views

forrtl: severe(111)

Hello

My application is generating the following error:

forrtl: severe(111): position number is outside of the valid range, unit 11, file (...)

I cannot find any documentation on what this specifically means, and since this is happening in a deployed environment, stack traces e.t.c. are not an option (since symbols have been stripped). 

Are any of you aware as to what this error specifically means? I am assuming that it has to do with the POS= input to write and read commands, but since those are 64-bit integers, I am having trouble with understanding how this could be out of range.

 

Thank you in advance.

0 Kudos
6 Replies
Highlighted
New Contributor I
4 Views

POS < 1, perhaps? 

POS < 1, perhaps? 

Note for Intel - 111 is not in the "List of Run-Time Error Messages" in my copy of the compiler documentation (Windows XE 2017 U4).

0 Kudos
Highlighted
Beginner
4 Views

Thanks for your comment Mark

Thanks for your comment Mark - I couldn't find 111 in my list either, which was very surprising to me.

POS < 1 I guess might be an option, but would then be caused by overflow of the POS integer that I am entering, which seems unlikely to me since it is a 64-bit integer. But of course, it could happen.

0 Kudos
Highlighted
Black Belt
4 Views

Is this a FORMATTED or

Is this a FORMATTED or UNFORMATTED file? If FORMATTED, the standard says:

If the file is connected for formatted stream access, the file position specified by POS= shall be equal to either (the beginning of the file) or a value previously returned by a POS= specifier in an INQUIRE statement for the file.

In other words, you can't use POS= to position a formatted file outside the data already written. It could be that your POS= variable is being corrupted by an error elsewhere in the program.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Beginner
4 Views

Thank you Steve for your

Thank you Steve for your reply - this is an unformatted file, so while I understand your comment I do not believe that it is the reason behind the error I am seeing.

0 Kudos
Highlighted
Black Belt
4 Views

Since you had not provided a

Since you had not provided a test case, I had to think of what might cause this in the absence of a compiler/runtime bug. Now that we have eliminated that possibility, it's time to see a test case. You may need to provide the client with a non-stripped application in order to gather further information.

You also haven't told us which compiler version you used and whether the application is linked statically or to the shared objects.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Beginner
4 Views

POS < 1 I guess might be an

POS < 1 I guess might be an option, but would then be caused by overflow of the POS integer that I am entering, which seems unlikely to me since it is a 64-bit integer. But of course, it could happen.

 A mistake I have made in the past is to have intermediate calculations using 32-bit integers, resulting in overflow before the final calculations producing the 64-bit integer. Is it possible that this is your problem?

0 Kudos