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

[Peter Hunkeler]

>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 to logrec, so the only place
>it is easily visible is in system trace.



I see. Setting a MSGID= SLIP kind of stores the message id somewhere for WTO to 
compare it to the msgid of WTOs, and issue an abend to invoke SLIP when matched.


--
Peter Hunkeler



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

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

[Jim Mulder]

> >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 how I learned about the MSGID= 
> type SLIP. 
> Seems to be neither error nor PER type of SLIP. The manual describes
> SLIP being called as part of WTO procesing. 

  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 to logrec, so the only place 
it is easily visible is in system trace.

Jim Mulder z/OS Diagnosis, Design, Development, Test, etc. IBM Corp. 
Poughkeepsie, NY


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

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

[Peter Hunkeler]

--
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 how I learned about the MSGID= type SLIP.
Seems to be neither error nor PER type of SLIP. The manual describes SLIP being 
called as part of WTO procesing.




>Completion code applies to the last 3. As to the question, in practice, it 
>is typically only for some sort of 0C4 (whether PIC 10, PIC 11, PIC 38,
>etc)  that routines convert that program check to something else, such as
>"I tried to access storage identified by the caller, but failed, so
>provide a nicer completion code for the user to deal with than the generic 
>0C4". It could be any program check, it just happens not to be.
>
>SLIP gets control before recovery routines, so any completion code set by
>the recovery routine is not matchable by a SLIP trap.


Stupid me. I completely misinterpreted the text in the manual.



>I know nothing about SmartRestart, but even LE recommends not using its
>ESPIE path (and wisely so, in general). ESPIE is so restrictive that there 
>is no "surely" here.


Are you recommending to run with TRAP(ON,NOSPIE)? The LE Programming Reference 
manual still says "IBM highly recommends running with TRAP(ON,SPIE) in all 
environments".

--
Peter Hunkeler



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

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

[Peter Relson]

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 and converted ones: 11A, 12E, 15D, 15F, 200, 212, 25F, 279, 282, 
42A, 430, 57D, 700, 72A, A00, B00, and E00.



SLIP gets control in 4 environments:
-- PER
-- RTM1 (think "FRR")
-- RTM2 (think "ESTAE")
-- MEMTERM

Completion code applies to the last 3. As to the question, in practice, it 
is typically only for some sort of 0C4 (whether PIC 10, PIC 11, PIC 38, 
etc)  that routines convert that program check to something else, such as 
"I tried to access storage identified by the caller, but failed, so 
provide a nicer completion code for the user to deal with than the generic 
0C4". It could be any program check, it just happens not to be.

SLIP gets control before recovery routines, so any completion code set by 
the recovery routine is not matchable by a SLIP trap.

>SmartRestart surely needs an ESPIE of its own to be able 
>to recognize problems and act accordingly.

I know nothing about SmartRestart, but even LE recommends not using its 
ESPIE path (and wisely so, in general). ESPIE is so restrictive that there 
is no "surely" here. 

>The exit can try to recover or not. If not, it 
>percolates to the Recovery Termination Manager. The Program Interrupt 
>gets converted to a S0Cx abend.

This is not true in general. As of z/OS 1.12 the ESPIE exit can request 
that percolation. It does not happen otherwise. The exit can choose to 
"keep running" or it can choose to "resume" the mainline (by returning to 
the address in reg 14 on entry). Maybe you think about that as "recover or 
not", it really does not have to be related to that. Regardless, RTM is 
not involved unless requested (EPIEPERC is the bit).

Peter Relson
z/OS Core Technology Design


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

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

[Peter Hunkeler]

