Apologies, Mr. Crayford :-) z/OS is an interesting environment these days. There are a lot of options in using C, Metal C, in-line assembler, assembler subroutines, or Metal C subroutines from assembler. It's great to learn these, and learn them well enough to choose wisely in organizing your programs.
sas On Tue, Aug 14, 2018 at 11:35 PM, David Crayford <dcrayf...@gmail.com> wrote: > On 15/08/2018 6:34 AM, Steve Smith wrote: > >> I would like to reiterate David Crawford's question: why use Metal C >> instead of the complete C? >> > > That would be Crayford :) > > Metal C is intended for writing exits and small routines where full >> functionality isn't needed. It is a crippled C environment, and while you >> may enjoy pushing it to its limits and beyond, you should at least be able >> to articulate your reason for doing so. >> > > The interesting thing about Metal/C is the ability to do AR mode > programming using __far pointers which makes it suitable for low level > cross-memory > applications. I would suggest most of the heavy users of Metal/C are > vendors who develop systems software. We still use assembler for that > stuff because > we have lots of excellent assembler programmers who are not inclined to > learn a new language. They all acknowledge that the Metal/C optimizer > generates > more efficient code then the can. > > > >> For full disclosure, I have plenty of experience with Metal C being >> used... >> just because somebody wanted to. >> > > > I agree. I get the impression that some people use Metal/C just for the > sake of it or because they think it's cool. I stumbled across an SMF > formatting routine [1] from IBM that uses > Metal/C and I see no reason why it wasn't written in LE C. Why bother > inlining assembly to use QSAM macros when you can just use stdio fopen() > etc and not > have to worry about DCBs and getting storage below the line? > > [1] https://github.com/IBM/IBM-Z-zOS/tree/master/SMF-Tools/SMF84Formatter > > > Something tells me that if IBM had called it C-lite, or Basic C, it would >> have stayed in its place. >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
