Posted: Mon Jun 07, 2004 4:39 am Post subject: Advantages of Converting 24 to 31 Bit Address
Hi,
I am working on Z/OS system right now. I have some programs with AMode=24 & RMode=24 and some programs with AMODE=31 & RMODE=Any. I came to know that If program with AMODE=24 calls Program with Amode=31 will abend.
Also i came to know that Z/OS uses 64 Bit Addressing and Even the Programs are compiled with AMode=24/31 these Loads will make use of 64 Bit Address.
This means the On Z/OS even AMODE=24 Program Calls
31 Program will not abend ?? Is it right or wrong..
Posted: Mon Jun 07, 2004 7:07 am Post subject: Thanks for response
kolusu,
Thanks for your fast response.This given links given me good idia about 24 Bit & 31 Bit addressing. But i have these doubts.Please respond..
1)These above given links are not given any direct solution to my problem. But i understood that even in Z/OS, it will abend when 24 Bit Program calls 31 bit program.Am i right?
2)Also i have a doubt that whether there is Compiler for 64 Bit. As per my understanding there is no compiler available for 64 Bit & 31 Bit Load Modules can use the facilities of 64 Bit...
Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
Posted: Mon Jun 07, 2004 9:07 am Post subject:
Niranjan,
1.Not exactly true.You can call a 31 bit program from a 24 bit program without any problem.
2. Though COBOL does not support 64-bit addresses in COBOL programs, the BINDER already supports 64-bit assembler programs and will support 64-bit C/C++ programs in the future.
Joined: 03 Jan 2003 Posts: 550 Topics: 23 Location: Michigan, USA
Posted: Mon Jun 07, 2004 9:23 am Post subject:
Kolusu,
If you dynamically call a 24 bit subroutine from a program that resides above the line (in 31 bit land), there may be a problem on the return as the return address will exceed the maximum value that a 24 bit address can hold. Is this not true?
There may also be problems if you call it with a "using" phrase and the variable is also above the line.
Incidentally, this problem also applies to 31 bit subroutines being called by programs that reside above the bar (64 bit land)
Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
Posted: Mon Jun 07, 2004 9:51 am Post subject:
Bithead,
You are right about the problem when calling a 24 bit subroutine from a program that resides above the line.
Examples of this are ILBOWAT0, [/b]IDCAMS[/b]. When you are calling these programs 2the main program which is calling these modules needs to be compiled with CBL DATA(24)
Niranjan's question was the reverse, he wanted to know if he can a 31 bit program from a 24 bit program
Joined: 03 Jan 2003 Posts: 550 Topics: 23 Location: Michigan, USA
Posted: Mon Jun 07, 2004 10:04 am Post subject:
Then isn't the problem reversed? If you dynamically call a 31 bit program that is residing above the line from a program with 24 bit addressing, then you will get an S0C4.
Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
Posted: Tue Jun 08, 2004 12:03 am Post subject:
Did they reside in the same load module? If so, the code will all be <16M. Unless the compler does mode switching (BSM, etc), or uses SVC 6 or similar (LINK, etc), calling an AMODE31 pgm from an AMODE 24 will usually abend. That is, unless by chance the AMODE31 program gets loaded <16M (which is not unusual, but should never be assumed). Something has to switch the bit in the PSW or you will get into trouble.
As for 64 bit, any program can change its addressing mode, but it must do so explicitly. At this point, 64bit addressing is pretty much reserved for system routines.
Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
Posted: Tue Jun 08, 2004 7:53 am Post subject:
Semigeezer,
They are not in the same load module. The main program is with AMODE(24) and RMODE(24) and the subprogram is AMODE(31) and RMODE(any). This is how the load module looks like
Code:
TXXXXXX.TEST.LOADLIB Row 00001 of 00002
===> Scroll ===> CSR
Name Prompt Alias-of Size TTR AC AM RM
COBSQRT 00001340 000010 00 31 ANY
MAIN 000012D0 000003 00 24 24
The MAIN program calls the COBSQRT program dynamically.
Joined: 03 Jan 2003 Posts: 550 Topics: 23 Location: Michigan, USA
Posted: Wed Jun 09, 2004 10:58 am Post subject:
Kolusu,
I created a program called TRASH3 which I compiled with DATA(24) and linked with AMODE(24),RMODE(24).
I then created a program called TRASH2 which was compiled with data(31) and linked AMODE(31),RMODE(ANY). It dynamically called TRASH3 with a 10 byte data area.
I got the following error:
IGZ0033S An attempt was made to pass a parameter address above 16 megabytes to AMODE(24) program TRASH3.
From compile unit TRASH2 at entry point TRASH2 at compile unit offset +00000442 at address 0B20115A.
I changed both programs to removed the pass-area and compiled / linked them the same way. This time it worked fine.
Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
Posted: Wed Jun 09, 2004 6:04 pm Post subject:
As mentioned, something has to change the addressing mode of the system (hardware) for such calls to work. In Kolusu's case, it sounds like an SVC 6 was called (LINK). Data passed from a 24 to 31 bit pgm will be below the line so it will work. Not so the other way around. The reason return logic works in your 2nd case is that the LINK is doing the mode switching. That is to say, your program calls the link code via SVC 6 which sets up a save area and return address below the line and then calls TRASH3. TRASH3 runs and returns in 24bit mode to the system which then simply switches modes, propagates the return code to its save area and returns to your TRASH2 program.
Even if you just do a LOAD and branch from a 31 bit pgm to a 24 bit one, it *might* work, as long as no registers used for addressing contain non-zero values in the first byte. But the reason that programs usually have to run in 24 bit mode is precisely because they use that byte for something else. The old I/O routines (DCBs not DCBEs) are the usual reason for such things.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum