>When a WTO message ID matches a SLIP MSGID, we issue a 06F-8 abend
>to get into an RTM1 environment (for branch entry WTO) or RTM2
>environment (for SVC entry WTO). This allowed us to avoid the
>development cost of creating a new SLIP environment. We retry
>from the 06F-8 abend without recording
> >SLIP gets control in 4 environments:
> >-- PER
> >-- RTM1 (think "FRR")
> >-- RTM2 (think "ESTAE")
> >-- MEMTERM
>
> How about SLIPs with keyword MSGID=. We've been asked by IBM support
> in response to a PMR to set a such SLIP to get a dump when a
> specific message was issues. This is h
--
Peter Hunkeler
>SLIP gets control in 4 environments:
>-- PER
>-- RTM1 (think "FRR")
>-- RTM2 (think "ESTAE")
>-- MEMTERM
How about SLIPs with keyword MSGID=. We've been asked by IBM support in
response to a PMR to set a such SLIP to get a dump when a specific message was
issues. This is ho
SLIP command description has the following note for the COMP= operand:
Note: 1. The SLIP action is not taken when the abend completion code is
originally a program check (code 0C4) that the system converts to a new
value. The following abend completion codes may be originally a program
check an
>If you can provide the PTF level of nucleus module IEAVESPI, we
could set a SLIP SET,IF,N=IEAVESPI,xxx,xxx) in it at some offset
where it has decided that it will be invoking an ESPIE exit.
I may consider this and will come back to you in that case. Thanks.
>SLIP gets called from RTM.
Of co
> Ohhh my. I just asked engineering to set a SLIP as you suggested,
> Jim, hoping it will match. The above is bad news. I will have them
> to run the job with LE TRAP(OFF), but I suspect this will not help.
> I mentioned there it SmartRestart that our appications depend on.
> SmartRestart surel
On Fri, 29 Jul 2016 19:23:34 +0200, Peter Hunkeler wrote:
>What is the reasoning behind excluding SLIP from matching when ESPIE is active?
Perhaps this will help a little, based upon my understanding. If I've got this
wrong,
I hope Jim or someone else more knowledgeable than I am will correct m
>You are right, I have to eat those words. ESPIE processing
translates unresolved program interrupt codes x'10', x'11',
x'38', x'39', x'3A', and x'3B' into program interrupt code 4,
so an ESPIE established for interrupt code 4 will also get control
for any of those access exceptions when they canno
>Make sure that you have your systrace set at maximum, then (not the default
>64K, and even 1MB will not be enough, especially on a busy system).
I had a look at the size recently but can't remember what it was right now. But
I remember It to be of decent size.
>Did you get the same set of i
> > ESPIE for unauthorized programs (like LE) supports interrupt codes
> > 1-15 (decimal), which does not include 17 (x'11') page fault. So
> > SLIP SET,A=SVCD,C=0C4,RE=11,ML=1,MODE=PP,J=jobname,END
> > should be able take a dump of this problem without interference from
> > LE's ESPIE.
> Admi
> All I'm looking for is a system trace. Hoping to find hints what do look for
> next.
Make sure that you have your systrace set at maximum, then (not the default
64K, and even 1MB will not be enough, especially on a busy system). LE
processing takes up a whole lot of real estate in systrace fro
> > >I don't know how LE plays that game. A SLIP of the 0C4 would have
> true contents.
> > System Trace would also help with this information but it is not
> in the dump produced by the "little"helpers". Setting a SLIP in
> production is a not so short adventure trip; and SLIPping for a 0C4
>
On Wed, 27 Jul 2016 06:29:48 -0700, Lizette Koehler wrote:
>Since z/OS V1.13, you can add CEEOPTS as a JCL Statement
>
>https://www.ibm.com/support/knowledgecenter/SSLTBW_1.13.0/com.ibm.zos.r13.ceea500/ceedd.htm
>
Is this a new reserved DD Name?
Actually, that 1.13 documentation is better than t
>Since z/OS V1.13, you can add CEEOPTS as a JCL Statement
Yes, I know. It is not that I would not know *what* to do if I was allowed to
do it.
--
Peter Hunkeler
--
For IBM-MAIN subscribe / signoff / archive access instru
//CEEOPTS DD DUMMY
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of nitz-ibm
> Sent: Wednesday, July 27, 2016 12:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: AW: Re: Follow-on: S0C4-11 abend
>Just my 2 cents: As long as TRAP(ON,SPIE) is set (and you said you cannot turn
>it off for various reasons) slip will not get control because (E)SPIE gets
>control before slip. So your slip trap probably won't match at all.
In another case where the application failed with an S30A-10 sporadica
> >I don't know how LE plays that game. A SLIP of the 0C4 would have true
> >contents.
> System Trace would also help with this information but it is not in the dump
> produced by the "little"helpers". Setting a SLIP in production is a not so
> short adventure trip; and SLIPping for a 0C4 is no
>> Thanks. What I do not yet understand: The TRNE address is 231A7800,
>> where as the address in R15 231A7BB8. Why the difference?
>
>TRNE is a copy of Translation-Exception Identification, which is
>defined in Principles Of Operation.
I usually do read the manuals before posting, and I di
On 7/26/2016 4:21 PM, Peter Hunkeler wrote:
In (late) response to Jim Mulder's comment:
How about the TRNE and BEA fields in that same XSB?
>
XSBBEA and XSBTRNE confirm what I said before. The BASSM was
executed. The target address in R15 was in a page of storage
that was not GETMAINed at
> Thanks. What I do not yet understand: The TRNE address is 231A7800,
> where as the address in R15 231A7BB8. Why the difference?
TRNE is a copy of Translation-Exception Identification, which is
defined in
Principles Of Operation.
Jim Mulder z/OS Diagnosis, Design, Development, Test, etc.
>> In (late) response to Jim Mulder's comment:
>>>How about the TRNE and BEA fields in that same XSB?
>
>XSBBEA and XSBTRNE confirm what I said before. The BASSM was
>executed. The target address in R15 was in a page of storage
>that was not GETMAINed at that time, resulting in a 0C4-11 abend.
>
> In (late) response to Jim Mulder's comment:
> >How about the TRNE and BEA fields in that same XSB?
XSBBEA and XSBTRNE confirm what I said before. The BASSM was
executed. The target address in R15 was in a page of storage
that was not GETMAINed at that time, resulting in a 0C4-11 abend.
Sinc
>You told us that the instruction address where the BASSM goes is correct.
No, I told that the address fetched into R15 matches where the BASSM jumped to
and matches what is seem in the PSW.
>What happens, if you switch off LE dump processing by LE option TRAP(OFF)?
I don't dare to ask f
>[snip] I would take a closer look at the call position of the COBOL module at
>level 3, at position 4396.
>The name is HRDRFREA. >>maybe this is all misleading ...
I agree with your findings. Module HRDRFREA is calling DSNHLI at this offset.
So far nothing special. However, the job runs under
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 w
IMO, the DSA address of the 2nd Save Area is not resonable:
DSA DSA Addr E AddrPU AddrPU Offset Comp Date Compile
Attributes
1 23117AE0 08DA2B60 08DA2B60 +4A4C 20150130 CEL
2 0001 24D90B66 24D90B66 -01BE8FAE
3 231176E8 24D85
List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Binyamin Dissen
Sent: Tuesday, July 26, 2016 5:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Follow-on: S0C4-11 abend caused by BASSM to address
with all X'00' bytes
On Tue, 26 Jul 2016 14:29:06 +0200 Peter Hunkeler wrote:
On 7/26/2016 7:20 AM, Peter Hunkeler wrote:
Thanks, Ed, I wasn't aware of the *trailing* whilte space behaviour. However, I
think apart from that Listserv removes all leading space (and multiple spaces?)
and thus also makes reading the dump output difficult.
It does nothing of the kind! I and
>:>That would lead to a S0C4-4 not S0C4-11, wouldn't it?
>
>Program Unit: Entry: Statement: Offset: -01BE8FAE
>Machine State:
>ILC. 0002Interruption Code. 0004
Thanks. I was mislead by the fact the the failure was reported as S0C4 reason
11 in the joblog. Also LE as well as IPCS
Thanks, Ed, I wasn't aware of the *trailing* whilte space behaviour. However, I
think apart from that Listserv removes all leading space (and multiple spaces?)
and thus also makes reading the dump output difficult.
--Peter Hunkeler
---
On 7/26/2016 4:08 AM, Peter Hunkeler wrote:
PS: If the data below is too much unreadable after going through the
ListServ, I'd be happy to send it as attachement to anyone interested.
*** CEEDUMP data folows:
CEE3DMP V2 R1.0: Condition processing resulted in the unhandled condition.
07
On Tue, 26 Jul 2016 14:29:06 +0200 Peter Hunkeler wrote:
:>
:>>It seems that you branched to a location that is fetch protected and not in
:>>key 8.
:>That would lead to a S0C4-4 not S0C4-11, wouldn't it?
Program Unit: Entry: Statement: Offset: -01BE8FAE
Machine State:
>It seems that you branched to a location that is fetch protected and not in
>key 8.
That would lead to a S0C4-4 not S0C4-11, wouldn't it?
>What do you expect to find at 231A7BB8? My guess is that the LE formatter is
>showing all zeroes since it cannot access it.
The storage is available,
Peter Hunkeler wrote:
>As expected, having the dump information inline did not work out. I'm
>reposting with an attachement. Hopefully this will work better.
I could see both attachments from IBM-MAIN web site. Thanks, it is working well
including formatting too inside those attachments.
Your
It seems that you branched to a location that is fetch protected and not in
key 8.
What do you expect to find at 231A7BB8? My guess is that the LE formatter is
showing all zeroes since it cannot access it.
On Tue, 26 Jul 2016 13:22:54 +0200 Peter Hunkeler wrote:
:>
:>
:>As expected, having the
As expected, having the dump information inline did not work out. I'm reposting
with an attachement. Hopefully this will work better.
In (late) response to Jim Mulder's comment:
>How about the TRNE and BEA fields in that same XSB?
and Tom Marchant's comment:
>If you show the exact inform
Oopps, I was afraid of that. Does IBM-MAIN allow attachements? Can't remember,
but will try.
--
Peter Hunkeler
*** CEEDUMP data folows:
CEE3DMP V2 R1.0: Condition processing resulted in the unhandled condition.
07/15/16 12:12:28 AMASID: 0159 Job ID: J0274722 Job name: P07W04UA
Warning, long post.
In (late) response to Jim Mulder's comment:
>How about the TRNE and BEA fields in that same XSB?
and Tom Marchant's comment:
>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 t
38 matches
Mail list logo