> On Jan 26, 2018, at 7:26 PM, Paul Gilmartin > <[email protected]> wrote: > > On 2018-01-26, at 18:01:35, Jon Perryman wrote: > >>>> I wrote: Writing those in PL/X would have make MVS unmaintainable. >>> Peter Relson wrote: The second sentence is untrue, >> Peter, it would be interesting to see how PL/X has solved abstract coding >> techniques. I know DCB is not written in PL/X. Could you show us a short >> snippet of how you would implement this logic in PL/X? Just enough for us to >> understand how PL/X solved this would be great. Alternatively, you could >> show us how TSO commands such as ALTER implemented it's command parsing. >> > Isn't a PL/X flavor of DCB provided? > >> In C, the solutions was a runtime string that was parsed. It does not >> implement the full functionality of DCB (e.g. 'recfm=fb lrecl=100 >> blksize=6100'). >> > Is "full functionality of DCB" useful for any OS other than for z/OS? For > z/OS, > allocate with BPXWDYN or JCL DD statement and open by fopen("//DDN:..." ). > > — gil
Probably not - in C someone would simply modify or extend the standard library open() and open() calls to do what is needed for the platform. (Essentially what AIX services do on OS/390 and above…) We did something similar under Linux with HLASM reading a proprietary filesystem under Linux - the OPEN Macro for instance, just choses what open function to use based upon the DCB information. Same with READ, WRITE, CLOSE, etc. It’s easy and elegant. This is a funny area to compare though, since on most platforms, C file access is always a binary stream. The application pretty much defines the way the file is treated - byte by byte, record by record, block by block, buffer size by buffer size, etc. To load an image for instance, it is pretty common to fstat() the image file to get its size, malloc() a buffer of the appropriate size, then do a single read() or fread() to populate the buffer. It is extremely efficient on most platforms, often due to the OS buffering. But it does not equate all that well to traditional mainframe thinking. I mean, under UNIX, if you fread() a byte or so too much from a file, you simply put the extra back on the file. :)
