On Tue, 16 Dec 2014 13:31:54 -0500 Steve Smith <[email protected]> wrote:
:>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. Uncertain why the calling routine expected the AR15-AR1 to remain unchanged. :>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. LA Rx,5(Rx) would set ARx to zero. Break existing code. :>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. Than the AR/GR will not point to the data in ARMODE. :>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. There weren't ARs in the original XMEM. -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies.
