For me, this discussion rises the question, if there should be special techniques
for 31-bit-software running below the bar to access storage areas above the bar.
Because: the impact on existing software and compilers would be enormous,
if all pointers would have to be enlarged to 8 bytes.
So: is there a need to have two classes of pointers, some of them able to
access storage above the bar? And special function calls and language
constructs to create and access areas above the bar?
Of course, you can do it with ASSEMBLER or C language subprograms,
then you don't need AMODE 64 versions of PL/1 or COBOL with RMODE
below the bar. The subprograms have to copy the relevant parts of the area
into below-the-bar-storage (think of a key/data-interface that gets a page
or so from the large area above the bar).
What do you think about this? For the existing PL/1 code base, for example,
it would be a big change if all pointers would be 8 bytes long ... I don't see
this happen in the near future.
Am 18.01.2015 um 03:30 schrieb S.T.:
> No, you do not understand. I was answering Tom on why COBOL should be made to
> have access to data above the bar (2GB address range) now, not later.
> That a COBOL program can't execute in the area above 2GB is a completely different issue.
> On 01/17/2015 01:52 AM, M.M. wrote:
>> Dear S.
>> As I understand from your explanations, compiling COBOL in 64 bit mode is not useful.
>> But the question is that this much of addressable of memory (64 Bit ) is for what ?
>> Because as I know most the applications in mainframe are developed by COBOL and C.(Mostly COBOL)
>> Best regards M.