IBM Mainframe Forum

bobguo wrote:As i understood, RMODE is enough to tell computer where it should be resided, below the line or above? I can not think up the purpose of AMODE.

AMODE is a hint to the Assembler and Linkage Editor to tell the OS to EXECUTE the program in 24/31/64 bit.
RMODE is a hint to the Assembler and Linkage Editor to tell the OS to LOAD the program below 16M or 2G, if needed.

... What's the difference between them? Can AMODE tell computer some information more? ...

It does get a little complicated. The Assembler does not care about AMODE and RMODE; it just passes the value to the object code.

The Binder/Linkage Editor cares about RMODE: it tallies all of the RMODE declarations it sees in its input; the output load module is assigned the most restrictive RMODE in its input, unless, of course, the RMODE is forced by parameters or *PROCESS statements.

The Binder/Linkage Editor assigns the load module the AMODE specified for the section or ENTRY symbol specified as the entry point, unless, of course, the AMODE is forced by parameters or a *PROCESS statement.

Finely, program fetch loads the load module according to the module RMODE.

The AMODE is a little more complicated. If the module is called by the supervisor (in other words by a LINK, XCTL or ATTACH macro) the AMODE is the AMODE defined for the entry point. If the module is loaded into storage by the LOAD macro, the module address returned by the macro provides the expected AMODE, but it is up to the calling program to switch to the specified AMODE before it calls the module, and switch back, if necessary, to the preferred AMODE when the module returns. Originally, the BSM instruction was provided to reset the AMODE; in z/Architecture the TAM (Test Addressing Mode) and SAM (Set Addressing Mode) instructions were provided to support AMODE 64.

thank you for your reply. To catch it, i still have to read and think it over and over again.

bobguo wrote:

Select all

         DS    0F
         ORG   *-40
THEDCB   DS    0F
         ORG   *+40
* 12 bytes of DCB data

by doing this, the size of DCB was expanded by 40 bytes, from 96 to 136 bytes, so there is enough room to store 31 bits addresses, right?

"* 12 bytes of DCB data"
Do you mean at the beginning of the original DCB, there are 4 addresses, and each one is 24 bits?

I missed this last year, but bobguo is mistaken. The "missing" 40 bytes are part of the DCB, they just are not used. I downloaded an OS/360 MACLIB from the overflow "tape" at http://www.cbttape.org, then prepared the following assembly and ran it through the assembler with both the MVT MACLIB, and the z/OS SYS1.MACLIB.With the OS/360 MACLIB, EXCPDCB1 expanded as expected, but EXCPDCB2 expanded asUsing a z/OS SYS1.MACLIB, EXCPDCB1 expanded as
and EXCPDCB2 expanded just like it did with OS/360.

In OS/360 most DCBS were 96 bytes, just like z/OS. I think some DCBs could be bigger.

recently,i found that most of programs can use AMODE(31) and RMODE(24), I wounded which programs must be set to
AMODE 24
RMODE 24
?
thx.

bobguo wrote:recently,i found that most of programs can use AMODE(31) and RMODE(24), I wounded which programs must be set to
AMODE 24
RMODE 24
?
thx.

You are correct. Your question about AMODE 24/RMODE 24 is a good one, and it's actually kind of hard to answer. Recently I retrieved some MVT MACLIBs from http://www.cbttape.org. I assembled one of my programs using them. Though it's not obvious, the program is AMODE 24/RMODE 24. The same program, with definition changes, runs perfectly well AMODE 31/RMODE ANY when assembled with z/OS macros.

There are detail issues about instruction execution differences between AMODE 24 and AMODE 31. Check BAL/BALR, LA, and a few other instructions. I will discuss a few of these issues.

In the old days, many programmers (me included) usedto remove data from the high order 8 bits of register x. This won't work in AMODE 31, for obvious reasons. This was done, for example, when fiddling with addresses in a DCB, or just using the addresses.

BAL/BALR in AMODE 24 can be used to retrieve the condition code and program mask in AMODE 24, though it was rarely used for that purpose. It won't work in AMODE 31. Extended Architecture (the official name for AMODE 31) added the IPM instruction for this purpose.

The GET/PUT/READ/WRITE/CHECK macros before MVS/XA will not work correctly in AMODE 31 because of the way addresses are stored in a DCB. I'm sure there are others.

"wounded"!? I think you meant "wondered."

steve-myers wrote:A quick quiz for you. In the R form GETMAIN macro, you see

Select all

         BAL   1,*+4

Why is the instruction there? What happens in the 31-bit addressing mode?

In 24-bit mode, the condition code is loaded into the leftmost byte of register 1 while in 31-bit mode the left-most bit is set to 1 and all remaining 31 bits are used for the address. I know that in earlier days, code like that has been used to save the condition code, but I admit I never understood what that was for.

BAL in both AMODE 24 and AMODE 31 set the high order bit of the link register to 1, but for different reasons.

In AMODE 24, the two high order bits of the link register are set to the instruction length code of the instruction; the ILC for a 4 byte BAL instruction is 10, which causes the high order bit to be set.

In AMODE 31, the 32 right most bits of the PSW are stored in the link register. Since the high order bit is set to 1 to indicate AMODE 31, by definition the high order bit in the link register is set to 1.

The second part of the question is why does the macro set the high order bit? The answer is to identify a GETMAIN request since SVC 10 is used for both GETMAIN and FREEMAIN.

FREEMAIN R,LV=(0),A=(1) where the length to free is in register 0 and the address to free is in register 1 will generate

LA 1,0(,1) to ensure the high order bit of register 1 is off.