That's unfortunate, since PL/I is a much better language for such purposes. I suppose that the business case for Ada headers would be even worse. Sigh.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of David Crayford <[email protected]> Sent: Tuesday, September 17, 2019 10:16 PM To: [email protected] Subject: Re: C headers in z/OS 2.4 On 2019-09-18 12:16 AM, Seymour J Metz wrote: > I'd rather have PL/I headers. I don't think IBM could justify doing any work for PL/I because there isn't a compelling requirement from customers or vendors to use PL/I for systems level code. On the other hand, Metal/C is taking off very quickly and is being used by vendors to write infrastructure and products. The company I work for only uses Metal/C for new code. Assembler and PL/X, while still very important, are legacy languages. Some products that were originally written in PL/X have started to use Metal/C for new code. The reason for this is obvious. Assembler and PL/X programmers are disappearing fast and attracting good young talent to replace them is difficult. We have some brilliant young engineers who are writing systems level code in C. Retaining them would be difficult if they had to work primarily in a legacy language. These guys all learn C at college so we just have to teach them z/OS. The smart ones pick it up quickly. We use Metal/C to write cross-memory servers, pc-ss, pc-cp, AR-mode stuff etc, etc. A lot of that code has been open sourced https://secure-web.cisco.com/11v_88vV4bklk-5ZjhNVLQcJii6iwzPXQacehBGHDc3hRV89gyIMlR7GaJkGxmGbCjxZumo6-0c4Ux3B69tydtfDEZLRMYXJUOtsSk4t1bW4wGyTfODc5AchhektFYJRdE2dBt2a8vsKXYZ2lBPS1_oHCFENlKT-R6cDiJztW_u83x_Juhvlw6nkJKRfuKKO4IVAp3073psI4iiC3KaAuitto0Qlc1-Q5aAqQkMbHSiTi9QCIiN6ShBNwkD1_86xEWcu6bCaLyR6EsE9knD-Th4pS-h8gQIje_He37wRgaDhIEc4C7tHHCArjvxF8eL0RyRSHrQ6pN39nk0uxCwvoPAdzyekdwSpdubVU5unZnjID18oO8yyNgz5EFW-k8tQn/https%3A%2F%2Fgithub.com%2Fzowe%2Fzowe-common-c > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > ________________________________________ > From: IBM Mainframe Discussion List <[email protected]> on behalf of > Peter Relson <[email protected]> > Sent: Tuesday, September 17, 2019 9:20 AM > To: [email protected] > Subject: C headers in z/OS 2.4 > > You might have seen mention in the announce that z/OS 2.4 is shipping more > C headers. > > The eventual goal is to do the mappings in SYS1.MACLIB and many in > SYS1.MODGEN, particularly the ones that have programming interfaces. > z/OS 2.4 starts small, concentrating on the SMF records that the z/OS core > elements produce. > > The headers are provided both in a data set (e.g., SYS1.SIEAHDR.H) and > within the file system (in a new subdirectory, /usr/include/zos). > The name of the header is the same as the name of the maclib/modgen macro > (plus the ".h" suffix when in the file system). > > There is no explicit documentation for any of the header files, including > no list of what is being provided. They are expected to be analogous to > the existing maclib/modgen mappings and the documentation for those > maclib/modgen mappings applies (allowing for differences in syntax, of > course). Once you have access to a z/OS 2.4 system, you can look. Here is > the list of mappings that are not SMF being provided in 2.4: > csvftchx cvt fxefr fxezctrl iazctkn iazjcor iazjpckp > iazjpcls iazjpitd iazjplex iazjplxi iazjpnjn iazjproc > iazjpspl iazlimd iazsplio iazssjd iazssji iazssjm iazssjp > iazssnu iazsssf iazssst iazsss2 iazsymdf iefjesct iefjscvt > iefjssib iefssobh iefssso iezjscb ihaascb ihaassb ihaasxb > ihaecvt ihafacl ihapsa ihapsae ihapsax iharb ihasdwa > ihasrb ihastcb ikjrb ikjtcb > > We do intend to document (this will make its way into the 2.4 publications > in some not too distant refresh) that the way to get the mappings for SMF > is to include header file ifacsmfr. Unlike assembler IFASMFR for which you > give it an operand that indicates which single SMF record type to expand, > ifacsmfr expands all the headers under its umbrella (and of course your > program will use whichever of the struct's it needs). In general, those > headers will be the analogs of the ones that IFASMFR makes available in > assembler. But note that a subsystem with its own SMF record in general > does not get expanded by IFASMFR and will not be expanded by ifacsmfr. > > We are looking for help in deciding which mappings/headers to do next. > Feel free to send me an email with your group's (or personal) > recommendations. > Mappings related to system exit routines seem like they might be of high > interest, in order to write the exit routine in metal C. > > Peter Relson > z/OS Core Technology Design > relson (at) us.ibm.com > > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
