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
