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
Optimization and new data types for COBOL was Re: Optimization, CPU time, and related issues
On 17 Feb 2014 13:42:30 -0800, in bit.listserv.ibm-main you wrote: Starting a new thread . This discussion leads to a new thought. There may be a greater need for USAGE BIT, DECIMAL FLOATING POINT and IEEE floating point in COBOL programs. There also are added instructions related to these. All of these usages are in either the 2002 standard or the draft standard being worked on. The DECIMAL FLOATING POINT also includes the ability to choose the rounding method which could speed some banking programs and other financial ones. The decades overdue ability to manipulate bits also could allow for significant savings in some cases. The ability to do decimal arithmetic in registers can change how computation is done in some compute intensive programs. The ability to use IEEE floating point eliminates the conversion done when COBOL calls or is called by JAVA using COMP-1 and COMP-2 fields. The change would be controlled by changing the usage to the standard COBOL usages in the 2002 standard and recompiling. Both floating points (IEEE and Hex) could co-exist in the same program. Clark Morris It seems to me that as the hardware has gotten faster and faster, it is tempting to think that optimization and CPU time no longer matter. I think three things have conspired to make that thought not true: 1. Of course as hardware has gotten faster and faster, transaction volumes have gotten greater. The one instruction that used to get executed 100,000 times a day now gets executed a million times a day. 2. Much of the increase in speed has been due to increased numbers of processors per box. That gives the customer more MIPS but it is no help to processes that are either inherently single-thread, or have been implemented in a way that makes them single thread, and must be completed within some finite window. 3. Most significantly, as machines have gotten faster, customers have also gotten much more cost conscious, and are very aware that every instruction brings them closer to the day that they have to upgrade the box, which will bring an inevitable major increase in the cost of IBM and non-IBM software. It would be an interesting exercise to try to figure out an estimated dollar cost for a million instructions executed per day, using an assumed typical installation and an assumed typical mix of IBM and non-IBM software -- on the assumption that those million instructions represent x% of the need to upgrade to a faster box, and the increase in costs, hardware and software, due to that upgrade. Charles -- 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. 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
