Mysterious Abend 0C1

[Robin Atwood]

Here is a puzzle. The program has taken an 0C1 half-way through an
instruction. It cannot have got there via the normal instruction sequence,
so it must have been branched to. However, none of the registers have a
value less than or equal to the PSW. This is compiled C code so no PC/PR
instructions are involved, AFAIK. How could the PSW get to be where it is?
Absolute address X'A9E' is all zeros so we didn't go there.





Using ASXB519 TCB: 007CC950 Abend Code: 0C1000 ILC: 00 Int: 04

PSW: 000180E100008000 Csect EP:



R0 R1 R2 R3 R4 R5 R6 R7

7FFFF000 00000000 00000000 00000000 00FD6D40 00000000 00000000 000A0000

R8 R9 R10 R11 R12 R13 R14 R15

000140E1 000A0000 000150E1 000A0000 000160E1 000A0000 000170E1 000A0000



00007FF6 00000016 92D5 7055 MVI 85(7),X'D5'

00007FFA 0000001A 91FF 7056 TM 86(7),X'FF'

00007FFE 0000001E 4770 5A9E BC 7,2718(0,5)

00008002 00000022 92D5 7056 MVI 86(7),X'D5'

00008006 00000026 41A0 61C8 LA 10,456(0,6)



Cheers

-Robin




----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN

[Elardus Engelbrecht]

Robin Atwood wrote:

>Here is a puzzle. The program has taken an 0C1 half-way through an instruction.

What z/OS and C compiler releases are you using? Did that program worked correctly in the past? With the same set of input? Did you recompiled it and it then gave that instruction exception? Can you retry the program with a known correct input?

Where and in what module is that abend happening? Do you see any other message(s) in SYSLOG for example?

>How could the PSW get to be where it is?

It could be the address is calculated during execution, perhaps on a set of input?

Or that instruction was overlaid somehow and you ended up in that address.

I would suggest that you put in instruction trace or put in diagnostic messages throughout the program so you can trace the execution flow.

Groete / Greetings
Elardus Engelbrecht

[Gerhard Postpischil]

On 5/22/2013 7:20 AM, Robin Atwood wrote:8

> R0 R1 R2 R3 R4 R5 R6 R7
>
> 7FFFF000 00000000 00000000 00000000 00FD6D40 00000000 00000000 000A0000

> 00007FF6 00000016 92D5 7055 MVI 85(7),X'D5'
>
> 00007FFA 0000001A 91FF 7056 TM 86(7),X'FF'
>
> 00007FFE 0000001E 4770 5A9E BC 7,2718(0,5)

GPR 5 is zero, so whatever is in A9E may have kicked you to 8000.



Gerhard Postpischil
Bradford, Vermont

[Robin Atwood]

No, I already mentioned that A9E is all zeros so we cannot have gone there.

Thanks
-Robin

[Robin Atwood]

The program is one of our products has been running at numerous installations for years. One client is really hammering the product and finding various exposure windows. This is the first occurrence of this error.

All the registers are much greater than the PSW and you cannot have negative displacements, so how did we get to that point in the code?

Thanks
-Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht
Sent: 22 May 2013 19:36
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mysterious Abend 0C1

[nitz...@gmx.net]

> > R0 R1 R2 R3 R4 R5 R6 R7
> >
> > 7FFFF000 00000000 00000000 00000000 00FD6D40 00000000 00000000 000A0000
>
> > 00007FF6 00000016 92D5 7055 MVI 85(7),X'D5'
> >
> > 00007FFA 0000001A 91FF 7056 TM 86(7),X'FF'
> >
> > 00007FFE 0000001E 4770 5A9E BC 7,2718(0,5)
>
> GPR 5 is zero, so whatever is in A9E may have kicked you to 8000.

And A9E is an address in PSA, so whatever is there *now* isn't necessarily what was there when the branch was taken.

Barbara Nitz

[Tom Marchant]

On Wed, 22 May 2013 19:20:29 +0800, Robin Atwood wrote:

>Here is a puzzle. The program has taken an 0C1 half-way through an
>instruction.

