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

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

HRDRFREA has had at least part of its "executable code" overwritten. That has caused a branch, directly or indirectly (through more than one branch), to somewhere close to where it abended. As soon as it branches out of the COBOL program, the information is irrelevant for problem determination

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

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

>Is the program CALLed (or "called")? CICS, IMS, DB2, batch? You mentioned >records and database, so I'd take a stab at batch with IMS or DB2. The program is called via EXEC PGM=, and it is using DB2. We live in a complex environment here, i.e. we've got a home grown middle ware layer that

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

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

Ok, either from the Production compile listing or by browsing the member on the Production loadlibrary, can you provide the 36 bytes, in hex (even better binary :-) ) from displacement X'84' from the start of the program? These are the "signature information bytes" which the compiler includes

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

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

>Tiny chance, tiny, tiny, of runtime/compiler problem if you are on V5+. Nice >to know, just to know whether to discount it completely. We're on the way to Cobol V5 but production is still V4. >With the COBOL program and the record causing the failure, it would be >possible to identify the

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

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

For a COBOL program to produce an exotic abend (removing the current record and having a clean run points a pretty big finger at the COBOL program) then it is a storage overlay. Tiny chance, tiny, tiny, of runtime/compiler problem if you are on V5+. Nice to know, just to know whether to

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

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

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

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

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

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

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

>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

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

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

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

>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

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

> 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

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

>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

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

>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

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

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

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

On 22 July 2016 at 14:32, Ed Jaffe wrote: >> Just curious that the PER bit is on. Was someone running a SLIP of a >> PERish sort? > > These days the PER bit is *always* on, in any serious development/test > environment, because of the ever-present ZAD SLIP in effect.

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

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

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

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

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

On 7/22/2016 9:31 AM, Tony Harminc wrote: Just curious that the PER bit is on. Was someone running a SLIP of a PERish sort? These days the PER bit is *always* on, in any serious development/test environment, because of the ever-present ZAD SLIP in effect. -- Edward E Jaffe Phoenix Software

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

On 7/22/2016 8:36 AM, Charles Mills wrote: Ah! Wait! The exact discussion was about a S0C6 on a branch to an odd address. Not sure if this would behave the same. Someone surely knows, and almost as surely will correct me if I am wrong. IIRC, the question was whether the 0C6 from the odd PSW

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

On Fri, 22 Jul 2016 18:23:04 +0200, Peter Hunkeler wrote: >>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

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

>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

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

>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

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

> 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

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

On 22 July 2016 at 11:14, Peter Hunkeler wrote: > I got a CEEDUMP and an analysis from StartTool DA. Both tell me the failing > PSW is 478D0400 A31A7BB8 > Looking at the SVC dump at the PRB/XSB which is now producing the SVC dump > (WLIC is 00020033), I see: > XSB+00E0 PSW16

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

>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

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

>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

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

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

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

Completes. The system takes a S0C4 when it tries to execute the inaccessible instruction. It's a pedantic difference but important if you are shooting a problem. Some discussion here recently. Ah! Wait! The exact discussion was about a S0C6 on a branch to an odd address. Not sure if this would

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

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

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

>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

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

On 7/22/2016 6:50 AM, Peter Hunkeler wrote: Any hint what I'm missing? What are the full contents of the 128-bit PSW? What's the 64-bit TEA value? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/

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

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

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

On Fri, 22 Jul 2016 16:21:46 +0200, 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.

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

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.

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

Don't you have the 0C4 on the L instruction? Is the storage at x'90'(,7) available? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: 22 July, 2016 15:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: S0C4-11 abend

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

No? What does a wild branch to unavailable storage do then? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: 22 July, 2016 16:02 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: S0C4-11 abend caused by BASSM to

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

We just had a discussion: a branch never S0C4's (short version). Is the storage x'90'(,R7) fetchable? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Hunkeler Sent: Friday, July 22, 2016 6:51 AM To:

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

I'm confused. Can I not see the obvious? We've got an S0C4-11 abend in a batch job. The last instructions seem to be L R15,x'90'(,7) BASSM R14,R15 R15 has the address that is seen in the PSW in the dump. The storage at this address *is* in the dump, and it contains a couple of X'00'. How