uly 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
FWIW, the IBM Record Generator for Java (formerly: JZOS RecordGenerator)
also processes ADATA records from either COBOL and HLASM and will generate
Java mapping classes.
https://www.ibm.com/support/knowledgecenter/en/SSMQ4D_3.0.0/documentation/recgen_overview.html
It also has a feature where you
Sent: Wednesday, July 18, 2018 4:20 PM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: New Metal C standalone product for z/OS
c pointers are easily thought of as just automatic 'using' statements.
Tony Thigpen
Steve Thompson wrote on 07/18/2018 03:54 PM:
> * TYPEing
>
>DC 0F,A(B
On 2018-07-18, at 21:45:38, Robin Vowels wrote:
> From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
> Sent: Thursday, July 19, 2018 8:00 AM
>
>>> Generally. Of course HLASM is all but untyped. A might mean an integer
>>> constant, especially since A supports expressions
Gil wrote:
>DC F'-2147483648' assembles successfully, while
>DC A(-2147483648) gets a syntax error.
>
> A designer's perverse notion of completeness?
The parsing of F-type values was modified to support unsigned
values (prefixed with U) which means that it was also able to
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Thursday, July 19, 2018 8:00 AM
Generally. Of course HLASM is all but untyped. A might mean an integer
constant, especially since A supports expressions while F somewhat
inexplicably does not. You can code
Not sure that anyone on this list gives a darn but just in case, here is a
concrete example. I picked the COM DSECT (MODIFY and STOP interface for
started tasks) -- it's small and people should be somewhat familiar with it.
It's here:
: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 co
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
output.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Wednesday, July 18, 2018 5:15 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: New Metal C standalone product for z/OS
On 2018-07-18, at 14:54
On 2018-07-18, at 14:54:39, Charles Mills wrote:
>
> Yes, assembler has types. A macro that cares can tell the difference among
> FOO DS C, FOO DS A, and FOO DS F -- but few macros and fewer instructions
> care. ...
>
It's been a while since I tried it, but using AIF to select among three
On 2018-07-18, at 13:54:01, Steve Thompson wrote:
>
> Meanwhile, I'm thinking a bit about c and learning it. I still remember that
> c's pointers are about as obtuse as they get... But I'm told once you get
> past that, c becomes easy :)
>
No, merely the next lesson is no harder.
-- gil
Gödel would be proud.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Wednesday, July 18, 2018 5:00 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: New Metal C standalone product for z/OS
Various observations and assertions:
HLASM has very weak typing. On the other hand, it doesn't claim to be a
compiler.
On the other other hand, you'd think that by now maybe there would be an
option to flag something like L R1,=H'2', and not just because you were
unlucky with alignment.
The new
On 2018-07-18, at 11:42:43, Charles Mills wrote:
>
> Going from structs to DSECTs would make a lot of sense except that there is
> no C equivalent of SYSADATA, so the utility would have to have its own
> built-in (partial) C compiler. Going from PL/X to DSECTs (or C headers!)
> makes a lot of
an array and its first
element are the same thing.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Tony Thigpen
Sent: Wednesday, July 18, 2018 1:20 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: New Metal C standalone
ncorrectly.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Steve Thompson
Sent: Wednesday, July 18, 2018 12:54 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: New Metal C standalone product for z/OS
* TYPEing
Gilmartin
Sent: Wednesday, July 18, 2018 10:10 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: New Metal C standalone product for z/OS
On 2018-07-17, at 18:04:14, Charles Mills wrote:
One annoying thing also is that it is non-trivial to use a text
editor to
find and convert all
char foo[8];
to
7) but not F'BUFF_LEN+7'.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Wednesday, July 18, 2018 10:10 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: New Metal C standalone product for z/OS
On 2
an code A(BUFF_LEN+7) but not F'BUFF_LEN+7'.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Paul Gilmartin
Sent: Wednesday, July 18, 2018 10:10 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: New Metal C standalone produ
On 2018-07-17, at 18:04:14, Charles Mills wrote:
> 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.
Thanks. (I'm a lazy son of a gun!)
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Walt Farrell
Sent: Wednesday, July 18, 2018 6:50 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: New Metal C standalone product
On Tue, 17 Jul 2018 17:04:14 -0700, Charles Mills wrote:
>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.
: Re: New Metal C standalone product for z/OS
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
valid and the storage layout is correct.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Farley, Peter x23353
Sent: Tuesday, July 17, 2018 4:19 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: New Metal C standalone
July 17, 2018 6:58 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: New Metal C standalone product for z/OS
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
gs" in the (mis-)definitions).
Peter
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Charles Mills
Sent: Tuesday, July 17, 2018 6:34 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: New Metal C standalone produc
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,
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 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).
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
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).
33 matches
Mail list logo
