Re: cobol data format!!! urgent!!!
From: Chuck Stevens (charles.stevens_at_unisys.com)
Date: 08/27/04
- Next message: Richard: "Re: cobol data format!!! urgent!!!"
- Previous message: Richard: "Re: MaxDB = SAPDB = ADABAS (was: Sorts (revised)"
- In reply to: Robert Wagner: "Re: cobol data format!!! urgent!!!"
- Next in thread: Clark F. Morris, Jr.: "New users for traditional architectures was Re: cobol data format!!! urgent!!!"
- Reply: Clark F. Morris, Jr.: "New users for traditional architectures was Re: cobol data format!!! urgent!!!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 27 Aug 2004 12:47:05 -0700
"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
news:jm8ti01aeo3igm42n2d2ole964csm8k3v7@4ax.com...
> On Thu, 26 Aug 2004 17:53:40 -0700, "Chuck Stevens"
> <charles.stevens@unisys.com> wrote:
>
> >
> >"Robert Wagner" <robert@wagner.net.yourmammaharvests> wrote in message
> >news:1j1si05tv3jdi13t2j0lchj0e9u3kkjg0e@4ax.com...
> >
> >> Like most standard committees, the 10967 folk take the attitude 'if
> >> you don't do it our way, you're on your own.' Why should they support
> >> the competition in IEC 559?
> >
> >And what would you expect "if you do <x> the expected results are <y>" to
> >imply if you refuse to follow the constraints of <x>? Perhaps I have
> >misunderstood what "conformance to a standard" means.
>
> It would be nice if they'd allocated two bits and defined four values
> as 10967, 559, native and unknown. They had the arrogance to name the
> indicator ISO, which implies 559 is not an ISO standard.
It's not. It's an *IEC* standard.
> >> >What *one* format of high-precision floating-point do you believe is
> >> >appropriate for *every* existing machine, producing identical results
> >across
> >> >all platforms?
> ... intermediate conversation elided for brevity ...
> ... I meant IEEE generically. Its 32-bit and
> 64-bit versions are in current hardware; extended formats generally
> are not.
And that brings us back to my point that the 2002 standard requires 31-digit
precision for all numeric data items that have PICTURE clauses, which makes
the 32-bit and 64-bit formats unusable for manipulating values at that
precision level.
And you've already gone on record as being *adamantly* opposed to using
anything but DISPLAY numeric for any sort of data exportation from or
importation into COBOL programs on grounds of portability. If 32-bit
formats are virtually useless *within* the COBOL program, and they're to be
eschewed as visible elements *from or to* a COBOL program, what does COBOL
need with them?
> I didn't say they did; I said the ISO C++ standard has a long double
> AND claims to be compliant with 10967. The C++ standard committee
> found 10967 extended format adequate. This document explicitly says
> "extended" for long double, not for the others.
What the C++ user community directs the standards committee for C++ to
incorporate and to treat as adequate in that environment is entirely
orthogonal to what the COBOL community directs the standards committee for
COBOL to treat as adequate.
The COBOL community has made it abundantly clear to the standards committee
that the standard requirement that PICTUREs for numeric items provide for no
more than 18 digits (ANSI X3.23-1974) was an onerous limitation to them, and
the 2002 standard provides for 31.
> >And each went their own way. That's precisely my point.
>
> Machines designed after 1985 went with IEEE. They did not go their own
> way.
Machines designed after 1985 *still* don't have a single basic portable
floating-point format capable of meeting the needs of the COBOL community.
And I would have to say there are *plenty* of machines designed after 1985
that neither went their own way nor went with IEEE. What many of them did
was provide additional capabilities within a given *architecture*.
I remember the stories of IBM introducing the large-scale 704 system as
their answer for the *scientific* community, and the large-scale 705 system
for the *business* community. The 705 was fairly successful, and it went
through two more generations enhancing capability. When the second
generation was introduced, the 704/709 architecture lived on in the
7040/7090, but IBM introduced the entirely-incompatible 7070 as the
replacement for the 705. Existing 705 customers stayed away in droves,
forcing IBM to rush the 7080 (which had 705-compatibility switches on its
console) to market in record time.
I personally think it's a Really Bad Idea for a manufacturer to turn its
back on an existing customer base or to force a user to abandon an existing
library of his programs with which he is otherwise quite satisfied.
While many (and I daresay not all!) new *architectures* may have
incorporated hardware support for 32-bit and 64-bit basic floating-point
formats, if they're not suitable for internal use within COBOL, there's not
a whole lot of incentive for the *COBOL* standard to "bless" them as an
attractive new feature for that language! What's the attraction?
> It was offered as an example of 128-bit. If I'd read it more
> carefully, I wouldn't have used it.
You're responsible for that choice!
> With the base types that were defined in 1985.
The term "base type" does not appear in IEEE 754. The term "base" is used
in IEEE 754 only to describe the number base used for the representation.
The 128-bit format is not a *basic format* in 1985, it's a possibility from
among the myriad possible *extended formats*. IEEE 754 doesn't
characterize the 128-bit format as a "base type", and I'd say goes to rather
significant lengths to indicate otherwise, both for the general and the
specific cases.
> I dispute that floating-point formats are typically defined for the
> individual platform. They haven't been since 1985.
Are you *truly* insisting that the floating-point formats designed decades
ago for the Burroughs Large System, the IBM 360, the Univac 1108, and other
platforms whose architectures continue to attract new customers to this day
*ceased to exist as defined formats* in 1985?
> IBM S/390 now has IEEE 754 hardware support.
Goody for them. The 32-bit and 64-bit formats are *still* not adequate for
31-digit COBOL arithmetic.
> All those follow IEEE 754.
The other question I have is whether they also follow IEEE 854, and the
various ISO and IEC standards *already published*.
> > Or is it the irrelevance of everything but PC's to the world of COBOL
these days?
>
> On the Top 500 computer list, 93% are based on Intel, Power, HP, AMD
> or Alpha. For instance, the Thunder system at Lawrence Livermore
> delivers 20 teraflops from 4K Intel Itaniums chewing on IEEE 754
> numbers.
>
> Granted, that's not a likely Cobol machine. But high-end servers from
> Sun and HP costing $2M are candidates, as are millions of mid-range
> servers.
> None of these machines are PCs.
Are any of them capable of the 32-digit arithmetic that COBOL requires (and
COBOL requires it because *users* demanded it)?
> I didn't site these sources to show a 128-bit implementation; I cited
> them to show that chip manufacturers are serious about following IEEE
> 754. They don't go their own way. They do not define floating-point
> formats for each platform.
Being serious about IEEE 754 isn't necessarily the same as being serious
about meeting the needs of the large financial institution or the large
manufacturer. Or of the average COBOL user.
32-bit and 64-bit basic binary floating-point formats from IEEE 754 might be
a "nice touch" for standard COBOL, but doesn't add functionality as far as
I'm concerned. The implementor of COBOL for a given platform is *today*
free to use these formats for USAGE FLOAT-SHORT, FLOAT-LONG and/or
FLOAT-EXTENDED -- or to *not* use them for those USAGEs -- *whether or not
the target platform provides hardware support for these formats*.
As for BINARY-CHAR, BINARY-SHORT, BINARY-LONG and BINARY-DOUBLE, what each
of these is understood to mean in a given environment in COBOL or otherwise
is frequently defined in terms of the word length of the individual
*platform*. This means that what is BINARY-LONG on one machine may be
BINARY-SHORT on another. And what I read of C++, the same is true there.
The only formal movement I've seen toward the adoption of IEEE-style
floating-point formats *in language standards* is in the current draft for
the next FORTRAN standard.
Now that a single 128-bit binary floating-point format is *on its way* to
becoming formally standardized, I personally would think adding support for
these formats *as a syntactic addition to* the language would be worthwhile,
and will probably end up pursuing it for a future standard.
But as it is, any implementor on a platform is free to define the three
standard floating-point formats provided by the language as defining items
in IEEE formats -- or not -- as they see fit or as their users demand. They
are also free to provide syntax in the language describing the three IEEE
formats in implementor-defined extensions -- or not -- as they see fit or
as their users demand.
As to standardization in other languages, I see the following in an on-line
C++ reference:
<<The size and range of any data type is compiler and architecture
dependent. The "cfloat" (or "float.h") header file often defines minimum and
maximum values for the various data types. You can use the sizeof operator
to determine the size of any data type, in bytes. However, many
architectures implement data types of a standard size. ints and floats are
often 32-bit, chars 8-bit, and doubles are usually 64-bit. bools are often
implemented as 8-bit data types.>>
"Often" is not "always", even in standard C++, as I see it. In a
(hypothetical) machine with addressibility at 64-bit boundaries, does a
32-bit int (or BINARY-SHORT) really make all that much sense? The extra
cost that might be incurred by arithmetic involving a BINARY-LONG instead of
a BINARY-SHORT might actually be offset by the cost of retrieving the
half-word item! I have seen the Intel architecture go from 16 to 32 to 64
bits. How long will it be before the "native word length" for commodity
hardware becomes 128 bits, and thus the logical format for a "long
double-precision item" occupies 512 bits?
-Chuck Stevens
- Next message: Richard: "Re: cobol data format!!! urgent!!!"
- Previous message: Richard: "Re: MaxDB = SAPDB = ADABAS (was: Sorts (revised)"
- In reply to: Robert Wagner: "Re: cobol data format!!! urgent!!!"
- Next in thread: Clark F. Morris, Jr.: "New users for traditional architectures was Re: cobol data format!!! urgent!!!"
- Reply: Clark F. Morris, Jr.: "New users for traditional architectures was Re: cobol data format!!! urgent!!!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