If the PSW that you listed is the correct PSW, the code you
have shown is not the correct code. You could not have
received an operation exception for trying to execute a X'5A'
opcode. In fact, unless you are on a _very_ old processor,
the only halfword that shows an invalid opcode is at 00008008.

>It cannot have got there via the normal instruction sequence,
>so it must have been branched to. However, none of the registers have a
>value less than or equal to the PSW.

You show registers 1, 2, 3, 5 and 6 as being zero. And have
you forgotten register 0? What about relative branches?

>This is compiled C code so no PC/PR

>instructions are involved, AFAIK. How could the PSW get to be where it is?
>Absolute address X'A9E' is all zeros so we didn't go there.

ITYM virtual address A9E, which would be the same as real
address A9E. Absolute address A9E is something altogether
different and is not relevant.

--
Tom Marchant

>
>
>
>
>Using ASXB519 TCB: 007CC950 Abend Code: 0C1000 ILC: 00 Int: 04
>
>PSW: 000180E100008000 Csect EP:
>
>
>

> R0 R1 R2 R3 R4 R5 R6 R7
>
>7FFFF000 00000000 00000000 00000000 00FD6D40 00000000 00000000 000A0000
>

> R8 R9 R10 R11 R12 R13 R14 R15
>

>000140E1 000A0000 000150E1 000A0000 000160E1 000A0000 000170E1 000A0000

>
>
>
>00007FF6 00000016 92D5 7055 MVI 85(7),X'D5'
>
>00007FFA 0000001A 91FF 7056 TM 86(7),X'FF'
>
>00007FFE 0000001E 4770 5A9E BC 7,2718(0,5)
>

>00008002 00000022 92D5 7056 MVI 86(7),X'D5'
>
>00008006 00000026 41A0 61C8 LA 10,456(0,6)

[Robin Atwood]

I have now discovered that the dump analyser picked up the wrong PSW and the
useful one is in a more reasonable place. So not so mysterious now!

Thanks for the replies.

-Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
Behalf Of nitz...@gmx.net
Sent: 22 May 2013 20:02
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mysterious Abend 0C1

[Tom Marchant]

On Wed, 22 May 2013 07:24:01 -0500, Tom Marchant <m42tom-...@YAHOO.COM> wrote:

>On Wed, 22 May 2013 19:20:29 +0800, Robin Atwood wrote:
>
>>Here is a puzzle. The program has taken an 0C1 half-way through an
>>instruction.
>
>If the PSW that you listed is the correct PSW, the code you
>have shown is not the correct code. You could not have
>received an operation exception for trying to execute a X'5A'
>opcode. In fact, unless you are on a _very_ old processor,
>the only halfword that shows an invalid opcode is at 00008008.
>
>>It cannot have got there via the normal instruction sequence,
>>so it must have been branched to. However, none of the registers have a
>>value less than or equal to the PSW.
>
>You show registers 1, 2, 3, 5 and 6 as being zero. And have
>you forgotten register 0? What about relative branches?

Please disregard most of the preceding paragraph. Register zero
and the registers containing zero are not important. Relative
branches could still have been used.

>
>>This is compiled C code so no PC/PR
>>instructions are involved, AFAIK. How could the PSW get to be where it is?
>>Absolute address X'A9E' is all zeros so we didn't go there.
>
>ITYM virtual address A9E, which would be the same as real
>address A9E. Absolute address A9E is something altogether
>different and is not relevant.
>
>--
>Tom Marchant
>
>>
>>
>>
>>
>>Using ASXB519 TCB: 007CC950 Abend Code: 0C1000 ILC: 00 Int: 04
>>
>>PSW: 000180E100008000 Csect EP:
>>
>>
>>

>> R0 R1 R2 R3 R4 R5 R6 R7
>>
>>7FFFF000 00000000 00000000 00000000 00FD6D40 00000000 00000000 000A0000
>>

>> R8 R9 R10 R11 R12 R13 R14 R15
>>

>>000140E1 000A0000 000150E1 000A0000 000160E1 000A0000 000170E1 000A0000

