> Defining the two DFP encodings as explicitly different types is overkill|
> in my opinion, for the reasons I've stated repeatedly, but it should work,
> because exported data must (presumably) already define their record field
> types, and that definition now identifies the encoding as well.
Exactly. If we presume DPD encoding for all items declared as decimal128, we have no wyy to tell that the presumption was incorrect at the data-retrieval level.
> I'm curious however how a programmer would write their code to run with
> best performance on either BID or DPD platforms when that program deals
> primarily wil local data (so the issue of import/export conversions does
> not arise). Will there be a means to declare the arithmetic to be the
> platform-preferred STANDARD-DECIMAL, in a *portable* manner? This could
> be an enquiry function that describes the execution environment, or could
> be handled by omission if each platform has a suitable default setting.
Aside from the ARITHMETIC clause in the OPTIONS paragraph of the IDENTIFICATION DIVISION, the source code is EXACTLY the same whether the arithmetic mode specifies binary or decimal encoding.
The implementor would certainly be free to build object code for BOTH modes, and to build into the compiled object code do an inquiry at the beginning of execution to find out which mode to use at run time. Given that "STANDARD-DECIMAL" is no longer proposed as a STANDARDS-defined mode, hat term would be a likely candidate for such a feature! The object program would still bear the performance "hit" of checking for which mode to use on every arithmetic operand and result, though.
When it comes to portability, the COBOL standard is concerned about SOURCE CODE portability, not OBJECT CODE portability. At the very least, recompilation of the program is expected when moving from one architecture to another -- or even from one software release level to another. The only change to the SOURCE program needed to switch from one mode of decoding to another for the generated object code is the ARITHMETIC clause. One source line.
The run-time determination could certainly be done; it qualifies as an implementor-defined extension. The standard doesn't forbid such extensions, it just requires that they be identified in the documentation. We don't plan to mandate or suggest this feature in the standard, nor do we plan to forbid an implementor from providing it.
> (Sorry -- I was dreaming -- this domain is waaay outside the application
> domain of COBOL. I'm still curious however how COBOL implementations deal
> with the issue of Endianness and character encodings in exported data.)
Yes, "endianness" is outside the application domain of COBOL. The specifications for Boolean items, strings of bits, and "bit-fiddling" in general are decidedly rudimentary even today. COBOL is not a language in which one expects to "bit-fiddle". It's not C or assembler language. COBOL is a "COmmon Business Oriented Language", was designed to do that (and not more), and that remains its focus today. "Bit-fiddling" is largely outside the range of interest of COBOL users. "Endianness" is outside the range of interest of the vast majority of those who are seeking to contribute to the improvement of the standard.
Now, if you can convince WG4 that the World is Coming to an End if COBOL doesn't address all aspects of bit-fiddling, including endianness, in the draft before its publication, have fun -- doing so would almost certainly have a SERIOUS effect on the publication schedule, and as far as I'm concerned this isn't an issue that needs to be addressed right now, if at all. I've said that before (several times). I doubt you'd get much agreement from those deciding whether or not to publish the standard without it. There are much bigger fish to fry in the COBOL standardization process than "endianness", particularly those issues that seek to refine and improve the language in light of its fundamental purpose. COBOL is not a "Do everything you could ever think of wanting to do with a computer" language.
Fortran does integer and floating-point math really well. It doesn't do floating-asterisk check protection at all well, and isn't well suited to string operations like extraction and concatenation. Is the language, given its purpose (FORmula TRANslation) deficient for not being a whiz at these capabilities? I don't think so.