On 8 Oct 2009 14:08:24 -0700, in bit.listserv.ibm-main you wrote: >------------------------------------<snip>----------------------------------- >Obviously given the lack of support for 64 bit, the failure to implement >64 bit addressing so COBOL can run nicely in 64 bit Websphere, the >failure to implement USAGE BIT, the failure to implement the IBM pushed >decimal floating point, the failure to implement IEEE floating point >using the 2002 COBOL STANDARD floating point usages, it is obvious COBOL >is seen as a cash cow to be milked until phase-out. >----------------------------------<unsnip>----------------------------------- >I can't agree with that conclusion. Having examined compilers and >libraries from OS/360 with an eye toward 31-bit addressing, I can tell >you that the changes atr non-trivial and could get very expensive very >fast. For all we know, the changes you ask for may be already in the >works, but updating a compiler and all the associated library >subroutines can get very involved very quickly, especially when downward >compatability is still an important feature.
It could be done (and probably would have to be done) as a compile option since 31 and 64 bit can't be mixed in an enclave if I have read things correctly. Thus you can't have a 64 bit COBOL bean in a 64 bit Websphere enclave. IBM could have defined binary IEEE floating point as the floating point for the 2002 standard true binary usages leaving COMP-1 and COMP-2 to mean what they currently mean. This would have been the intelligent way to interoperate with Java since changes to programs were needed to interact with Java anyway. > >Rick > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
