On 25/08/2017 11:10 AM, Farley, Peter x23353 wrote:
That may well be true, but use of C stdio then requires POSIX mode, which makes
it not suitable for a *generalized* file handler which might, for instance,
need to be invoked in a totally non-LE environment.
Good point about the non-LE environment. The only time I run non-LE
these days is systems level programming and I don't do much of that. I'm
doing a lot of Java work these days and C stdio pops it's head up again
when using ZFile. It's remarkable that I only need one simple wrapper
class to access all the different file types on z/OS. It's not perfect
though. I wish it had better support for enumerating PDS members.
There is no POSIX requirement for C stdio (or sockets). In my experience
the only time I've required POSIX semantics is to use runtime functions
for threads, mutexes and IPC stuff.
I would agree with "hundreds of lines" but not thousands. QSAM support only
takes a few hundred, even including MOVE/LOCATE and UPDATE modes (and a lot of that can
be explanatory comments for the next maintainer). Maybe by the time the BSAM/BDAM/VSAM
support was done you would have a thousand or more lines, but not I think two or three
thousand.
Depending on how many bells and whistles you want to include of course. As
usual, YMMV.
We've got a common code assembler VSAM I/O program that's ~1700 LOC, but
it does have quite a few bells and whistles. fopen() has extra bling
like dynamic allocation. Our assembler dynalloc routine is 987 LOC. It
all adds up and that's before adding extra layers of abstraction.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of David Crayford
Sent: Wednesday, August 23, 2017 12:53 AM
To: [email protected]
Subject: Re: Cobol Help
On 22/08/2017 11:59 PM, Farley, Peter x23353 wrote:
In that case the assembler I/O modules handled any errors that they could
(SYNAD, etc.) and passed back error code(s) and messages to the COBOL interface
module to pass up to the caller, simulating COBOL FILE STATUS and VSAM error
variable where possible.
Metal C might be a better choice for more generalized file I/O handling, one
small step above assembler but with all assembler facilities available.
The best generalized file handling I've seen on z/OS is the C stdio
fopen() and friends (by a country mile). That one factory function can handle
all the standard access methods: BSAM, QSAM, VSAM (KSDS, RRDS, ESDS),
hiperspaces and Unix files. It's a thing of beauty. To code the equivalent
functionality in Metal/C would take hundreds if not thousands of lines of code.
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
