While the DOS I/O was very device dependent, there was the DTFDI with limited device independence.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Steve Thompson <[email protected]> Sent: Sunday, January 28, 2018 8:55 PM To: [email protected] Subject: Re: Fair comparison C vs HLASM On 01/26/2018 10:05 PM, Paul Gilmartin wrote: > On 2018-01-26, at 19:20:02, Jon Perryman wrote: > >>> Paul Gilmartin wrote: >>> 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:..." ). >>> >> BPXWDYN is dynamic allocation and does not provide every feature in DCB. >> FOPEN allows some DCB parms to be specified as runtime text that is parsed >> to fill in a DCB. Neither actually provides all functionality provided by >> DCB. >> > Does DCB provide functionality not available via DYNALLOC? > > BPXWDYN has a poorly documented side door allowing specification of SVC 99 > text units by code. > >>> Paul Gilmartin Wrote: Isn't a PL/X flavor of DCB provided? >> There may be DCB in PL/X. The DCB has many fields to be filled in. Does PL/X >> require you simply fill in the fields or does it allow abstraction where the >> programmer specifies a few parameters and the appropriate fields are filled >> in to fulfill the requirements the programmer specified. >> > How would a mere mortal know any of that? One would be by reading a manual or two of the MVS world. And if one wrote in PL/?, there are commands to drop directly into ALC and come back (so I'm told, was never allowed access to PL/S, PL/AS, or PL/X). A DCB, going back to a prior post (don't remember by whom), does not have to have every field "defined". That is, one can do a GETMAIN or whatever in "C" and init it to nulls and then fill in those fields that one needs. Then issue OPEN against that DCB and the system will fill in everything else. It will even put in the address of the read or write routine (GET/PUT, etc.). Now, if you did it one way, you got QSAM, if another, you got BSAM, or BDAM, or ISAM (which is no longer supported by IBM), etc. But NOT VSAM. That requires an ACB as does VTAM. One does not need HLASM to this. We used to do this with the old "F" assembler. And then with DCB, why not DTFxx from DOS/VS? systems. A bit lower level in what it does, but there are manuals for this too. Here is the difference between the DOS and MVS worlds: DOS was device dependent (DTFxx for Cards, Printer, Sequential DASD, TAPE, ISAM, etc.) and also had to know the format of the data (Undefined, Fixed, Fixed Block, Variable, Variable Block, etc.). Let's talk High Level Languages: COBOL does a lot of stuff that the programmer just doesn't have to know. Comparing that to "c" is a mistake! The problem with "c" is that it does not have a defined set of I/O verbs in the language def that then gets handled by some predefined routine for that architecture wherein it is being compiled. But, we do have "verbs" defined for ALC in the form of Macros that generates the code to get to the system provided routines. And as I recall, the system wherein "c" was developed was a system for handling "telemetry" from C/O Switches (Phone Company Central Office switches) for doing switch control and billing. So a sequential string oriented system was the way things were done. It turned out that MVS/ESA was *so* needed by PACBELL one would think it had almost been written for them. Back in those days (1990ish) it was taking them more than 30 days to do billing for a set of Central Offices (CO) (problem of the Telco's own design because of ZUM vs. how things were done around Washington DC --- Long story on that) So with being able to load a data space, multiple simultaneous C/O Billing runs could be done and share the big CO-CO billing table.... Sorry, this was so long ago I'm forgetting many of the details on this. But they presented it at a NaSPA local chapter in the Silicon Valley Area (SPANC, SysProgrammers Association of Northern California IIRC) at the Boole & Babbage offices right down the street from Amdahl. I think you are trying to compare a base ball bat to a mechanical pencil. Just my observation. And I do not consider myself to be a c programmer. Frankly, I can't get past its obtuse pointer handling. Regards, Steve Thompson
