On 12 Apr 2006 21:45:26 -0700, [EMAIL PROTECTED] (Timothy Sipples) wrote: >Clark Morris writes: >>So will you be able to compile COBOL programs that can run in 64 bit >>mode inside of Websphere? Can they interoperate with JAVA and will >>they finally recognize IEEE floating point so that NO conversions are >>needed to work with JAVA. > >Really good questions. All I know at this point is that IBM provided a >"technology preview" (starting a couple years ago) describing how you >could compile COBOL in such a way as to run as EJBs inside WebSphere >Application Server for z/OS. You had to follow certain rules >(thread-safe, extreme care in how to do I/O, etc.), but it's an intriguing >technology. > >Before anyone asks, no, I don't have the reference for this technology. >IBM may be hiding the information now -- it's not popping up in my >searches of the IBM Internet Web sites. Talk with your friendly local >WebSphere and/or mainframe specialist about it. Just because it's possible >doesn't mean it's necessarily a good idea, especially post-zAAP. > >As you might know, here's what IBM is officially saying about 64-bit >COBOL: > >- - - - - > >http://www-03.ibm.com/servers/eserver/zseries/zos/installation/zos_cobol_faqs.html > >Question: Will there be a version of COBOL and/or the BINDER that will >create 64-bit COBOL load modules to run under z/OS? > >Answer: We have no plans for 64-bit addressing support in COBOL. The >BINDER already supports 64-bit assembler programs and will support 64-bit >C/C++ programs in the future. We have not heard of any customers requiring >64-bit addressing in COBOL programs. If you have a need for that, please >send your requirements to us with details about why 31-bit addressing is >not enough. Please use the Contact z/OS link below. >
This answer shows that the responders neither understand the problem nor the strategic implications. Most if not all existing COBOL programs by themselves are not in any need of 64 bit addressing. However as data requirements expand (take a look at the maximum size data area expansion in Enterprise COBOL) and the number of data areas for a COBOL routine within an instance expand (Websphere, CICS region, etc.) the pressure for COBOL to have data areas that can live above the BAR will grow. This in most ways is transparent to the COBOL application and is driven by IBM strategy. Failure to be able to exist in a 64 bit environment eventually will introduce limitations in use and a requirement to rewrite in some other language. In short COBOL developers see no need to play nice in the new world. >- - - - - > >Now, is this a problem (with respect to the COBOL EJB technology preview)? >I don't know, but it's interesting that we'll have both 31-bit and 64-bit >Java support in the same WebSphere Application Server release. I was >thinking in terms of how it'd be useful for smooth Java migration >(especially for ultra-cautious customers), but COBOL interoperability >(with COBOL EJBs) might be another such area. If you're working with the >COBOL EJB technology then I would check with your IBM contact on that to >see what he/she says. I guess we'll all find out more as the 64-bit >delivery gets closer how this all fits together in the various mixed-mode >permutations. It's a little early for me yet. My educated guess is that it >will be very flexible. > >With respect to the IEEE floating point question, obviously the current >situation functions just fine, but I think you're referring to a question >of overhead and efficiency (which I get the impression is good, but >engineers always look for better). I believe the official line on this is, >"We understand." For slightly less official information I'd recommend >SHARE forums, possibly combined with alcohol. :-) Again, there are certain boundary conditions where the floating points don't translate but the basic issue is why should we have to put up with the overhead of translation of parameters that from the COBOL point of view are NEW with the Java interface. There has been since 2002 an ANSI/ISO approved way to add IEEE floating point to COBOL. And to others, there are SHARE requirements on record requesting all of these with justifications that include the points that I have just made. > >- - - - - >Timothy F. Sipples >Consulting Enterprise Software Architect, z9/zSeries >IBM Japan, Ltd. >E-Mail: [EMAIL PROTECTED] > ---------------------------------------------------------------------- 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
