When looking some time longer at this, all seems ok;
the 2nd DSA contains the informations that result from the exception,
and the exception is because the BASSM jumps to a place where
the machine instructions have been overwritten by zeroes (wild guess).
You told us that the instruction address where the BASSM goes is correct.
That should give 0C1, not 0C4;
could it be that the 0C1 is covered by a 0C4 which happens while
LE tries to do its dump processing?
What happens, if you switch off LE dump processing by LE option TRAP(OFF)?
(used to be called NOSPIE,NOSTAE some ten years ago).
Kind regards
Bernd
Bernd Oppolzer schrieb:
IMO, the DSA address of the 2nd Save Area is not resonable:
DSA DSA Addr E Addr PU Addr PU Offset Comp Date Compile
Attributes
1 23117AE0 08DA2B60 08DA2B60 +00004A4C 20150130 CEL
2 00010000 24D90B66 24D90B66 -01BE8FAE ********
3 231176E8 24D85D48 24D85D48 +00004396 20130225 COBOL
4 231174F0 20EDB610 20EDB610 +000002FC 20140722 LIBRARY
5 23117078 235F6400 235F6400 +00009C92 20160624 COBOL
...
14 23115258 20EDB610 20EDB610 +000002FC 20140722 LIBRARY
15 23115030 23100428 23100428 +00000A10 20100129 COBOL
I would take a closer look at the call position
of the COBOL module at level 3, at position 4396.
The name is HRDRFREA.
What is called there, and why does the called module build a save
area at such a strange place 00010000? The informations contained
there seem wrong, too. That is the save area and register information
printed;
maybe this is all misleading ...
Kind regards
Bernd
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
