- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As far as I know the fortran standard does not say anything about the valid range of unit numbers or the pre-connected units (stdin,stdout,stderr). The pre-connected units I beleive are usually in the neighborhood of 4,5,6 and using the intrinsic module iso_fortran_env you can find them at run time.
Does anybody know:
1) if there is an upper bound on allowable unit numbers, and if so is this hardware dependant, compile dependant, OS dependant or some combination?
2) if there are any other unit numbers one must be carefull about, other than stdin,stdout,stderr and working within a valid range of numbers.
3) Is there a way to querry available unit numbers at runtime?
4) Is there a way to gracefully recover from openning bad unit numbers?
Many thanks in advance.
-Z
Does anybody know:
1) if there is an upper bound on allowable unit numbers, and if so is this hardware dependant, compile dependant, OS dependant or some combination?
2) if there are any other unit numbers one must be carefull about, other than stdin,stdout,stderr and working within a valid range of numbers.
3) Is there a way to querry available unit numbers at runtime?
4) Is there a way to gracefully recover from openning bad unit numbers?
Many thanks in advance.
-Z
Link Copied
10 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you read comp.lang.fortran for expert recommendations there, you'll see it is usual practice to assume no pre-opened unit numbers greater than 9 on current Fortran platforms. It wouldn't be a good quality implementation if there were a reliance on pre-connected units other than the 3 (at most) standard ones which you could find with iso_fortran_env.
When you OPEN a unit number which was pre-connected, you replace the pre-connected functionality and can't get it back. It should behave just as a unit number which was not previously connected, so that would not act as a "bad unit number."
When you OPEN a unit number which was pre-connected, you replace the pre-connected functionality and can't get it back. It should behave just as a unit number which was not previously connected, so that would not act as a "bad unit number."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - tim18
If you read comp.lang.fortran for expert recommendations there, you'll see it is usual practice to assume no pre-opened unit numbers greater than 9 on current Fortran platforms. It wouldn't be a good quality implementation if there were a reliance on pre-connected units other than the 3 (at most) standard ones which you could find with iso_fortran_env.
When you OPEN a unit number which was pre-connected, you replace the pre-connected functionality and can't get it back. It should behave just as a unit number which was not previously connected, so that would not act as a "bad unit number."
When you OPEN a unit number which was pre-connected, you replace the pre-connected functionality and can't get it back. It should behave just as a unit number which was not previously connected, so that would not act as a "bad unit number."
It seems to me there is some upper bound on allowable unit numbers. For instance if I try to open a file connected to unit 124 the code just hangs. This is more what my question is about, allowable unit numbers, if there are certain units which don't exist, or should be avoided, what the maximum allowable unit number is and how to find all of this information.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - zbeekman
It seems to me there is some upper bound on allowable unit numbers. For instance if I try to open a file connected to unit 124 the code just hangs. This is more what my question is about, allowable unit numbers, if there are certain units which don't exist, or should be avoided, what the maximum allowable unit number is and how to find all of this information.
I'm using unit numbers has high as 999 without problem...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - rreis
I'm using unit numbers has high as 999 without problem...
03:28 PM (1) Codes $ uname -a
Linux XXXXXXXXX.XXXXXXXXX.EDU 2.6.18-128.1.1.el5 #1 SMP Tue Feb 10 18:09:15 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - zbeekman
Does 124 ever give you trouble? If I start at 110 and try to increment the unit number by 1 using a do loop to loop through the 106 files I am reading it hangs at 124. I haven't tried unit numbers greater than 124. I am on a RHEL derivative x86_64 machine.
03:28 PM (1) Codes $ uname -a
Linux XXXXXXXXX.XXXXXXXXX.EDU 2.6.18-128.1.1.el5 #1 SMP Tue Feb 10 18:09:15 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
03:28 PM (1) Codes $ uname -a
Linux XXXXXXXXX.XXXXXXXXX.EDU 2.6.18-128.1.1.el5 #1 SMP Tue Feb 10 18:09:15 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
Intel Fortran shouldn't have a problem with unit=124. However, your shell (process) will have a limit 'open files':
ulimit -a
to list it (look for 'open files' limit). However, this is typically 1024. Did you mean it hangs at 1024 and not 124? It would make sense that you'd have problems around this file limit.
ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Ronald Green (Intel)
Intel Fortran shouldn't have a problem with unit=124. However, your shell (process) will have a limit 'open files':
ulimit -a
to list it (look for 'open files' limit). However, this is typically 1024. Did you mean it hangs at 1024 and not 124? It would make sense that you'd have problems around this file limit.
ron
So, a while ago, I posted a possible compiler bug using asynchronous IO. I noticed that the asynchronous OPEN statements hung after the first 13 successful ones. For each file that was opened the unit number was incremented from 110 by 1. I tried changing this offset to 10 and now it appears that the code works, with the notable exception that the index variables in the implied do loops of asynchronous read statements do not appear to be "thread private" : I get segmentation faults, complaints about too much data required in read statements, and when compiled with the -check option i get array out-of-bounds errors. (I suspect that since multiple asynchronousIO files are open simultaneously with asynchronous reads they are incrementing the same index variable. Note, also, that I am using the fortran 03 language feature of asynchronous IO and NOT using openMP or any other explicit thread management.) Once I have nailed down whether there is a legitimate issue with my choice of unit numbers I plan to update the thread I started about the asynchronousIO issues. Also, ulimit -n is 1024 on all the machines I have been testing on, as Ron had mentioned.
Thanks for all the help,
-Z
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the details on what you are seeing. It does sound like there is something to investigate. Keep us updated on your progress and try to find a concise code reproducer so we can get a bug report going on this.
thanks
ron
thanks
ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The range of unit numbers is implementation dependent. Intel Fortran allows any positive 32-bit integer as a unit number.
There was an issue related to the implementation of asynchronous I/O that caused "collision" between units with a certain spacing between them, but that has been fixed for a while now.
There was an issue related to the implementation of asynchronous I/O that caused "collision" between units with a certain spacing between them, but that has been fixed for a while now.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Steve Lionel (Intel)
The range of unit numbers is implementation dependent. Intel Fortran allows any positive 32-bit integer as a unit number.
There was an issue related to the implementation of asynchronous I/O that caused "collision" between units with a certain spacing between them, but that has been fixed for a while now.
There was an issue related to the implementation of asynchronous I/O that caused "collision" between units with a certain spacing between them, but that has been fixed for a while now.
Steve: Do you know which versions are affected by the bug? Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Version 10.1 was affected. It was fixed in an update to 10.1 in July 2008. The issue affected two units whose numbers were separated by 521.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page