This is a matter of how the ANSI C library functions are defined.
No hercules or GCC topic, in fact. When I wrote some programs in C for MVS
mainframe, I suddenly discovered (some time ago) that the fopen - fprintf -
fclose calls all returned zero etc., although the PDS to which I wrote was full.
I had many B37 messages in the JESMSGLG etc., but the C runtime ignored the
But that's how it is supposed to work. If you don't call ferror on the open
file, you will not recognize that there have been errors occured during writing.
You can complain about that, but that's some of the pitfalls of the ANSI C
library, and every C implementation that has to be conforming to the ANSI
standard has to behave like this.
BTW: this has nothing to do with the C language definition; you can use - for
example - the functions of the ANSI C library from languages like PL/1 or Free
Pascal - if you like to do so.
Am 30.07.2013 18:12, schrieb K.V.:
> --- In email@example.com, M.F. wrote:
>> Not all errors are either hardware or programming
>> error. For example "out of space". It's a
>> "condition" really, not an error. Most of the
>> I/O functions return an int, which is supposed
>> to be zero for no error, non-zero otherwise,
>> thus allowing error (or 'condition') recovery.
>> But as implemented in PDPCLIB you just get an
>> abend, no chance to do anything (especially
>> no return at all, let alone non-zero).
> Most MVS programs will encounter a D37 et when
> they run out of space, won't they? The natural
> thing to do is abend.
> BFN. P.