On 21 Jun 2013 11:26:53 -0700, in bit.listserv.ibm-main you wrote: >On Fri, 2013-06-21 at 15:18 -0300, Clark Morris wrote: >> And IBM thinks COBOL is the language of the future. Right and I sell >> bridges. > >Well... that's what Tom Ross says anyway. You'd dispute Tom?
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. Java uses IEEE floating point and instead of adding the IEEE floating point types to COBOL as DEFINED in the 2002 standard and leaving the COMP-1 and COMP-2 type for hex floating point thus keeping upward compatibility, there is a conversion to or from hex floating point when dealing with Java. USAGE BIT and logical operations which are in the 2002 standard have not been implemented. There are OO classes for CICS in C/C++ and PL1. Are there any for COBOL? COBOL as defined in the 2002 standard can handle the SMF 14 and 30 records without going through contortions to handle the bit switches. COBOL 2002 finally has EXIT PERFORM and EXIT PARAGRAPH. Granted that a sales job would be needed to explain why management should care about the improvements made available in that standard but if it were the language of the future, it would be worth the expenditure. On the other hand, given many of the tales told here and probably the stories told about all of the features in the 1985 standard that have remained unused in many or most shops, IBM could well question whether it would be worth the effort. If the long term is movement to packages that are implemented in other languages anyway, improvement is money wasted. I believe that a lot less work is being done by COBOL programs than was done ten or fifteen years ago. Every SAP installation reduces the workload on COBOL by that much more. On other platforms the native COBOL file systems (there is no equivalent of VSAM for example) don't exist and the run-time costs can be high. From my following of comp.lang.cobol and what I see in the market place, COBOL is in its final years. Clark Morris ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
