RE: Two technical questions on IEEE Std 754-2008
Chuck Stevens wrote:
There's another advantage to this approach, Michel. Let's suppose
an application runs just fine on a BID-native machine, and let's
also suppose that the end user has a bunch of data on disk in BID
encoding. Let's further suppose that, for whatever reason, the
user decides to migrate to a DPD machine (exact same thing applies
I agree with everything Chuck wrote in that post.
I would like to point out however, again, that this reasoning ALSO
applies to the other two value-encoding issues, namely Endiannness and
Character coding. William Klein reported that some COBOL compilers do
support some form of Endianness tagging, and lamented the fact that
Ascii vs Ebcdic issues still remain.
Would it not be nice if COBOL also provided a standard way to deal
with archived data migrating to a platform with different byte orders
or character sets, as easily as the new DFP support is expected to do?
Actually, the Endiannness issue remains in Chuck's example.
Such support is NOT intended for bit-twiddling (that's not what COBOL
is for), it is only intended to qualify the execution environment,
and not individual records. The intent is to facilitate data migration.
And along my point has been that the BID/DPD distinction should ALSO be
at the execution-environment level, and not at the individual-field level.
But I understand Chuck's point of view if COBOL does not now have STANDARD
means to do this kind of execution-environment tagging, yet field tagging
is under active construction and can thus accomodate the distinction now.
Now, the distinctions above don't exhaust all differences between systems,
even today. There are still differences at the file level (e.g. how
records are separated, whether there is a difference between "binary"
and "text" files (addressed by FTP and TFTP for example), file names etc.
But they do pretty much exhaust differences at the record level, when
standard (not "native") types are used.
P.S. Don't interpret this as a request to do something NOW!
---Sent: 2011-02-28 18:56:02 UTC