Re: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
My meager understanding of compiling is that it is a multi-phase process internally. code generation is the second last phase. the last phase being reporting, i.e. the listing etc. One would not want to generate C but whatever the stuff is that C produces in its parse+ portion, before it does code generation. I have seen on this list comments that PL/I and C share part of the code generation. why not add Cobol to the mix? It is a less rich language than either C or PL/I. IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 10/12/2009 07:42:30 PM: A COBOL compiler that runs on Linux (including Linux for System z) does produce intermediate C code, before running it through GCC. It is not technically considered a GCC based COBOL, though. Take a look at OpenCOBOL, http://www.opencobol.org. There was some work done some years ago on GCC COBOL, but it has lagged somewhat. I have heard recently that the maintainer was going to get back to it. But, GCC COBOL was going to use LISP. When I read that, I lost interest. Kirk Talman wrote: Why can't Cobol use the C code generator? - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
On 13 Oct 2009 09:58:31 -0700, in bit.listserv.ibm-main you wrote: My meager understanding of compiling is that it is a multi-phase process internally. code generation is the second last phase. the last phase being reporting, i.e. the listing etc. One would not want to generate C but whatever the stuff is that C produces in its parse+ portion, before it does code generation. I have seen on this list comments that PL/I and C share part of the code generation. why not add Cobol to the mix? It is a less rich language than either C or PL/I. I will almost guarantee that COBOL has constructs that C/C++ doesn't plus depending on the C/C++, decimal data types PL1 may still effectively be a superset of COBOL rest snipped -- 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
This new article in zJournal might be of some interest in the context of this thread: http://www.zjournal.com/index.cfm?section=articleaid=1231 Kirk Wolf Dovetailed Technologies http://dovetail.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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
Why can't Cobol use the C code generator? IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 10/09/2009 04:55:20 PM: Meanwhile, IBM spends considerable effort in optimizing its C/C++ compilers. Customers with C and C++ applications have more alternatives to Big Iron. - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
On 12 Oct 2009 10:37:56 -0700, in bit.listserv.ibm-main Kirk Talman wrote: Why can't Cobol use the C code generator? IBM could write a parser to generate optimal C/C++ code from COBOL but that would be a large investment and might not produce as good results as the current compiler parser generator. The C/C++ generator might not have the handling for the COBOL edited moves. IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 10/09/2009 04:55:20 PM: Meanwhile, IBM spends considerable effort in optimizing its C/C++ compilers. Customers with C and C++ applications have more alternatives to Big Iron. -- 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
IBM needs to keep optimizing the c/c++ compiler to support *nix/windows server consolidation onto zLinux. On Mon, Oct 12, 2009 at 7:47 PM, Clark Morris cfmpub...@ns.sympatico.cawrote: On 12 Oct 2009 10:37:56 -0700, in bit.listserv.ibm-main Kirk Talman wrote: Why can't Cobol use the C code generator? IBM could write a parser to generate optimal C/C++ code from COBOL but that would be a large investment and might not produce as good results as the current compiler parser generator. The C/C++ generator might not have the handling for the COBOL edited moves. IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 10/09/2009 04:55:20 PM: Meanwhile, IBM spends considerable effort in optimizing its C/C++ compilers. Customers with C and C++ applications have more alternatives to Big Iron. -- 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sam Siegel Sent: Monday, October 12, 2009 3:00 PM To: IBM-MAIN@bama.ua.edu Subject: Re: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions? IBM needs to keep optimizing the c/c++ compiler to support *nix/windows server consolidation onto zLinux. But doesn't z/Linux require the use of gcc for the C/C++ compiler? That would be a different engine than the c89 (or whatever it's called) compiler on z/OS Unix Services, wouldn't it? 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
I think they are tightly related. Looking at the compiler suite from the outside it would seem that parsing, options, run-time-libraries, STL support, Inter-procedures analysis, etc. would be very common across platforms because much of this is standards based. The code generation would be machine and OS specific. Also, much of the doc mentions all of their platforms and highlights which extensions are relevant for each. Sam On Mon, Oct 12, 2009 at 8:09 PM, Farley, Peter x23353 peter.far...@broadridge.com wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sam Siegel Sent: Monday, October 12, 2009 3:00 PM To: IBM-MAIN@bama.ua.edu Subject: Re: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions? IBM needs to keep optimizing the c/c++ compiler to support *nix/windows server consolidation onto zLinux. But doesn't z/Linux require the use of gcc for the C/C++ compiler? That would be a different engine than the c89 (or whatever it's called) compiler on z/OS Unix Services, wouldn't it? 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 -- 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
http://www-01.ibm.com/software/awdtools/xlcpp/aix/ http://www-01.ibm.com/software/awdtools/xlcpp/aix/From IBM's website: C and C++ compilers, available for many IBM platforms, share a common code base that simplifies porting applications between platforms. On Mon, Oct 12, 2009 at 8:19 PM, Sam Siegel s...@pscsi.net wrote: I think they are tightly related. Looking at the compiler suite from the outside it would seem that parsing, options, run-time-libraries, STL support, Inter-procedures analysis, etc. would be very common across platforms because much of this is standards based. The code generation would be machine and OS specific. Also, much of the doc mentions all of their platforms and highlights which extensions are relevant for each. Sam On Mon, Oct 12, 2009 at 8:09 PM, Farley, Peter x23353 peter.far...@broadridge.com wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sam Siegel Sent: Monday, October 12, 2009 3:00 PM To: IBM-MAIN@bama.ua.edu Subject: Re: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions? IBM needs to keep optimizing the c/c++ compiler to support *nix/windows server consolidation onto zLinux. But doesn't z/Linux require the use of gcc for the C/C++ compiler? That would be a different engine than the c89 (or whatever it's called) compiler on z/OS Unix Services, wouldn't it? 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 -- 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
A COBOL compiler that runs on Linux (including Linux for System z) does produce intermediate C code, before running it through GCC. It is not technically considered a GCC based COBOL, though. Take a look at OpenCOBOL, http://www.opencobol.org. There was some work done some years ago on GCC COBOL, but it has lagged somewhat. I have heard recently that the maintainer was going to get back to it. But, GCC COBOL was going to use LISP. When I read that, I lost interest. Kirk Talman wrote: Why can't Cobol use the C code generator? -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2010 - Apr 9-14, 2010 Covington, KY -- 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
COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
Clark Morris cfmpub...@ns.sympatico.ca wrote in message news:mq7tc51ajbefs2n1tc5e769m2gb2aep...@4ax.com... On 8 Oct 2009 14:08:24 -0700, in bit.listserv.ibm-main you wrote: snip It could be done much snippage For those in IBM-MAIN who don't follow such things. Clark has had long running desires of how it would like to see IBM COBOL development prioritize things. When voted upon by SHARE (LNGC project) members, many of the things that Clark wants are things that current IBM customers also want. HOWEVER, in most cases, those enhancements that IBM has delivered in recent releases and versions of Enterprise COBOL have received HIGHER priorities from customers (in and out of SHARE) that those things that Clark has asked for. I suspect that many (Possibly even most) existing IBM COBOL customers would like it if IBM COBOL development had unlimited resources for enhancements - ASSUMING that the cost of COBOL to their shops did not increase and that all future COBOL environments were %100 per cent upwardly (and downwardly) compatible. This isn't true and is unlike to ever be true. Therefore, similar to other specific IBM-MAIN participants who hate such things as LE, his repeated posts ranting bout specific issues (such as 64-bit COBOL and *non* decimal IEEE floating point) provide little service. OBVIOUSLY, if any other IBM-MAIN participant belongs to SHARE and wants to see some new/different enhancement request for Enterprise COBOL processed, I would encourage you to use the SHARE requirement process and/or marketing REQUEST procedures. I can certainly help you with the SHARE requirement process if you are interested in such. If you are interested in specific things that have already been voted upon by LNGC (such as 64-bit COBOL and/or IEEE binary Floating-Point), then I would be more than happy to provide you with information on the existing requirements and you submit a marketing REQUEST that references them. -- 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
Wrong equations :-) What is the *business case* for adding better optimizations to the COBOL compiler? Back in the day when there was fierce PCM competition, you could add new instructions and then spend money in compiler exploitation as a competitive advantage. Now the business case is a little fuzzier, I would guess. On Fri, Oct 9, 2009 at 8:20 AM, David Andrews d...@lists.duda.com wrote: On Fri, 2009-10-09 at 02:32 -0400, Bill Klein wrote: I suspect that many (Possibly even most) existing IBM COBOL customers would like it if IBM COBOL development had unlimited resources for enhancements Unlimited? No, but if IBM applied a higher percentage of gross it would be nice. Rounding down, on my dinky little 15 MSU box I pay $900 a month for COBOL. There are something like 10,000 mainframe customers, so suppose that they all have dinky little 15 MSU boxes like me and that only 10% of them use COBOL. That's $900,000/month revenue for the COBOL effort at IBM, or a little over $10M per year, and pretty conservative numbers. I'll bet I could rent some nice office space and hire a small team of superprogrammers for that same money, PLUS have enough to pay a modest shareholder dividend. Yeah I know, IBM has other expenses that have to be covered: admin types, testers, support staff. Tom Ross's attention at SHARE isn't free, and he likely has a bigger development crew than my imaginary small team of superprogrammers. But holy cash cow, ten megabucks! -- 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 -- 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
On Fri, Oct 9, 2009 at 2:48 PM, Kirk Wolf k...@dovetail.com wrote: Wrong equations :-) What is the *business case* for adding better optimizations to the COBOL compiler? Back in the day when there was fierce PCM competition, you could add new instructions and then spend money in compiler exploitation as a competitive advantage. Now the business case is a little fuzzier, I would guess. Sure; the case is making z more competitive against the squatty little boxes, but that's clearly MUCH fuzzier. And not warmer. Just fuzzier. -- 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
To add even more topic-skew, no mention of a full blown COBOL port to zLinux with ahem.. CICS. JC = On Fri, Oct 9, 2009 at 2:48 PM, Kirk Wolf k...@dovetail.com wrote: = Wrong equations :-) = What is the *business case* for adding better optimizations to the = COBOL compiler? = = Back in the day when there was fierce PCM competition, you could add = new instructions and then spend money in compiler exploitation as a = competitive advantage. Now the business case is a little fuzzier, I = would guess. = = Sure; the case is making z more competitive against the squatty = little boxes, but that's clearly MUCH fuzzier. And not warmer. Just = fuzzier. = = -- = 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 = John Cassidy (Dipl.-Ingr.) Kapellenstr. 21a 65193 Wiesbaden Germany Mobile: +49 (0) 170 794 3616 http://www.JDCassidy.net http://en.federaleurope.org/ http://sva-zhosting.com/en/index.php -- 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Andrews Sent: Friday, October 09, 2009 9:20 AM To: IBM-MAIN@bama.ua.edu Subject: Re: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions? Snipped I'll bet I could rent some nice office space and hire a small team of superprogrammers for that same money, PLUS have enough to pay a modest shareholder dividend. BUT the resulting reduction in customer CPU utilization would cannibalize the additional hardware sales that would have been made when customer work volume increases, making the hardware side of the house *very* unhappy... Reducing customer CPU utilization likely loses IBM more money than it makes them, so guess what priority optimal code generation is likely to have? 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
Meanwhile, IBM spends considerable effort in optimizing its C/C++ compilers. Customers with C and C++ applications have more alternatives to Big Iron. Farley, Peter x23353 wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Andrews Sent: Friday, October 09, 2009 9:20 AM To: IBM-MAIN@bama.ua.edu Subject: Re: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions? Snipped I'll bet I could rent some nice office space and hire a small team of superprogrammers for that same money, PLUS have enough to pay a modest shareholder dividend. BUT the resulting reduction in customer CPU utilization would cannibalize the additional hardware sales that would have been made when customer work volume increases, making the hardware side of the house *very* unhappy... Reducing customer CPU utilization likely loses IBM more money than it makes them, so guess what priority optimal code generation is likely to have? 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 -- 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
COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
Obviously given the lack of support for 64 bit, the failure to implement 64 bit addressing so COBOL can run nicely in 64 bit Websphere, the failure to implement USAGE BIT, the failure to implement the IBM pushed decimal floating point, the failure to implement IEEE floating point using the 2002 COBOL STANDARD floating point usages, it is obvious COBOL is seen as a cash cow to be milked until phase-out. On 8 Oct 2009 12:45:16 -0700, in bit.listserv.ibm-main you wrote: Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Steve Comstock Farley, Peter x23353 wrote: I did not see anything about it in the updates page in the language reference nor the programmer's guide, but I'm wondering if anyone here knows if the newest release of the Enterprise COBOL compiler will generate grande arithmetic instructions for COBOL binary fields (e.g. will it generate an AG or AGR instruction for adding two PIC S9(18) BINARY fields?). 1. Latest and greatest is actually Enterprise COBOL 4.2 2. Ran an experiment for you; here is the generated code for 'add fld-d to fld-e' where both are pic s9(18) binary: Did you try it with PIC S9(18) COMP-5? -jc- No, but good idea; so here it is: LM2,3,48(8) FLD-D SLDA 2,0(0) BC11,394(0,11)GN=31(0009EA) LCR 2,2 LCR 3,3 BC8,394(0,11) GN=31(0009EA) BCTR 2,0 GN=31EQU * ZAP 344(16,13),1367(1,10) TS2=0 LTR 2,2 BC2,420(0,11) GN=32(000A04) BC8,436(0,11) GN=33(000A14) AP344(16,13),1354(6,10) TS2=0 X 2,1336(0,10)PGMLIT AT +1324 GN=32EQU * CVD 2,360(0,13) TS2=16 AP344(16,13),360(8,13)TS2=0 MP344(16,13),1348(6,10) TS2=0 GN=33EQU * LTR 3,3 BC2,456(0,11) GN=34(000A28) BC8,466(0,11) GN=35(000A32) AP344(16,13),1354(6,10) TS2=0 X 3,1336(0,10)PGMLIT AT +1324 GN=34EQU * CVD 3,360(0,13) TS2=16 AP344(16,13),360(8,13)TS2=0 GN=35EQU * TM48(8),X'80' FLD-D BC8,478(0,11) GN=36(000A3E) OI359(13),X'01' TS2=15 GN=36EQU * LM2,3,56(8) FLD-E SLDA 2,0(0) BC11,500(0,11)GN=37(000A54) LCR 2,2 LCR 3,3 BC8,500(0,11) GN=37(000A54) BCTR 2,0 GN=37EQU * ZAP 360(16,13),1367(1,10) TS2=16 LTR 2,2 BC2,526(0,11) GN=38(000A6E) BC8,542(0,11) GN=39(000A7E) AP360(16,13),1354(6,10) TS2=16 X 2,1336(0,10)PGMLIT AT +1324 GN=38EQU * CVD 2,376(0,13) TS2=32 AP360(16,13),376(8,13)TS2=16 MP360(16,13),1348(6,10) TS2=16 GN=39EQU * LTR 3,3 BC2,562(0,11) GN=40(000A92) BC8,572(0,11) GN=41(000A9C) AP360(16,13),1354(6,10) TS2=16 X 3,1336(0,10)PGMLIT AT +1324 GN=40EQU * CVD 3,376(0,13) TS2=32 AP360(16,13),376(8,13)TS2=16 GN=41EQU * TM56(8),X'80' FLD-E BC8,584(0,11) GN=42(000AA8) OI375(13),X'01' TS2=31 GN=42EQU * AP365(11,13),350(10,13) TS2=21 MVC 376(16,13),360(13) TS2=32 L 2,92(0,9) TGTFIXD+92 L 15,60(0,2) V(IGZCIDB ) LA1,1802(0,10)PGMLIT AT +1790 BASR 14,15 MVC 56(8,8),392(13) FLD-E So, still using packed decimal; one more try with trunc(opt): LM2,3,48(8) FLD-D SLDA 2,0(0) BC11,394(0,11)GN=31(0009EA) LCR 2,2 LCR 3,3 BC8,394(0,11) GN=31(0009EA) BCTR 2,0 GN=31EQU * ZAP 344(16,13),1367(1,10) TS2=0 LTR 2,2 BC2,420(0,11) GN=32(000A04) BC8,436(0,11) GN=33(000A14) AP344(16,13),1354(6,10) TS2=0 X 2,1336(0,10)PGMLIT AT +1324 GN=32EQU * CVD 2,360(0,13) TS2=16 AP344(16,13),360(8,13)TS2=0 MP344(16,13),1348(6,10) TS2=0 GN=33EQU * LTR 3,3 BC2,456(0,11) GN=34(000A28) BC8,466(0,11) GN=35(000A32) AP344(16,13),1354(6,10) TS2=0 X
Re: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
snip--- Obviously given the lack of support for 64 bit, the failure to implement 64 bit addressing so COBOL can run nicely in 64 bit Websphere, the failure to implement USAGE BIT, the failure to implement the IBM pushed decimal floating point, the failure to implement IEEE floating point using the 2002 COBOL STANDARD floating point usages, it is obvious COBOL is seen as a cash cow to be milked until phase-out. --unsnip--- I can't agree with that conclusion. Having examined compilers and libraries from OS/360 with an eye toward 31-bit addressing, I can tell you that the changes atr non-trivial and could get very expensive very fast. For all we know, the changes you ask for may be already in the works, but updating a compiler and all the associated library subroutines can get very involved very quickly, especially when downward compatability is still an important feature. Rick -- 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
And point you mentioned --- downward compat show me others that really--- REALLY -- worry about that ..other than IBM.. In the beginning...and I remember...back in the late 60's... it was a big issue and over the years the ability to run a program you wrote 3 decades ago still runs ... amazing ..concept. today your lucky...with others... to run from one release to another without major problems .. From: Rick Fochtman rfocht...@ync.net To: IBM-MAIN@bama.ua.edu Date: 10/08/2009 04:07 PM Subject: Re: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions? Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu snip--- Obviously given the lack of support for 64 bit, the failure to implement 64 bit addressing so COBOL can run nicely in 64 bit Websphere, the failure to implement USAGE BIT, the failure to implement the IBM pushed decimal floating point, the failure to implement IEEE floating point using the 2002 COBOL STANDARD floating point usages, it is obvious COBOL is seen as a cash cow to be milked until phase-out. --unsnip--- I can't agree with that conclusion. Having examined compilers and libraries from OS/360 with an eye toward 31-bit addressing, I can tell you that the changes atr non-trivial and could get very expensive very fast. For all we know, the changes you ask for may be already in the works, but updating a compiler and all the associated library subroutines can get very involved very quickly, especially when downward compatability is still an important feature. Rick -- 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 -- Email Disclaimer This E-mail contains confidential information belonging to the sender, which may be legally privileged information. This information is intended only for the use of the individual or entity addressed above. If you are not the intended recipient, or an employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of the E-mail or attached files is strictly prohibited. -- 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: COBOL is an obvious cash cow to be milked to death was Re: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions?
On 8 Oct 2009 14:08:24 -0700, in bit.listserv.ibm-main you wrote: snip--- Obviously given the lack of support for 64 bit, the failure to implement 64 bit addressing so COBOL can run nicely in 64 bit Websphere, the failure to implement USAGE BIT, the failure to implement the IBM pushed decimal floating point, the failure to implement IEEE floating point using the 2002 COBOL STANDARD floating point usages, it is obvious COBOL is seen as a cash cow to be milked until phase-out. --unsnip--- I can't agree with that conclusion. Having examined compilers and libraries from OS/360 with an eye toward 31-bit addressing, I can tell you that the changes atr non-trivial and could get very expensive very fast. For all we know, the changes you ask for may be already in the works, but updating a compiler and all the associated library subroutines can get very involved very quickly, especially when downward compatability is still an important feature. It could be done (and probably would have to be done) as a compile option since 31 and 64 bit can't be mixed in an enclave if I have read things correctly. Thus you can't have a 64 bit COBOL bean in a 64 bit Websphere enclave. IBM could have defined binary IEEE floating point as the floating point for the 2002 standard true binary usages leaving COMP-1 and COMP-2 to mean what they currently mean. This would have been the intelligent way to interoperate with Java since changes to programs were needed to interact with Java anyway. Rick -- 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
