Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26732 Discussions

Fortran Open error iostat=30 gerror returns "broken pipe"

Lothar_Braun
Beginner
391 Views

Hi,

on some occasions, the OPEN statements returns with IOSTAT=30 and GERROR() returns the string "broken pipe".

        OPEN(UNIT=IUNIT,FILE=ICFILE,ACTION='READWRITE',ACCESS='SEQUENTIAL'
     *      ,STATUS='REPLACE',FORM='FORMATTED',BLANK='NULL'
     *      ,IOSTAT=JIOS,ERR=930)

Compiled with /VMS switch. Sometimes the file in question has been opened for reading and closed, the file is not in the local file system but on a network share, the filename is fully qualified with drive letter, path etc.

Any ideas where to look? And is there a better method to get more information than GERROR()?

Thanks

Lothar

 

 

0 Kudos
14 Replies
Allan_Aagaard_N_
Beginner
391 Views

Hi Lothar

If you take a look at the documentation, you can find a list over IOSTAT codes (https://software.intel.com/en-us/node/678472#EAAA16FF-06DF-4E0E-9058-EA6F9EF8D059)

Here you will see that IOSTAT code 30 means:

30

severe (30): Open failure

FOR$IOS_OPEFAI. An error was detected by the Intel® Fortran RTL I/O system while attempting to open a file in an OPENINQUIRE, or other I/O statement. This message is issued when the error condition is not one of the more common conditions for which specific error messages are provided. It can occur when an OPEN operation was attempted for one of the following:

  • Segmented file that was not on a disk or a raw magnetic tape

  • Standard I/O file that had been closed

Why GERROR returns something else, I don't know. 

 

TimP
Black Belt
391 Views

Does this mean a delayed Windows close ?

Lothar_Braun
Beginner
391 Views

Hi Allen,

somewhere else in the documentation (I do not remember where) is stated, that RTL error 30 is some what generic and a more specific message may be found with getlasterror() (or getlasterrorqq()). My understanding is, that GERROR() returns the text associated with the error number returned from getlasterror() called inside GERROR(), but I am not sure about that.

The reasons stated in the referenced documentation are not really helpful.

Lothar_Braun
Beginner
391 Views

Tim P. wrote:

Does this mean a delayed Windows close ?

That would be my guess. Is there a way to verify this?

jimdempseyatthecove
Black Belt
391 Views

>>That would be my guess. Is there a way to verify this? (delayed Windows close)

When you receive this error (30), instead of aborting, delay some TBD time and retry. Then if the error persists print your error message and stop.

As to what this time is you will have to determine this yourself (e.g. have your retry placed in a loop and find the time to resolve, if any).

Jim Dempsey

Lothar_Braun
Beginner
391 Views

jimdempseyatthecove wrote:

>>That would be my guess. Is there a way to verify this? (delayed Windows close)

When you receive this error (30), instead of aborting, delay some TBD time and retry. Then if the error persists print your error message and stop.

As to what this time is you will have to determine this yourself (e.g. have your retry placed in a loop and find the time to resolve, if any).

Jim Dempsey

Easier said then done. I will keep it in mind and add such a loop for our next version. For now, we change the file status to 'UNKNOWN' and hope to resolve the issue in that way. (The status is something we can change at runtime. No need to deliver a new version.)

Before we started using 'REPLACE', we had coded a check for the file with inquire and deleted it before we reopened it with 'NEW'. But this lead to much more timing problems. I thought we had solved them all with using 'REPLACE', but well ...

What I still do not know, is how to get a clean picture of what is happening. Are there any more error codes I could check? Or maybe a trace switch for the runtime?

Thanks, Lothar

Steven_L_Intel1
Employee
391 Views

Rather than GERROR, try ERRSNS and get the sys_err value.  I am suspicious of that "broken pipe" message - it makes no sense. Usually what we see is that the call to the Windows CreateFile API routine returns an error saying that access is denied because the file is still open. If you are closing and reopening the file, try putting a 500ms delay (use SLEEPQQ) after the CLOSE.

Lothar_Braun
Beginner
391 Views

Steve Lionel (Intel) wrote:

Rather than GERROR, try ERRSNS and get the sys_err value.  I am suspicious of that "broken pipe" message - it makes no sense. Usually what we see is that the call to the Windows CreateFile API routine returns an error saying that access is denied because the file is still open. If you are closing and reopening the file, try putting a 500ms delay (use SLEEPQQ) after the CLOSE.

Thanks Steve,

I am just on my way replacing the message retrieval. Could you please confirm, that this would get me the same value as a call to GETLASTMESSAGE or GETLASTMESSAGEQQ?

As these routines are likely a wrapper for the win32API, I should be able to use FormatMessage(...) to get a meaningful message. What do you think?

Steven_L_Intel1
Employee
391 Views

The problem with GETLASTERROR is that if there were any Windows API calls since the CreateFile failed, you would not see the correct value. ERRSNS returns the system error message stored at the right time.

Lothar_Braun
Beginner
391 Views

Steve Lionel (Intel) wrote:

The problem with GETLASTERROR is that if there were any Windows API calls since the CreateFile failed, you would not see the correct value. ERRSNS returns the system error message stored at the right time.

Thank you Steve,

I suspected something, but did not think of that. May be that could be added to the documentation?

Lothar

Steven_L_Intel1
Employee
391 Views

GETLASTERRORQQ is of no use here - it applies only to a select set of IFPORT procedures. I think GETLASTERROR is a wrapper for the Windows API routine GetLastError, but I see that the documentation could use improvement (especially in regards to its reference to "examining errno"!)

Steven_L_Intel1
Employee
391 Views

Had a look at the source. GETLASTERROR is also of no use here - it returns the C errno value, which tells you nothing about an OPEN on WIndows. Use ERRSNS (or maybe GetLastError from KERNEL32.)

Lothar_Braun
Beginner
391 Views

Thank you very much for this clarification Steve,

one way to improve the documentation would be to have an example of how to handle "all" error codes and show the corresponding messages to the user.

I think, I will stick with GERROR to display a description for the FORTRAN error codes, add a call to ERRSNS to get the system code and, if not 0, use FormatMessage (in C or C++) to show the corresponding text. (Our application is a mixed language program with fortran, c and c++.) Perhaps I will add some code to cross check the values of errsns with those of the open statement.

Thanks, Lothar

Steven_L_Intel1
Employee
391 Views

Don't bother with GERROR - we support the standard IOMSG= keyword in OPEN and other I/O statements. You put in IOMSG=character-variable-name, and the variable is filled with the message text if there is an error. Use it in conjunction with IOSTAT=.

Reply