When it comes specifically to 64-bit COBOL, the biggest issue (IMHO) is "mixing" of 31-(and/or 24-)bit COBOL with 64-bit COBOL.
It is my impression (and I do NOT speak for IBM) that IBM is aware of the "desire" for 64-bit COBOL, but that (given the LE, not z/OS restriction on mixed 31-/64-bit) code, that they are looking at a "foreseeable but not immediate" 64-bit COBOL that will work A) in a 64-bit only environment (and maybe) B) will have some "mechanism" (NOT traditional COBOL run-unit and CALL statements) for communicating between 31-bit and 64-bit COBOL programs. My personal guess is that either or both of these will be "nice to have" but will get very little actual user-community use. COBOL "shops" (and applications) are just too used to "transparent" inter program communication. However, when/if such are available, it may (or may not) give IBM additional information on how to proceed from there and actually meet paying customer demands and expectations. When there was a recent SHARE LNGC vote on IBM providing such a solution (even if it were a transition step to a future more "mixed" environment), the LNGC project gave this sufficiently LOW priority that the requirement never even got sent to IBM. If any shop (with readers in IBM-MAIN) thinks that such a 64-bit COBOL product *would* meet their needs, please feel free to contact me off-list and I can give you the "rejected by user" requirement information so that you can submit it as a marketing REQUEST. NOTE: If your shop is interested in IBM providing a 64-bit COBOL solution with an explicit "statement of direction" (or actual implementation) of mixed 31-/64-bit COBOL programs in a single run-unit, then you can also contact me off-list and I will provide you information on that requirement and you can do a marketing REQUEST for that too. I wouldn't be very optimistic about how IBM would respond, but it can still be communicated to them. "Timothy Sipples" <[email protected]> wrote in message news:<of79a78257.faa461e9-on4925764a.001ddf83-4925764a.001f5...@us.ibm.com>. .. > This COBOL discussion feels like deja vu. :-) > > As a reminder, I am not speaking for IBM. > > There have been and are lots of discussions about future COBOL innovations, > both within IBM and with our customers. One of the big ones is how (and > consequently when) to get to 64-bit. I have my own (strong) views on that > question, which I express as often as I can. (And I know I'm right. :-)) > But, in all seriousness, there is a rather complex set of factors that have > to be considered on how, and ultimately the relevant voices are customers'. > They decide the "right" answer. > > So, I'll say it again: tell IBM what you want and how you want it -- and > what you value most. In particular, there is a tension between innovation > and potential risk. Do you want zero or near-zero risk? Well, then, maybe > IBM shouldn't be so aggressive in innovating. (I'm oversimplifying, but > that's the idea.) Said another way, COBOL (and PL/I) really do run the > mission-critical world, while some of these other languages don't. :-) > > Now, I happen to think my recommended approach perfectly combines maximum > innovation with zero or near-zero risk. (I have a "have your cake and eat > it too" idea.) But I don't get to decide these things. You do, subject to > the technical constraints of course. So please speak up, through the proper > channels. Much appreciated. Thanks. > > - - - - - > Timothy Sipples > IBM Consulting Enterprise Software Architect > Based in Tokyo, Serving IBM Japan / Asia-Pacific > 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 > ---------------------------------------------------------------------- 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
