>yea- but why would you do that?
>If you are without a base, it is likely code- right?

I'd say "not right". The reason we would usually do this is because we are 
trying truly to have no base at all except when needed (because with the 
advent of all the immediate instructions you have far fewer cases where 
you need to access data in static storage when you're not invoking 
macros). 

Then it comes down to whether the instruction you need to access the data 
has an index reg.

So consider
         LARL  RegX,MyData
         L     RegY,MyWord(RegX,0)
         MVC   MyTarget(L'MyString),MyString(RegX)

MyData   DS    0D
MyWord   DC    F'3'
MyString DC    CL16'...'

In AR-mode, you would need to set the AR of RegX for the MVC but not for 
the L, since the L uses RegX in the index reg position.

Everyone familiar with AR-mode coding or with reading AR-mode code should 
well understand the extremely valuable technique of utilizing the "index 
reg" notation

>But beware that some MVS services (notably WTO) use some subset of ARs
>0-1 and 14-15 as work registers, and return them containing non-zero
>values. It's documented, but it changed some time back, and caused
>trouble for code that inadvertently relied on their not being changed.

>a CPOOL callable service started returning some junk in AR1. 

The linkage conventions are clear; the documentation for the services is 
clear. Do not rely on things that the documentation says are not 
preserved. And unless some specific service documents otherwise, assuming 
that the low half of reg 0, 1, 14, 15 or the high half of reg 0, 1, 15 or 
access register 0, 1, 15 is preserved across any system service is simply 
wrong. When it is convenient or necessary services will use the registers 
that are available to them (whether that be the low half of registers, the 
high half of registers or access registers). FWIW, "junk" to you might be 
valuable data to someone else (or might truly be "junk" for everyone other 
than the service itself).

>But maybe the CALL macro should be changed to use LAE.

The fact that this statement is made implies to me that you are not in the 
habit of telling macros via SYSSTATE what your ASC environment is.
In many cases you can expect incorrect code if you do not properly tell.
I'll leave to the readers to compare the expansions of
         CALL  (15),(A,B,C)
         SYSSTATE ASCENV=AR
         CALL  (15),(A,B,C)

>As an aside, LAE didn't even exist when the first version of 
>cross-memory access came out (primary/secondary only), to the best of my 
>recollection.

More completely, access registers did not exist at that time.

Peter Relson
z/OS Core Technology Design

Reply via email to