What's wrong with me?

15 views
Skip to first unread message

Mario Bezzi

unread,
May 29, 2021, 2:46:12 AM5/29/21
to ASSEMBL...@listserv.uga.edu
Hello,

I have a Language Environment enabled program which seldomly fails with
a program check.
The Machine State section of the LE DUMP shows PSW and REGS at time of
error.

 Machine State
 MCH_EYE:ZMCH

 GPR00:00000007    GPR01:0003A970
 GPR02:2F63612C    GPR03:00094D62
 GPR04:2F62A248    GPR05:2F636110
 GPR06:800912A0    GPR07:2F1B833C
 GPR08:2F31ADB8    GPR09:80000000
 GPR10:0C8C36FF    GPR11:8C8C2700
 GPR12:00034B20    GPR13:0003A8C0
 GPR14:80094C8A    GPR15:010DB148

 PSW:078D1400 80094C8A

 ILC:0002    IC1:00      IC2:82      PFT:00000000

If I am not wrong, the failing Instruction Length (ILC) is 2 and the
interruption code (IC2) is 82.
This means to me PER + Privileged Operation Exception. For this kind of
interrupt execution is
suppressed, and the PSW points to the instructions following the failing
one.

 00094C7C ! 58FF 0120      ! L       R15,X'120'(R15)
 00094C80 ! 58FF 007C      ! L       R15,X'7C'(R15)
 00094C84 ! 4100 0007      ! LA      R0,X'7'
 00094C88 ! 05EF           ! BALR    R14,R15
 00094C8A ! 5810 1000      ! L       R1,X'0'(,R1)
 00094C8E ! D20F 2000 10AA ! MVC     X'0'(X'10',R2),X'AA'(R1)

What puzzles me is that the PSW doesn't not show PER being active, and
the exception seems to be
caused by a fully valid BALR instruction. The target of BALR is:

 010DB148 ! A7F4 000E      ! BRC     X'F',*+X'1C'

Anyone see where is the issue?

This is from a production system, where this is all I can get in terms
of documentation.

Thank you in advance,
mario

Jonathan Scott

unread,
May 29, 2021, 5:06:34 AM5/29/21
to ASSEMBL...@listserv.uga.edu
Ref: Your note of Sat, 29 May 2021 08:45:20 +0200

The PSW and registers being shown by LE are presumably those at
the linkage stack level for the calling program.

The routine IXGL1RTE being called via the IXGCONN macro uses BSM
14,0 then BAKR 14,0 to save the PSW and registers in the linkage
stack, so the PSW will point after the BALR.

So presumably the real error occurs within the IXGCONN macro
processing.

Jonathan Scott, HLASM
IBM Hursley, UK

Mario Bezzi

unread,
May 29, 2021, 10:43:01 AM5/29/21
to ASSEMBL...@listserv.uga.edu
Jonathan, thank you for bringing into play the linkage stack, good
point, and congratulations for recognizing IXGCONN from just few
instructions. amazing!

I will follow the execution within IXGL1RTE and see if I can make sense
of this.

Still I don't understand the PER interrupt code while it seems to me
that the PSW has the PER mask set to zero.

Thank you!
mario

Jonathan Scott

unread,
May 29, 2021, 11:08:50 AM5/29/21
to ASSEMBL...@listserv.uga.edu
Ref: Your note of Sat, 29 May 2021 16:42:56 +0200

> Still I don't understand the PER interrupt code while it seems to me
> that the PSW has the PER mask set to zero.

There's nothing in the interrupt information to suggest that it
has to relate to the actual error. The information presumably
relates to the point at which the current RB execution level was
last suspended.

So the interrupt code could for example be for an SVC, and hex
0082 is SVC 130, RACHECK, which seems quite plausible to me.

What even tells you that the real problem is a program check?

Is there anything more in the system log at that point, such as
a RACF error message?

Seymour J Metz

unread,
May 29, 2021, 9:14:29 PM5/29/21
to ASSEMBL...@listserv.uga.edu
> The routine IXGL1RTE being called via the IXGCONN macro uses
> BSM14,0 then BAKR 14,0

