AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

>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

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

> >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

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

-- 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

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

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

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

>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

Re: AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

> 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

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

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

AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

>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

AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

>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

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

> > 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. >

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

> 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

Re: AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

> > >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 >

CEEOPTS (was: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes)

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

AW: Re: AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

>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

Re: AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

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.ceea50 0/ceedd.htm Language Environment allows you to provide additional invocation-level run-time options using the CEEOPTS DD statement. The CEEOPTS DD can refer

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

>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

Re: AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

> >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

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

>> 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

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

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

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

> 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.

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

>> 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.

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

> 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.

AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

>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

AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

>[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

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

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

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

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

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

I was once tasked with debugging a mysterious S0C4 in an old COBOL program. I set a SLIP for the failing job without specifying an abend code. Turned out that the original abend was a garden variety S0C7 that was mishandled by an ancient STAE routine, leading to a wild branch into some PLPA

Re: AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

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

AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

>:>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

AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

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

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

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.

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: :> :>>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

AW: Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

>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

Re: AW: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

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

Re: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

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

AW: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

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

AW: Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

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

Follow-on: S0C4-11 abend caused by BASSM to address with all X'00' bytes

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