[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: <stds-754@xxxxxxxx>*Subject*: COBOL, Commercial Data Processing, Decimal Operations and the Current IEEE 754r Draft*From*: "Stevens, Charles C" <Charles.Stevens@xxxxxxxxxx>*Date*: Thu, 18 Aug 2005 15:30:27 -0700*Sender*: stds-754@xxxxxxxx*Thread-index*: AcWkRG8Lkiyi0d80QMSBKQf6/BksRA==*Thread-topic*: COBOL, Commercial Data Processing, Decimal Operations and the Current IEEE 754r Draft

This is an updated, expanded and re-edited version of a private communication I sent to Mr. Hough a few weeks back. I am concerned that the committee is not giving adequate weight to the value -- in general and specifically within the COBOL environment -- that the Basic Decimal Floating-Point Formats as described in the current IEEE 754r draft offers to the commercial data processing environment, as distinct from the statistical one. It has been intimated in various communications associated with the IEEE 754r draft that the formats and the rules presented therein are of no particular interest or utility in the commercial data processing environment; it has also been intimated that the commercial data processing environment is itself of no significant interest other than historical. I believe those intimations are both incorrect and misleading. The reality is that enterprise servers, of a wide range of architectures and implementations, are alive and well and are serving the needs of businesses worldwide. It has been estimated that there are hundreds of billions of source lines of live production business-oriented code worldwide, and modernizing their *existing* applications to incorporate, for example, internet access is a wiser financial decision than simply throwing away that which works and starting over. Commercial data processing, using enterprise servers descended from the mainframes of old, is alive, well, and thriving. Yes, much web-oriented and graphics-oriented work is done in other languages. But in many, many instances and in many, many environments, the web-access mechanisms and the graphics interfaces are front end software for commercial code, portions of which may have been serving their authors well for decades. There are many reasons people have written in COBOL over the last four-and-a-half decades. One of the main reasons the language is chosen by large businesses is that the choice helps protect the enormous investment in resources that the development of a site-specific application represents. It protects it by being as platform-independent as possible (portable across platforms) and it protects it by avoiding introducing changes that prevent existing code from running (portable across standards versions). Portability is of paramount importance to COBOL *users*, and is thus of paramount importance to COBOL itself. Factors that enhance portability include common formats for data, compatible interfaces, the ability to compile a program for an arbitrary platform and produce identical results, both in terms of arithmetic but also in terms of operating characteristics. This has been the case since the language was first proposed in 1959, and it remains so today. For the first time in history, a *decimal-oriented* platform-independent floating-point format sufficiently capacious for COBOL's use as arithmetic operands is being proposed for an industry standard (IEEE 754), in the form of the Basic 128-bit Decimal Floating-Point Format. I presented a quick overview of the IEEE 754r draft as it might affect COBOL at the WG4 meeting in The Hague last October, and the delegates were practically expressing *glee* over the prospects of incorporating Decimal128 formats and the associated arithmetic rules into COBOL, precisely because it is a *single* format, producing *identical* results on *all* platforms. They directed that, if at all possible, a complete specification for Decimal128 formats be included in the 2008 draft, and the necessary additions are present in the current working draft for ISO/IEC 1989. I am not convinced that Decimal128 offers *significantly* more to the scientific-computing community than is offered by Binary128, and I'd be interested in the arguments in that respect. I've heard things along the lines of "conceptually easier to use", but that doesn't strike me as an overwhelming advantage. But I *am* convinced that Decimal128 *does* offer a *whole lot* more to the commercial community (COBOL or otherwise!) than any comparable specification currently available -- in platform-dependent code or in any sort of standard. The other Basic Decimal floating-point formats are not that interesting to COBOL specifically, and I think the industry in general, because they do not provide as much precisiou as has been available in most commercially-oriented hardware for some decades ('68, '74 and '85 COBOL standards require numeric descriptions to allow for as many as 18 digits, which essentially means that arithmetic operations must allow the same; Decimal64 (along with the existing IEEE 754-1985 basic formats) is insufficiently precise to be useful for COBOL arithmetic operations. It's Decimal128 that is particularly interesting for COBOL; I tend to think of the rest of the Basic Decimal formats are along for the ride, and the Basic Binary formats are also specified as an! option. I deal on a daily basis in which algebraic operations on decimal operands require conversion to binary form, and that process introduces inconsistencies and imprecisions that are quite simply not appropriate to COBOL. Until the promulgation of ISO/IEC 1989:2002, the current COBOL standard, implementors did what they felt appropriate for arithmetic in COBOL. That revision to the standard put the world on notice that "platform-dependent" arithmetic was at least on the way to being disparaged in COBOL by introducing "standard arithmetic", which involves a 32-decimal-digit-precision mantissa and at least three digits of power-of-ten exponent, and specified rules for rounding (and truncation) for the basic math operators (including exponentiation but excluding square root). But there were circumstances in which the standard allowed the implementor to "escape" to "native arithmetic" which essentially allows the language implementor to do whatever he thought most appropriate. Native arithmetic is not portable across platforms; nor is the standard format associated with intermediate operands, precisely because the format is not defined, only the content and minimum ranges for the exponent and the significand. And perhaps most importantly, there was also no mechanism specified in the '02 standard for declaring a user-allocated data item in the intermediate format, because there was no specified format in the first place. Decimal128 as currently described provides answers to all these concerns. It is a single industry-standard format. It is sufficiently capacious for COBOL's functions. It is decimal-oriented, as COBOL is, which means that conversion from other forms *of decimal* to this form is straightforward. It provides arithmetic rules that are both language-independent and platform-independent, improving portability of applications. Users can declare data items in these formats and can interchange them as parameters or in files regardless of the platforms of the senders or the recipients, and can expect identical arithmetic results from their programs, regardless of implementation and regardless of the operating environment. There are many features that have been added to COBOL over the subsequent decades that have contributed to its *functionality*, but I personally think the introduction of Decimal128 is likely to be *the single* most important factor in improving COBOL's cross-platform portability *in the history of the language*. COBOL has provided the equivalent of "exchange" formats and "internal" formats for numeric data since its very beginnings; USAGE DISPLAY has always been available for "exchange" of data, and whatever the implementor uses for arithmetic operations is the "internal" format. It is *precisely* the availability of *one industry-standard format* that can be used *both* for "exchange" and for "internal" purposes that makes the addition of Decimal128 formats for user data and for algebraic manipulation a huge advancement for the COBOL language and for the commercial data processing environment at large. My experience with COBOL on a number of platforms leads me to believe that the efficiency of arithmetic operations is but a small contributor to the overall performance of programs in that language. In particular, I would contend that the ability to do efficient numeric comparisons of decimal items, whether of the same scale factor or not, is at least as important, if not more important, to overall performance as the ability to perform arithmetic on such items efficiently. For COBOL, the Basic 128-bit Decimal Floating-Point Format offers an industry-standard way of representing *decimal* operands *in decimal* -- for purposes of arithmetic, for purposes of comparison, and for purposes of cross-platform, cross-language, cross-implementation information exchange. That advantage is contingent at least in part on the principle that items intended for manipulation in base 10 are encoded in a format that represents base 10, not base 2, not base 1000. I remain unconvinced that binary representations -- of the entire significand or of groups of digits as in the base-1000 proposals -- are a fundamentally and unconditionally more efficient method of representing decimal-oriented operands than decimal representations are, and I also remain unconvinced that what someone who decides to use an *industry-standard* format for interchange and for algebraic manipulation has as his primary motive is how *fast*, rather than how *portable*, his application is. Given that it is almost certain that *every* COBOL vendor will continue to offer "native arithmetic" alongside "standard-decimal arithmetic", the arithmetic performance of a given format used in "standard-decimal arithmetic" is of less importance than its singularity and its portability. Some recent developments in the IEEE 754r draft alarm me, because some of them directly interfere with COBOL's ability to incorporate as completely as possible the arithmetic, rounding, and exception handling rules -- for example, the recently-mentioned proposal that conversion from decimal floating-point format to integer always raise an exception rather than truncate or round. If such a requirement is mandatory for conformance, then COBOL cannot be brought into conformance, precisely because COBOL already has rules that define such things. These requirements did not exist in the draft of IEEE 754r at the time I prepared my proposal to WG4 just a year ago, and it is the unconditionality of them that concerns me. Another such example (of longer standing) is the mandate that "banker's rounding" always be the default rounding, and that anything else would therefore have to be an exception to conformance. IEEE 754r does not stand alone; it will be referenced (either as such or as, I expect, a revision to ISO 60559) by other international standards. I believe it would be appropriate for the draft to include more mechanisms whereby such other standards can conform, for example, wording to the effect that a convention is to be the default unless an environment such as another International Standard requires a different default. Among such International Standards referencing IEEE 754r or its ISO/IEC equivalent will be the revision to ISO/IEC 1989 that is expected to appear in 2008. I do not believe it will be the only one, and I do not believe it will be the last. -Chuck Stevens -Unisys MCP Languages -Secretary, INCITS/J4 -Member, US delegation to ISO/IEC JTC1/SC22/WG4 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.

- Prev by Date:
**styles of standards definition** - Next by Date:
**Mea Culpa, minutes, & RFC...** - Previous by thread:
**styles of standards definition** - Next by thread:
**Mea Culpa, minutes, & RFC...** - Index(es):