>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 course, now that you remind me. How could I forget about this :-(
I assume this is true only for error type SLIPs, other SLIPs are recognized in 
other parts of processing. PER type SLIPs are probably handled by PGM check 
FLIH, since A PER event is a PGM check event. RTM is not invoked for those; 
they are not errors. Message ID traps are maybe handled in WTO processing. I 
may as well be completely wrong with this.


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 and 
converted ones: 11A, 12E, 15D, 15F, 200, 212, 25F, 279, 282, 42A, 430, 57D, 
700, 72A, A00, B00, and E00.


This is not all too clear for me. Firstly, why is there the text "(code 0C4)" 
in the first sentence? Is this meant as an example, or is it meant to say the 
note only applies to 0C4s? Secondly, is the list of abend codes in the second 
sentence the complete list of completion codes which fall into this category? 
If so notge 1 would not apply to a PGM check 4 which was percolated and finally 
lead to an S0C4-4 abend so the abend would be trapped. The same would apply to 
an PGM 11 converted to a S0C4-11.


Can you clarify, please, Jim?


>I have not found any such documentation.  There is probably room
for some documentation improvements in that area.



Shall I open an RCF? If so what manual for?


--
Peter Hunkeler



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

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

[Jim Mulder]

> 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 surely needs an ESPIE of its own to be able to 
> recognize problems and act accordingly. If this is the case, I'm out
> of luck with the SLIP. Will have to check whether SmartRestart sets 
> up an ESPIE or not.
> 

  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. 
 
> What is the reasoning behind excluding SLIP from matching when ESPIEis 
active?
 
  SLIP gets called from RTM.  ESPIEs are invoked out of program check
processing, before RTM. So when an ESPIE exit handles things without 
percolating, there is no 0Cx abend, and RTM is not involved, so SLIP
is not involved. It is not that the SLIP was excluded from matching -
it is that there was no abend, and hence no RTM and no SLIP. 
 
> Is that information about how ESPIE interferes with ESPIE documented
> in detail somewhere? The MVS System Commands has only a single line 
> saying that SLIP will not match if ESPIE is active. No mentioning of
> authorized versus nonauthorized, or what ESPIE does with the pgm 
> check x'10', etc.

  I have not found any such documentation.  There is probably room 
for some documentation improvements in that area. 

Jim Mulder z/OS Diagnosis, Design, Development, Test, etc. IBM Corp. 
Poughkeepsie, NY


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

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

[Tom Marchant]

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

If an ESPIE is active at the time a Program Interruption occurs, the ESPIE exit 
will get 
control if the Program Interruption code is one that was specified on the ESPIE 
SET. 
The exit can try to recover or not. If not, it percolates to the Recovery 
Termination 
Manager. The Program Interrupt gets converted to a S0Cx abend. One of the 
things 
that RTM does is to check for a matching SLIP trap for that abend code. So, if 
the 
ESPIE exit attempts to recover, whatever it means by "recover", RTM doesn't 
receive 
control and is therefore not able to recognize the SLIP trap.

So it's not that SLIP was excluded, it never saw the S0Cx abend. In fact, the 
Program 
Interruption was never converted to a S0Cx abend.

-- 
Tom Marchant

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

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

[Peter Hunkeler]

>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 cannot be resolved.




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 surely needs an ESPIE of its own 
to be able to recognize problems and act accordingly. If this is the case, I'm 
out of luck with the SLIP. Will have to check whether SmartRestart sets up an 
ESPIE or not.




What is the reasoning behind excluding SLIP from matching when ESPIE is active?




Is that information about how ESPIE interferes with ESPIE documented in detail 
somewhere? The MVS System Commands has only a single line saying that SLIP will 
not match if ESPIE is active. No mentioning of authorized versus nonauthorized, 
or what ESPIE does with the pgm check x'10', etc.




--
Peter Hunkeler



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

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

[Peter Hunkeler]

>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 insufficient dump data? Just for comparison - were 
>the same addresses involved?

Yes, there seems to be some consistency. It was the same NSI address in the PSW 
in some dumps I lokked at.





>Admittedly we never specified RE=11 (or mode=pp) on the slip trap we had 
>attempted for an 0C4 in my last job, but the slip trap on OC4 only prodcued a 
>dump when TRAP was set to OFF. Maybe what interfered was the fact that parts 
>of the code were authorized. Maybe Peter's "middleware infrastructure" is also 
>authorized, at least in parts.




Nothing authorizied involved. What I call "middleware" here is just a bunch of 
Cobol and Assembler routines that have to be CALLed by application code to 
perform such basic things as opening, reading, writing, closing data sets. I 
don't know much about it yet; too new to the company.


--
Peter Hunkeler



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

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

[Jim Mulder]

> >  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. 
> Admittedly we never specified RE=11 (or mode=pp) on the slip trap we
> had attempted for an 0C4 in my last job, but the slip trap on OC4 
> only prodcued a dump when TRAP was set to OFF. Maybe what interfered
> was the fact that parts of the code were authorized. Maybe Peter's 
> "middleware infrastructure" is also authorized, at least in parts.

  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 cannot be resolved. 

Jim Mulder z/OS Diagnosis, Design, Development, Test, etc. IBM Corp. 
Poughkeepsie, NY


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

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

[Bill Woodger]

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 without a 
"full" dump.

HRDRFREA looks to be six CALLs deep. ZTVXXX00, HRDEFREA or any of the other 
modules involved in that specific chain, or any other module that has been 
CALLed previously in that run-unit, has caused the overwriting. 

One particular record "causes" the issue. Bear in mind that this may not be so. 
The issue may be there every day (overwriting) but only some combination of 
conditions prompted by that record presents the busted code for execution, or 
in a similar way but only on a few days, or only on that day - those conditions 
can be from other records, external data relating to those other records (DB or 
other reference data), previous program state. 

Or it may directly be that record causing, and suffering from, the overwriting. 
But that may be directly, or relying on previous state, as above.

Without at least a dump containing the executable code of HRDRFREA it is 
"difficult" to establish what has happened.

The investigator (singular - if you have multiple people looking at it, each 
should work singly) must be aware of the many possibilities, and be open to 
others. They have to be completely open - preconceptions will lead astray. 
After working for a period of time, take a break from looking at it. You've 
probably already missed it. Clear new preconceptions.

You start with that record. That record is going to get you there. You have to 
conceptualise how that record becomes an abend.

The "short-cuts" will usually get you there, or on the road. You find a 
mismatch in parameters, now you have to say "how does that cause the problem"? 
You may just be noticing another "issue", with no connection to the one at 
hand. Same with subscripting, reference-modification and the use of pointers. 
Don't just jump on the first error, fix, recompile and then go with it. Even if 
the run then completes, it may only be because now something less significant 
(for that run) has been overwritten, simply through the changed code from the 
fix (the overwriting only needs to move by one byte to have a different, even 
benign, result).

Until the failure can be fully explained by what is discovered, it cannot be 
resolved. Suggested explanations should also be tested against "and why doesn't 
it fail every day" and similar.

Yes, it's easier with a full dump, but sometimes you don't have a full dump. 

If the issue is sufficiently important, then "escalation" may allow some way to 
get sufficiently more information. "We absolutely need this, and the only way 
we can get it is by doing that", followed by "signatures of power" may be a 
possibility.

Also, of course, and you probably already are, review the exact use of the 
tools for cases like this (when the far-from-usual happens). 99% of the time a 
formatted dump is going to be sufficient. The other 1% consumes 99.999% of 
abend-solving time (for COBOL application programs). Figures are invented, but 
intended to be indicative.

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

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

[nitz-ibm]

> 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 from the inintial 
incident to the time the trace actually gets captured.
 
> I did in parallel to the discussion here and succeeded. I now know how to 
> change the options, but as you might have guessed, I'm working for a large 
> company. And large companies have processes. It will take quite some time to 
> bring those changed options to production, once I could convince engineering 
> to actually do it.
Do I know about processes! :-(

> Not at will, yet, but it reocurred in production. Application people are 
> still trying to reproduce it in test. Would make everyting much easier.
Did you get the same set of insufficient dump data? Just for comparison - were 
the same addresses involved?

>  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. 
Admittedly we never specified RE=11 (or mode=pp) on the slip trap we had 
attempted for an 0C4 in my last job, but the slip trap on OC4 only prodcued a 
dump when TRAP was set to OFF. Maybe what interfered was the fact that parts of 
the code were authorized. Maybe Peter's "middleware infrastructure" is also 
authorized, at least in parts.

Barbara

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

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

[Jim Mulder]

> > >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 not trivial as long as I don't have more information what 
> actually happens. 

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

  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. 

Jim Mulder z/OS Diagnosis, Design, Development, Test, etc. IBM Corp. 
Poughkeepsie, NY


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

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

[Paul Gilmartin]

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 the 2.2 documentation:

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ceeam00/ceeoptsdd.htm

RCF as follows submitted:

Hello, MHVRCFs

• z/OS
• z/OS 2.2.0
• z/OS Language Environment
• z/OS V2R1.0 Language Environment Programming Guide for 64-bit Virtual 
Addressing Mode
• Creating AMODE 64 applications with Language Environment
• Using runtime options
• Understanding the basics
• CEEOPTS DD syntax

... tells me how I might code CEEOPTS as instream, sequential, PDS, or DUMMY.
It does not mention UNIX files such as:
   //CEEOPTS  DD  PATH=...

Might one conclude from this that UNIX files are not supported for CEEOPTS?

Actually, I find the section superfluous, silly in fact.  Coding
DD statements is well explained in JCL Reference or Using Data
Sets.  The section should be replaced with a cross reference to
such a document.

Thanks,
gil

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

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

[Peter Hunkeler]

>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 instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

[Lizette Koehler]

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 to
  an in-stream data set, regular sequential data set, or a member of
 a regular or extended partitioned data set. If specified, the data
 set must be available during initialization of the enclave so the
 options can be merged. To specify the CEEOPTS DD statement, use the
 following syntax, as appropriate.

For in-stream JCL   
//CEEOPTS   DD  *
ALL31(OFF),STACK(,,BELOW)

For a sequential data set   
//CEEOPTS   DD DSN=MY.CEEOPTS.DATASET,DISP=SHR

For a partitioned data set  
//CEEOPTS   DD DSN=MY.CEEOPTS.DATASET(MYOPTS),
//  DISP=SHR

To ignore the DD statement  
//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 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 not trivial as long as I don't
> have more information what actually happens.
> > I have asked that the job be changed to switch off the 'little helpers' and
> a SYSMDUMP DD be added. Hopefully I will have more information next time it
> fails.
> 
> 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. And your
> sysmdump may contain a dump, but not the first 0C4. I speak from three years
> of dealing with LE in the picture (lucky for me, it was only LE). If it were
> me, I would a) try to find out if that dump option thing is customizable and
> if not kick the vendor in the behind - very hard - for disabling installation
> set dump options, and b) I would try to figure out where that bit is set and
> zap it off to get the full set of dump options that I have defined (everything
> except the IBM-software-support-all-time-favourite of ALLNUC which is
> unnecessary for most problems anyway, but gets copied every time a slip dump
> is requested).
> 
> >Machine State:
> > ILC. 0002Interruption Code. 0004
> That's the ZMCH and that is what FLIH recorded. It gets copied early in LE
> processing and is the first problem that occured.
> 
> >RTPSW1... 478D0400  A31A7BB8
> >RTPSW2... 00020011  231A7800
> >What can I learn from this? How do I properly use these fields in dump
> analysis?
> 
> There's your PIC 11 in RTPSW2. So following the first 0c4-4 (see ZMCH in LE)
> you got (at least one) subsequent 0c4-11. If both fields are set, it means
> that while RTM was still dealing with the first problem, a second problem
> occured.
> 
> I think that the fields in the XSB may have also been reused by the later
> problem, which means at the time of the dump things are definitely not the way
> they were at the time of the first problem anymore (they never are when LE has
> a chance to get at something first). I'm sure that Jim will correct me if I
> said something wrong here.
> 
> If it were me, I would try to find out what address is supposed to be at
> r7+x'90'. Assuming that DCA$DCT is a vendor control block and not one
> belonging to JES2. To do that, take a slip dump of the same program execution
> in test (the equivalent of address 24D90BE0 in your code snippet), find the
> same control block in it using the eyecatcher, look at that storage and see if
> the addresses look similar to what you have in the error case. If they do,
> then find out where the address at x'90' points to. Maybe that will give a
> clue. Another option would be getmain/freemain trace (if you can set that up
> in production) presumably for SP0, KEY8.
> 
> Another idea - get yourself IPCS access to private storage in other address
> spaces (a FACILITY class profile) and while the job is running, look at the
> same control block - I am betting that it will always be at offset DC20. In
> IPCS active storage (using the asid) you can then use the pointer command (?)
> to see where offset x'90' points to. Maybe it is getmained then!
> 
> Not sure that you mentioned it - is the problem reproducible at will?
> 
> Barbara
> 

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

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

