[Default] On 27 Aug 2017 16:54:26 -0700, in bit.listserv.ibm-main [email protected] (scott Ford) wrote:
>David, All, > >I have to think about hardening a COBOL written STC performing security >calls. This my main reason for the question regarding the I/O error >handler, it makes sense to move the I/O into an assembler module or C.. > If you want the program to control the I/O error handling, adding a status code to the FD (the name of a 2 character PIC XX field normally in WORKING-STORAGE) and checking it after ALL I/O operations to take appropriate action should be adequate. Clark Morris > >Scott > > >On Fri, Aug 25, 2017 at 12:07 AM David Crayford <[email protected]> wrote: > >> 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 >> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