Wouldn't that put the wrong R14 value in the stack? The R14 in the dump points just after the BALR, which is what I would expect if there is no BSM R14,0 before the BAKR R14,0.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Jonathan Scott [jonatha...@VNET.IBM.COM]
Sent: Saturday, May 29, 2021 4:46 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: What's wrong with me?

Seymour J Metz

unread,
May 29, 2021, 9:19:12 PM5/29/21
to ASSEMBL...@listserv.uga.edu
For an SVC, the PSW would point just after the SVC, not just after the BALR. It seems more likely that the PSW shown comes from the stack.

BTW, my standard debugging paradigm includes looking at the RB chain so I don't have to guess which PSW is display in the summary. Of course, in this case the linkage stack is also relevant.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Jonathan Scott [jonatha...@VNET.IBM.COM]
Sent: Saturday, May 29, 2021 10:58 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: What's wrong with me?

Jonathan Scott

unread,
May 30, 2021, 4:31:21 AM5/30/21
to ASSEMBL...@listserv.uga.edu
Ref: Your note of 30 May 2021, 01:13:52 UTC

BSM 14,0 only sets the AMODE bit in R14.

Shmuel (Seymour J.) Metz writes:
> > The routine IXGL1RTE being called via the IXGCONN macro uses
> > BSM14,0 then BAKR 14,0
>
> Wouldn't that put the wrong R14 value in the stack? The R14
> in the dump points just after the BALR, which is what I would
> expect if there is no BSM R14,0 before the BAKR R14,0.

Jonathan Scott

unread,
May 30, 2021, 4:40:03 AM5/30/21
to ASSEMBL...@listserv.uga.edu
Ref: Your note of 30 May 2021, 01:19:09 +0000

I don't know the specifics of the routine which is showing the
error information in this case, but as I already said, the PSW
and registers appear to be for the caller's linkage stack level.
The interrupt code is however related to the current RB level,
so in this case it does not relate to the PSW and registers.

Shmuel (Seymour J.) Metz writes:
> For an SVC, the PSW would point just after the SVC, not just
> after the BALR. It seems more likely that the PSW shown comes
> from the stack.

Peter Relson

unread,
May 30, 2021, 9:37:04 AM5/30/21
to ASSEMBL...@listserv.uga.edu
Are you able to get a dump that would have the SDWA in it (or record the
error in logrec so you can view it)?

RTM presents two sets of registers. One is from "time of error". One is
from the RB / linkage stack.
I have no idea what an "LE Dump" provides.

But I'd be skeptical that anything provides the RB / linkage stack regs as
the only set of regs, as that is close to useless for debugging.

And of course the SDWA has information about the type of event.

Peter Relson
z/OS Core Technology Design

Seymour J Metz

unread,
May 30, 2021, 11:34:12 AM5/30/21
to ASSEMBL...@listserv.uga.edu
Yes, and the register contents shown are what I would expect if the routine did not mess with R14 before issuing the BAKR.

As you noted, the OP did not provide the RB chain, so we' all going by guesswork :-(


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Jonathan Scott [jonatha...@VNET.IBM.COM]
Sent: Sunday, May 30, 2021 4:31 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: What's wrong with me?

Seymour J Metz

unread,
May 30, 2021, 11:35:44 AM5/30/21
to ASSEMBL...@listserv.uga.edu
Whoops! Thanks. They say that the memory is the second thing to go.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBL...@LISTSERV.UGA.EDU] on behalf of Jonathan Scott [jonatha...@VNET.IBM.COM]
Sent: Sunday, May 30, 2021 4:28 AM
To: ASSEMBL...@LISTSERV.UGA.EDU
Subject: Re: What's wrong with me?

Mario Bezzi

unread,
May 30, 2021, 1:24:55 PM5/30/21
to ASSEMBL...@listserv.uga.edu
Thank you all for your kind help.

I will try to get an svc dump and see what the SDWA says.

I'll keep you posted.
mario
Reply all
Reply to author
Forward
0 new messages