[Default] On 17 Sep 2019 06:20:49 -0700, in bit.listserv.ibm-main [email protected] (Peter Relson) wrote:
>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. This is nice but when I was still doing system type coding I wanted a tool that converts Assembler mappings to COBOL or PL1. If people currently in the field would push for getting the BIT, BINARY-Character, the true binary, IEEE binary and decimal floating point usages that are in the current COBOL standard, then these mappings would be even more valuable. One of the justifications for making the effort is that COBOL should be able to access all data types that can be stored in DB2. I write this as someone who has used COBOL to get program and data set usage from SMF data. Clark Morris > >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
