Re: S00C Slip trap for any Stc

[Mark A. Brooks]

The key piece of information missing from the discussion is the abend reason 
code that would have been issued with the XCF abend code 00C.  The reason codes 
meant for customer consumption will be documented with explanations in "MVS 
System Codes" book; anything else is likely an "internal error" for which an 
XCF dump should have been produced.  Can't really say much without that reason 
code.

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

Re: S00C Slip trap for any Stc

[Elardus Engelbrecht]

Mark A. Brooks wrote:

>The key piece of information missing from the discussion is the abend reason 
>code that would have been issued with the XCF abend code 00C.  The reason 
>codes meant for customer consumption will be documented with explanations in 
>"MVS System Codes" book; anything else is likely an "internal error" for which 
>an XCF dump should have been produced.  Can't really say much without that 
>reason code.

Good catch. I had to review the whole thread to refresh my memory.

The OP should say what z/OS level is he using, what reason code is he getting 
and what actions were done at all. 
For example were there any LOGREC records, were any D XCF,??? commands done, 
etc.

Mark, you are also right about reason code, because depending on it, you may 
get two dumps, not one. Or you get only a SVC dump or only a MVS dump or only a 
LOGREC dump. 

Depending on the reason code, the OP should post the IXC??? message(s) too.

I would also advise the OP to also check "z/OS MVS Diagnosis: Reference" for 
more background info.

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: S00C Slip trap for any Stc

[Lizette Koehler]

Nathan,

It helps the list to help you when you provide the complete messages or summary 
dump.  There are subtleties based on reason codes and registers.

Since you are looking at the XCF, have you opened a SR/PMR with IBM?  They can 
probably expedite your resolution.   Since IBM has the source code, they can 
review the sections and see what is going on with your environment.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nathan Astle
> Sent: Friday, December 18, 2015 10:22 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: S00C Slip trap for any Stc
> 
> Hi Group
> 
> Basically I am trying to capture the SLIP for the XCF signal failure in our 
> base sysplex
> environment.
> 
> Our SMF logstream has been defined in IXGLOGR with dasdonly. Does that mean
> IXGLOGR will Buffer SMF records in memory if it cannot write to DASD ?
> 
> What might be happening here, is that the S00C abend affects XCF services, 
> which in
> turn effect the users of XCF which are: WLM, JES2, GRS, and MASTER. At this 
> point
> GRS becomes unresponsive, and won’t permit the ENQ of a dataset, if that 
> dataset is
> the IFASMF logstream, the records start to backup, where does IXGLOGR put 
> them.
> Would allowing IXGLOGR to use structures in the CF help prevent IXGLOGR from
> stealing real storage to buffer SYS EVENTs in the event of the S00C abend of 
> XCF?
> 
> Any suggestions ?
> 
> Regards
> Nathan

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

Re: S00C Slip trap for any Stc

[Elardus Engelbrecht]

Nathan Astle wrote:

>The 'a' is invalid in the slip trap

Please show the full error message(s) why the 'a' is invalid. Perhaps Barbara 
and your z/OS systesm are on different versions.

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: S00C Slip trap for any Stc

[Elardus Engelbrecht]

Barbara Nitz wrote:

>> Please show the full error message(s) why the 'a' is invalid. Perhaps 
>> Barbara and your z/OS systesm are on different versions.

>As I said, I did not test this for syntactical correctness. 

I know, many IBM-MAIN members post sample syntax, sometimes omitting crucial 
info for brevity, but it is up to the actual user to verify/modify the command 
and all its parameters for accuracy.

Similar with the other thread where I said, use a program, I did not say how 
the JCL + input should look like. It is up to the OP to figure that out.

>Check the manuals ...

That's it! Good homework before the weekend! ;-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: S00C Slip trap for any Stc

[nitz-ibm]

abend00C always means some problem with coupling services. If you don't know 
which connector will be hit for which structure/group, I suggest to set the 
slip trap rather generically as 

sl set,c=00c,a=(cu,h,s),dspname=('xcfas'.*),id=s00C,e

Not having tested this for correctness, the a=(cu,h,p,s) should ensure that the 
current address space along with any home or secondary address space get 
dumped. And you may want to include XCFs data spaces, and maybe other data 
spaces (depending on the problem). Just make sure that your maxspace is large 
enough, especially if you're dealing with DB2. Maxspace needs to get set 
beforehand.

Barbara

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

Re: S00C Slip trap for any Stc

[Nathan Astle]

Hi


The 'a' is invalid in the slip trap

On Friday 18 December 2015, nitz-ibm  wrote:

