>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