Some historical background might help ...

EPM SAA C/400 was fist available with OS/400 V1R3, circa 1990 or 1991 ... it did not support the packed decimal data type directly.

ILE C/400 was first introduced with V2R3, circa 1993, and supported packed decimal data as a "native" data type right from the start.

C++ was not available on the AS/400 for several more years, and even then, when it was first available, the IBM VisualAge C++ for OS/400 compiler ran only on OS/2... it was not for several more years after that before there was a "native" C++ compiler that actually ran on OS/400.

Also, IBM's C++ compilers have never supported packed decimal as a native data type, but only via the BCD library, on any platforms, AFAIK.


Mark S. Waterbury

> On 2/18/2015 4:32 AM, Jevgeni Astanovski wrote:
What I saw in my tests is that whatever approach you use in an attempt
to convert packed decimal in C++ to something "faster" (tried
__dectoi, QXXPTOI, cpynv) the result is exactly the same as if I make
a plain assignment of packed decimal variable value to integer (or
long long) value. So these functions provide no work around.
And at the same time I saw that ANY operation with packed decimal (or
as they call it BCD) is extremely expensive in terms of performance.
At the same time in C plain assignment is absolutely fastest of all
the ways to convert packed to int.

In this situation there are 2 things that surprise me:
1. Why IBM decided not to use the same engine for packed decimal in C
as they use in C++? What was the trade off? I mean did they gain
anything by loosing so much in performance?
2. How did it happen that noone have mentioned that earlier (at least
I googled and found no evidence that anyone new about it)?

But these questions can potentially be answered only by "insiders", I

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].