Re: Optimization and new data types for COBOL was Re: Optimization, CPU time, and related issues
Both BFP and DFP are IEEE-standard. Both are more portable if that means usable outside IBM environments, than HFP; but this portability is compromised by big- and little-endian differences. In general, HFP values are readily converted into BFP or DFP ones using hardware instructions on a mainframe. The reverse is not at all true in general, but such convertibility is very likely, indeed all but certain, to be possible for the arithmetic values that figure in business applications. (Non-arithmetic BFP and DFP values, NaNs, are useful everywhere.; but they are not yet much used) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization and new data types for COBOL was Re: Optimization, CPU time, and related issues
I can only speak for the insurance company that I am working with since a very long time now. For them, the portability across platforms of the non-trivial arithmetic package is the most important challenge, and so they decided to do it all in C, (using HFP on the mainframe, because at the time, when they started, there was no BFP around). It's been a while, since I counted the source lines the last time (maybe it was when I did the port to Linux 64 bit on Windows), but it must be several millions. The business logic above the math package is PL/1 - on the mainframe - ; the data is converted to DEC FIXED on exit from the math package, and they have a good working rounding function (post processing, as John calls it), that normally doesn't surprise the users. No COBOL around. The number of platforms supported by this solution is 18 in the meantime !!. This is partly due to the large number of external partners with different needs. I'm pretty sure that they will stay with this solution for a very long time. It has been this way (production) since 1995. So DFP is far too late to be exploited by them. And: they will only use things that are available on all platforms. Source code portability is the major concern. Kind regards Bernd Am 26.02.2014 21:21, schrieb John Gilmore: Insurance and banking applications that do non-trivial arithmetic will benefit significantly from this change, which eliminates the need for post processing HFP results to ensure that they do not surprise users and users' customers. Better performance without source-program changes is highly desirable, and this use of DFP provides it. This said---as Tom surely knows---the pressure to make DFP directly available to Enterprise COBOL applications programmers will now grow. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization and new data types for COBOL was Re: Optimization, CPU time, and related issues
On Fri, 28 Feb 2014 00:43:02 +0100, Bernd Oppolzer wrote: I can only speak for the insurance company that I am working with since a very long time now. For them, the portability across platforms of the non-trivial arithmetic package is the most important challenge, and so they decided to do it all in C, (using HFP on the mainframe, because at the time, when they started, there was no BFP around). But nowadays, isn't IEEE FP far more portable than HFP? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization and new data types for COBOL was Re: Optimization, CPU time, and related issues
On 25 Feb 2014 15:16:54 -0800, in bit.listserv.ibm-main you wrote: There is evidence that IBM's COBOL people are thinking hard about making Mike Cowlishaw's ANSI-standard DFP available in COBOL. They may even have progressed further. Tom can, however, speak for himself and will, I suspect, do so. Actually, we have it on our list of things that we will for sure do. More interesting, I think, is that we use DFP instructions heavily , in COBOL V5 for all kinds of decimal arithmetic, with External Decimal conversion and arithmetic on Packed-Decimal data. This is more interesting because lots of shops have External Decimal and Packed-Decimal data, while almost NO shops have Decimal Floating Point data. In fact, many shops have hex floating-point data stored in databases today. So, adding a DFP data type for COBOL would not really help anyone right away. To take advantage, users would have to write new code, create new data (or convert old data) and build up DFP data that way. One interesting question is whether packages or Java have the possibility of creating DFP data in a given shop. PL1, C/C++, Java and DB2 version 10 all support Decimal Floating Point. Adding decimal floating point to COBOL along with the rounding options in IEE754 could allow some shops that require rounding to nearest even or other special rounding to get rid of complicated in house routines. I know that the shop I was associated with from 1966 through 1991 had bit switches on their customer, product and open account files. I have seen on the COBO? news group and here references to other organizations that have bit switches on their files and maybe data bases. Having the ability to specify both IEEE and hex floating point in the same program could be useful for use with Java and various data bases. Clark Morris Adding exploitation of DFP instructions to COBOL V5 means everyone can take advantage of these wonderful instructions without changing any data or source programs! All you have to do is convert your PDS dataset COBOL load libraries to PDSE dataset load libraries and then buy COBOL V5! 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
Re: Optimization and new data types for COBOL was Re: Optimization, CPU time, and related issues
There is evidence that IBM's COBOL people are thinking hard about making Mike Cowlishaw's ANSI-standard DFP available in COBOL. They may even have progressed further. Tom can, however, speak for himself and will, I suspect, do so. Actually, we have it on our list of things that we will for sure do. More interesting, I think, is that we use DFP instructions heavily , in COBOL V5 for all kinds of decimal arithmetic, with External Decimal conversion and arithmetic on Packed-Decimal data. This is more interesting because lots of shops have External Decimal and Packed-Decimal data, while almost NO shops have Decimal Floating Point data. In fact, many shops have hex floating-point data stored in databases today. So, adding a DFP data type for COBOL would not really help anyone right away. To take advantage, users would have to write new code, create new data (or convert old data) and build up DFP data that way. Adding exploitation of DFP instructions to COBOL V5 means everyone can take advantage of these wonderful instructions without changing any data or source programs! All you have to do is convert your PDS dataset COBOL load libraries to PDSE dataset load libraries and then buy COBOL V5! 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
Re: Optimization and new data types for COBOL was Re: Optimization, CPU time, and related issues
There is evidence that IBM's COBOL people are thinking hard about making Mike Cowlishaw's ANSI-standard DFP available in COBOL. They may even have progressed further. Tom can, however, speak for himself and will, I suspect, do so. The problems with HFP and BFP in business applications center on their rounding and conversion practices. These practices are not 'wrong', but they do violate accountants' expectations. DFP behaves just as those who know only decimal arithmetic would expect it to behave. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
