We have a problem with a stacking, space-switching, cross-memory PC routine
called from CICS (from an L8 region). It works fine--it's heavily used and
heavily tested--except when testing some invalid use cases, which force a S0C4
(as expected). What isn't expected is that the CICS region goes down *under
certain circumstances* with a KERNDUMP resulting in a U1800 ABEND. Since we
have tested many other deliberate ABENDs and get ASRAs as expected, this seems
odd.
Environment:
- mainline does a BRAS to a subroutine to validate storage access. There are
ESTAEs set up in the STC. These don't seem related, as disabling them does not
change behavior.
- subroutine causes S0C4. Region goes down with U1800 ABEND, reason=00000000.
- in trying to nail things down, we put a DC H'0' in the subroutine, moving it
earlier and earlier.
- eventually we had it as the FIRST instruction in the subroutine, before even
saving registers. Still U1800.
- then we moved it to before the BRAS. ASRA.
After much tinkering, we moved the BRAS much earlier in the routine, and made a
dummy version of the subroutine that just did the DC X'00'. ASRA.
Also left the BRAS where it was and moved the dummy version of the subroutine
earlier. ASRA.
So it *seems* like CICS is unhappy when the exception occurs further down in
the module. But why would it care? It's not past the first page of
addressability (indeed, the module only has one base register). But there's no
substantive difference between:
BRAS R14,LABEL
...
LABEL DS 0H
DC X'00'
and
DC X'00
BRAS R14,LABEL
(I mean, there is, but shouldn't be in terms of ABEND behavior!)
It isn't even that R14 is somehow important (which would make no sense anyway,
since registers were saved etc. long ago)--changed it to use an otherwise-free
register, same behavior.
Any ideas?
--
...phsiii
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
