There needs to be an expectation level set here: 64 bit addressing does not equal 64 bit arithmetic.
You can use the 64 bit arithmetic instructions WITHOUT using 64 bit addressing. Our product does it all of the time. You just need to be running on the correct architecture to use the 64 bit arithmetic instructions. Lloyd --- On Fri, 10/9/09, Bill Klein <[email protected]> wrote: > From: Bill Klein <[email protected]> > Subject: Does Ent. COBOL 4.1 generate 64-bit binary arithmetic instructions? > To: [email protected] > Date: Friday, October 9, 2009, 2:47 AM > 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 > ---------------------------------------------------------------------- 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
