One thing to remember about CDSECT is that it's reading ADATA, and
conditionals tailor what's in there, just like the assembled source.
I've been playing with it lately for a SHARE presentation (hint), and
I've become very familiar with its output and idiosyncrasies.
On 2018-07-18 16:22, Charles Mills wrote:
Hmmm. I have not encountered that as a limitation.
CDSECT is not a macro (in the HLASM sense) converter; it is a DSECT
converter. If you had some sort of a multi-platform HLASM macro (z/OS and
VSE? 31- and 64-bit? MVS and z/OS?) it would be lovely to think it would
generate a corresponding multi-platform header with ifdef's for AIF's but it
does not. I guess it would make sense, but it does not do that. You would
indeed have to generate two structs and ifdef between them.
It generates pretty much vanilla C. If you had two platforms that both
needed headers corresponding to a Z DSECT I suspect its output could be made
to work for both. In fact, I am that audience: I generate headers and use
them in "production" on z/OS; and for compilation and very-alpha testing on
Visual Studio.
The only tweaking I have had to do is with the syntax of #pragma pack: it
generates pack(packed)/pack(reset) and Visual Studio wants
pack(push)/pack(1)/pack(pop).
It is not a perfect "automated" tool. I would not expect to push 100 DSECTs
through CDSECT and have all 100 be usable without manual intervention. But
it's a darned sight easier and more accurate than hand conversion. Believe
me -- I have tried.
One thing CDSECT does not attempt to do itself is naming. It would take some
cleverness on the user's part to create a job or script that would push a
PDS with members MYMACRO1, MYMACRO2, etc. through CDSECT and come out
automatically with mymacro1.h, mymacro2.h, etc. I always do them one at a
time. My output is always named MYUSRID.CDSECT and I manually copy that and
rename it to whatever.h.
Charles
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Wednesday, July 18, 2018 3:33 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: New Metal C standalone product for z/OS
On 2018-07-18, at 16:24:33, Charles Mills wrote:
CDSECT cares only about assembled code and labels. I believe conditional
assembly instructions are ignored (but not their effect, of course -- it's
usual input is an assembled macro such as DCBD). CDSECT does not to my
knowledge generate #ifdefs. I think #pragma packed(xxxx) is its only C
macro
output.
Given the intense use that both C and Assembler make of conditional
compilation to support multiple target environments, this is an
onerous limitation. I'm imagining assembling a DSECT for each
target; running CDSECT for each, then concatenating the outputs
separated by #ifdef ... #endif.
Hmmm... Doesn't diff(1) have the ability to generate such #ifdefs?
-- gil
--
M. Ray Mullins
Roseville, CA, USA
http://www.catherdersoftware.com/
http://www.z390.org/
German is essentially a form of assembly language consisting entirely of far
calls heavily accented with throaty guttural sounds. ---ilvi
French is essentially German with messed-up pronunciation and spelling.
--Robert B Wilson
English is essentially French converted to 7-bit ASCII. ---Christophe Pierret
[for Alain LaBonté]
