Looks like IBM is really trying to eliminate HLASM programming in the user
community. Or, perhaps, extend the community to include C "systems"
programmers (like with a UNIX background).
On Tue, Jul 17, 2018 at 12:40 PM Gord Tomlin <
gt.ibm.li...@actionsoftware.com> wrote:
> On 2018-07-17 12:45, John McKown wrote:
> I don't see anything in the announcement that suggests any new
> functionality has been added to Metal C.
>
I think that the main push is that Metal C can be
On 2018-07-17, at 10:45:20, John McKown wrote:
>
> http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/6/897/ENUS218-326/index.html=en_locale=en
> ...
> Enterprise Metal C for z/OS is the newest, stand-alone offering for the IBM
> family of development tools. Enterprise Metal C
On 2018-07-17 12:45, John McKown wrote:
Looks like IBM is really trying to eliminate HLASM programming in the user
community. Or, perhaps, extend the community to include C "systems"
programmers (like with a UNIX background).
Indeed, that is true. And it is even possible (and not terribly hard) to
automate a process to "massage" the CDSECT output to make it far more palatable
and sensible (e.g., define known address variables as A or AD as needed, add
__PTR32 or __PTR64 where needed, and even fix "bugs" in the
And of course I confused my assembler and my C. I meant to say ". . . address
variables as "void *" and __PTR32 or __PTR64 as needed . . . ". CDSECT (at
least as of V2.1) has a bad habit of translating some assembler address
variable definitions as "char[4}" or "char[8]". I haven't exercised
On 2018-07-17, at 16:33:55, Charles Mills wrote:
> EDCDSECT, sometimes called just CDSECT, a part of the XLC compiler, does a
> very adequate job of converting assembler DSECTs, including from z/OS macros,
> to C headers. Are they pretty? No. Do they "make sense"? Oftentimes not. Are
> they
Actually, I would say it is the other way around. It is relatively easy to
create a set of structurea that resemble the control blocks and traverse
around, providing that IBM create the appropriate header files and maintain
them (most of us are capable of translating the macros to C headers,
Well, the problem of course is that assembler is not strongly typed. You can
code
BUFFADDR DS CL4 (or even 4C) and it works just fine for assembler, but what is
poor CDSECT supposed to do.
Last I knew, it did all FD and AD as char[8] which IMHO is pretty d@mned
stupid. But it is syntactically
One annoying thing also is that it is non-trivial to use a text editor to find
and convert all
char foo[8];
to
uint64_t foo;
It would be easier if the c syntax were char[8] foo; then getting to uint64_t
foo; would be trivial.
I guess if I were handier with regex it would be a piece of cake.
10 matches
Mail list logo
