- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 OPEN, INQUIRE, 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:
|
Why GERROR returns something else, I don't know.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does this mean a delayed Windows close ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tim P. wrote:
Does this mean a delayed Windows close ?
That would be my guess. Is there a way to verify this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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"!)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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=.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page