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://github.com/zowe/zowe-common-c
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Peter Relson <rel...@us.ibm.com> Sent: Tuesday, September 17, 2019 9:20 AM To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
