Cobol - The fate of Packed-Decimal (was: Error with COMP-3

Author

The fate of Packed-Decimal (was: Error with COMP-3

William M. Klein

2007-09-13, 3:55 am

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5krfr2F54tbsU1@mid.individual.net...
>
<snip>
>
> Packed Decimal will eventuall disappear because the reasons it was invented
> have no relevance today. (I remember it being an option on early System 360s;
> Gene Amdahl never designed it into the system. It was implemented in firmware,
> and only if you paid for the "commercial instruction set". The idea was to
> make 360 a flexible system that could be sold to the commercial and scientific
> communities. When competing systems like the ICL 1900 began creaming IBM in
> benchmarks, they realised it was much too slow...)

My guess is that
- COBOL
- IBM mainframes
and
- Packed-Decimal

will all "disappear" at about the same time and as long as one (much less two)
of the 3 remain, the others will too.

--
Bill Klein
wmklein <at> ix.netcom.com

Pete Dashwood

2007-09-13, 7:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:dD2Gi.58809$gR1.4966@fe03.news.easynews.com...
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5krfr2F54tbsU1@mid.individual.net...
> <snip>
>
> My guess is that
> - COBOL
> - IBM mainframes
> and
> - Packed-Decimal
>
> will all "disappear" at about the same time and as long as one (much less
> two) of the 3 remain, the others will too.
>
Yes, I think that's fair... :-)

Pete.
--
"I used to write COBOL...now I can do anything."

Frank Swarbrick

2007-09-13, 6:55 pm

>>> On 9/12/2007 at 10:02 PM, in message
<dD2Gi.58809$gR1.4966@fe03.news.easynews.com>, William M.
Klein<wmklein@nospam.netcom.com> wrote:
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5krfr2F54tbsU1@mid.individual.net...
> <snip>
> invented
> 360s;
> firmware,
> to
> scientific
[color=darkred]
> in
>
> My guess is that
> - COBOL
> - IBM mainframes
> and
> - Packed-Decimal
>
> will all "disappear" at about the same time and as long as one (much
> less two)
> of the 3 remain, the others will too.

I've long wondered, what do non-mainframe systems use for their currency
data types? Do they use floating point, with it's inherent decimal
inaccuracies?

I know that the .NET framework has a "Decimal" data type, though since x86
does not (as far as I know) have support for decimal arithmetic I wonder
what type of actual machine code instructions are used to support it.
Anyone know? Is integer arithmetic used, along with the knowledge of where
the decimal point exists?

Frank

Michael Mattias

2007-09-13, 6:55 pm

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46E90A64.6F0F.0085.0@efirstbank.com...
>
> I've long wondered, what do non-mainframe systems use for their currency
> data types? Do they use floating point, with it's inherent decimal
> inaccuracies?

> Is integer arithmetic used, along with the knowledge of where
> the decimal point exists?

Give that man one of the big stuffed teddy bears for his little lady
friend......

Microsoft's CURRENCY (Access, Visual BASIC/C/C++, .NET products) is a signed
64-bit binary integer ( LARGE_INTEGER) with four assumed decimals.

MCM

Rick Smith

2007-09-13, 6:55 pm

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46E90A64.6F0F.0085.0@efirstbank.com...
[snip]
> I've long wondered, what do non-mainframe systems use for their currency
> data types? Do they use floating point, with it's inherent decimal
> inaccuracies?

It is not mainframe vesus non-mainframe; it is languages
that have decimal data types versus those that do not.
What might a mainframe FORTRAN programmer use
for a currency data type?

Floating-point may be used, as an integer, to hold a
currency data type. Such use requires attention to scaling,
rounding, and normalization.

I suspect most who use currency data types extensively
would build or buy a library for support.

> I know that the .NET framework has a "Decimal" data type, though since x86
> does not (as far as I know) have support for decimal arithmetic I wonder
> what type of actual machine code instructions are used to support it.
> Anyone know? Is integer arithmetic used, along with the knowledge of
where
> the decimal point exists?

There are x86 instructions for decimal arithmetic. These
instructions operate on both ASCII characters and
packed decimal, one byte at a time. There are also
floating-point instructions for loading and storing packed
decimal numbers, 8-byte (or 16 digit) positive integers.
(Source: Micosoft Macro Assembler 5.1 Reference)

Rick Smith

2007-09-13, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13ej03sga4od6b6@corp.supernews.com...
[snip]
> [...] There are also
> floating-point instructions for loading and storing packed
> decimal numbers, 8-byte (or 16 digit) positive integers.

My memory failed me. It is 10-byte positive integers.
FBLD mem, to load, and FBSTP mem, to store.

Charles Hottel

2007-09-14, 3:55 am

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:46E90A64.6F0F.0085.0@efirstbank.com...
<snipo>
[color=darkred]
> I've long wondered, what do non-mainframe systems use for their currency
> data types? Do they use floating point, with it's inherent decimal
> inaccuracies?
>
> I know that the .NET framework has a "Decimal" data type, though since x86
> does not (as far as I know) have support for decimal arithmetic I wonder
> what type of actual machine code instructions are used to support it.
> Anyone know? Is integer arithmetic used, along with the knowledge of
> where
> the decimal point exists?
>
> Frank
>

For Java your options are BigDecimal, long, int, double or float.

Here are some of my notes from Effective Java by Joshua Bloch:

item 31: avoid float/double if exact answers required
149
float/double designed primarily scientific/engineering calculations 149
binary floating-point arithmetic
149
accurate approximations over broad range magnitudes 149
do not provide exact results
149
float/double particularly ill suited monetary calculations
149
impossible represent 0.1 or any other negative power of 10 exactly 149
example: float/double monetary calculation problem
149
use BigDecimal, int, or long for monetary calculations
150
example: use BigDecimal monetary calculation
150
BigDecimal less convenient than primitive arithmetic/slower 150
int/long alternative to BigDecimal, depends on amounts involved 150
example: use int for monetary cslculation
150
BigDecimal give full control over rounding
151
BigDecimal lets you select from eight rounding modes 151
can use int if quantities not exceed 9 decimal digits
151
can use long if quantities not exceed 18 digits
151

Numbers on right side are page numbers.

William M. Klein

2007-09-14, 3:55 am

<all snipped>

as a follow-up on "decimal" vs other data types and operations ....

For those interested in "decimal arithmetic", the latest draft of the IEEE
Decimal Floating Point Standard is expected to be available for comment soon.
(I will be posting information on the invitation to participate in the review,
when I get it).

So far, IBM has already introduced hardware support (in z/OS 1.9 related OS &
hardware) and both Sun (for Java) and XML (W3C - if I recall correctly) have
indicated INTENTIONS to include support for the new data types and operations.
It is also included in the current draft of the NEXT COBOL Standard.

--
Bill Klein
wmklein <at> ix.netcom.com

Sponsored Links