RE: Two technical questions on IEEE Std 754-2008
(And also: RE: A general comment on COBOL "modes of arithmetic")
I'd like to thank Chuck for his generous time in reminding me how COBOL
works. COBOL grew up in an area where machines and data representations
varied much more widely than they do today, and I have to agree that in
this context Endianness is just a minor glitch. It just happens to be
the major remaining representation issue today, when nearly all machines
are byte-oriented with power-of-two-sized formats.
What really sums it up is the following:
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.
I've essentially said the same thing when I wrote, regarding 745-2008 3.2:
... (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.)
What Chuck's approach permits, and my suggestion doesn't, is the following:
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 other words, mixed encodings in the same record.
I suppose it's conceivable that the programmer did this knowing that the
two fields were going to be forwarded to different processing programs,
one running on BID-friendly hardware and the other on DPD-friendly
hardware. This is something languages like C would not be able to do.
I still consider it as the equivalent of having some fields explictly
declared Big-Endian and others Little-Endian in the same record -- but
as we all agree this is NOT what COBOL is intended to deal with.
Another advantage of Chuck's way is that he (in his standardization work)
took on the job of dealing with this new distinction, taking the burden
away from implementers. My way would require implementers to modify the
way they handle record conversions generically by dealing with BID/DPD as
well. My point was simply that if there is a way to transmit records such
as the above across Endianness differences, that could have been augmented
to deal with BID/DPD as well. I would have been extra work for somebody
other than Chuck.
P.S. I hope we reached a satisfactory conclusion to this long excursion
prompted by a simple question!
---Sent: 2011-02-27 16:58:34 UTC