>>
>>
>>
>>00007FF6 00000016 92D5 7055 MVI 85(7),X'D5'
>>
>>00007FFA 0000001A 91FF 7056 TM 86(7),X'FF'
>>
>>00007FFE 0000001E 4770 5A9E BC 7,2718(0,5)
>>

>>00008002 00000022 92D5 7056 MVI 86(7),X'D5'
>>
>>00008006 00000026 41A0 61C8 LA 10,456(0,6)
>

[John McKown]

I didn't see mentioned, but if you ever think that the problem is due
to a "wild branch" of any sort, remember that the BEA Register
contains the address last successfully "branched from". It is in the
SYSUDUMP under the PRB of the program which was in execution. So I'd
look at the instruction at that address and see if it could cause
execution to proceed to where the S0C1 was reported. If so, you
probably have your culprit.

--
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

[Paul Gilmartin]

On Wed, 22 May 2013 06:35:59 -0500, Elardus Engelbrecht wrote:
>
>>How could the PSW get to be where it is?
>

>It could be the address is calculated during execution, perhaps on a set of input?
>
>Or that instruction was overlaid somehow and you ended up in that address.
>

BALR 15,15 ?

Or with long/negative displacements?

-- gil

[Robin Atwood]

John -
That's very interesting to know, thanks a lot. Is that a comparatively
recent register? It would have been useful in the past!

Cheers

-Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
Behalf Of John McKown
Sent: 22 May 2013 20:38
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mysterious Abend 0C1

[John McKown]

It's been on all the z machines. I don't remember which was the
earliest machine. But I'm sure somebody does and will tell us.

[Álvaro Guirao López]

22 de May, 14:29 - ‪+34 671 44 47 12‬: Hola quien eres
22 de May, 14:30 - ‪+34 671 44 47 12‬: Tiengo un msn
22 de May, 14:30 - Alvaro Guirao: Ni idea
22 de May, 14:30 - Alvaro Guirao: No te tengo en la agenda
22 de May, 14:31 - Alvaro Guirao: Q pone en el mensaje?
22 de May, 14:31 - ‪+34 671 44 47 12‬: Por donde vas
22 de May, 14:31 - Alvaro Guirao: Tolle?
22 de May, 14:31 - Alvaro Guirao: Su amigo?
22 de May, 14:32 - ‪+34 671 44 47 12‬: Pon Com vas
22 de May, 14:32 - ‪+34 671 44 47 12‬: El 4 de mayo
22 de May, 14:32 - Alvaro Guirao: Eres de Valdenoro?
22 de May, 14:32 - Alvaro Guirao: Amigo de Tolle?
22 de May, 14:32 - ‪+34 671 44 47 12‬: Si
22 de May, 14:32 - Alvaro Guirao: Vale
22 de May, 14:32 - Alvaro Guirao: Viniste a mi casa en las fiestas
22 de May, 14:33 - Alvaro Guirao: Como te llamas?
22 de May, 14:33 - ‪+34 671 44 47 12‬: Cuando q fiestas
22 de May, 14:34 - Alvaro Guirao: No te preocupes
22 de May, 14:34 - ‪+34 671 44 47 12‬: Las de valdemoro
22 de May, 14:34 - Alvaro Guirao: No soy nadie importante
22 de May, 14:34 - Alvaro Guirao: 
22 de May, 14:34 - Alvaro Guirao: Te dejo
22 de May, 14:34 - Alvaro Guirao: Ciao!
22 de May, 14:35 - ‪+34 671 44 47 12‬: A ken concies aki en valdemoro

[Álvaro Guirao López]

Sorry, i sent this message by error, ignore it please.

[Tom Marchant]

On Wed, 22 May 2013 20:57:03 +0800, Robin Atwood wrote:

>John -
>That's very interesting to know, thanks a lot. Is that a comparatively
>recent register? It would have been useful in the past!
>

z990, IIRC

--
Tom Marchant

>
>-----Original Message-----
>From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
>Behalf Of John McKown
>Sent: 22 May 2013 20:38
>

>I didn't see mentioned, but if you ever think that the problem is due to a
>"wild branch" of any sort, remember that the BEA Register contains the
>address last successfully "branched from".

