I've read in the Princ. of Ops that SACF is a bit faster than SAC. Initial
implementation on the test system went fine. (Why not squeeze a little
performance out, eh?) :-)
However, after putting the code in a busy production system, I am getting
screwy results, and am wondering if SACF is biting me.
Here's the situation. I have a piece of intercept code that gets control.
I issue SACF 0 to make sure I am in primary ASC mode. The program
subsequently S0C4s, pic 11.
Looking in the dump, the PSW says primary mode, CR4 = ASID X'01B6'.
CR3=ASID X'0C1D'. CR1=FFAEC003. CR7=FFC6C003, CR13=FFC6C003.... which
all jives for what I expect.
GPRegisters are:
R3=0
R4=7FFF0000
R14 = 0
R13=the caller's save area in storage. R13 is correct.
In IPCS, I look in primary address space (ASID X'01B6') storage, at the
location of R13, and there exists a valid save area. Good so far. (For
grins, in ASIDx'0C1D', the value is the same common storage area.)
At R13+12 in the dump, where I would expect to find valid return address,
it
is indeed there. However, just prior to the abend, R14 was loaded via
R13+12, and at the time of the dump, R14 is zero. This is certainly not
as
expected.
Also, in the save area pointed to by R13, the value in the location for R3
also contains what I expected it to contain, but after loading R3 from its
location off of R13, the register is also zero in the dump. I S0C4'ed
after loading R4 a bit from R3 (low core), and then referencing off of R4.
This is the weirdest thing. Could using SACF 0, a few instructions
prior,
be causing these results?
z/OS 1.4. Running key 0, supervisor state, AMODE64, SRB mode. All ARs
are
0, except AR0.
Thanks for any insight. tb.
|
