>> 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
>Just a thought -
>Could the area R15 points to have been allocated by one of those "we'll figure
>out your problem for you" >routines after the 0C4-11 and before the dump so
>that when you look in the dump they provide it looks like >you should have
>gotten an 0C1 rather than an 0C4-11?
>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
> These days the PER bit is *always* on, in any serious development/test
> environment, because of the ever-present ZAD SLIP in effect.
Good hint. I would hope we don't have this active in production (the problem
occurred in production). Will check on Monday.
--
Peter Hunkeler
>You provided analysis of some data. If you had provided the data that you used
>to arrive at the conclusions >that you did, that would have been helpful. It
>may have led to a request for more data, but at least we would >have had a
>place to start.
You're right. Would have been better to
>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
A S0C4-4 would occur only if there were a storage access violation. The
S0C4-11 implies that it is a page translation exception - i.e. that this
4K page has not been allocated within an already allocated segment (else
would have S0C4-10). A S0C1 would have occurred only if the S0C4-11 had
not
On 7/22/2016 8:14 AM, Peter Hunkeler wrote:
What are the full contents of the 128-bit PSW? What's the 64-bit TEA value?
I got a CEEDUMP and an analysis from StartTool DA.
Oh gawd. This is where I shrug my shoulders and wash my hands of it. I
like SVC dumps with all storage dumped and
>Just curious that the PER bit is on. Was someone running a SLIP of a
>PERish sort? Any chance of a dump or trace from that, or is the toy
>dump all you have to work with?
Made me wondering as well, but I have not checked the SLIPs yet. I doubt there
is a SLIP for this job, so the SLIP is set
>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
> I'm not asking for help to solve that actual problem that
> application has had and which caused the dump. I'm looking for help
> to undestand why we get the S0C4-11 when I had expected an S0C1. I
> trust once I understand this, I'll be able to continue debugging the
problem.
The most
>If you show the exact information from the dump, rather than your
>interpretation of that data, there is a better chance that someone will be
>able to see something that you didn't.
I'll happily show any data you ask me specifically. I would not know what to
post otherwise; It simply too
>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
On 7/22/2016 10:21 AM, Peter Hunkeler wrote:
The storage R7 point to, and the storage at offset x'90' is in SP251 key 8. It
is part of a load module. The fullword at R7+x'90' is the value seen in the
PSW, so both the L as well as the BASSM have been executed. The program fails
when the CP is
> >What are the full contents of the 128-bit PSW? What's the 64-bit TEA
value?
>
>
> I got a CEEDUMP and an analysis from StartTool DA. Both tell me the
> failing PSW is478D0400 A31A7BB8 Looking at the SVC dump at the PRB/
> XSB which is now producing the SVC dump (WLIC is 00020033), I see:
>
>What are the full contents of the 128-bit PSW? What's the 64-bit TEA value?
I got a CEEDUMP and an analysis from StartTool DA. Both tell me the failing PSW
is478D0400 A31A7BB8 Looking at the SVC dump at the PRB/XSB which is now
producing the SVC dump (WLIC is 00020033), I see:
XSB+00E0
What is the Translation Exception Address?
Bob
On 7/22/2016 10:21 AM, Peter Hunkeler wrote:
The storage R7 point to, and the storage at offset x'90' is in SP251 key 8. It
is part of a load module. The fullword at R7+x'90' is the value seen in the
PSW, so both the L as well as the BASSM have
The storage R7 point to, and the storage at offset x'90' is in SP251 key 8. It
is part of a load module. The fullword at R7+x'90' is the value seen in the
PSW, so both the L as well as the BASSM have been executed. The program fails
when the CP is accessing the instruction at the PSW's NSI.
20 matches
Mail list logo
