There are some cases that do need it. If a program is processing XML or Large OBjects ( LOBs - document images, video, audio ) the memory use baloons up pretty fast. If these are being used under CICS multiply by the number of concurrent transactions. There is only so much that you can fit below the bar so more data there means less of code. Channels and containers in CICS are already above the bar and have to be shuffled around the bar because COBOL can't address them where they are. In my opinion this enhancement is more useful than the object oriented entensions they added I- don't-know-when-because-I-have-yet-to-see-them-being-used. Mohammad
On Fri, 9 Jan 2009 08:09:12 -0600, John McKown <joa...@swbell.net> wrote: >On Fri, 9 Jan 2009 14:56:51 +0100, R.S. <r.skoru...@bremultibank.com.pl> wrote: > >>Is there any reason to have 64-bit COBOL on z/OS ? >>Of course except satisfaction when watching AMODE 64 in ISPF member list... >> >>-- >>Radoslaw Skorupka >>Lodz, Poland > >I've often wondered this as well. 31 bit addressing gives the possibility of >more than 1 Gib of data for an application. What __user written__ >application would use more than this? > >I understand 64 bit addressing for system type functions. I guess. But even >that is overkill because you cannot configure any z/OS system such that you >could actually acquire that much addressable storage. Now, using 64 bit >address space to "memory map" VSAM LDSes starts to make sense to me. > >"64 bit" is, for now, more marketing hype as far as I can see. But I've been >wrong before, if somebody has a good, actual (not theoretical) use for 64 >bit addressing in an application program. > >-- >John > ---------------------------------------------------------------------- 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