[Peter Hunkeler]

>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 application code needs to use for just about anything. Apart from 
that, there are dozens of applicaition modules loaded in the address space.


My job is to find what might have gone wrong causing that writd situation and 
abend. It's the application people's job to read the code then. I have no 
knowledge about the business function and business data, so I cannot help with 
this.




--
Peter Hunkeler



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

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

[Peter Hunkeler]

>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 sporadically, I 
had set a SLIP and it matched. But this was not a PGM check, so ESTAE and not 
ESPIE was in charge.




>And your sysmdump may contain a dump, but not the first 0C4.


All I'm looking for is a system trace. Hoping to find hints what do look for 
next.


>If it were me, I would a) try to find out if that dump option thing is 
>customizable


I did in parallel to the discussion here and succeeded. I now know how to 
change the options, but as you might have guessed, I'm working for a large 
company. And large companies have processes. It will take quite some time to 
bring those changed options to production, once I could convince engineering to 
actually do it.



>Not sure that you mentioned it - is the problem reproducible at will?




Not at will, yet, but it reocurred in production. Application people are still 
trying to reproduce it in test. Would make everyting much easier.


--
Peter Hunkeler



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

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

[Bill Woodger]

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 in each 
program. Reveals compile options and COBOL language elements used. See the 
Programming Guide for detailed explanation.

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.

Does the program have a "reputation"? Is it "feared" whenever it comes up for 
change? Are there outstanding minor issues with the program?

Does the program CALL (or otherwise "call") other programs? (the signature 
information bytes will reveal anyway, but can be simpler if the answer is 
already known to be "yes")?

Is the program big, small, medium, and how big, small or medium?

When you look at the code, is it easy to read, or difficult? More on "style" 
later if necessary.

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

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

[nitz-ibm]

> >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 not trivial as long as I 
> don't have more information what actually happens. 
> I have asked that the job be changed to switch off the 'little helpers' and a 
> SYSMDUMP DD be added. Hopefully I will have more information next time it 
> fails.

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. And your 
sysmdump may contain a dump, but not the first 0C4. I speak from three years of 
dealing with LE in the picture (lucky for me, it was only LE). If it were me, I 
would a) try to find out if that dump option thing is customizable and if not 
kick the vendor in the behind - very hard - for disabling installation set dump 
options, and b) I would try to figure out where that bit is set and zap it off 
to get the full set of dump options that I have defined (everything except the 
IBM-software-support-all-time-favourite of ALLNUC which is unnecessary for most 
problems anyway, but gets copied every time a slip dump is requested).

>Machine State:
> ILC. 0002Interruption Code. 0004
That's the ZMCH and that is what FLIH recorded. It gets copied early in LE 
processing and is the first problem that occured. 

>RTPSW1... 478D0400  A31A7BB8
>RTPSW2... 00020011  231A7800
>What can I learn from this? How do I properly use these fields in dump 
>analysis?

There's your PIC 11 in RTPSW2. So following the first 0c4-4 (see ZMCH in LE) 
you got (at least one) subsequent 0c4-11. If both fields are set, it means that 
while RTM was still dealing with the first problem, a second problem occured. 

I think that the fields in the XSB may have also been reused by the later 
problem, which means at the time of the dump things are definitely not the way 
they were at the time of the first problem anymore (they never are when LE has 
a chance to get at something first). I'm sure that Jim will correct me if I 
said something wrong here.

If it were me, I would try to find out what address is supposed to be at 
r7+x'90'. Assuming that DCA$DCT is a vendor control block and not one belonging 
to JES2. To do that, take a slip dump of the same program execution in test 
(the equivalent of address 24D90BE0 in your code snippet), find the same 
control block in it using the eyecatcher, look at that storage and see if the 
addresses look similar to what you have in the error case. If they do, then 
find out where the address at x'90' points to. Maybe that will give a clue. 
Another option would be getmain/freemain trace (if you can set that up in 
production) presumably for SP0, KEY8. 

