>> It will be cleared to X'00' by MVS.
>
>YMMV on that...
>
>"When you obtain storage, the system clears the requested storage to
>zeros if you obtain either:
>
>8192 bytes or more from a pageable, private storage subpool.
>4096 bytes or more from a pageable, private storage subpool,
>with
On 2016-07-23 02:38, Peter Hunkeler wrote:
It will be cleared to X'00' by MVS.
YMMV on that...
"When you obtain storage, the system clears the requested storage to
zeros if you obtain either:
8192 bytes or more from a pageable, private storage subpool.
4096 bytes or more from a
>So why was the page not allocated and what executable code
>should have been loaded into it - or is its address corrupted?
I don't have a clue yet, but as said in my previous post, I suspect some
storage overlay. Results are unpredictable.
>(The x'' seems to be left-over garbage.)
It
>Oh gawd. This is where I shrug my shoulders and wash my hands of it. I
>like SVC dumps with all storage dumped and nice long trace tables.
>Anything else is just frustration in a can!
I couldn't have said this better.
--
Peter Hunkeler
>You say it's in the load module. Did you violate reentrancy?
N, I never do :-)
But seriousy, the data being loaded into R15 comes from the load module's
storage and this is accessible. The code then seems to happily branch to the
address in R15 (the BASSM instruction), i.e. the content
>The most likely explanation is that the target address of the BASSM
>was not GETMAINed storage at the time of the abend (causing the
>0C4-11 abend), but was subsequently GETMAINed and used before the dump
>was initiated or as part of the dump processing.
Yes, I had thought about this possibilty
>How about the TRNE and BEA fields in that same XSB?
I seem to remember to have had a look a the BEA address and it matched with the
BASSM. Will double check. on Monday when back in the office. Will also have a
look at the TRNE then.
There is LE, Smart/Restart and StarTool DA which
