Re: New Metal C standalone product for z/OS
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() 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é]
Re: New Metal C standalone product for z/OS
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 can parse the ADATA and generate an XML description of the ADATA. This might be interesting to leverage to generate mappings for other languages. You might also want process this to specify alternate types over the data. Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Jul 18, 2018 at 5:00 PM, Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > 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 (technical) sense. > > > I hadn't understood that CDESECT exploited SYSADATA. That's > a great advantage. > > > 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 A(BUFF_LEN+7) but not F'BUFF_LEN+7'. > > > OTOH, >DC F'-2147483648' assembles successfully, while >DC A(-2147483648) gets a syntax error. > > A designer's perverse notion of completeness? > > -- gil >
Re: New Metal C standalone product for z/OS
Many things that are easily thought will get you in trouble if you think them. Understand the difference or get bitten; your choice. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Tony Thigpen 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(BUFF_LEN+7) Get The Charles Constant... > > The type of the LABEL is "F" not "A" and you got what you needed. yes? > > This is typically done for certain "ASSIST" type macros that I've used > in the past where they check what the label is (IF, DO, DOWHILE, > SELECT, etc.). > > 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 :) > > Regards, > Steve Thompson > > On 07/18/2018 01:42 PM, Charles Mills wrote: >> It *does* get alignment right. CDSECT's output does not depend on >> "inherent" >> C alignment. Char[8] and uint64_t both end up in the same place. It >> constructs the struct using the SYSADATA offsets. It inserts its own >> padding >> where necessary. It emits #pragma pack(packed). >> >> 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 (technical) sense. >> >> I fail to see how is any clearer than A, unless you happen to be >> coming from a C-only background. Neither one is clear if you don't >> know what >> it means. A means "32-bit pointer." >> >> 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 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 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 >>> uint64_t foo; >>> >>> It would be easier if the c syntax were char[8] foo; then getting to >> uint64_t foo; would be trivial. >> It seems the designers were fixated on making declarators look >> like member references. >> >>> -Original Message- >>> From: Charles Mills >>> Sent: Tuesday, July 17, 2018 4:57 PM >>> >>> 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 valid and the storage layout is correct. >> Subject to bouldary alignment. >> >> A more useful design would code the data area descriptions initially >> as C structs and supply an ASTRUCT utility to convert to DSECTS. >> >> I believe I'd name it DESTRUCT. >> >> Or, an assembler programmer with foresight could have employed SETC >> symbols such as: >> &__ptr32 SETC A >> POINTER DC &__ptr32(symbol) >> ... >> Providing some guidance for a CDSECT utility and clarity for the >> reader of the source. (IMO, "&__ptr32" conveys better information >> than "A". I'm not advocating Hungarian Notation.) >> >> (This solves nothing for legacy source code.) >> >> -- gil >> > >
Re: New Metal C standalone product for z/OS
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 while F somewhat >>> inexplicably does not. You can code A(BUFF_LEN+7) but not F'BUFF_LEN+7'. >>> >> OTOH, >> DC F'-2147483648' assembles successfully, while >> DC A(-2147483648) gets a syntax error. > > Well, it should get some kind of error. > What error do you perceive here? What I see is that an overflow occurred evaluating a 31-bit signed integer expression. -- gil
Re: New Metal C standalone product for z/OS
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 support values outside the normal range before applying the specified sign. The parsing of self-defining decimal constants in any other context currently parses them as unsigned 31-bit values, with any sign being taken as a separate unary operator applied afterwards. Some years ago I prototyped a change to HLASM which supports signed self-defining decimal constants, so a unary minus preceding a decimal digit is taken to be part of the value (both for assembler expressions and for conditional assembly expressions) which means that decimal self-defining constants could cover the full range, just like the other types (hex, binary and character). The main benefit in practice was that the largest negative number was then allowed in expressions. However, that development item was shelved for some reason, probably mostly due to nervousness about potential incompatibility, although we could not come up with a realistic example of such a problem. I do remember being quite irritated with running into a silly problem in testing due to the historical oddity (which definitely cannot be fixed for compatibility reasons) that substitution of a SETA symbol loses any minus sign, requiring the use of the SIGNED built-in function to transfer the signed value via a SETC symbol! I'll try to revisit that item some time to evaluate whether it might be a good idea to complete it. Jonathan Scott, HLASM IBM Hursley, UK
Re: New Metal C standalone product for z/OS
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 A(BUFF_LEN+7) but not F'BUFF_LEN+7'. OTOH, DC F'-2147483648' assembles successfully, while DC A(-2147483648) gets a syntax error. Well, it should get some kind of error. A designer's perverse notion of completeness? --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: New Metal C standalone product for z/OS
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:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ie
ad100/COM.htm
Here is the CDSECT output (depending on options). Notice that it lost
COMTOKEN -- thought only the flag bit was significant.
#pragma pack(packed)
#ifndef __iezcom__
#define __iezcom__
struct iezcom {
void *comecbpt; /* -PTR TO ECB FOR STOP OR
MODIFY COMMAND */
void *comcibpt; /* -PTR TO COMMAND INPUT BUFFER
(CIB) */
intcomtokhr : 1, /* -BIT = 1 INDICATES A TOKEN
PRESENT */
: 31;
};
#endif
#pragma pack(reset)
Charles
Re: New Metal C standalone product for z/OS
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() 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
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() 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
Re: New Metal C standalone product for z/OS
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() is its only C macro 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: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 such alternatives may yield unexpected resuts. Lookahead can make it worse. Given such complexity, will CDSECT realize the AIFs as #ifdefs? Probably not because SYSADATA doesn't reflect the AIFs. -- gil
Re: New Metal C standalone product for z/OS
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 such alternatives may yield unexpected resuts. Lookahead can make it worse. Given such complexity, will CDSECT realize the AIFs as #ifdefs? Probably not because SYSADATA doesn't reflect the AIFs. -- gil
Re: New Metal C standalone product for z/OS
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
Re: New Metal C standalone product for z/OS
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 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 (technical) sense. > I hadn't understood that CDESECT exploited SYSADATA. That's a great advantage. > 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 A(BUFF_LEN+7) but not F'BUFF_LEN+7'. > OTOH, DC F'-2147483648' assembles successfully, while DC A(-2147483648) gets a syntax error. A designer's perverse notion of completeness? -- gil
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 register symbol attribute facility is fatuous. C, imho, suffers from apparently being designed to the first principle that every keystroke the programmer has to make kills a puppy. Both programmers and compiler writers would have enormously benefited from the simple expedient of the 'DCL' keyword (well, 'dcl', of course) like PL/I has. Every "special" character (operator) in C is overloaded. That C compilers actually work will always amaze me. sas
Re: New Metal C standalone product for z/OS
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 (technical) sense. > I hadn't understood that CDESECT exploited SYSADATA. That's a great advantage. > 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 A(BUFF_LEN+7) but not F'BUFF_LEN+7'. > OTOH, DC F'-2147483648' assembles successfully, while DC A(-2147483648) gets a syntax error. A designer's perverse notion of completeness? -- gil
Re: New Metal C standalone product for z/OS
c pointers are like USING if you had as many registers as you wanted. The biggest problem I had with making the leap from assembler to C was the concept that char foo; declares a variable but char bar[n]; is an address, and the corollary that bar is not the same thing as bar[0]. In HLASM 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 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(BUFF_LEN+7) Get The Charles Constant... > > The type of the LABEL is "F" not "A" and you got what you needed. yes? > > This is typically done for certain "ASSIST" type macros that I've used > in the past where they check what the label is (IF, DO, DOWHILE, > SELECT, etc.). > > 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 :)
Re: New Metal C standalone product for z/OS
By "HLASM is not really typed" I mean that subject only to alignment L 0,FOO assembles without complaint whether FOO is a character, a halfword, a word, or a doubleword, and therefore it is hard for software to make guesses about the usage of FOO based on its declaration. 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. The closest that HLASM comes to real typing is when you declare a register to be an AR or a GPR or whatever, and the assembler balks if you use it incorrectly. 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 DC 0F,A(BUFF_LEN+7) Get The Charles Constant... The type of the LABEL is "F" not "A" and you got what you needed. yes? This is typically done for certain "ASSIST" type macros that I've used in the past where they check what the label is (IF, DO, DOWHILE, SELECT, etc.). 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 :) Regards, Steve Thompson On 07/18/2018 01:42 PM, Charles Mills wrote: > It *does* get alignment right. CDSECT's output does not depend on "inherent" > C alignment. Char[8] and uint64_t both end up in the same place. It > constructs the struct using the SYSADATA offsets. It inserts its own padding > where necessary. It emits #pragma pack(packed). > > 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 (technical) sense. > > I fail to see how is any clearer than A, unless you happen to be > coming from a C-only background. Neither one is clear if you don't know what > it means. A means "32-bit pointer." > > 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 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 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 >> uint64_t foo; >> >> It would be easier if the c syntax were char[8] foo; then getting to > uint64_t foo; would be trivial. >> > It seems the designers were fixated on making declarators look > like member references. > >> -Original Message- >> From: Charles Mills >> Sent: Tuesday, July 17, 2018 4:57 PM >> >> 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 valid and the storage layout is correct. >> > Subject to bouldary alignment. > > A more useful design would code the data area descriptions initially > as C structs and supply an ASTRUCT utility to convert to DSECTS. > > I believe I'd name it DESTRUCT. > > Or, an assembler programmer with foresight could have employed SETC > symbols such as: > &__ptr32 SETC A > > POINTER DC &__ptr32(symbol) > ... > Providing some guidance for a CDSECT utility and clarity for the > reader of the source. (IMO, "&__ptr32" conveys better information > than "A". I'm not advocating Hungarian Notation.) > > (This solves nothing for legacy source code.) > > -- gil >
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(BUFF_LEN+7) Get The Charles Constant... The type of the LABEL is "F" not "A" and you got what you needed. yes? This is typically done for certain "ASSIST" type macros that I've used in the past where they check what the label is (IF, DO, DOWHILE, SELECT, etc.). 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 :) Regards, Steve Thompson On 07/18/2018 01:42 PM, Charles Mills wrote: It *does* get alignment right. CDSECT's output does not depend on "inherent" C alignment. Char[8] and uint64_t both end up in the same place. It constructs the struct using the SYSADATA offsets. It inserts its own padding where necessary. It emits #pragma pack(packed). 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 (technical) sense. I fail to see how is any clearer than A, unless you happen to be coming from a C-only background. Neither one is clear if you don't know what it means. A means "32-bit pointer." 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 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 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 uint64_t foo; It would be easier if the c syntax were char[8] foo; then getting to uint64_t foo; would be trivial. It seems the designers were fixated on making declarators look like member references. -Original Message- From: Charles Mills Sent: Tuesday, July 17, 2018 4:57 PM 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 valid and the storage layout is correct. Subject to bouldary alignment. A more useful design would code the data area descriptions initially as C structs and supply an ASTRUCT utility to convert to DSECTS. I believe I'd name it DESTRUCT. Or, an assembler programmer with foresight could have employed SETC symbols such as: &__ptr32 SETC A POINTER DC &__ptr32(symbol) ... Providing some guidance for a CDSECT utility and clarity for the reader of the source. (IMO, "&__ptr32" conveys better information than "A". I'm not advocating Hungarian Notation.) (This solves nothing for legacy source code.) -- gil
Re: New Metal C standalone product for z/OS
* TYPEing DC 0F,A(BUFF_LEN+7) Get The Charles Constant... The type of the LABEL is "F" not "A" and you got what you needed. yes? This is typically done for certain "ASSIST" type macros that I've used in the past where they check what the label is (IF, DO, DOWHILE, SELECT, etc.). 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 :) Regards, Steve Thompson On 07/18/2018 01:42 PM, Charles Mills wrote: It *does* get alignment right. CDSECT's output does not depend on "inherent" C alignment. Char[8] and uint64_t both end up in the same place. It constructs the struct using the SYSADATA offsets. It inserts its own padding where necessary. It emits #pragma pack(packed). 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 (technical) sense. I fail to see how is any clearer than A, unless you happen to be coming from a C-only background. Neither one is clear if you don't know what it means. A means "32-bit pointer." 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 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 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 uint64_t foo; It would be easier if the c syntax were char[8] foo; then getting to uint64_t foo; would be trivial. It seems the designers were fixated on making declarators look like member references. -Original Message- From: Charles Mills Sent: Tuesday, July 17, 2018 4:57 PM 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 valid and the storage layout is correct. Subject to bouldary alignment. A more useful design would code the data area descriptions initially as C structs and supply an ASTRUCT utility to convert to DSECTS. I believe I'd name it DESTRUCT. Or, an assembler programmer with foresight could have employed SETC symbols such as: &__ptr32 SETC A POINTER DC &__ptr32(symbol) ... Providing some guidance for a CDSECT utility and clarity for the reader of the source. (IMO, "&__ptr32" conveys better information than "A". I'm not advocating Hungarian Notation.) (This solves nothing for legacy source code.) -- gil
Re: New Metal C standalone product for z/OS
It *does* get alignment right. CDSECT's output does not depend on "inherent" C alignment. Char[8] and uint64_t both end up in the same place. It constructs the struct using the SYSADATA offsets. It inserts its own padding where necessary. It emits #pragma pack(packed). 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 (technical) sense. I fail to see how is any clearer than A, unless you happen to be coming from a C-only background. Neither one is clear if you don't know what it means. A means "32-bit pointer." 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 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 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 > uint64_t foo; > > It would be easier if the c syntax were char[8] foo; then getting to uint64_t foo; would be trivial. > It seems the designers were fixated on making declarators look like member references. > -Original Message- > From: Charles Mills > Sent: Tuesday, July 17, 2018 4:57 PM > > 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 valid and the storage layout is correct. > Subject to bouldary alignment. A more useful design would code the data area descriptions initially as C structs and supply an ASTRUCT utility to convert to DSECTS. I believe I'd name it DESTRUCT. Or, an assembler programmer with foresight could have employed SETC symbols such as: &__ptr32 SETC A POINTER DC &__ptr32(symbol) ... Providing some guidance for a CDSECT utility and clarity for the reader of the source. (IMO, "&__ptr32" conveys better information than "A". I'm not advocating Hungarian Notation.) (This solves nothing for legacy source code.) -- gil
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 > uint64_t foo; > > It would be easier if the c syntax were char[8] foo; then getting to uint64_t > foo; would be trivial. > It seems the designers were fixated on making declarators look like member references. > -Original Message- > From: Charles Mills > Sent: Tuesday, July 17, 2018 4:57 PM > > 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 valid and the storage layout is correct. > Subject to bouldary alignment. A more useful design would code the data area descriptions initially as C structs and supply an ASTRUCT utility to convert to DSECTS. I believe I'd name it DESTRUCT. Or, an assembler programmer with foresight could have employed SETC symbols such as: &__ptr32 SETC A POINTER DC &__ptr32(symbol) ... Providing some guidance for a CDSECT utility and clarity for the reader of the source. (IMO, "&__ptr32" conveys better information than "A". I'm not advocating Hungarian Notation.) (This solves nothing for legacy source code.) -- gil
Re: New Metal C standalone product for z/OS
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 for z/OS 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. > >I guess if I were handier with regex it would be a piece of cake. I should >just figure it out once and then I would have it. One possibility for a regex (only minimally tested): Search expression: char +(\w(\w|\d)*)\[8\]; Replace expression: uint64_t \1; That should search for: (a) the string "char" followed by 1 or more spaces (b) followed by a "word" character (things like a-z, A-Z, _) followed by 0 or more word characters or digits (c) followed by the string "[8];" The replacement is then the string "uint64_t " followed by whatever was matched in (b) followed by ";". The only questionable part I can think of is in (b), which needs to match all the legal characters in the variable name. Rather than trusting to the definition of \w one could instead use: ([a-zA-Z_][a-zA-z0-9_]*) And then one can add any additional characters between the [] that may be legal in variable names but that aren't covered in \w. Some might need to be escaped with \ if they happen to be significant in regular expressions. Also, some regex engines have somewhat differnt syntaxes, so the final version might depend on what your text editor implements, but something as basic as this one should be fairly robust. -- Walt
Re: New Metal C standalone product for z/OS
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. > >I guess if I were handier with regex it would be a piece of cake. I should >just figure it out once and then I would have it. One possibility for a regex (only minimally tested): Search expression: char +(\w(\w|\d)*)\[8\]; Replace expression: uint64_t \1; That should search for: (a) the string "char" followed by 1 or more spaces (b) followed by a "word" character (things like a-z, A-Z, _) followed by 0 or more word characters or digits (c) followed by the string "[8];" The replacement is then the string "uint64_t " followed by whatever was matched in (b) followed by ";". The only questionable part I can think of is in (b), which needs to match all the legal characters in the variable name. Rather than trusting to the definition of \w one could instead use: ([a-zA-Z_][a-zA-z0-9_]*) And then one can add any additional characters between the [] that may be legal in variable names but that aren't covered in \w. Some might need to be escaped with \ if they happen to be significant in regular expressions. Also, some regex engines have somewhat differnt syntaxes, so the final version might depend on what your text editor implements, but something as basic as this one should be fairly robust. -- Walt
Re: New Metal C standalone product for z/OS
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. I should just figure it out once and then I would have it. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Tuesday, July 17, 2018 4:57 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: New Metal C standalone product for z/OS 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 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 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 variable definitions as "char[4}" or "char[8]". I haven't exercised CDSECT V2.2 yet, it will be interesting to see what it does with those kind of definitions.
Re: New Metal C standalone product for z/OS
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 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 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 variable definitions as "char[4}" or "char[8]". I haven't exercised CDSECT V2.2 yet, it will be interesting to see what it does with those kind of definitions.
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 variable definitions as "char[4}" or "char[8]". I haven't exercised CDSECT V2.2 yet, it will be interesting to see what it does with those kind of definitions. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Farley, Peter x23353 Sent: Tuesday, 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 known address variables as A or AD as needed, add __PTR32 or __PTR64 where needed, and even fix "bugs" 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 product for z/OS 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 ideal? No. But they are syntactically correct and 99% of the time the storage layout is correct, and they do the job. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ze'ev Atlas Sent: Tuesday, July 17, 2018 3:16 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: New Metal C standalone product for z/OS 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, but maintence would be a nigtmare.)OTH, I won't be comfortable relying on some home grown assembler code. I think that if IBM true to the stated goal they should supply a small set of key liw level system callsZA Sent from Yahoo Mail on Android On Tue, Jul 17, 2018 at 1:27 PM, Paul Gilmartin<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: 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 for z/OS > delivers a high-level language alternative to having to write programs > in High Level Assembler (HLASM). The ability to write programs in > HLASM is a specialized skill for the z/OS platform and developers with > expertise in assembler skills are difficult to find. Developers can > use C syntax instead to develop systems programs. This eliminates the > need to manage the use of registers and to manually tune assembler > instruction sequences. Enterprise Metal C for z/OS does this for developers. > What about availability of equivalent of macros for SVC and PC interfaces and control block mapping? Embedded assembler code might suffice for SVC and PC; it's less comfortable to rely on embedded assembler to access control block fields. IBM made a serious mistake in not making PL/S a product a half-century ago. -- 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. 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.
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 known address variables as A or AD as needed, add __PTR32 or __PTR64 where needed, and even fix "bugs" 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 product for z/OS 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 ideal? No. But they are syntactically correct and 99% of the time the storage layout is correct, and they do the job. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ze'ev Atlas Sent: Tuesday, July 17, 2018 3:16 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: New Metal C standalone product for z/OS 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, but maintence would be a nigtmare.)OTH, I won't be comfortable relying on some home grown assembler code. I think that if IBM true to the stated goal they should supply a small set of key liw level system callsZA Sent from Yahoo Mail on Android On Tue, Jul 17, 2018 at 1:27 PM, Paul Gilmartin<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: 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 for z/OS delivers a > high-level language alternative to having to write programs in High Level > Assembler (HLASM). The ability to write programs in HLASM is a specialized > skill for the z/OS platform and developers with expertise in assembler > skills are difficult to find. Developers can use C syntax instead to > develop systems programs. This eliminates the need to manage the use of > registers and to manually tune assembler instruction sequences. Enterprise > Metal C for z/OS does this for developers. > What about availability of equivalent of macros for SVC and PC interfaces and control block mapping? Embedded assembler code might suffice for SVC and PC; it's less comfortable to rely on embedded assembler to access control block fields. IBM made a serious mistake in not making PL/S a product a half-century ago. -- 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.
Re: New Metal C standalone product for z/OS
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 ideal? No. But they are syntactically correct and 99% of the time the > storage layout is correct, and they do the job. > I understand that nowadays new CSECTs are coded in PL/S and translated automatically into assembler. PL/S to C might be a better fit tnan assembler to C. There have been cases where syntax errors percolated into assembler; only the PL/S is tested by IBM. -- gil
Re: New Metal C standalone product for z/OS
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, but maintence would be a nigtmare.)OTH, I won't be comfortable relying on some home grown assembler code. I think that if IBM true to the stated goal they should supply a small set of key liw level system callsZA Sent from Yahoo Mail on Android On Tue, Jul 17, 2018 at 1:27 PM, Paul Gilmartin<0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: 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 for z/OS delivers a > high-level language alternative to having to write programs in High Level > Assembler (HLASM). The ability to write programs in HLASM is a specialized > skill for the z/OS platform and developers with expertise in assembler > skills are difficult to find. Developers can use C syntax instead to > develop systems programs. This eliminates the need to manage the use of > registers and to manually tune assembler instruction sequences. Enterprise > Metal C for z/OS does this for developers. > What about availability of equivalent of macros for SVC and PC interfaces and control block mapping? Embedded assembler code might suffice for SVC and PC; it's less comfortable to rely on embedded assembler to access control block fields. IBM made a serious mistake in not making PL/S a product a half-century ago. -- gil
Re: New Metal C standalone product for z/OS
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 ordered as a stand alone product, separate from XLC. I would hope at a substantially reduced price. > > -- > > -- > > Regards, Gord Tomlin > Action Software International > (a division of Mazda Computer Corporation) > Tel: (905) 470-7113, Fax: (905) 470-6507 > Support: https://actionsoftware.com/support/ > -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown
Re: New Metal C standalone product for z/OS
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). http://www-01.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_ca/6/897/ENUS218-326/index.html=en_locale=en IBM Enterprise Metal C for z/OS Trial, V3.1 is an evaluation release of the Enterprise Metal C for z/OS, V3.1 product that is available with a 90-day evaluation license at no charge for non-production use. It is available from IBM Shopz. Enterprise Metal C for z/OS is the newest, stand-alone offering for the IBM family of development tools. Enterprise Metal C for z/OS delivers a high-level language alternative to having to write programs in High Level Assembler (HLASM). The ability to write programs in HLASM is a specialized skill for the z/OS platform and developers with expertise in assembler skills are difficult to find. Developers can use C syntax instead to develop systems programs. This eliminates the need to manage the use of registers and to manually tune assembler instruction sequences. Enterprise Metal C for z/OS does this for developers. Enterprise Metal C for z/OS allows developers to create high-performing, low-level, free-standing applications. The generated optimized HLASM source code is independent of the Language Environment runtime, and the C runtime is not required for execution. The resulting programs seamlessly integrate with the HLASM code base to provide direct access to z/OS System Services. Enterprise Metal C for z/OS takes advantage of IBM optimization technology to generate high-performance, optimized code. Develop applications with Enterprise Metal C once, and then recompile to optimize for future advancements of IBM z/Architecture® systems. I don't see anything in the announcement that suggests any new functionality has been added to Metal C. -- -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/
Re: New Metal C standalone product for z/OS
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 for z/OS delivers a > high-level language alternative to having to write programs in High Level > Assembler (HLASM). The ability to write programs in HLASM is a specialized > skill for the z/OS platform and developers with expertise in assembler > skills are difficult to find. Developers can use C syntax instead to > develop systems programs. This eliminates the need to manage the use of > registers and to manually tune assembler instruction sequences. Enterprise > Metal C for z/OS does this for developers. > What about availability of equivalent of macros for SVC and PC interfaces and control block mapping? Embedded assembler code might suffice for SVC and PC; it's less comfortable to rely on embedded assembler to access control block fields. IBM made a serious mistake in not making PL/S a product a half-century ago. -- gil
