I get the same result from the latest version of RXSSL.
I have done some CP tracing in RXSSL.
The code is failing with
DMSITP143T Addressing exception occurred at 816D7724 in system routine
RXSSL; re
-IPL
CMS
DMSDIE3550I All APPC/VM and IUCV paths have been
severed.
The failing code (after macro expansion) is:
L SQRAR,WRKINTA
SR R1,R1
IC R1,0(,SQRAR)
(It’s failing on the IC.)
The value in SQRA = R9 is 1E38775C – way outside of my virtual machin
e.
This is happening in the IAMATH routine, subroutine IASQR. IAMATH is a
Large Integer Mathematics package from Central Missouri State University.
Unfortunately, many of the subroutine in IAMATH use WRKINTA, and most of
them use R9, with different symbolic names for R9 in each case. I don’t
see the value of using WRKINTA/WRKINTB everywhere. Why not give each
subroutine its own save area? It can only save a few bytes. And multiple
symbolic names for the same register is very confusing! I’m guessing t
hat
there is either a storage overlay, or a path through the code that
overlays one saved value of R9 with another one.
I have an educated guess as to what is causing this. The server I am usin
g
supports SSL 2.0 and SSL 3.0, but not TLS. I’ve never gotten IE or Fire
fox
to work without turning off TLS. The vendor says that IE must not be
negotiating correctly, but the problem may be in the web server. In any
case, the web browsers don’t crash! RXSSL should protect itself better,
even if the data it receives is incorrect.
I haven’t figure out a way to turn off TLS in RXSSL – that would prob
ably
be the next thing to try.
Alan Ackerman
Alan (dot) Ackerman (at) Bank of America (dot) com