[Mike W Stayton]

One thought: Look for the value in the SDWABEA field.
This is the "Breaking Event Address"
From the POPs:
Breaking-Event-Address Register
When the PER-3 facility is installed, each CPU has a 64-bit register called
the breaking-event-address register. Each time execution of an instruction
other than TRANSACTION ABORT replaces the instruction address in the PSW by
any means other than sequential instruction execution, the instruction
address used to fetch that instruction is placed in the
breaking-event-address register.

This is the last address that caused a branch that caused the 0C1.

Mike Stayton
z/OS Communications Server
m...@us.ibm.com

[Blaicher, Christopher Y.]

If you think you took a wild branch, find the RTM2WA and then towards the end of it find a field marked BEA, this is the address of the last branch instruction.

Chris Blaicher
Principal Software Engineer, Software Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260 | M: 512-627-3803
E: cbla...@syncsort.com

ATTENTION: -----

The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.

[Ed Jaffe]

On 5/22/2013 4:20 AM, Robin Atwood wrote:
> Here is a puzzle. The program has taken an 0C1 half-way through an
> instruction. It cannot have got there via the normal instruction sequence,
> so it must have been branched to. However, none of the registers have a
> value less than or equal to the PSW. This is compiled C code so no PC/PR
> instructions are involved, AFAIK. How could the PSW get to be where it is?
> Absolute address X'A9E' is all zeros so we didn't go there.

Do your dumps format the BEA? That will tell you how you got there.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

[Gerhard Adam]

This entire problem is suspect since the PSW itself isn't valid. There is
no situation of where bits 24-31 can contain an x'E1'

Adam

>Using ASXB519 TCB: 007CC950 Abend Code: 0C1000 ILC: 00 Int: 04

>PSW: 00 01 80 E1 00 00 80 00 Csect EP:

[Gerhard Adam]

Looking at it more closely, something is seriously wrong here. The ILC
shows zero. The PSW indicates that DAT is off, Supervisor state, Key 0 and
disabled for I/O, External, and Machine check interrupts.

Toto, I don't think we're in Kansas anymore.

Using ASXB519 TCB: 007CC950 Abend Code: 0C1000 ILC: 00 Int: 04

PSW: 000180E100008000 Csect EP:

[Elardus Engelbrecht]

Gerhard Adam wrote:

>This entire problem is suspect since the PSW itself isn't valid. There is no situation of where bits 24-31 can contain an x'E1'

Good catch. Even after reading my Principle of Operations, it is still a good catch :-)

Of course, the OP discovered later that 'dump analyser picked up the wrong PSW '.

I wish the OP published the CORRECT dump results including the PSW and the registers.

Groete / Greetings
Elardus Engelbrecht

[Ed Jaffe]

On 5/22/2013 8:34 AM, Elardus Engelbrecht wrote:
> Of course, the OP discovered later that 'dump analyser picked up the wrong PSW '.

This is why I stopped using all dump analyzers (other than my own brain)
over two decades ago!

I'd much rather find the PSW and registers myself--starting with
SYSTRACE and working from there.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

[Tony Harminc]

On 22 May 2013 12:39, Ed Jaffe <edj...@phoenixsoftware.com> wrote:
> On 5/22/2013 8:34 AM, Elardus Engelbrecht wrote:
>>
>> Of course, the OP discovered later that 'dump analyser picked up the wrong PSW '.
>
>
> This is why I stopped using all dump analyzers (other than my own brain)
> over two decades ago!

It's not obvious that "dump analyser" meant a program as opposed to a person.

> I'd much rather find the PSW and registers myself--starting with SYSTRACE
> and working from there.

But then you're trusting IPCS (presumably) to format the trace entries
correctly. Something it has been known to silently get wrong, if there
is a version mismatch between IPCS and dump.

Tony H.

[Farley, Peter x23353]

Unfortunately not every shop makes IPCS available to application programmers. Some of us are stuck with just two choices - commercial abend analyzer selected by bean counters or read the SYSUDUMP yourself.

