WRT your first question, I would say "somewhat compatible". There are enough
similarities to make rough translations possible, EXCEPT that many macros only
have this kind of PL/S expansion published:
(From DCBD macro in SYS1.MACLIB):
**/%DCBD: MACRO KEYS(DATASET_ORG,DEVICE_TYPE,BASED_VALUE);
* ANS('?' || MACLABEL || ' DCBDP ' || MACKEYS || ';') SKIP;
* %END DCBD;
And of course the source of the PL/S macro DCBDP is not supplied anywhere,
possibly to prevent MACLIB bloat from the size of the actual PL/S macro text.
Even macros that have explicit PL/S mappings in the published macro text have
macro-conditional logic that often depends on global PL/S macro variables being
set to some value or other, with no plain indication of where or how those
macro variables need to be set / generated, though sometimes their meaning and
values can be inferred from the assembler source.
OTOH a library of PL/S ADATA mappings that matched the PL/S macro expansions
might be more easily translated to multiple language header definitions (COBOL
anyone? Maybe Java or Python?) by a replacement utility for EDCDSECT, which has
not proven to be nearly as useful as intended. A potential business
opportunity for an interested and well-funded ISV who could afford the no doubt
substantial NDA cost of acquiring PL/S ADATA documentation.
Not gonna happen in our lifetimes of course, but it is an interesting thought.
Peter
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Paul Gilmartin
Sent: Tuesday, September 17, 2019 1:06 PM
To: [email protected]
Subject: Re: C headers in z/OS 2.4
On Tue, 17 Sep 2019 16:16:31 +0000, Seymour J Metz wrote:
>I'd rather have PL/I headers.
>
Many macros contain PL/S alternatives. Are these PL/I compatible?
________________________________________
From: Peter Relson
Sent: Tuesday, September 17, 2019 9:20 AM
>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.
>
Good. This relieves the need for customers and ISVs to generate these by
filtering SYSPRINT or ASMADATA. To what extent can these be generated by
filtering the PL/S alternative sections?
>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).
>
Couldn't this duplication and its attendant maintenance and testing burden and
risk be reduced by suitable use of the -I option or by making /usr/include/zos
part of the conventional search order, perhaps in startup.mk?
"I see everything twice" -- Catch-22
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