> abend00C always means some problem with coupling services. If you don't
> know which connector will be hit for which structure/group, I suggest to
> set the slip trap rather generically as
>
> sl set,c=00c,a=(cu,h,s),dspname=('xcfas'.*),id=s00C,e
>
> Not having tested this for correctness, the a=(cu,h,p,s) should ensure
> that the current address space along with any home or secondary address
> space get dumped. And you may want to include XCFs data spaces, and maybe
> other data spaces (depending on the problem). Just make sure that your
> maxspace is large enough, especially if you're dealing with DB2. Maxspace
> needs to get set beforehand.
>
> Barbara
>
> --
> 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: S00C Slip trap for any Stc

[nitz-ibm]

> Please show the full error message(s) why the 'a' is invalid. Perhaps Barbara 
> and your z/OS systesm are on different versions.
As I said, I did not test this for syntactical correctness. The a should stand 
for asid, and I am sure that the (cu,h,s) are correct. Check the manuals for 
what the actual filter keyword is, it may be j (for jobname to be dumped).

Barbara

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

S00C Slip trap for any Stc

[Peter Relson]

>Can I set slip trap for abend s00c for any failing Address space ?

To be unhelpful, the answer is "yes", you can set it as long as you have 
the authority to set it. The real question is whether you can set such a 
trap and have it match.

Towards the end of having it match, we'd need to ask "what do you mean by 
failing Address space?" and what filters would be needed if you wanted to 
differentiate between "failing" and "non-failing" address space. We'd also 
need to ask if your subject of "any Stc" really meant "any STC (but not a 
non-STC)" in which case a further filter would be needed.

And there is always the underlying question of did you literally mean 
"abend s00C" (as in, abend with a code of system 00C) as opposed to 
"system completion code 00C". If the completion code is achieved by the 
abend (or CALLRTM TYPE=ABTERM) macro then SLIp will match it. But in some 
cases completion codes are set (changed) by recovery routines such as by 
SETRP COMPCOD=n after the initial abend or program check. In those cases, 
you need to trap on the code for the initial entry to recovery (whatever 
that is). That is why, for example, for some POST completion codes you 
have to trap on the 0C4 that initiated the recovery processing. I don't 
know how system completion code 00C comes about (other than that it is by 
the XCF component). And the answer might vary depending on the reason 
code.

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: S00C Slip trap for any Stc

[Shane Ginnane]

On Fri, 18 Dec 2015 08:51:08 -0500, Peter Relson wrote:

>>Can I set slip trap for abend s00c for any failing Address space ?
>
>To be unhelpful, the answer is "yes"

Peter, I can not (ever) recall an unhelpful answer from you - or Jim.
Some other respondents - now, that's a whole 'nuther kettle of fish.

Shane ...

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

Re: S00C Slip trap for any Stc

[Shmuel Metz (Seymour J.)]

In
<0601332775752188.wa.elardus.engelbrechtsita.co...@listserv.ua.edu>,
on 12/18/2015
   at 03:23 AM, Elardus Engelbrecht 
said:

>I know, many IBM-MAIN members post sample syntax, sometimes 
>omitting crucial info for brevity, but it is up to the actual user 
>to verify/modify the command and all its parameters for accuracy.

And for relevance; even if the command is correct for the responders
installation it may not be quite what you need.

>Similar with the other thread where I said, use a program, I did 
>not say how the JCL + input should look like.

That's better than a lot of IBM manuals that spell out how to code JCL
and REXX, incorrectly. 

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: S00C Slip trap for any Stc

[Shmuel Metz (Seymour J.)]

In <20151218092003.952fe4e53c2ab28a6061e...@gmx.net>, on 12/18/2015
   at 09:20 AM, nitz-ibm  said:

>abend00C always means some problem with coupling services.

Shirley other programs get underflow.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: S00C Slip trap for any Stc

[Nathan Astle]

Hi Group

Basically I am trying to capture the SLIP for the XCF signal failure in our
base sysplex environment.

Our SMF logstream has been defined in IXGLOGR with dasdonly. Does that mean
IXGLOGR will Buffer SMF records in memory if it cannot write to DASD ?

What might be happening here, is that the S00C abend affects XCF services,
which in turn effect the users of XCF which are: WLM, JES2, GRS, and
MASTER. At this point GRS becomes unresponsive, and won’t permit the ENQ of
a dataset, if that dataset is the IFASMF logstream, the records start to
backup, where does IXGLOGR put them.  Would allowing IXGLOGR to use
structures in the CF help prevent IXGLOGR from stealing real storage to
buffer SYS EVENTs in the event of the S00C abend of XCF?

Any suggestions ?

Regards
Nathan



On Saturday 19 December 2015, Shmuel Metz (Seymour J.) <
shmuel+ibm-m...@patriot.net> wrote:

