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
