Standard COBOL DOES have support for different character sets, it's just at the program level, not at the data declaration level. It's generally assumed that no more than 256 different components of a character set can be identified within an 8-bit pattern, and each such character set is presumed to have a given 'collating sequence'. While adding data-declaration clauses to specify a particular character set for what is now a generic USAGE DISPLAY description might be "nice to have" in COBOL, it hasn't been raised as a significant enough issue for the various committees to consider it. |
Yes, this and endianness could be appllied to COBOL data-declaration entries. Nobody's asked for it with sufficient "volume" to raise it as a controversy at the WG4 level.
What WG4 HAS asked the drafting committe to provide is the ability to deal with IEEE floats as data, and the ability to do arithmetic with them directly. That's what I'm concerned with.
> Date: Mon, 28 Feb 2011 13:36:07 -0500
> To: stds-754@xxxxxxxxxxxxxxxxx
> From: hack@xxxxxxxxxxxxxx
> Subject: 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
> > in reverse).
> 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