On Wed, Mar 26, 2014 at 11:03 PM, David Crayford dcrayf...@gmail.comwrote:
...
We use the same technique. Grrr, __malloc31(), __malloc24() only supported
in AMODE(64)! How brain damaged is that?
No kidding! And you can't call CEEGTST from your 64-bit code to get
24-bit storage, since
@LISTSERV.UA.EDU
Sent: Tuesday, March 25, 2014 11:38 PM
Subject: Re: Metal C vs. HLASM - for C callable subroutine?
On 2014-03-25 22:11, David Crayford wrote:
I find that I rarely need Metal/C. What I do want to do is inline
assembler into LE code.
I have found Metal to be useful in a few situations
David,
I agree - this would be GREAT. I've asked IBM about this and I think that
at the time they said that it was a known requirement. Will be asking
again next week. In the meantime, I would suggest that all interested
submit your requirements.
What we do (a lot) is to write XPLINK
David Crayford wrote:
On 26/03/2014 4:32 AM, Tony Harminc wrote:
On 25 March 2014 16:16, Paul Gilmartin paulgboul...@aim.com wrote:
Wouldn't it be nice if all the header files were trilingual?
Assembler/PLS/Metal C? It'll take a while.
Ugh, please. :-( There's nothing wrong with Metal C
In 3653742774909972.wa.paulgboulderaim@listserv.ua.edu, on
03/25/2014
at 06:03 PM, Paul Gilmartin paulgboul...@aim.com said:
Actually, I can. That's an implementation technique. Suppose a
Requirement for trilingual macros were to be submitted to IBM.
They'd reject it.
It's my
On 27/03/2014 12:20 AM, Kirk Wolf wrote:
David,
I agree - this would be GREAT. I've asked IBM about this and I think that
at the time they said that it was a known requirement. Will be asking
again next week. In the meantime, I would suggest that all interested
submit your requirements.
Yes, I am reading the book on Metal C. But I often appreciate other
peoples' opinions and ideas. So I'm just asking.
I am porting some C code to z/OS (nedit thread on MVS-OE). I need to be
able to do z/OS enqueues and dequeues. I don't see any C subroutine to do
this. So I need to write
On 2014-03-25 13:29, John McKown wrote:
Yes, I am reading the book on Metal C. But I often appreciate other
peoples' opinions and ideas. So I'm just asking.
I am porting some C code to z/OS (nedit thread on MVS-OE). I need to be
able to do z/OS enqueues and dequeues. I don't see any C
John:
I have to look but can you do :
__asm ….inline
Regards,
Scott
From: John McKown
Sent: Tuesday, March 25, 2014 1:29 PM
To: IBM Mainframe Discussion List
Yes, I am reading the book on Metal C. But I often appreciate other
peoples' opinions and ideas. So I'm just
But that's only in Metal C, if I'm reading it correctly. I may do this for
a learning experience. What I may learn is don't _do_ that! grin/
On Tue, Mar 25, 2014 at 2:36 PM, Scott Ford scott_j_f...@yahoo.com wrote:
John:
I have to look but can you do :
__asm ….inline
Regards,
Scott
On Tue, 25 Mar 2014 13:57:16 -0400, Gord Tomlin wrote:
If you are already using LE and XPLINK for the nedit C code, then I'm
not sure I see the benefit to writing a Metal C subroutine to do the
ENQ/DEQ. The C code in this case will likely be mostly comprised of
inline Assembler with the cryptic
On 25 March 2014 16:16, Paul Gilmartin paulgboul...@aim.com wrote:
Wouldn't it be nice if all the header files were trilingual?
Assembler/PLS/Metal C? It'll take a while.
Ugh, please. :-( There's nothing wrong with Metal C that a complete
redesign wouldn't fix.
But in any case, what would
On Tue, 25 Mar 2014 16:32:43 -0400, Tony Harminc wrote:
On 25 March 2014 16:16, Paul Gilmartin paulgboul...@aim.com wrote:
Wouldn't it be nice if all the header files were trilingual?
Assembler/PLS/Metal C? It'll take a while.
Ugh, please. :-( There's nothing wrong with Metal C that a
On 25 March 2014 16:56, Paul Gilmartin paulgboul...@aim.com wrote:
But in any case, what would you do to allow PL/X and C to pick out
their own code? The assembler vs PL/X or C comment format makes it
easy, but both PL/X and C have /* comments */ .
#if ?
But how will both PL/X and assembler not
On Tue, 25 Mar 2014 17:53:50 -0400, Tony Harminc wrote:
On 25 March 2014 16:56, Paul Gilmartin paulgboul...@aim.com wrote:
But in any case, what would you do to allow PL/X and C to pick out
their own code? The assembler vs PL/X or C comment format makes it
easy, but both PL/X and C have /*
On 25 March 2014 18:11, Paul Gilmartin paulgboul...@aim.com wrote:
#if ?
But how will both PL/X and assembler not see it?
That's their problem. Perhaps AGO for assembler. And hasn't
PL/X something similar?
Well you can't reasonably ask for trilingual macros and then shrug
your shoulders
On Tue, 25 Mar 2014 18:38:14 -0400, Tony Harminc wrote:
Well you can't reasonably ask for trilingual macros and then shrug
your shoulders when asked for how it might work.
Actually, I can. That's an implementation technique. Suppose a
Requirement for trilingual macros were to be submitted to
On 25 March 2014 19:03, Paul Gilmartin paulgboul...@aim.com wrote:
Well you can't reasonably ask for trilingual macros and then shrug
your shoulders when asked for how it might work.
Actually, I can. That's an implementation technique. Suppose a
Requirement for trilingual macros were to
On Tue, 25 Mar 2014 19:15:45 -0400, Tony Harminc wrote:
Sigh. By the same token asking for trilingual macros is an
implementation technique. What is the business problem you want IBM to
address? Perhaps shipping mappings for all three languages, with
identical names and such? Then maybe IBM can
On 26/03/2014 4:32 AM, Tony Harminc wrote:
On 25 March 2014 16:16, Paul Gilmartin paulgboul...@aim.com wrote:
Wouldn't it be nice if all the header files were trilingual?
Assembler/PLS/Metal C? It'll take a while.
Ugh, please. :-( There's nothing wrong with Metal C that a complete
redesign
On 2014-03-25 22:11, David Crayford wrote:
I find that I rarely need Metal/C. What I do want to do is inline
assembler into LE code.
I have found Metal to be useful in a few situations where it is
desirable to have a self-contained program with inline Assembler and no
dependencies on the LE
21 matches
Mail list logo