Another idea - get yourself IPCS access to private storage in other address 
spaces (a FACILITY class profile) and while the job is running, look at the 
same control block - I am betting that it will always be at offset DC20. In 
IPCS active storage (using the asid) you can then use the pointer command (?) 
to see where offset x'90' points to. Maybe it is getmained then!

Not sure that you mentioned it - is the problem reproducible at will?

Barbara

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

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

[Peter Hunkeler]

>> 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 did in this case as well. 
Unfotunately, I was searching the PoOp (offline in the PDF) for "Translation 
exception" but got no hint. The missing dash makes the difference. Argrrr


Understood now. Slowly derusting my debugging skills. Thanks for all the help 
with this.


--
Peter Hunkeler







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

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

[Peter Hunkeler]

>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 issue. Of course, it is not always possible to supply 
>these things.


Yes, this is what I have asked the developer to do. However, there are two 
possible inhibitor: a) We're not given permission to move the record from prod 
to test, and b) the problem does not occur in test with even that record, 
because the data on the data base is different.
I have little hope so far they will succeed to reproduce the problem in test 
before we know more about the cause (chicken or egg problem).


>For the first, using compiler option SSRANGE (with LE Runtime option CHECK(ON) 
>if you are before V5) will help.


Yes, but again, easy in test, impossible in prod.



>I don't look at programs the way a Sysprog does, and that's probably true vice 
>versa. What is easy for me to say and do, is probably as much like moon-dust 
>to you as a lot on this list is to me :-)



Fortuntately, I've been doing application programming a lot in my career as 
well, so I know both sides very well. What I'm pretty ignorant at is Cobol. I'm 
mainly a PL/I, Assembler and REXX programmer. But I'm learning




--
Peter Hunkeler



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

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

[Bob Rutledge]

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 that time, resulting in a 0C4-11 abend.
Since the dumping program subsequently dumped that page, the page
must have been GETMAINed after the 0C4-11 abend, presumably by
the exception handling/dumping processing.





Thanks. What I do not yet understand: The TRNE address is 231A7800, where as 
the address in R15 231A7BB8. Why the difference?


Described in Principles of Operation under "assigned memory locations" (A8-AF).

Bob

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

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

[Bill Woodger]

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 discount it completely.

With the COBOL program and the record causing the failure, it would be possible 
to identify the issue. Of course, it is not always possible to supply these 
things.

Two main things cause storage overlays in COBOL. Wild "subscripts" (which 
includes reference-modifiers) and parameter mismatches on CALLs.

For the first, using compiler option SSRANGE (with LE Runtime option CHECK(ON) 
if you are before V5) will help.

For the CALLs, it is down to "inspection" of the code. 

Since "pointers" have been available in COBOL, those have to be taken into 
consideration as well. Look for any "manipulation" of pointers, especially with 
'rithmatic, and especially on definitions which are not COMP-5 (or TRUNC(BIN)).

I don't look at programs the way a Sysprog does, and that's probably true vice 
versa. What is easy for me to say and do, is probably as much like moon-dust to 
you as a lot on this list is to me :-)

You're on the right track. Deleting the record shows that. S0CA is interesting, 
but you don't get many of those in a COBOL program either. Perhaps the same 
cause?

For this type of problem (removing the record "fixes" it) there are two things 
to look for: what is it about that current record?; is there any "crosstalk" 
possible with a previous record.

Yes, even for a COBOL programmer a SYSUDUMP would help. Oldschool, anyway. 
Shoot anyone who suggests firing up a debugger :-)

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

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

[Jim Mulder]

> 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. IBM Corp. 
Poughkeepsie, NY



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

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

[Peter Hunkeler]

>> 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.
>Since the dumping program subsequently dumped that page, the page
>must have been GETMAINed after the 0C4-11 abend, presumably by
>the exception handling/dumping processing.




Thanks. What I do not yet understand: The TRNE address is 231A7800, where as 
the address in R15 231A7BB8. Why the difference?


--
Peter Hunkeler

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

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

[Jim Mulder]

> 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.
Since the dumping program subsequently dumped that page, the page
must have been GETMAINed after the 0C4-11 abend, presumably by
the exception handling/dumping processing. 

Jim Mulder z/OS Diagnosis, Design, Development, Test, etc. IBM Corp. 
Poughkeepsie, NY



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

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

[Peter Hunkeler]

>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 for this. As said there is Smart/Restart and with my 
current (limited) understanding of what this does and what it depends on, this 
would be risky. The application depends on the tool to coordinate sequential 
file processing with DB2 processing in the case of abends and restarts.


I'm hoping for the SYSMDUMP. If that fails, I will take the burden and ask for 
a SLIP.


--
Peter Hunkeler



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

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

[Peter Hunkeler]

