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

RE: Two technical questions on IEEE Std 754-2008



> And in another post I pointed out that
> if Endianness really doesn't matter, e.g. because import/export records
> are always in decimal character form for numerics, then DPD vs BID would
> not matter either, and each platform could quietly use its own format
> (or even a third one, such as Mike Cowlishaw's decNumber objects), all
> completely invisible to the COBOL programmer or user, and with no need
> to be addressed by the standard.

That's just it.  "import/export records" from/to COBOL programs are in exactly the form the user has specified they be in.  While the format of USAGE DISPLAY is pretty much agreed upon, and it's conventional for transparency/portability to put such information in USAGE DISPLAY format, from its earliest times implementors have provided "their own wrinkles" on how information is recorded.
COBOL records are not "always" in decimal character form; they're in that form only if, when, and because the END USER has put them in that form.     USAGE DISPLAY is the default unless a different USAGE is specified by the user. 
 
Yes, users put non-USAGE-DISPLAY items in such "externally-visible" records at their peril.  And part of the standardization effort over the years has been to add, in a PLATFORM-INDEPENDENT way, mechanisms beyond USAGE DISPLAY.  USAGE COMPUTATIONAL has always been whatever the implementor says it is -- on some machines, it's packed decimal, on others it's a binary integer, etc., etc. 
 
Let's start with a record description entry (intended for data archiving and cross-platform portability) that one could write using ONLY standards-defined constructs:  
 
01  EMPLOYEE-RECORD.   
     03  NAME.
          05  FIRST-NAME PIC X(20).
          05  MIDDLE-INITIAL PIC X.
          05  LAST-NAME PIC X(20). 
03  SSN PIC 9(9). 
03  HOURLY-WAGE PIC 9(3)V99.
03  HOURLY-ADJUSTMENTS PIC S9(3)V99.  
03  HOURS-WORKED-THIS-YEAR PIC 9(7)V99.
... etc., for a total of 72 bytes.
 
Now, PACKED-DECIMAL was introduced in 2002 COBOL; unfortunately, in my view, its internal structure is implementor-defined, so I'm skipping that possibility in this sequence.  
 
In Unisys MCP systems (the old Burroughs Large System architecture), using Unisys-specfic extensions in its COBOL74 dialect, the user might well have written (just 'cause!) this as: 
01  EMPLOYEE-RECORD.   
     03  NAME.
          05  FIRST-NAME PIC X(20).
          05  MIDDLE-INITIAL PIC X.
          05  LAST-NAME PIC X(20). 
03  SSN PIC 9(9) USAGE BINARY TRUNCATED.   
03  HOURLY-WAGE PIC 9(3)V99 USAGE BINARY EXTENDED. 
03  HOURLY-ADJUSTMENTS USAGE REAL.  
03  HOURS-WORKED-THIS-YEAR USAGE DOUBLE.  
... etc. A BINARY (of whatever flavor) in that implementation occupies 48 bits if it's 11 digits or less, and 96 bits otherwise.  A REAL is a 48-bit float; a DOUBLE is a 96-bit float.  This comes to a total of 61 bytes by my reckoning. 
 
Clearly this record wouldn't be readily decipherable on other platforms.   Now, let's say the user decides to migrate from the A Series to an IEEE-compliant platform, and decides to replace all these "implementor-defined" numeric definitions with constructs with ones he expects will be portable to ANY machine that supports all of the IEEE formats. 
 
We'll start with the way it is in the FCD.  He might decide to do this, for whatever reasons:     
01  EMPLOYEE-RECORD.   
     03  NAME.
          05  FIRST-NAME PIC X(20).
          05  MIDDLE-INITIAL PIC X.
          05  LAST-NAME PIC X(20). 
03  SSN PIC 9(9). 
03  HOURLY-WAGE USAGE FLOAT-BINARY-7.  
03  HOURLY-ADJUSTMENTS USAGE FLOAT-DECIMAL-16.    
03  HOURS-WORKED-THIS-YEAR USAGE FLOAT-DECIMAL-16.  
... etc.  FLOAT-BINARY-7 is binary32, 4 bytes; FLOAT-DECIMAL-16 is decimal64, 8 bytes.  The total is 50 bytes, by my reckoning.   
 
The problem here is that a program using this data description on another platform doesn't know whether the last two entries are in DECIMAL encoding or in BINARY encoding.  The proposal I'm developing resolves that ambiguity. 
 
If he wanted to do it this way, one of his options (and it's his choice) would be to code it
01  EMPLOYEE-RECORD.   
     03  NAME.
          05  FIRST-NAME PIC X(20).
          05  MIDDLE-INITIAL PIC X.
          05  LAST-NAME PIC X(20). 
03  SSN PIC 9(9). 
03  HOURLY-WAGE USAGE FLOAT-BINARY-7.  
03  HOURLY-ADJUSTMENTS USAGE FLOAT-DECIMAL-D-16.    
03  HOURS-WORKED-THIS-YEAR USAGE FLOAT-DECIMAL-B-16.  
... etc., still 50 bytes. 
 
In this case -- and from the standardization point of view we're not in a position to tell him "That's REALLY propeller-head programming..." -- he ends up with HOURLY-WAGE in IEEE binary32 format, HOURLY-ADJUSTMENTS in IEEE decimal64 format using the decimal encoding, and HOURS-WORKED-THIS-YEAR in IEEE decimal64 format using the binary encoding. 
 
The intent here is that the data descriptions, AND the data, are intended to be portable and legible across all platforms that support the IEEE floating-point usages.  This ability is a big "value-add" to the standard over (e.g.) the Unisys-MCP-specific description. 
 
A program whose ARITHMETIC is STANDARD-BINARY would have to convert HOURLY-ADJUSTMENTS and HOURS-WORKED-THIS-YEAR into binary128 format before dealing with them as numeric values. 
 
A program whose ARITHMETIC IS STANDARD-DECIMAL-B would have to convert HOURLY-WAGE and HOURLY-ADJUSTMENTS into decimal128 format, using the binary encoding, before dealing with them as numeric values. 
 
A program whose ARITHMETIC IS STANDARD-DECIMAL-D would have to convert HOURLYY-WAGE and HOURS-WORKED-THIS-YEAR into decimal128 format using the decimal encoding, before dealing with them as numeric values. 
 
Now, I grant that the non-propeller-head programmer would say "PICK A FORMAT AND ENCODING, AND STICK WITH IT!!!". That's not the standard's business.  As it sits, the record SHOULD BE cross-platform legible and comprehensible across ALL platforms and implementations of COBOL that support the seven IEEE floating-point usages, in EXACTLY the same way and to EXACTLY the same degree that the all-display record presented first is legible. 
 
That's the plus here:  we have a set of formats for floating-point data that is dependent NOT on the implementor, NOT on the COBOL standard, but on a SEPARATE INTERNATIONAL STANDARD.  COBOL coming up with its own form (as it did with ARITHMETIC IS STANDARD in the 2002 standard) didn't work, because the only motivation to support the "intermediate form" was compliance with COBOL, and that wasn't enough.  COBOL's specification for USAGE PACKED-DECIMAL doesn't work, because its format is implementor-defined. 
 
Here we have an industry-standard format, intended to be generally recognized, that COBOL can point to and say "Go look at the specifications for these formats in IEEE 754 for what data defined by these USAGEs looks like.  Neither we nor the implementor is in charge of this format."  
 
That's a HUGE value-add to COBOL, and it's one that ISO/IEC JTC1/SC22/WG4 requested that the COBOL-standard development folks provide back in (I think) 2004. 
 
> We needed
> to get down to the bit level in order to permit data exchange, and glossed
> over Endianness because that issue is common to all numeric types beyond
> single bytes. (Perhaps we should have mentioned it, to make sure everybody
> understood that BID vs DPD is almost at the same level as Endianness. It
> is in practice not quite at the same level because all sorts of mechanisms
> are already in place to deal generically with Endianness, whereas the DFP
> encoding issue is new and rides on top of the Endianness distinction.)

If "endianness" is an issue for the IEEE floats, it seems to me it's no less an issue for all the other fields in the record.  It's not related, specifically and only, to the IEEE floating-point usages. 
 
DFP encoding is a specific issue for COBOL when adding these formats, and does affects the standard as I've illustrated above. 
 
Endianness as I see it is generic to the platforms across data types. and unless somebody shows that endianness affects the IEEE floats in some way that's different from how it affects everything else in data, it's not a COBOL standardization issue at this time.  
 
    -Chuck Stevens

754 | revision | FAQ | references | list archive