On 8 Jul 2013 11:15:24 -0700, in bit.listserv.ibm-main you wrote: >>I realize that this is belated but yes I would vigorously dispute him. >>Mike Cowlishaw of Rexx renown worked diligently on defining decimal >>floating point and the standard for it. The z series has had decimal >>floating point for a number of years. It has been supported in PL1, >>C/C++ and Java. To date it has NOT been implemented in COBOL despite >>the claim for Java interoperability and the fact that decimal floating >>point natively supports 6 types of rounding. > >Clark, if you still attended SHARE and our numerous discussions of what >z/OS COBOL customers want added to COBOL, you would know that almost no >one is interested in adding a new floating point data type to COBOL, >(other than you). OTH, IBM is interested in it, and that is why we have >accepted the requirement to add DFP data type support to COBOL, which >you would also know if you still attended SHARE or asked someone in >IBM. Finally, the new version of COBOL (V5.1) uses DFP instructions to >do decimal arithmetic faster on other data types, such as external >decimal and packed decimal.
I am well aware that the interest in COBOL at SHARE was low up until 2002 when I stopped attending and that requests that did come in for the most part were tactical hitting such things as debugging capability. I would not be surprised that this has continued. I see the requests for XML support as being tactical - meet an immediate need as opposed to strategic. I would agree with anyone who says that top applications management for the most part has no interest in DFP and probably no knowledge of it. I also was an oddball in the systems programming side in that I used COBOL to manipulate the SMF records which would have been easier if COBOL had supported the true binary USAGES and the BIT usages of the 2002 standard. I suspect that there was not that much greater clamor in the C/C++ and PL/1 communities at SHARE for Decimal Floating Point than there was in the COBOL community. The strategic direction for those two languages was to implement Decimal Floating Point. I can make the case that it was too late for all of the systems that needed peculiar rounding rules such as round half to the nearest even. This was also true of the Millenium Language extensions which would have greatly eased the year 2000 project I was on had they been introduced in 1995 or 1996 before we started work in earnest to meet a 1998 deadline for one of the major systems. The case for implementing many of the constructs of the 2002 standard would be what they can do for code generators and for interoperability with other languages (especially JAVA). I also believe that I was clear in my posting that a major selling effort would have to be made to many application managements since they still have not embraced the 1985 improvements and even to those that take advantage of the 1985 standard. I have concluded that many believe that the combined costs of doing the implementation of what I believe would be useful plus the cost of educating the current application managements as to what they can do for their shops isn't worth the effort. > >Finally, just to explain my email closing, COBOL will always be with >us because it does what people need it do efficiently, and because >there is so much of it running the world today that even if we spent >all of our money and time trying to convert it to some other >language, we would still have not completed the job in 20 years. >Besides, if you convert an application from one language to another, >you end up with the same application that you started with, except >maybe with new bugs and maybe less function, and you just lost a lot >of money. And whatever language you converted to will be legacy in >a few years. Google "Java is dead" for some fun. Ruby killed Java, >Groovy killed Ruby, etc, etc. Yeah, I have heard "x is dead" before, eh? Here, I have seen packages (SAP, Oracle Financials, etc.) replace major systems and I believe that most of the systems that I worked at one client in the 1990's which were on a 390 are now replaced by packages running on either AIX or Windows. Both the client and those of us who worked on the systems believed that replacement was the only hope for major improvement. While I am skeptical about the language of the day phenomena, COBOL really wasn't designed to handle many of the things on the web and really wasn't that great for writing reports. There is a reason why companies paid big bucks for DYL280, Easytrieve, etc. Ireally liked DYL280 for many things over COBOL. While systems are being just upgraded COBOL will live in a shop. When they are replaced, the replacements probably won't be in COBOL. I am not seeing the demand being that great for either COBOL programmers or mainframe systems programmers so I got out just in time. I don't see COBOL being a major force in the Windows and Unix Environments which have increasing shares of the market. I suspect that the COBOL strongholds are the IBM i and z series, the Unisys descendants of the 22000 and B5000 and any other mainframe like systems still in existence. The Windows and Unix environments are not that friendly to COBOL. > >It has taken us a while, but we now have a modern backend (code generator >and optimizer) for COBOL that can exploit the latest hardware, and will >support DFP, AMODE 64 and many of the other z/OS system features that we >have not be able to exploit in the past. I'm glad to see it and if I were still programming (no one is actively looking for 74 year old COBOL mainframers in Nova Scotia) I would not be surprised to be in a very small minority that would want the DFP, USAGE BIT, true BINARY usages and the IEEE floating point. A greater percentage would be very happy to get the EXIT PERFORM and EXIT PARAGRAPH enhancements. Clark Morris > >Cheers, >TomR >> COBOL is the Language of the Future! << > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
