COBOL, Commercial Data Processing, Decimal Operations and the Current IEEE 754r Draft

["Stevens, Charles C" <Charles.Stevens@xxxxxxxxxx>]

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.