On 2019-09-18 11:31 PM, Seymour J Metz wrote:
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.
Ada is a fine language. It comes down to popularity.
There are even better languages for safety critical applications in use
today https://www.rust-lang.org/
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of David
Crayford <dcrayf...@gmail.com>
Sent: Tuesday, September 17, 2019 10:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
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 <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
----------------------------------------------------------------------
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