Some skills from the days of paper mounds are still important.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Tony Harminc
Sent: Wednesday, May 22, 2013 12:50 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mysterious Abend 0C1

On 22 May 2013 12:39, Ed Jaffe <edj...@phoenixsoftware.com> wrote:
> On 5/22/2013 8:34 AM, Elardus Engelbrecht wrote:
>>
>> Of course, the OP discovered later that 'dump analyser picked up the wrong PSW '.
>
> This is why I stopped using all dump analyzers (other than my own brain)
> over two decades ago!

It's not obvious that "dump analyser" meant a program as opposed to a person.

> I'd much rather find the PSW and registers myself--starting with SYSTRACE
> and working from there.

But then you're trusting IPCS (presumably) to format the trace entries
correctly. Something it has been known to silently get wrong, if there
is a version mismatch between IPCS and dump.

Tony H.
--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Gerhard Adam]

>>Unfortunately not every shop makes IPCS available to application
programmers. Some of us are stuck with just two choices - commercial abend
analyzer selected by >>bean counters or read the SYSUDUMP yourself.

>>Some skills from the days of paper mounds are still important.

Since the OP included register values and assembler code, it seems like a
serious disconnect to suggest that they don't know how to read a SYSUDUMP.

[Farley, Peter x23353]

I wasn't suggesting any such thing. Just responding to Ed J.'s and Tony H.'s comments about using IPCS. Many here seem to assume everyone in a z/OS shop has access to that tool. I was just pointing out that is not always true.

The OP certainly seems to have the necessary skills.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam
Sent: Wednesday, May 22, 2013 1:22 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mysterious Abend 0C1

>>Unfortunately not every shop makes IPCS available to application
programmers. Some of us are stuck with just two choices - commercial abend
analyzer selected by >>bean counters or read the SYSUDUMP yourself.

>>Some skills from the days of paper mounds are still important.

Since the OP included register values and assembler code, it seems like a
serious disconnect to suggest that they don't know how to read a SYSUDUMP.

--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Ed Jaffe]

On 5/22/2013 10:10 AM, Farley, Peter x23353 wrote:
> Unfortunately not every shop makes IPCS available to application programmers. Some of us are stuck with just two choices - commercial abend analyzer selected by bean counters or read the SYSUDUMP yourself.

What about SYSABEND? ISTR that has SYSTRACE, RTM2WA, TCB, RB chains, etc.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

[Farley, Peter x23353]

True, and sometimes necessary, and a lot of the same dump-reading skills apply along with more-than-average knowledge of system architecture and control block structures. And they are a LOT bigger and thus take a wee bit longer to search.

The information is available, just not as conveniently as when one has IPCS available.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe
Sent: Wednesday, May 22, 2013 1:44 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mysterious Abend 0C1

On 5/22/2013 10:10 AM, Farley, Peter x23353 wrote:
> Unfortunately not every shop makes IPCS available to application programmers. Some of us are stuck with just two choices - commercial abend analyzer selected by bean counters or read the SYSUDUMP yourself.

What about SYSABEND? ISTR that has SYSTRACE, RTM2WA, TCB, RB chains, etc.
--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

[Shmuel Metz , Seymour J.]

In <003601ce56eb$dcde9100$969bb300$@com>, on 05/22/2013

at 08:57 PM, Robin Atwood <aben...@GMAIL.COM> said:

>That's very interesting to know, thanks a lot. Is that a
>comparatively recent register?

The PER-3 facility, including the Breaking-Event-Address Register, was
documented in the fifth edition of z/Architecture Principles of
Operation, SA22-7832; I don't recall which processors introduced it.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

[Ed Jaffe]

On 5/22/2013 11:44 AM, Shmuel Metz (Seymour J.) wrote:
> The PER-3 facility, including the Breaking-Event-Address Register, was
> documented in the fifth edition of z/Architecture Principles of
> Operation, SA22-7832; I don't recall which processors introduced it.

The BEAR was introduced with the z9-109 (later renamed z9EC) processor.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

[nitz...@gmx.net]

> But then you're trusting IPCS (presumably) to format the trace entries
> correctly. Something it has been known to silently get wrong, if there
> is a version mismatch between IPCS and dump.

