> > The original issue that I raised had to do with "What do we do if a datum is
> > described as decimal64 (implicitly DPD), and it actually contains BID?" As
> > was pointed out more than once, you have to know what you're dealing with.
> > If it doesn't match what you've been told it is, the results are undefined,
> > and that's on the backs of the sender. But if it's been described to you
> > as decimal64 BID, it's a Really Bad Idea to treat it as decimal64 DPD.
> My point is that IF the BID/DPD distinction was treated like Endianness,
> this issue would not even arise. Type "decimal64" would NOT imply DPD,
> just as type "binary64" does not imply Big-Endian. Indeed, at the
> encoding level there are two forms of binary64 and four of decimal64.
> The fact that Endianness is usually swept under the rug (including in
> IEEE 754-2008) is just because the issue is so trivial it does not need
> a detailed description, unlike the BID vs DPD distinction -- but those
> who implement runtime environments and language processors (compilers
> or interpreters) do have to deal with it.
If COBOL were expected by the users (or the implementors) to address endianness, that issue would have been raised long ago.
"You have to know what you're dealing with." So long as COBOL only recognizes DPD and presumes DPD, anything else produces garbage.
I've written a proposal, as I said before, to do what I think is right for COBOL for the upcoming standard. The rest of this presumes that that proposal is accepted.
As I wrote earlier, I would have preferred that the two encodings of decimal float formats had been treated as separate formats rather than as variants of the same format in IEEE 754, but that wasn't the final verdict during the development of that standard. From COBOL's standpoint, if the language is to handle them, it needs to treat them as separate formats. In that way, so long as the description the user's been given about a given datum is accurate about the encoding, the mechanisms exist to process either "variant". From IEEE 754's point of view, decimal128 DPD and decimal128 BID are "almost the same thing"; from COBOL's point of view, they're not.
So, the answer to initial question above in my proposal is that decimal128 will NO LONGER be implicitly DPD. Decimal128-ness is no longer sufficient information to identify the form and format of the item from COBOL's standpoint; the encoding becomes a required part of the description. A 128-bit decimal float in COBOL can either be described as decimal128-dpd or decimal128-bid, but not neither, and not both simultaneously, and not anything implicitly. There are exactly two choices for the format corresponding to a decimal128.
Again, that isn't to say that this will make it into the final standard, but I'm doing everything I can to make that happen.