Re: Metal C and System Programming C (SPC)
On Tue, May 31, 2011 at 12:47 PM, Steve Comstock st...@trainersfriend.comwrote: Are these two products essentially the same? I'm thinking Metal C is the XL C version and SPC is from an earlier C compiler (maybe even pre-z/OS), but I can't find any confirmation. Anyone know the answer to this bit of trivia? Thanks. METAL C permits coding inline assembler. I don't think SPC catered to that. -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our new tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C and System Programming C (SPC)
On 31 May 2011 15:47, Steve Comstock st...@trainersfriend.com wrote: Are these two products essentially the same? I'm thinking Metal C is the XL C version and SPC is from an earlier C compiler (maybe even pre-z/OS), but I can't find any confirmation. Anyone know the answer to this bit of trivia? No - Metal C generates assembler language statements; SPC C generates object decks. I have no knowledge of how they differ under the covers, but unlike SPC, Metal C does not support e.g. the generate backlevel instructions options, and does support inline assembler statements, so it sounds as though there are quite different paths, presumably with some common code. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C and System Programming C (SPC)
On 5/31/2011 1:55 PM, Tony Harminc wrote: On 31 May 2011 15:47, Steve Comstockst...@trainersfriend.com wrote: Are these two products essentially the same? I'm thinking Metal C is the XL C version and SPC is from an earlier C compiler (maybe even pre-z/OS), but I can't find any confirmation. Anyone know the answer to this bit of trivia? No - Metal C generates assembler language statements; SPC C generates object decks. I have no knowledge of how they differ under the covers, but unlike SPC, Metal C does not support e.g. the generate backlevel instructions options, and does support inline assembler statements, so it sounds as though there are quite different paths, presumably with some common code. Tony H. OK, thanks. One further clarification then: is SPC available as part of the current XL C/C++ compiler, or is it a stand alone product? -- Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com * To get a good Return on your Investment, first make an investment! + Training your people is an excellent investment * Try our new tool for calculating your Return On Investment for training dollars at http://www.trainersfriend.com/ROI/roi.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C and System Programming C (SPC)
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Steve Comstock Sent: Tuesday, May 31, 2011 4:13 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Metal C and System Programming C (SPC) On 5/31/2011 1:55 PM, Tony Harminc wrote: On 31 May 2011 15:47, Steve Comstockst...@trainersfriend.com wrote: Are these two products essentially the same? I'm thinking Metal C is the XL C version and SPC is from an earlier C compiler (maybe even pre-z/OS), but I can't find any confirmation. Anyone know the answer to this bit of trivia? No - Metal C generates assembler language statements; SPC C generates object decks. I have no knowledge of how they differ under the covers, but unlike SPC, Metal C does not support e.g. the generate backlevel instructions options, and does support inline assembler statements, so it sounds as though there are quite different paths, presumably with some common code. Tony H. OK, thanks. One further clarification then: is SPC available as part of the current XL C/C++ compiler, or is it a stand alone product? Steve, AFAIK SPC and Metal C are all part of the same product. The SPC documentation is part of the XL C/C++ documentation as well, even though the Metal C docs are separate. The JCL EXEC statement to execute (whatever)C is all the same, EXEC PGM=CCNDRVR, and the STEPLIB's are also the same. The PARM controls what version you actually run. Tony, I'm not so sure about your statement that Metal C does not support generate backlevel instructions. It seems to me that using PARM='ARCH(0),TUN(0)' would produce backlevel instructions from any of the C compiler outputs, would it not? Peter -- 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C and System Programming C (SPC)
On 31 May 2011 17:52, Farley, Peter x23353 peter.far...@broadridge.com wrote: Steve, AFAIK SPC and Metal C are all part of the same product. The SPC documentation is part of the XL C/C++ documentation as well, even though the Metal C docs are separate. The JCL EXEC statement to execute (whatever)C is all the same, EXEC PGM=CCNDRVR, and the STEPLIB's are also the same. The PARM controls what version you actually run. I suspect that program name CCNDRVR says what it is doing, and that there are underlying different versions of the compiler. Or maybe it is just a JCLish front end, like c89 for the UNIX environment. Regardless... Tony, I'm not so sure about your statement that Metal C does not support generate backlevel instructions. It seems to me that using PARM='ARCH(0),TUN(0)' would produce backlevel instructions from any of the C compiler outputs, would it not? One would think so, and I thought the manual said so too. But it doesn't work - specifying ARCH(0) (or anything else lower than the default 5) gets a friendly CCN0790(S) Options METAL and ARCHITECTURE(0) are in conflict. What the book says is that METAL disables: DLL RENT XPLINK IPA HOT DFP METAL sets the following as defaults: ARCH(5) TUNE(5) CSECT HGPR(PRESERVE) FLOAT(IEEE) NOLONGNAME NODEBUG(FORMAT(DWARF),NOHOOK,SYMBOL) METAL ignores the following: TARGET INLRPT GOFF INLINE when OPTIMIZE(0) is in effect All suboptions of INLINE So when it says sets the following as defaults, I assumed they could be overridden, but it seems not. Perhaps it should say METAL forces the following... Or maybe it's almost right, and it's only downlevel code generation they don't do. I haven't played with other combinations of the sets the following as defaults group. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: METAL C Source Code Width
Sounds like an opportunity for IBM to make some changes. I understand 71 for HLASM.. but 98 seems a bit arbitrary. Seems like some sort of utilization option for HLASM for Metal C might be in order. IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 11/08/2009 05:46:10 PM: [image removed] METAL C Source Code Width Edward Jaffe to: IBM-MAIN 11/08/2009 05:51 PM Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Please respond to IBM Mainframe Discussion List Just curious what source line width most people are using for METAL C programs. The C compiler supports wider than 80 columns, which is liberating. However, the area on the compiler listing data set (SYSCPRT) is only 98 columns, meaning long source lines will wrap, which is ugly. And, the C source is further emitted in the HLASM input as comments, which are truncated after column 71,which is even uglier. :-( -- Edward E Jaffe -Rob Schramm -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C and CICS
Bill Klein wrote: (to IBM-MAIN and CICS lists), I have asked this off-list but so far can't find an answer. Can anyone tell me if Metal C is supported with (works under) CICS or not? I can imagine that it would be pretty unusual to want this, but as HLASM (both LE-enabled and not) works with CICS, I was thinking that Metal C may as well (withOUT the LE CICS run-time libraries). Metal C will run under CICS with some caveats. Because Metal C generates HLASM code it can run anywhere HLASM runs (everywhere). The problem will be if you want to use a Metal/C environment, which will attempt to allocate storage with a GETMAIN. CICS will obviously choke when that happens. Some Metal C runtime functions require an environment, for example sprintf(). I would suggest asking z/OS C/C++ questions in the new cafe http://www-949.ibm.com/software/rational/cafe/community/ccpp. BTW, out of interest why would you want to run a Metal C program in CICS when LE C does the job just fine? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C and CICS
On Fri, 8 May 2009 16:01:10 +0800, David Crayford wrote: Metal C will run under CICS with some caveats. Because Metal C generates HLASM code it can run anywhere HLASM runs (everywhere). ... You neglected to assert the major premise of your syllogism, with which I believe I disagree: Any language processor which generates HLASM code can run anywhere HLASM runs (everywhere). Going further, any language that produces a SYSLIN file that can be disassembled to HLASM code can run anywhere HLASM runs (everywhere). The devil is in the caveats. Or in the non sequitur. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: METAL C: CodeGen defeciency?
Let suppose IBM make processors with predicatble instruction speed, no heuristics etc , as it had been. We are back (with assembler) again ? Interesting that they didn't use XC, isn't it? If you spend any time looking at XLC generated code you will see lots of interesting stuff. Of particular interest is some of the loop unwinding optimizations. After a while you start to wonder if you should ever write in assembler again, since only IBM knows what instruction heuristics slide through the pipelines the best. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Miklos Szigetvari Development Team ISIS Information Systems Gmbh tel: (+43) 2236 27551 570 Fax: (+43) 2236 21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our Website: http://www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: METAL C: CodeGen defeciency?
Paul Gilmartin wrote: On Wed, 22 Apr 2009 13:36:13 -0400, Thomas David Rivers wrote: * setting 14 bytes to 0x00 XC102(14,13),102(13) You're only trying to help the programmer, but perhaps thereby thwarting the intent of a deliberate Dirty GETMAIN. This setting-of-zero is required by the ANSI C standard. Essentially, if you initialize part of an aggregate (in this case, an array) the remainder is given zero values. The array is defined as having 20 bytes, with only the first 6 being explicitly initialized by the programmer. - Dave Rivers - -- riv...@dignus.comWork: (919) 676-0847 Get your mainframe programming tools at http://www.dignus.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: METAL C: CodeGen defeciency?
On Thu, 2009-04-23 at 12:55 -0400, Bill Klein wrote: See IBM response IBM response in quotes, I know. Whatever influential IBMers are out there, know that at least one customer *really* appreciates this kind of give-and-take. ibm-main is not an official support forum, requirements should be taken up with SHARE or your business partner, yadda yadda. I understand all that. But I'm grateful for Peter, Jim, John, Greg, Tom, Marna, Martin, Martha, Kelly -- the list goes on. Y'all put the face on IBM. -- David Andrews A. Duda and Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: METAL C: CodeGen defeciency?
On Thu, 23 Apr 2009 11:55:18 -0500, Bill Klein wmkl...@ix.netcom.com wrote: It looks as if Kelly posted this directly to the newsgroup and didn't send it to the list. My apologies. Thanks Bill. Kel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: METAL C: CodeGen defeciency?
Johnny Luo wrote:
Hi,
I was trying new METAL option of XL C and the following is the HLASM code
generated :
* {
*char a[20]=12345;
MVC 88(6,13),0(11)
MVI @74a+6,0
MVC @74a+7(13),@74a+6
MVI @74a+6,0
MVC @74a+7(13),@74a+6
* return;
* }
It initialized the buffer twice! I cannot think of why. Is it normal?
Not to point too many fingers, but since we did it first,
here's what Systems/C did with Johnny's example:
* *
* *** char a[20]=12345;
LA14,@lit_6_0
MVC 96(6,13),0(14)
* setting 14 bytes to 0x00
XC102(14,13),102(13)
* *** return;
* *** }
- Dave Rivers -
--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: METAL C: CodeGen defeciency?
On Wed, 22 Apr 2009 13:36:13 -0400, Thomas David Rivers wrote:
Johnny Luo wrote:
Hi,
I was trying new METAL option of XL C and the following is the HLASM code
generated :
* {
*char a[20]=12345;
MVC 88(6,13),0(11)
Is that the actual initialization, in which case the next 4
instructions are incomprehensible?
MVI @74a+6,0
MVC @74a+7(13),@74a+6
MVI @74a+6,0
MVC @74a+7(13),@74a+6
* return;
* }
I wouldn't expect it to move 13 characters to assign a 5-character
(well, 6, counting the terminating NUL) in a 20-character buffer.
It initialized the buffer twice! I cannot think of why. Is it normal?
Not to point too many fingers, but since we did it first,
here's what Systems/C did with Johnny's example:
* *
* *** char a[20]=12345;
LA14,@lit_6_0
MVC 96(6,13),0(14)
Wouldn't it work to:
MVC 96(6,13),@lit_6_0
...? If the LA works you have addressability. Yah, I know;
I've worked with (simple) code generators. I probably don't
understand the environmental constraints. Perhaps as simple
as the optimizer detected a need for R14 subsequently.
* setting 14 bytes to 0x00
XC102(14,13),102(13)
You're only trying to help the programmer, but perhaps thereby
thwarting the intent of a deliberate Dirty GETMAIN.
* *** return;
* *** }
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: METAL C: CodeGen defeciency?
On Wed, Apr 22, 2009 at 6:25 PM, Paul Gilmartin paulgboul...@aim.com wrote:
On Wed, 22 Apr 2009 13:36:13 -0400, Thomas David Rivers wrote:
Johnny Luo wrote:
Hi,
I was trying new METAL option of XL C and the following is the HLASM code
generated :
* {
* char a[20]=12345;
MVC 88(6,13),0(11)
Is that the actual initialization, in which case the next 4
instructions are incomprehensible?
MVI @74a+6,0
MVC @74a+7(13),@74a+6
MVI @74a+6,0
MVC @74a+7(13),@74a+6
* return;
* }
I wouldn't expect it to move 13 characters to assign a 5-character
(well, 6, counting the terminating NUL) in a 20-character buffer.
It is initializing the rest of the automatic storage to zeros (twice),
which probably has to do with the compiler options in effect.
I can't say why it is done twice; seems like a bug to me.
I would suggest that you compile the same thing with the regular XLC
compiler and look at the generated assembler listing to see if it does
the same thing (double zeroing).
Interesting that they didn't use XC, isn't it? If you spend any time
looking at XLC generated code you will see lots of interesting stuff.
Of particular interest is some of the loop unwinding optimizations.
After a while you start to wonder if you should ever write in
assembler again, since only IBM knows what instruction heuristics
slide through the pipelines the best.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C Question (was COBOL Java Ldap and between)
Rob Schramm wrote: Does anyone know if the license for the IBM Metal C is more attractive to the customers that may have balked at the IBM C/C++ compiler? AFAIK, METAL is an option not a compiler. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C Question (was COBOL Java Ldap and between)
AFAIK, METAL is an option not a compiler That is correct. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C Question (was COBOL Java Ldap and between)
Huh.. well.. I guess I am off to the manual/announcements. I was under the impression that it was separately ordered... not just a part of the existing C/C++ offering. I must have been engaging in wishful thinking. -Rob Schramm Sirius Computer Solutions AFAIK, METAL is an option not a compiler That is correct. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C
Tony Harminc wrote: Then it seems that METAL inhibits use of the ARCH option, so METAL C must generate code at the ARCH(CURRENT) level, which means it can (and does) use LARL and the like from the long displacement facility. Well, no, actually it accepts ARCH(5), which says is the default and generates code at the z900/z800 level, but it still generates LARL, which I don't believe is architected at that level. LARL was added to the ESA/390 instruction set implemented on the very first machines supporting z/Architecture. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C (was Re: PL/S ??)
On Fri, 2 Nov 2007 11:28:49 -0500, Scott Fagen [EMAIL PROTECTED] wrote: The runtime environment is only required if you make use of the services provided by the runtime environment. It also doesn't change the fact that HLASM is what is emitted. It is not like 'regular' C which cannot execute without an LE environment and the LE RTL linked with your program. Let's not forget the System Programming C (SPC) option, which has been around for many years. This was sold early on as a facility for writing exits and the like, and indeed it can be used for just about environment-free programming. It comes with a smaller-than-LE RTL, and you can provide your own heap and stack management routines. But it emits object code rather than HLASM statements, so you can't include inline assembler. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C (was Re: PL/S ??)
On Fri, 2 Nov 2007 01:24:13 -0500, Bruce Hewson [EMAIL PROTECTED] wrote: It does say! You can use the METAL C option to generate code that does not have Language Environment runtime dependencies. And it also says! Metal C Runtime Library The Metal C Runtime Library is a new base element of z/OS and is completely independent of Language Environment. The library modules are made available in the link pack area (LPA) during IPL. Both AMODE 31 and 64 are supported, as long as you are calling the functions in primary address space control (ASC) mode. The library functions make use of the default linkage provided by the compilers METAL option, which requires a small contiguous stack that uses the standard save area convention that z/OS assembler programmers are familiar with. The runtime environment is only required if you make use of the services provided by the runtime environment. It also doesn't change the fact that HLASM is what is emitted. It is not like 'regular' C which cannot execute without an LE environment and the LE RTL linked with your program. Scott Fagen Enterprise Systems Management -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C (was Re: PL/S ??)
On Fri, 2 Nov 2007 11:55:08 -0500, Tony Harminc [EMAIL PROTECTED] wrote: Let's not forget the System Programming C (SPC) option, which has been around for many years. This was sold early on as a facility for writing exits and the like, and indeed it can be used for just about environment-free programming. It comes with a smaller-than-LE RTL, and you can provide your own heap and stack management routines. But it emits object code rather than HLASM statements, so you can't include inline assembler. Actually, I _do_ try to forget that g, as you needed to manage and connect up your own runtime environments to the routines as they got control. Not particularly friendly for code that might have high reentrancy requirements or could execute in any address space (like system exits). With all due apologies to Anuja, Scott Fagen Enterprise Systems Management -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C (was Re: PL/S ??)
Tony Harminc wrote: Let's not forget the System Programming C (SPC) option, which has been around for many years. This was sold early on as a facility for writing exits and the like, and indeed it can be used for just about environment-free programming. It comes with a smaller-than-LE RTL, and you can provide your own heap and stack management routines. But it emits object code rather than HLASM statements, so you can't include inline assembler. We use SPC to support products that run in z/OS, z/VSE, and CMS. We have our own run-time library. METAL C looks good, but I haven't seen any SOD about providing its LPA-resident library functions in other (non-z/OS) environments. That seems to imply we will be stuck with SPC for the foreseeable future. Hopefully, IBM won't do something stupid like desupport it. They've already de-emphasized its development to the point where we've had to start policing them to be sure they don't mess things up when people work on it that don't understand the big picture. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Metal C (was Re: PL/S ??)
This was supposed to have a new subject.so I have re-posted... On Fri, 2 Nov 2007 01:21:16 -0500, Bruce Hewson [EMAIL PROTECTED] wrote: Hello Scott, The METAL C option does not provide bare metal HL/ASM code. It does require a new z/OS base element which is the run-time library. your reference: == http://www-03.ibm.com/servers/eserver/zseries/zos/metalc extracts from that page: == It does say! You can use the METAL C option to generate code that does not have Language Environment runtime dependencies. And it also says! Metal C Runtime Library The Metal C Runtime Library is a new base element of z/OS and is completely independent of Language Environment. The library modules are made available in the link pack area (LPA) during IPL. Both AMODE 31 and 64 are supported, as long as you are calling the functions in primary address space control (ASC) mode. The library functions make use of the default linkage provided by the compilers METAL option, which requires a small contiguous stack that uses the standard save area convention that z/OS assembler programmers are familiar with. On Thu, 1 Nov 2007 17:45:26 -0500, Scott Fagen [EMAIL PROTECTED] wrote: snip Recently, IBM has made something better available: http://www-306.ibm.com/software/awdtools/czos/features/czosv1r9.html Look for METAL option. Scott Fagen Enterprise Systems Management Regards Bruce Hewson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