Which you're informed about in bold at the initialization of the dump for the past 10 years.

Barbara

[Robin Atwood]

OK, this is what happened. The "dump analyser" is a trusty clist written for IPCS by me over 20 years ago. It (almost always) works by using the chain: ASXB -> abending TCB -> RTWA, from where it gets the PSW and registers. In this case it got caught out because there was a preceding TCB with a completion code of 0C1 but only a PRB, no RTWA and hence the mayhem.

So, sorry for the noise but this exchange has proved very useful because I now know about the BEAR. Unfortunately it is not listed by either the IPCS STATUS or SUMMARY commands, which would have been very useful since there is a chain of control blocks to follow (SDWAXPAD->SDWAPTRS, SDWAXEME->SDWARC4).

Cheers
-Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht
Sent: 22 May 2013 23:34
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mysterious Abend 0C1

[Elardus Engelbrecht]

Robin Atwood wrote:

>OK, this is what happened. The "dump analyser" is a trusty clist written for IPCS by me over 20 years ago. It (almost always) works by using the chain: ASXB -> abending TCB -> RTWA, from where it gets the PSW and registers. In this case it got caught out because there was a preceding TCB with a completion code of 0C1 but only a PRB, no RTWA and hence the mayhem.

Thanks for clarifying. Could you select / re-select the Address space (other TCB?) to be used in your dump analysis?

>So, sorry for the noise but this exchange has proved very useful because I now know about the BEAR. Unfortunately it is not listed by either the IPCS STATUS or SUMMARY commands, which would have been very useful since there is a chain of control blocks to follow (SDWAXPAD->SDWAPTRS, SDWAXEME->SDWARC4).

SDWARC4. Hmmm, I now rememeber. EREP does show the Breaking-Event-Address Register.

Could you get any info from Logrec?

[Robin Atwood]

>Thanks for clarifying. Could you select / re-select the Address space (other TCB?) to be used in >your dump analysis?

Yes, I set a symbol to the desired TCB address and then the analysis proceeds correctly.

> Could you get any info from Logrec?

It's a client's system, so I look at what I am given. Anyway, I found the bad branch from the BEAR, a routine address in an internal control block had been stomped on. By what and when remains a mystery.

-Robin
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht
Sent: 23 May 2013 14:29
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mysterious Abend 0C1

[Miklos Szigetvari]

On 23.05.2013 09:44, Robin Atwood wrote:
>> Thanks for clarifying. Could you select / re-select the Address space (other TCB?) to be used in >your dump analysis?
> Yes, I set a symbol to the desired TCB address and then the analysis proceeds correctly.
>
>> Could you get any info from Logrec?
> It's a client's system, so I look at what I am given. Anyway, I found the bad branch from the BEAR, a routine address in an internal control block had been stomped on. By what and when remains a mystery.

In this case maybe the SLIP SA trap would help

>
> -Robin
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht
> Sent: 23 May 2013 14:29
> To: IBM-...@LISTSERV.UA.EDU
> Subject: Re: Mysterious Abend 0C1
>
> Robin Atwood wrote:
>
>> OK, this is what happened. The "dump analyser" is a trusty clist written for IPCS by me over 20 years ago. It (almost always) works by using the chain: ASXB -> abending TCB -> RTWA, from where it gets the PSW and registers. In this case it got caught out because there was a preceding TCB with a completion code of 0C1 but only a PRB, no RTWA and hence the mayhem.
> Thanks for clarifying. Could you select / re-select the Address space (other TCB?) to be used in your dump analysis?
>
>> So, sorry for the noise but this exchange has proved very useful because I now know about the BEAR. Unfortunately it is not listed by either the IPCS STATUS or SUMMARY commands, which would have been very useful since there is a chain of control blocks to follow (SDWAXPAD->SDWAPTRS, SDWAXEME->SDWARC4).
> SDWARC4. Hmmm, I now rememeber. EREP does show the Breaking-Event-Address Register.
>
> Could you get any info from Logrec?
>
> Groete / Greetings
> Elardus Engelbrecht
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>

