Oppolzer - Informatik / Blog

Am 31.07.2013 02:40, schrieb M.N.:
>
> As usual I find I need to get more and more precise as I continue a thread. My
> concern is why I think I might need to code my own DCB based access in TSO/CMS,
> versus using standard C library calls on Linux. Let me give a very specific
> example: fprintf
> http://www.gnu.org/software/libc/manual/html_node/Formatted-Output-Functions.html#Formatted-Output-Functions
> says (for printf) "The printf function prints the optional arguments under the
> control of the template string template to the stream stdout. It returns the
> number of characters printed, or a negative value if there was an output error."
> and for fprintf "This function is just like printf, except that the output is
> written to the stream stream instead of stdout". I therefore believe that if I
> do an f printf, and run out of space, it should come back negative and I should
> be able to subsequently examine errno to find out what the error actually was.
> See
> http://www.gnu.org/software/libc/manual/html_node/Checking-for-Errors.html#Checking-for-Errors
> Obviously if there is an abend I never get to see the negative return, let alone
> check errno...
>
>

That's why there will be no abend with fprintf if the C runtime acts correct
according to the C library specifications. Of course, on z/OS for example, that
means that B37 etc. ABENDs issued by the I/O subsystem have to be caught and
hided from the C runtime. Otherwise, as you said, you would have no chance to
check for a negative returncode of fprintf or to lookup the value of errno.

The C runtime was probably designed with other operating systems (minicomputers,
PDP-11 etc.) in mind, so maybe the functions it provides don't fit well with the
z/OS system. But that's the way it is, and if you don't like it, you have to use
your own I/O routines (which is possible, after all).

I remember doing this for COBOL on VSE some 25 years ago, because it was not
possible to write variable length records in a clean and straightforward way. So
I added some ASSEMBLER routines to do that.

If, for example, you want to do the I/O from C using a ASSEMBLER routine, you
can still provide the power of fprintf etc. (using sprintf for example to fill
the buffer), but then do the I/O using ASSEMBLER. If done right, you can put
this all in a function, so that there is no difference from fprintf other than
the name of the function (call it asm_fprintf, for example). You will need
vsprintf inside the new function, and the function has to be declared with the
ellipsis (...) to accect a variable number of parameters.

Kind regards

Bernd