Clark,
When you bring up Java, this confuses me. Currently IBM does all the
required conversion for floating point items shared between COBOL and Java
in a z/OS environment.
Do you have real-world evidence that this does isn't working.
***
As far as SHARE requirements go, Requirement SSLNGC0413617,
ISO 2002 defined floating point data types
from 2004 includes the following information,
Again, it is important to state that not all of these reasons are valid
for all
SHARE installations; some installations would find one or more of these
reasons
compelling; while other installations would find only a single reason their
motivation in setting the priority as it is.
Finally, to avoid continuing confusion about whether or not this requirement
is
asking for IEEE floating point support, a separate requirement
(SSLNGC0413621"
That requirement currently has a response of "RECOGNIZED" (the lowest
-non-REJECT response).
the requirement SSLNGC0413621,
COBOL (optional) support for IEEE Floating Point
also has a response of "RECOGNIZED"".
My assumption is that IBM is treating the older requirement as against the
binary format as the newer requirement SSLNGC07005
COBOL support for Hardware decimal floating point
already has an ACCEPT response.
As currently written, I would *think* that it would be clear to IBM that
this is asking for the ONLY format of IEEE floating point data that was
available IN 2004. However, there is nothing in the requirement that
actually says that it needs to be "old-style binary IEEE floating-point" and
that the requirement would NOT be met by providing decimal floating point
support.
"Clark Morris" <cfmpub...@ns.sympatico.ca> wrote in message
news:<6tkem45k95u9c18tmoutc4o98cs772i...@4ax.com>...
> On 7 Jan 2009 15:25:56 -0800, in bit.listserv.ibm-main you wrote:
>
> >Clark,
> > Easy answer, there have been no recent changes to IBM's responses on
> >floating point (or bit) support.
> >
> >Harder answer is that you keep getting confused about different terms and
> >requirements.
> >
> >In the '02 Standard there are 3 new USAGEs
> > FLOAT-SHORT
> > FLOAT-LONG
> > FLOAT-EXTENDED
> >
> >IBM (or anyone else) *COULD* implement these as any format of floating
point
> >they wanted, e.g.
> > FLOAT-SHORT *could* equal COMP-1
> > and both
> > FLOAT-LONG and FLOAT-EXTENDED *could* equal COMP-2
> >
> >There is no requirement in the Standard they be implemented in any IEEE
> >format (or any other portable format). There isn't even any requirement
> >that float-extended take more storage than float-long (but it can't be
> >smaller).
>
> I understand that IBM could implement these usages as hex floating
> point. However, this would be short-sighted and shoot self in foot
> implementation. IBM COBOL already has the requirement to communicate
> with JAVA which uses IEEE binary floating point. Thus implementing
> the new usages as IEEE is upward compatible with existing programs and
> in fact allows them to have both types of floating point in a single
> program.
> >
> > ***
> >
> >OK, now for the terminology "IEEE" floating point.
> >
> >I think (but won't swear to it) that you are talking about the OLD (not
> >decimal based) floating point format. Adding support for this would
> >certainly aid in communication with other z/OS languages and facilities
that
> >already support this - as well as in handling files created in other
> >environment.
> Exactly
>
> >
> >However, before you see that in COBOL, it would be my best guess that IBM
is
> >likely to implement the IEEE *decimal* floating-point formats already
> >available in Assembler, PL/I, DB2 and possibly other z/OS
> >languages/facilities. Not only does this seem to be a "strategic"
direction
> >for IBM, but it also provides a data-type that retains COBOL's historic
> >interest in "decimal arithmetic accuracy" that can be "lost" in both the
> >traditional IBM "hex" floating point and the older IEEE binary based
> >floating point.
>
> Why not do both at the same time. I believe JAVA now has the decimal
> floating point and JAVA COBOL co-existence was strategic at one point.
> Maybe the requirements for implementing various of the 2002 standard
> features should updated to point to JAVA co-existence and IBM
> strategic directions. While the last time I touched COBOL was late
> 2006, I would be willing to update any of the requirements I
> submitted.
> >
> >I certainly do not know when this latter may show up, but I would expect
it
> >sooner than later. As far as the older IEEE support, I wouldn't be
> >surprised if that NEVER shows up in COBOL (and I am not positive that
there
> >is a requirement that explicitly asks for it).
>
> I thought that I submitted one in the 2002 - 2004 time frame.
> >
> >"Clark Morris" <cfmpub...@ns.sympatico.ca> wrote in message
> >news:<ht7am41ddtc4r8c3cij01vdugok96c4...@4ax.com>...
> >> On 6 Jan 2009 13:09:50 -0800, in bit.listserv.ibm-main you wrote:
> >>
> >> >>for zcobol initial release at SHARE. It doesn't test things like
EXEC
> >CICS or
> >> >>Enterprise COBOL extensions such as EXTENDED-FLOAT, but it sure looks
> >like
> >> >
> >> >There is no "EXTENDED-FLOAT" in Enterprise COBOL.
> >> >There are floating-point data types, COMP-1, COMP-2, and "external
> >> >floating-point". There is a "FLOAT-EXTENDED" that is a part of the
2002
> >> >COBOL Standard that we have not yet implemented in Enterprise COBOL,
> >> >maybe you are thinking of that?
> >>
> >> So what is the status of USAGE BIT and the other usages related to the
> >> 2002 standard for which there are existing SHARE requirements? Proper
> >> implementation of the standard floating point USAGEs (IEEE floating
> >> point) would allow COBOL to cleanly communicate with JAVA while
> >> leaving any existing COMP-1 and COMP-2 data as hex floating point. And
> >> is IBM COBOL going to support the decimal floating point that has been
> >> implemented at least on the z series and that was sponsored by IBM?
> >> >
> >> >Cheers,
> >> >TomR >> COBOL is the Language of the Future! <<
> >> >
> >>
> >> ----------------------------------------------------------------------
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> >> Search the archives at http://bama.ua.edu/archives/ibm-main.html
> >
> >----------------------------------------------------------------------
> >For IBM-MAIN subscribe / signoff / archive access instructions,
> >send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> >Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