>[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 control of Smart/Restart 
that intercepts just about anything, and probably needs to, in order to 
fullfill it's duties to make the job restartable. I don't know much about the 
internals or Smart/Restart, but from another case I had to invesitgate, I 
learned that it is intercepting SVCs like open, close, as well as BSAM/QSAM 
read/write routines, etc., etc.
What makes it worse is the fact that we also use StarTool DA which should be a 
help in diagnosing appliation problems.
Smart/Restart is the first to learn about an exception (or is it after LE?), it 
recognized StarTools DA is also part of the game. The former then advises the 
later to take an SVC dump. The later has unfortunate dump options built in its 
code that request only mininmal content (not TRT, etc.) and forces system dump 
options to be ignored.
Result of all that is misleading information in the dumps. Lack of a system 
trace, I'm unable to see the real events that happened.
I only wanted to understand why a S0C4-11 was reported when I had expected a 
S0C1. I did not talk about the following so far for that reason.

Based on what I know so far, I'm convinced the problem seen is a delayed effect 
of a storage overlay somewhere else in the Cobol code. Support people 
identified the current input record, removed it from the input file and the job 
runs fine. Happened to more times so far. This why I suspect that something 
with that record leads to false behabiour of the code, such as writing beyond 
the end of a table.

What I also did not mention to anyone so far: I see a single line message from 
Smart/Restart that says a S0CA (Decimal Overflow) has happended. Not indication 
where, no dump at this time. Nothing but silence. This was just a bit before 
the S0C4-11 messages start to show up. I'm hoping for a system trace in the 
SYSMDUMP that I was requesting to be added to the job (mentioned in a previous 
post). Kind of seems to be a case liek the one Skip Robinson mentione (S0C7). 
We'll see.




--
Peter Hunkeler



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

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

[Bernd Oppolzer]

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 where the BASSM goes is correct.

That should give 0C1, not 0C4;
could it be that the 0C1 is covered by a 0C4 which happens while
LE tries to do its dump processing?

What happens, if you switch off LE dump processing by LE option TRAP(OFF)?
(used to be called NOSPIE,NOSTAE some ten years ago).

Kind regards

Bernd



Bernd Oppolzer schrieb:

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   24D85D48   24D85D48   +4396  20130225 COBOL
4 231174F0   20EDB610   20EDB610   +02FC  20140722 LIBRARY
5 23117078   235F6400   235F6400   +9C92  20160624 COBOL
...
1423115258   20EDB610   20EDB610   +02FC  20140722 LIBRARY
1523115030   23100428   23100428   +0A10  20100129 COBOL

I would take a closer look at the call position
of the COBOL module at level 3, at position 4396.

The name is HRDRFREA.
What is called there, and why does the called module build a save
area at such a strange place 0001? The informations contained
there seem wrong, too. That is the save area and register information 
printed;

maybe this is all misleading ...

Kind regards

Bernd



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

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

[Bernd Oppolzer]

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   24D85D48   24D85D48   +4396  20130225 COBOL
4 231174F0   20EDB610   20EDB610   +02FC  20140722 LIBRARY
5 23117078   235F6400   235F6400   +9C92  20160624 COBOL
...
1423115258   20EDB610   20EDB610   +02FC  20140722 LIBRARY
1523115030   23100428   23100428   +0A10  20100129 COBOL

I would take a closer look at the call position
of the COBOL module at level 3, at position 4396.

The name is HRDRFREA.
What is called there, and why does the called module build a save
area at such a strange place 0001? The informations contained
there seem wrong, too. That is the save area and register information 
printed;

maybe this is all misleading ...

Kind regards

Bernd




Peter Hunkeler schrieb:


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 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'm posting some raw information from the CEEDUMP as well as from IPCS. I have added a 
few lines of comment starting with "***".
  
In the CEEDUMP part I have shortened the trace back list by deleting some intermediate call information (entries 6-13).
  
  
I don't want to add an futher interpretation from me. If you still find some time to have a look and post whatever information you might find useful, I would very much appreciate.
  



Thanks
Peter
  
  
--

Peter Hunkeler




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



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

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

[Jesse 1 Robinson]

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 module. Sometimes 
omitting abend code can be quite illuminating. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion 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:

:>
:>>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:
ILC. 0002Interruption Code. 0004


:>>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, otherwise it would be marked as "inaccessible 
storage". I don't know what to expect at that address, it is not my 
application, I was merely asked if I could help debugging what seems to be a 
storage overlay problem.

I don't know how LE plays that game. A SLIP of the 0C4 would have true contents.

--
Binyamin Dissen  http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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

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

[Ed Jaffe]

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 many others have posted numerous code 
and dump fragments over the years. (As long as there is no trailing 
whitespace as per the email formatting RFC(s), all should be good.)


Here is one I was looking at over the weekend. Tell me if it looks bad 
to you:


SEARCH ARGUMENT ABSTRACT

  RIDS/EJESDJ3#L RIDS/EJESSUBS AB/S0DC2 PRCS/5C003F20 REGS/C3136

  Symptom Description
  --- ---
  RIDS/EJESDJ3#L  Load module name: EJESDJ3
  RIDS/EJESSUBS   Csect name: EJESSUBS
  AB/S0DC2System abend code: 0DC2
  PRCS/5C003F20   Abend reason code: 5C003F20
  REGS/C3136  Register/PSW difference for R0C:-3136

Time of Error Information

  PSW: 47045000 8000  018B77BA
  Instruction length: 02   Interrupt code: 000D
  Failing instruction text: 00181610 0A0D010E B24D001C

  Breaking event address: _0D176BA6
  AR/GR 0-1/_8400 /_84DC2000
  AR/GR 2-3/_ /_
  AR/GR 4-5/_01DF9000 /_9EF2
  AR/GR 6-7/_02697000 /0048_9EEF0001
  AR/GR 8-9/_ /_7F2DA250
  AR/GR 10-11  /_7F2D8000 /_0800
  AR/GR 12-13  /_018BA8F0 /_01DFB178
  AR/GR 14-15  /_01DFB000 /_5C003F20

  Home ASID: 007CPrimary ASID: 007CSecondary ASID: 007C
  PKM:   AX:   EAX: 0002

  This SRB'S PURGEDQ ASID/TCB: 007C/00AE12D0

  RTM was entered because an SVC was issued in an improper mode.
  The error occurred while an SRB routine was in control.
  No locks were held.
  No super bits were set.

RECOVERY ENVIRONMENT

  Recovery routine type: Functional Recovery Routine (FRR)
  PSW at entry to FRR: 470C 8D02E3F4
  LSED address when FRR was established: 01F291B8
  FRR parameter area on entry to FRR:
  +00  7F308100     

  NO DATA EXISTS IN THE VARIABLE RECORDING AREA

IEA24013I FORMATTING COMPLETED SUCCESSFULLY.

CPU STATUS:
PSW=47045000 8000  018B77BA
(Running in AR, key 0, AMODE 31, DAT ON, SUPERVISOR STATE)
Enabled for PER I/O EXT MCH
   ASID(X'007C') 018B77BA. IEANUC01.IAXV6+079A IN READ ONLY NUCLEUS
  ASCB124 at FA2100, JOB(EDJX2), for the home ASID
  ASXB124 at AFD000 for the home ASID. No block is dispatched
  HOME ASID: 007C PRIMARY ASID: 007C SECONDARY ASID: 007C

  General purpose register values
 0-1  _8400  _84DC2000
 2-3  _  _
 4-5  _01DF9000  _9EF2
 6-7  _02697000  0048_9EEF0001
 8-9  _  _7F2DA250
10-11 _7F2D8000  _0800
12-13 _018BA8F0  _01DFB178
14-15 _01DFB000  _5C003F20

  Access register values
  0-3        
  4-7        
  8-11       
 12-15       

  Control register values
 0-1  0082_DF8EE660  _E3950007
 2-3  _1FFB9040  0001_007C
 4-5  0001_007C  _1F37DF00
 6-7  _0200  _E3950007
 8-9  _0002  _0400
10-11 _  _
12-13 _9DC5AE4B  _E3950007
14-15 _DF89F37B  _01F292E0

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

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

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

[Peter Hunkeler]

>:>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 show the content of the memory at the 
address in R15 / PSW NSI, and this is key 8 storage.


*But* the main purpose of my post was to under how the job can fail with a 
S0C4-xx when I can see the storage in the dump. The conclusion was (see 
previous thread) that the "little helpers" must have getmained and gotten 
storage that was not there (or not in key 8) at the time if the initial error.



>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 not trivial as long as I don't 
have more information what actually happens.


I have asked that the job be changed to switch off the 'little helpers' and a 
SYSMDUMP DD be added. Hopefully I will have more information next time it fails.




--
Peter Hunkeler



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

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

[Peter Hunkeler]

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

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

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

[Ed Jaffe]

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/15/16 12:12:28 AMASID: 0159   Job ID: J0274722   Job name: P07W04UA   
Step name: DB2RUN UserID: TWSP0A CEE3845I CEEDUMP Processing started. 
Information for enclave ZTVXXX00   Information for thread 8000


This ugly wrapping of textual information is standard email behavior 
(detailed in an RFC) and occurs because you posted information with 
trailing whitespace.


You must remove ALL trailing whitespace before you paste the dump text 
into your email.


I use UltraEdit under Windows 10. In that editor it's Alt+T+G to do 
this. I'm sure other PC editors do similar things.


If all else fails, you should be able to save the text into a 
variable-length data set in ISPF and use FTP with ASCII transfer to copy 
to your workstation...


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

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

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

[Binyamin Dissen]

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:
ILC. 0002Interruption Code. 0004


:>>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, otherwise it would be marked as "inaccessible 
storage". I don't know what to expect at that address, it is not my 
application, I was merely asked if I could help debugging what seems to be a 
storage overlay problem.

I don't know how LE plays that game. A SLIP of the 0C4 would have true
contents.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

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

[Peter Hunkeler]

>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, otherwise it would be marked as "inaccessible 
storage". I don't know what to expect at that address, it is not my 
application, I was merely asked if I could help debugging what seems to be a 
storage overlay problem.


--
Peter Hunkeler



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

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

[Elardus Engelbrecht]

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 first attempt was horrrible! ;-D

Groete / Greetings
Elardus Engelbrecht

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

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

[Binyamin Dissen]

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 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 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'm posting some raw information from the CEEDUMP as well as from IPCS. I 
have added a few lines of comment starting with "***". 
:> 
:>In the CEEDUMP part I have shortened the trace back list by deleting some 
intermediate call information (entries 6-13). 
:> 
:> 
:>I don't want to add an futher interpretation from me. If you still find some 
time to have a look and post whatever information you might find useful, I 
would very much appreciate. 
:> 
:>
:>
:>Thanks 
:>Peter  
:> 
:> 

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

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

[Peter Hunkeler]

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 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'm posting some raw information from the CEEDUMP as well as from IPCS. I have 
added a few lines of comment starting with "***".

In the CEEDUMP part I have shortened the trace back list by deleting some 
intermediate call information (entries 6-13).


I don't want to add an futher interpretation from me. If you still find some 
time to have a look and post whatever information you might find useful, I 
would very much appreciate.



Thanks
Peter


--
Peter Hunkeler




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

*** CEEDUMP information follows *

CEE3DMP V2 R1.0: Condition processing resulted in the unhandled condition.  
   07/15/16 12:12:28 AM
ASID: 0159   Job ID: J0274722   Job name: P07W04UA   Step name: DB2RUN 
UserID: TWSP0A

CEE3845I CEEDUMP Processing started.

Information for enclave ZTVXXX00

  Information for thread 8000

  Traceback:
DSA   Entry   E  Offset  Statement   Load Mod Program Unit  
 Service  Status
1 CEEHDSP +4A4C  CEEPLPKA CEEHDSP   
 UI90017  Call
2 -01BE8FAE  HRDRFREA   
  Exception
3 HRDRFREA+4396  HRDRFREA HRDRFREA  
  Call
4 IGZCFCC +02FC  IGZCPAC  IGZCFCC   
 UI19860  Call
5 HRDDBLNK+9C92  HRDDBLNK HRDDBLNK  
  Call
...
14IGZCFCC +02FC  IGZCPAC  IGZCFCC   
 UI19860  Call
15ZTVXXX00+0A10  ZTVXXX00 ZTVXXX00  
  Call

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   24D85D48   24D85D48   +4396  20130225   COBOL
4 231174F0   20EDB610   20EDB610   +02FC  20140722   LIBRARY
5 23117078   235F6400   235F6400   +9C92  20160624   COBOL
...
1423115258   20EDB610   20EDB610   +02FC  20140722   LIBRARY
1523115030   23100428   23100428   +0A10  20100129   COBOL

  Condition Information for Active Routines
Condition Information for  (DSA address 0001)
  CIB Address: 231181B0
  Current Condition:
CEE0198S The termination of a thread was signaled due to an unhandled 
condition.
  Original Condition:
CEE3204S The system detected a protection exception (System Completion 
Code=0C4).
  Location:
Program Unit:  Entry:  Statement:  Offset: -01BE8FAE
  Machine State:
ILC. 0002Interruption Code. 0004
PSW. 478D0400 A31A7BB8
GPR0. _24BD7528  GPR1. _DDF4  GPR2. 
_24D96690  GPR3. _0004
GPR4. _23145460  GPR5. _77FC  GPR6. 
_0001  GPR7. _DC20
GPR8. _009B7028  GPR9. _24BD73A8  GPR10 
_009B7008  GPR11 _009B7E88
GPR12 _24D90B40  GPR13 _0001  GPR14 
_A4D90BE2  GPR15 _A31A7BB8

FPC.. 
FPR0. 4EE6ED27  D6668000FPR1. 487F  FF00
FPR2. 4264  FPR3.   
FPR4. 40326E64  05A0FPR5.   
FPR6.   FPR7.   
FPR8.   FPR9.   
FPR10   FPR11   
FPR12   FPR13   
FPR14   FPR15   

Storage dump near condition, beginning at location: 231A7BA8
  +00 231A7BA8         
   ||
  

*** IPCS Data follows 

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

[Peter Hunkeler]

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   
Step name: DB2RUN UserID: TWSP0A CEE3845I CEEDUMP Processing started. 
Information for enclave ZTVXXX00   Information for thread 8000   
Traceback:DSA   Entry   E  Offset  Statement   Load Mod 
Program Unit   Service  Status1 CEEHDSP +4A4C   
   CEEPLPKA CEEHDSPUI90017  Call
2 -01BE8FAE  HRDRFREA   
  Exception3 
.




--
Peter Hunkeler

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


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

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

[Peter Hunkeler]

>> 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 BNDRY=PAGE specified.




I stand corrected. Thanks for remembering me.


--
Peter Hunkeler





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

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

[Peter Hunkeler]

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 to see something that you didn't.
I'm posting some raw information from the CEEDUMP as well as from IPCS. I have 
added a few lines of comment starting with "***".

In the CEEDUMP part I have shortened the trace back list by deleting some 
intermediate call information (entries 6-13).


I don't want to add an futher interpretation from me. If you still find some 
time to have a look and post whatever information you might find useful, I 
would very much appreciate.

Thanks
Peter


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/15/16 12:12:28 AMASID: 0159   Job ID: J0274722   Job name: P07W04UA   
Step name: DB2RUN UserID: TWSP0A CEE3845I CEEDUMP Processing started. 
Information for enclave ZTVXXX00   Information for thread 8000   
Traceback:DSA   Entry   E  Offset  Statement   Load Mod 
Program Unit   Service  Status1 CEEHDSP +4A4C   
   CEEPLPKA CEEHDSPUI90017  Call
2 -01BE8FAE  HRDRFREA   
  Exception3 HRDRFREA+4396  
HRDRFREA HRDRFREACall4 
IGZCFCC +02FC  IGZCPAC  IGZCFCC 
   UI19860  Call5 HRDDBLNK+9C92  HRDDBLNK   
  HRDDBLNKCall...14IGZCFCC 
+02FC  IGZCPAC  IGZCFCC
UI19860  Call15ZTVXXX00+0A10  ZTVXXX00 
ZTVXXX00Call DSA   DSA Addr   E  AddrPU 
AddrPU Offset  Comp Date  Compile Attributes1 23117AE0   08DA2B60   
08DA2B60   +4A4C  20150130   CEL2 0001   24D90B66   24D90B66   
-01BE8FAE  3 231176E8   24D85D48   24D85D48   +4396  
20130225   COBOL4 231174F0   20EDB610   20EDB610   +02FC  20140722  
 LIBRARY5 23117078   235F6400   235F6400   +9C92  20160624   COBOL  
  ...1423115258   20EDB610   20EDB610   +02FC  20140722   LIBRARY   
 1523115030   23100428   23100428   +0A10  20100129   COBOL   
Condition Information for Active RoutinesCondition Information for  (DSA 
address 0001)  CIB Address: 231181B0  Current Condition:
CEE0198S The termination of a thread was signaled due to an unhandled 
condition.  Original Condition:CEE3204S The system detected a 
protection exception (System Completion Code=0C4).  Location:
Program Unit:  Entry:  Statement:  Offset: -01BE8FAE  Machine State:
ILC. 0002Interruption Code. 0004PSW. 478D0400 A31A7BB8  
  GPR0. _24BD7528  GPR1. _DDF4  GPR2. 
_24D96690  GPR3. _0004GPR4. 
_23145460  GPR5. _77FC  GPR6. _0001  
GPR7. _DC20GPR8. _009B7028  GPR9. 
_24BD73A8  GPR10 _009B7008  GPR11 _009B7E88 
   GPR12 _24D90B40  GPR13 _0001  GPR14 
_A4D90BE2  GPR15 _A31A7BB8 FPC..    
 FPR0. 4EE6ED27  D6668000FPR1. 487F  FF00
FPR2. 4264  FPR3.   
FPR4. 40326E64  05A0FPR5.   
FPR6.   FPR7.   
FPR8.   FPR9.   
FPR10   FPR11   
FPR12   FPR13   
FPR14   FPR15    
Storage dump near condition, beginning at location: 231A7BA8  +00 
231A7BA8          
  ||   ** IPCS Data 
follows **  SELECTED 
BY: CURRENTJOBNAME P07W04UA  ASCB 00F63B80  NEXT 00F5FE80  PREV 00F62880  ASID 
0159 TCB 009FDD40  NEXT 009FD040  PREV  COMP TCB 009FD040  NEXT 
009FF6C8  PREV 009FDD40 COMP TCB 009FF6C8  NEXT 009F8680  PREV 

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

[Gord Tomlin]

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 pageable, private storage subpool,
 with BNDRY=PAGE specified.

In all other cases, you must not assume that the storage is cleared 
to zeros.


The caller can specify CHECKZERO=YES to detect these and other 
cases where the system clears the requested storage to zeros."


(http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A4B0/11.2?SHELF=iea2bkb4=20110614131125)

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

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

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

[Peter Hunkeler]

>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 is more likely it is fresh storage after the page was initially assigned to 
newly getmained storage. It will be cleared to X'00' by MVS. If nobody writes 
before reading it, it is still x'00', i.e. garbage.


>BTW Why load offset x'90' on R7 as EP?


 I don't have clue. The storage where R7 point to belongs to a load module is 
called SQLBATCH and it seems to belong to Smart/Restart. Not our code.




--
Peter Hunkeler




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

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

[Peter Hunkeler]

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


Yes, Jim Mulder mentioned this already in an earlier post. In the meantime, I 
believe this really must have been the case. Nobody provided any information 
that would explain it to meant something else.




I had not been involved in debugging cased once others have given up for quite 
some time. I'm a bit rusty in reading dumps. I just wanted to make sure I'm not 
missing the obvious. I feel more confidet now.


Thanks everybody for your help so far.




I suspect the inital cause is some kind of storage overwrite by the applicaiton 
white hits some other code some time later. The result is what I got; with not 
hint on what wrote when and where, when it should not have This kind of 
problem is difficult enough, I don't want to base my analysis and guessing on a 
dump I cannot trust.


--
Peter Hunkeler






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

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

[Peter Hunkeler]

>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



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

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

[Peter Hunkeler]

> 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



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

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

[Peter Hunkeler]

>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 post snippets from the dump in addition 
to my conclusions and questions.


>You've shown the PSW. You haven't shown the data at and before the PSW. Do you 
>have the ILC?




I did not show the data but I wrote that the PSW NSI points to a bunch of 
x'00'. Sorry this was not clear enough. And I dd not post the ILC because I 
considered it irrelevant. With a 0C4-11 the NSI points to the failing 
isntruction itself and this was x''. But I admit, this was again subjective 
information instead of facts.


--
Peter Hunkeler



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

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

[Peter Hunkeler]

>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 from R15 is seen as 
the PSW's NSI address.

--
Peter Hunkeler

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

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

[CM Poncelet]

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 happened first and executing the instruction x'' at  had 
then failed. So why was the page not allocated and what executable code 
should have been loaded into it - or is its  address corrupted? 
(The x'' seems to be left-over garbage.) BTW Why load offset x'90' 
on R7 as EP?


My ha'pennyworth. CP

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 accessing the instruction at the PSW's NSI. The storage at this 
address is a couple of x'00', and the storage is in SP1, key 8.
If anyting was allocated but not accessible, a S0C4-4 would occur, not an 
S0C4-11.
--Peter Hunkeler


-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 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 can the storage be in the dump when the abend code suggests it is not even getmained (S0C4-11)? Why is this not an S0C1 (operation exception caused by X'' at the PSW NSI address)? 



The PSW in enabled, problem state, key 8. The storage pointed to by R15 is in SP 1, key 8. 



Any hint what I'm missing? 








 



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

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

[Tony Harminc]

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.

Sure - I'm used to seeing the bit on on my own systems. But I
understood -- perhaps incorrectly -- that this dump came from a
customer environment, and that that at least partly explains the
difficulty in getting a "real" SVC/SLIP dump. Presumably a production
environment is far less likely to have any kind of PER running.
Certainly we rarely see it on in customer dumps unless it's from a
SLIP we've asked them to set.

Tony H.

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

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

[Blaicher, Christopher Y.]

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 Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com





-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Friday, July 22, 2016 2:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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





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.

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

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

[Ed Jaffe]

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 nice long trace tables. 
Anything else is just frustration in a can!


Good luck...

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

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

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

[Ed Jaffe]

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 International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

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

[Ed Jaffe]

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 address would 
take precedence over the 0C4 for inability to fetch instructions from 
the target location. The answer was yes.


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

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

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

[Tom Marchant]

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 ask me specifically. I would not know what to 
>post otherwise; It simply too much data.

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've shown the PSW. You haven't shown the data at and before the PSW. 
Do you have the ILC?

-- 
Tom Marchant

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

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

[Peter Hunkeler]

>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 to be not limited for the target 
job(s), only. Bad, IMHO.


I did check if there is another SVc dump from that time around which could have 
provided me the missing system trace, but Murphy made sure there is none.


So yes, for the time being I'm left with the toy dumps.


--
Peter Hunkeler


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

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

[Peter Hunkeler]

>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 as well. The storage where the PSW NSI 
point to seems to be part of a chain of 4k areas. I see what looks like forward 
and backward pointers near the beginning of each 4k area. I also see the name 
of some of the applicaition modules that are loaded, as well as the lliters 
PCONTROL in each of the blocks. Some bytes before the first such block, there 
is the literal HANC, which indicates this might be LE heap storage.


For all this, I thought the storage must have been there before the S0C4, but 
of course this linked list can as well have been built as part of Smart/Restart 
or StarTool analysis. But is seemed unlikely to be that tools bilt to analyze 
failures would tell me false information. But again, who knows.


If I only had the system trace. It would all be so much easier. I cannot 
understand how someone coding an SDUMP macro can leave away TRT and explicitly 
specify that dump defaults and change dump options shall be ignored (seen in 
the SVC dump, dicussed in a separate thread).


Thanks for your help so far. I'll restart posting on Monday, if I have new 
questions or new information with wich you could help me.




--
Peter Hunkeler



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

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

[Jim Mulder]

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

Jim Mulder z/OS Diagnosis, Design, Development, Test, etc. IBM Corp. 
Poughkeepsie, NY


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

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

[Tony Harminc]

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 47850400  8000    231A7BB8

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?

Tony H.

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

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

[Peter Hunkeler]

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


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.


It's embarrassing how rusty my dump reading skills have become.


--
Peter Hunkeler




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

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

[Peter Hunkeler]

>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 actively try to get their say. 
As long as I don't understand where the S0C4-11 comes from, I don't trust the 
information I see in the dumps. It's too foggy which code does what and when 
during recovery.


We're trying to repoduce the case in test so I can switch off all those little 
(sometimes useless) helpers.


--
Peter Hunkeler


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

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

[Tom Conley]

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 accessing the instruction at the PSW's NSI. The storage at this 
address is a couple of x'00', and the storage is in SP1, key 8.
If anyting was allocated but not accessible, a S0C4-4 would occur, not an 
S0C4-11.
--Peter Hunkeler




You say it's in the load module.  Did you violate reentrancy?

Regards,
Tom Conley

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

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

[Charles Mills]

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 behave the same. Someone surely knows, and
almost as surely will correct me if I am wrong.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Vernooij, CP (ITOPT1) - KLM
Sent: Friday, July 22, 2016 7:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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?
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential
and privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment may
be disclosed, copied or distributed, and that any other action related to
this e-mail or attachment is strictly prohibited, and may be unlawful. If
you have received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its
employees shall not be liable for the incorrect or incomplete transmission
of this e-mail or any attachments, nor responsible for any delay in receipt.

Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered
number 33014286



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

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

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

[Jim Mulder]

> >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  PSW16 47850400  8000    231A7BB8
> 
> Seems to match.
> 
> Unfortunately, there is no LOGREC entry in the dump for this error, 
> the system trace table has not been dumped (Grrr...), and there is 
> no SDWA in the dump. I'm lost how to find the TEA in this case.

  How about the TRNE and BEA fields in that same XSB? 

Jim Mulder z/OS Diagnosis, Design, Development, Test, etc. IBM Corp. 
Poughkeepsie, NY


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

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

[Peter Hunkeler]

>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  PSW16 47850400  8000    231A7BB8

Seems to match.

Unfortunately, there is no LOGREC entry in the dump for this error, the system 
trace table has not been dumped (Grrr...), and there is no SDWA in the dump. 
I'm lost how to find the TEA in this case.

--Peter Hunkeler


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

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

[Ed Jaffe]

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/

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

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

[Bob Rutledge]

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 been executed. The program fails 
when the CP is accessing the instruction at the PSW's NSI. The storage at this 
address is a couple of x'00', and the storage is in SP1, key 8.
If anyting was allocated but not accessible, a S0C4-4 would occur, not an 
S0C4-11.
--Peter Hunkeler


-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 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 can the storage be in the dump when the abend code suggests it is not even 
getmained (S0C4-11)? Why is this not an S0C1 (operation exception caused by 
X'' at the PSW NSI address)?


The PSW in enabled, problem state, key 8. The storage pointed to by R15 is in 
SP 1, key 8.


Any hint what I'm missing?


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

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

[Tom Marchant]

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. The program 
> fails when the CP is accessing the instruction at the PSW's NSI. The storage 
> at this address is a couple of x'00', and the storage is in SP1, key 8.

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.

-- 
Tom Marchant

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

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

[Peter Hunkeler]

 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. The storage at this 
address is a couple of x'00', and the storage is in SP1, key 8.
If anyting was allocated but not accessible, a S0C4-4 would occur, not an 
S0C4-11.
--Peter Hunkeler


-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 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 can the storage be in the dump when the abend code suggests it is not even 
getmained (S0C4-11)? Why is this not an S0C1 (operation exception caused by 
X'' at the PSW NSI address)?


The PSW in enabled, problem state, key 8. The storage pointed to by R15 is in 
SP 1, key 8.


Any hint what I'm missing?







--
Peter Hunkeler

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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


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

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

[Vernooij, CP (ITOPT1) - KLM]

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 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 can the storage be in the dump when the abend code suggests it is not even 
getmained (S0C4-11)? Why is this not an S0C1 (operation exception caused by 
X'' at the PSW NSI address)?


The PSW in enabled, problem state, key 8. The storage pointed to by R15 is in 
SP 1, key 8.


Any hint what I'm missing?







--
Peter Hunkeler

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

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

[Vernooij, CP (ITOPT1) - KLM]

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 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: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 can the storage be in the dump when the abend code suggests it is not
even getmained (S0C4-11)? Why is this not an S0C1 (operation exception
caused by X'' at the PSW NSI address)?

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

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

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

[Charles Mills]

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: IBM-MAIN@LISTSERV.UA.EDU
Subject: 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 can the storage be in the dump when the abend code suggests it is not
even getmained (S0C4-11)? Why is this not an S0C1 (operation exception
caused by X'' at the PSW NSI address)?

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

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

[Peter Hunkeler]

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 can the storage be in the dump when the abend code suggests it is not even 
getmained (S0C4-11)? Why is this not an S0C1 (operation exception caused by 
X'' at the PSW NSI address)?


The PSW in enabled, problem state, key 8. The storage pointed to by R15 is in 
SP 1, key 8.


Any hint what I'm missing?







--
Peter Hunkeler

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