--
Kind regards, / Mit freundlichen Grüßen
Miklos Szigetvari

Research& Development
ISIS Papyrus Europe AG
Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria
T: +43(2236) 27551 333, F: +43(2236)21081
E-mail: miklos.s...@isis-papyrus.com
Info: in...@isis-papyrus.com Hotline: +43-2236-27551-111
Visit our brand new extended Website at www.isis-papyrus.com
---------------------------------------------------------------
This e-mail is only intended for the recipient and not legally
binding. Unauthorised use, publication, reproduction or
disclosure of the content of this e-mail is not permitted.
This email has been checked for known viruses, but ISIS Papyrus accepts
no responsibility for malicious or inappropriate content.
---------------------------------------------------------------

[Peter Relson]

It took quite a while but I was glad to see someone finally noticed that
the "PSW" is not a "PSW", and that the OP noticed this too.

My first thought was that it was perhaps displaying just the 8-byte PSW
address (not the whole PSW) and that the program had landed above the bar
in AMODE 64 (in which case it wouldn't be too surprising to get an 0C1 if
you didn't get some sort of page/segment/region fault). And of course
seeing the 64-bit GRs would have been interesting in that case, not just
the 32-bit GRs.

I also noticed that GRs 7-15 as shown appear to have been loaded from
various low storage locations which is rather bizarre.

Peter Relson
z/OS Core Technology Design

[Peter Relson]

FWIW,

The BEA can be found in such fields as
SDWABEA
RTM2BEA
LCCABEA2

So to the extent that the SDWA, RTM2WA, and LCCA are formatted in whatever
IPCS report you are using, the BEA value will be presented.

[Robin Atwood]

Peter -
Thanks for the info. The BEA can be easily retrieved from RTWA+6D0. I also
found a presentation that claimed the BEA was saved in low memory at 110.
but a few dumps I looked at did not bear this out (pun intended!).

Cheers

-Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-...@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: 24 May 2013 20:01
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: Mysterious Abend 0C1

[Ed Jaffe]

On 5/27/2013 12:25 AM, Robin Atwood wrote:
> Peter -
> Thanks for the info. The BEA can be easily retrieved from RTWA+6D0. I also
> found a presentation that claimed the BEA was saved in low memory at 110.
> but a few dumps I looked at did not bear this out (pun intended!).

The BEA is indeed stored in the PSA and that's where RTM gets it from.
But, it is a "fleeting" value.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

[Shmuel Metz , Seymour J.]

In <005001ce5aab$5c511c10$14f35430$@com>, on 05/27/2013

at 02:25 PM, Robin Atwood <aben...@GMAIL.COM> said:

>Thanks for the info. The BEA can be easily retrieved from RTWA+6D0. I
>also found a presentation that claimed the BEA was saved in low
>memory at 110. but a few dumps I looked at did not bear this out (pun
>intended!).

From z/Architecture Principles of Operation, SA22-7832-09

272-279 (110-117 hex). . . . . . . . . . . . . Real Address

Breaking-Event Address: If the PER-3 facility is
installed, then, during a program interruption, the
contents of the breaking-event-address register
are stored in locations 272-279. If the breaking-
event-address-recording facility is not installed,
this location remains unchanged.

Note that the dump almost certainly contains data from the wrong PSA,
and that there may have been program interruptions from other tasks,
so even if you're looking at the correct PSA you should rely on the
data there but should instead look at one of the fields to which z/OS
has copied the saved BEAR.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2 <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

[Tom Marchant]

On Mon, 27 May 2013 14:25:21 +0700, Robin Atwood wrote:

>I also
>found a presentation that claimed the BEA was saved in low memory at 110.
>but a few dumps I looked at did not bear this out (pun intended!).

You should read the POO.

"When the PER-3 facility is installed

and a program interruption occurs, whether or not
PER is indicated, the contents of the breaking-eventaddress
register are stored in real storage locations
272-279."

That's every time a program interruption occurs. Including a page fault.
And don't forget it's a 64-bit register that is stored in a doubleword.

--
Tom Marchant