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

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

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
Highlighted
91 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. 

 

0 Kudos
Highlighted
Black Belt
91 Views

Does this mean a delayed Windows close ?

0 Kudos
Highlighted
Beginner
91 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.

0 Kudos
Highlighted
Beginner
91 Views

Tim P. wrote:

Does this mean a delayed Windows close ?

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

0 Kudos
Highlighted
91 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

0 Kudos
Highlighted
Beginner
91 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

0 Kudos
Highlighted
91 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.

0 Kudos
Highlighted
Beginner
91 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?

0 Kudos
Highlighted
91 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.

0 Kudos
Highlighted
Beginner
91 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

0 Kudos
Highlighted
91 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"!)

0 Kudos
Highlighted
91 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.)

0 Kudos
Highlighted
Beginner
91 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

0 Kudos
Highlighted
91 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=.

0 Kudos