If that type of "low level" code is needed (i.e. it can't be done in COBOL), then some shops such as mine will continue to use HLASM until the C/C++ compiler is "free". And might not use C/C++ or Metal C even if it were like HLASM and included in the z/OS license. We have no real need for C/C++ on z/OS due to "lack of interest" in it by IT management. The only experienced HLASM programmers left here are my manager and myself. All our applications programmers are COBOL only. I have a low-middle knowledge of C,less of C++. I don't think my manager knows C/C++ at all. And he would likely not let me use Metal C instead of HLASM because only I could support it. Not that it matters much because he has, reasonably for this shop, tried to avoid using any exits for any products.
>From a personal standpoint, if I had the choice, I would likely use C for some >applications and even Metal C for exits instead of HLASM. But I can't know >that for certain because I've never had the choice. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of Kirk Wolf > Sent: Friday, April 13, 2012 9:24 AM > To: [email protected] > Subject: Re: Modernizing the BCP code ? > > It is also interesting (to me) to point out that "Metal C" > uses the same > back-end. > Metal-C generates assembler code which is not dependent on > the C library or > LE, supports user inlined assembler code, etc. Just like > with C/C++, you > can specify ARCH(),TUNE(), INLINE, etc. > > With the explosion of new instructions, at what point does writing > hand-written assembler code become less and less practical? > > Kirk Wolf > Dovetailed Technologies > http://dovetail.com > > On Thu, Apr 12, 2012 at 11:29 PM, Tom Ross > <[email protected]>wrote: > > > > > That is close to what I said. I said that C/C++ and PL/I > currently share > > a common back end, and that eventually IBM would like all > compilers to > > share > > a common backend. In response to another comment, the JIT > compiler does > > create optimized sequences of instructions, and we hope to > use some of > > that technology as well in a new COBOL compiler release. > > > > As for assembler code generated for COBOL usage of BINARY > data items, we > > are highly influenced by the COBOL standard. COBOL data > items are all > > base 10, with digits 1-9, so mapping BINARY data items to > that requires > > some trickery. The good news is that you can process > dollars and cents > > in many different data types with no floating points if you want to, > > unlike some other languages. > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
