I recently ran into this problem... I updated a common service
subroutine, and for no apparent reason, a CPOOL callable service started
returning some junk in AR1. The service routine doesn't touch the ARs,
and never switches ASC mode other than a "safety" SAC 0 at entry.
However, because AR1 isn't restored by PR, it propagated back to a main
routine that was running in AR mode. It typically used LA R1 to address
the parm list for its next call, and an S0E0 resulted. The lesson to be
learned is that AR code must never assume AR14-AR1 are preserved across
any subroutine call. Using LAE R1 was the fix in this case.
But it got me to thinking... why isn't LA modal for ASC mode? I can't
think of any situation where it would be a problem for it to act like
LAE when in AR-mode. Why even have LAE? LA and LARL are modal for
addressing mode, it would be simpler if they were for ASC mode, too.
The kicker is that LAE *is* modal for ASC mode (as well as amode). That
is, it always sets the target AR according to the current ASC mode (0 =
primary, 1 = secondary, AR to AR if AR mode). Seems to me that could be
surprising to code in secondary-space mode. It would be more logical to
me if LAE always copied the AR from the source base regardless of ASC mode.
However, it's a safe assumption the architecture won't be changed at
this late date. But maybe the CALL macro should be changed to use LAE.
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.
sas
On 12/16/2014 12:24, Tony Harminc wrote:
On 16 December 2014 at 03:51, <[email protected]> wrote:
I guess that I really want LARLE to set AR2 as well a GPR2.
Not - not realy- There is no need for it. You need an AR with zero in
it if your intent is to move some constants from non AR based stuff to
a dataspace (while in AR mode)
14 and 15 come in handy (they are very transient and are extrem
likely to have a zero)
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.
Worse, if the WTO is there for diagnosis only, the code breaks when
you enable tracing/logging but runs fine otherwise.
Tony H.
