- From: tholen@xxxxxxxxxxxx
- Date: Fri, 5 Dec 2008 22:46:28 +0100 (CET)
Well, you are missing quite a lot. Firstly, because of the way that
I/O is buffered and Unix works, you often get an error message MUCH
later than you should have done, and they may even get delayed until
after the CLOSE (so you miss them). That explains why youï¿½see the
error near the end.
In this particular case, I know exactly where the problem occurs,
because there is only one statement that uses that particular error
branch. The statement immediately following the WRITE statement
tests for a nonzero IOSTAT and if so, takes the error branch.
Furthermore, the program both writes the output to a disk file and
displays it on the screen. The screen write succeeds, and the disk
write fails, and the failure is when the program tries to write the
final two lines of the output file.
Secondly, think quotas and so on.
Already thought about that. If a quota was causing the problem, then
why wouldn't it also cause the same problem on the other disk drive?
Also remember that civilised systems
(not include Gnome, for example) use text files for configuration, and
can be searched. 'grep 127 /usr/include/*/errno.h' gives you your
It's the "answer" only if that's the only possible error 127. Without
knowing for sure what compiler was used to build the application, there
would seem to at least be the possibility that the runtime error is
specific to the compiler. What I found for g95 is that error numbers
1 to 199 are from the system, but I know that ifort has some runtime
errors in that range. Maybe they're the same?
I have no idea what sort of key it is blithering on about, as I am
no USB expert, but solving that is left as an exercise for the
There are no ideas here either, hence the request to the newsgroup.
- Re: IOSTAT=127
- From: nmm1
- Re: IOSTAT=127
- Prev by Date: Re: Using a 2-D Array
- Next by Date: Re: IOSTAT=127
- Previous by thread: Re: IOSTAT=127
- Next by thread: Re: IOSTAT=127