|
View previous topic :: View next topic
|
| Author |
Message |
praveen.vss
New User
Joined: 02 Sep 2009
Posts: 1
Location: hyearbad
|
|
|
|
| Why should we concerned about AMODE. Why can’t we just use an addressing mode (31 bit) that fits anywhere in the storage. |
|
| Back to top |
|
 |
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
In other words, specify AMODE ANY, or as you say, AMODE 31.
Some instructions and system interfaces work differently in AMODE 24 than in AMODE 31. The issues mainly affect lazy - or unknowledgeable - Assembler programmers. All the high level languages and their libraries are already AMODE agnostic.
For example, this code fragment will work correctly in AM0DE 24, but fail in AMODE 31. Brownie points to the first person that will tell us the problem. A few more brownie points to the first person who tells us how to make the code fragment AMODE agnostic. AMODE agnostic means the code fragment will work in either AMODE 24 or AMODE 31.
| Code: |
LA 2,CPARM
FPP L 1,0(,2)
FREEPOOL (1)
TM 0(2),X'80'
LA 2,4(,2)
BZ FPP
...
CPARM CLOSE (DCB1,LEAVE,DCB2),MF=L |
The LEAVE option in the CLOSE macro is actually a hint as to the actual problem.
The topic starter does raise a serious issue, one that causes problems for unwary programmers. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| Why can’t we just use an addressing mode (31 bit) that fits anywhere in the storage. |
And what about AMODE 64 (which is valid on system z machines now)? It does NOT behave like AMODE 24 or 31 but is still valid for C applications and LE. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| You're right, of course, but AMODE 64 is essentially non existent for Assembler. Personally, I've never done AMODE 64, so my experience with it is 0. I'm quite certain the usual access methods won't work. The topic starter didn't mention 64, so I decided to leave it alone. |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland
|
|
|
|
| Quote: |
but AMODE 64 is essentially non existent for Assembler
|
AMODE64 is essentially not available for high-level languages. it is available for Assembler - I've written AMODE=64 code in Assembler.
Garry |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1306
Location: Vilnius, Lithuania
|
|
|
|
| Garry Carroll wrote: |
| Quote: |
but AMODE 64 is essentially non existent for Assembler
|
AMODE64 is essentially not available for high-level languages. it is available for Assembler - I've written AMODE=64 code in Assembler. |
Enterprise PL/I supports AMODE64. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| Garry Carroll wrote: |
AMODE64 is essentially not available for high-level languages. it is available for Assembler - I've written AMODE=64 code in Assembler.
Garry |
I've always thought an AMODE 64 program will be switching between 64 and 31, do some regular I/O, switch back to 64. This strikes me as confusing as programs using access registers; they SAC 512 (if I remember correctly) to go into AR mode, and SAC 0 to go to normal mode. Yuck. At least you don't have access registers in AMODE 64 or the confusing (and nearly undocumented mess) to create a data space and connect it to an LDS! |
|
| Back to top |
|
|
Garry Carroll
Senior Member
Joined: 08 May 2006
Posts: 1193
Location: Dublin, Ireland
|
|
|
|
AMODE64 programs are RMODE31, so remain "below the bar". They don't need to switch to AMODE31 for I/O &c as they can address those areas an AMODE31 program can access without need for any switching.
Other than the fact that it can address data which is "above the bar", the AMODE64 program can do anything an AMODE31 program can do.
How the storage "above the bar" is managed is another matter and is completely different to AMODE24 / AMODE31 storage.
Garry. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| Garry Carroll wrote: |
AMODE64 programs are RMODE31, so remain "below the bar". They don't need to switch to AMODE31 for I/O &c as they can address those areas an AMODE31 program can access without need for any switching.
Other than the fact that it can address data which is "above the bar", the AMODE64 program can do anything an AMODE31 program can do. ...
Garry. |
Yes, but it is basically impossible to do I/O to areas above the bar or in AMODE 64. This means AMODE switching to do the I/O and MVC between above the bar and I/O buffers below the bar. I'm sure you realize the performance implications of large scale MVC or its equivalents. |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
Extract from the CICS TS V5R3 Resource Definition Guide, Chapter 38, "Invoking the DFHCSDUP program from a user program"
| Quote: |
Responsibilities of the user program
Before invoking the DFHCSDUP program, your calling program must ensure that:
* AMODE(24) and RMODE(24) are in force
* ... |
Sometimes, we just can't. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
My earlier point was that this statement of the OP
| Quote: |
| Why can’t we just use an addressing mode (31 bit) that fits anywhere in the storage. |
is not a valid statement -- 64-bit data is part of storage but cannot be addressed by an AMODE 31 program. |
|
| Back to top |
|
|
CICSWOLF
New User
Joined: 23 Oct 2018
Posts: 4
Location: USA
|
|
|
|
Hi Gentlemen,
I have the task to convert modules from AMODE 24 to AMODE 31,
after a couple intents, decided to separate DCB module from CICS module in order the second run in AMODE 31,
the code I take as example has 3 statements to set vector table as:
DC A(SYSPRT) Vector to standard sysprint DCB
DC A(SYSIN) Vector to standard sysin DCB
DC A(0)
tried to assembly and got errors in those, decided to
include macro CVT instead and assemble ok,
can still this module to be called by the CICS Module?
I will appreciate your Feedback. |
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK
|
|
|
|
| Please do not tail-gate other people's topics. Start your own. Topic locked. |
|
| Back to top |
|
|
|
|