> In
> <0601332775752188.wa.elardus.engelbrechtsita.co...@listserv.ua.edu
> >,
> on 12/18/2015
>at 03:23 AM, Elardus Engelbrecht  >
> said:
>
> >I know, many IBM-MAIN members post sample syntax, sometimes
> >omitting crucial info for brevity, but it is up to the actual user
> >to verify/modify the command and all its parameters for accuracy.
>
> And for relevance; even if the command is correct for the responders
> installation it may not be quite what you need.
>
> >Similar with the other thread where I said, use a program, I did
> >not say how the JCL + input should look like.
>
> That's better than a lot of IBM manuals that spell out how to code JCL
> and REXX, incorrectly.
>
> --
>  Shmuel (Seymour J.) Metz, SysProg and JOAT
>  ISO position; see 
> We don't care. We don't have to care, we're Congress.
> (S877: The Shut up and Eat Your spam act of 2003)
>
> --
> 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

S00C Slip trap for any Stc

[Nathan Astle]

Hi Group

Apology for a dummy question

Can I set slip trap for abend s00c for any failing Address space ?

Nathan

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

Re: S00C Slip trap for any Stc

[Nathan Astle]

Hi

To be precise to set a slip trap irrespective of any failing address space
when we are not sure of address space which is going to fail

On Thursday 17 December 2015, Nathan Astle  wrote:

> Hi Group
>
> Apology for a dummy question
>
> Can I set slip trap for abend s00c for any failing Address space ?
>
> Nathan
>

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

Re: S00C Slip trap for any Stc

[Lizette Koehler]

Have you done any internet searches on the S00C abend?  Have you contacted the 
group/vendor that supports this STC for the S00C?  Usually if it is a Vendor 
supported product, they can provide insight on this type of error or what kind 
of Slip trap they need.

If you could post the Summary Dump from SYSLOG or JOBLOG of the STC - this list 
might be able to provide guidance.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nathan Astle
> Sent: Thursday, December 17, 2015 3:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: S00C Slip trap for any Stc
> 
> Hi Group
> 
> Apology for a dummy question
> 
> Can I set slip trap for abend s00c for any failing Address space ?
> 
> Nathan
> 

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

Re: S00C Slip trap for any Stc

[Ed Finnell]

EREP has an ABEND section that will list DUMPs created in the reporting  
interval. This can be useful in determining if it's a particular Job or common 
 pgm.
 
Might want to look at DAE to see if's kicked in for this  exception(s).
 
https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2
.ieav100/dmpdae.htm
 
 
 
In a message dated 12/17/2015 6:28:43 A.M. Central Standard Time,  
elardus.engelbre...@sita.co.za writes:

It  depends. What actions do you want the SLIP to do? Oh, please read Peter 
 Hunkeler warning about multiple triggers and filters.

What z/OS version  are you using? Do you want the SLIP for only one LPAR or 
not? Is this a  temporary SLIP or do you want to change a  IEASLPxx?


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

Re: S00C Slip trap for any Stc

[Elardus Engelbrecht]

Ed Finnell wrote:

>EREP has an ABEND section that will list DUMPs created in the reporting 
>interval. This can be useful in determining if it's a particular Job or common 
>pgm.

>Might want to look at DAE to see if's kicked in for this  exception(s).

Good catch, which should be useful to the OP. Many thanks. It is a long time 
ago I looked at that ABEND sections...

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: S00C Slip trap for any Stc

[Ed Finnell]

Some things leave scars. I had a DB/2 system with one DB that wouldn't  
start. From the time I got the buzz until I got into work. There  were several 
packs worth of DUMPs. Long story short the 1st dump told the  tale but it 
had been deleted. All the rest were restart failed. Level2 got me  
straightened out in about 15 seconds
by looking at 1st symptom Dump in EREP. What's in Reg6? Oh, you have  to 
recreate the table with original values do the extend then do the restore.  
Oh, OK...worked like a champ. 
 
 
In a message dated 12/17/2015 8:35:45 A.M. Central Standard Time,  
elardus.engelbre...@sita.co.za writes:

Good  catch, which should be useful to the OP. Many thanks. It is a long 
time ago I  looked at that ABEND  sections...


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

Re: S00C Slip trap for any Stc

[Elardus Engelbrecht]

Nathan Astle wrote:

>Can I set slip trap for abend s00c for any failing Address space ?

and 

>To be precise to set a slip trap irrespective of any failing address space 
>when we are not sure of address space which is going to fail

It depends. What actions do you want the SLIP to do? Oh, please read Peter 
Hunkeler warning about multiple triggers and filters.

What z/OS version are you using? Do you want the SLIP for only one LPAR or not? 
Is this a temporary SLIP or do you want to change a IEASLPxx?

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

AW: Re: S00C Slip trap for any Stc

[Peter Hunkeler]

SLIPs always apply for any address space initially. The filter keywords you 
set, e.g. JOBNAME, then decide if the action is to be taken for the current 
case. Beware of coding a slip without filters and ACTION other than IGONRE. The 
event your're trapping might occur during normal processing elsewhere in the 
system and trigger too many times. Make sure you always add MATCHLIM=1

--
Peter Hunkeler



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