Re: timely

[Mark Zelden]

On Mon, 13 Mar 2017 01:13:21 -0500, Elardus Engelbrecht 
 wrote:

>Paul Gilmartin wrote:
>
>>>I see what you did there
 http://www.gocomics.com/nonsequitur/2017/03/12
>
>>What did I do there?  Did it work?
>
>You posted a link to a good joke. Now I know why Stonehenge was abandoned... 
>;-D
>
>Many thanks Paul for sharing it!
>
>Groete / Greetings
>Elardus Engelbrecht
>


When I saw the 2nd frame, I thought this was going to be a reference to big 
endian thread. 

--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: timely

[Elardus Engelbrecht]

Pommier, Rex wrote:

>I think Steve was commenting on your subject line tying nicely into the comic. 
> It was quite well done.  

Indeed! Just in time before you timed out! ;-)

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

[Pommier, Rex]

I think Steve was commenting on your subject line tying nicely into the comic.  
It was quite well done.  

Rex

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Sunday, March 12, 2017 6:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: timely

On Sun, 12 Mar 2017 18:16:42 -0500, Steve Horein wrote:

>I see what you did there
>
>On Sunday, March 12, 2017, Paul Gilmartin < 
>000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>> http://www.gocomics.com/nonsequitur/2017/03/12
>>
What did I do there?  Did it work?

-- gil

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: timely

[Elardus Engelbrecht]

Paul Gilmartin wrote:

>>I see what you did there
>>> http://www.gocomics.com/nonsequitur/2017/03/12

>What did I do there?  Did it work?

You posted a link to a good joke. Now I know why Stonehenge was abandoned... ;-D

Many thanks Paul for sharing it!

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

[Paul Gilmartin]

On Sun, 12 Mar 2017 18:16:42 -0500, Steve Horein wrote:

>I see what you did there
>
>On Sunday, March 12, 2017, Paul Gilmartin <
>000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>> http://www.gocomics.com/nonsequitur/2017/03/12
>>
What did I do there?  Did it work?

-- gil

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

Re: timely

[Steve Horein]

I see what you did there

On Sunday, March 12, 2017, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> http://www.gocomics.com/nonsequitur/2017/03/12
>
> -- gil
>

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

timely

[Paul Gilmartin]

http://www.gocomics.com/nonsequitur/2017/03/12

-- gil

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

Re: Getting timely dump out of LE

[Bill Hitefield]

Have you tried the TRAP(OFF) parameter on the step? That usually works for me. 
You lose the LE formatted dump, but you do get the "standard" dump.

Bill Hitefield
Dino-Software Corporation
800.480.DINO
423.878.5660
www.dino-software.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Anthony Thompson
Sent: Wednesday, May 25, 2016 11:17 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Getting timely dump out of LE

I was wondering if you looked in LOGREC to see if that recorded the first S0C4.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Don Poitras
Sent: Wednesday, 25 May 2016 8:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Getting timely dump out of LE

I wouldn't think that more than one of the 0C4's in the system trace would 
match the PSW in the MCH control block. You can display time in the system 
trace by doing 'ip systrace time(local)'. For the wrapping issue... some 
version of z/OS allowed the system trace table size to be set much higher. I 
recently asked our guys to bump up to 12M and that seems to be working for now.

In article <2013103444541247.wa.ronmacraehotmail.co...@listserv.ua.edu> you 
wrote:
> Lizette,
>I can get the registers and PSW no problem.  The problem I have is 
> getting the TIME of the S0C4 so I can see which one is first.  So much 
> happens before LE gets round to taking a system dump that the z/OS trace has 
> wrapped and I can't tell which of the 6 S0C4 abends, on different TCBs, was 
> first. I don't think I can assume that the first to produce a CEE dump or the 
> first to produce a SYSMDUMP was the first as they seem to preempt each other.

> Anyway I got round the problem by slipping on the instruction that sets us up 
> to fail by setting a control block pointer to zero before any of the TCBs 
> S0C4ed.

> However it would have been nice to be able to tell the time of the S0C4s.

> Ron.

--
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

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

Re: Getting timely dump out of LE

[Anthony Thompson]

I was wondering if you looked in LOGREC to see if that recorded the first S0C4.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Don Poitras
Sent: Wednesday, 25 May 2016 8:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Getting timely dump out of LE

I wouldn't think that more than one of the 0C4's in the system trace would 
match the PSW in the MCH control block. You can display time in the system 
trace by doing 'ip systrace time(local)'. For the wrapping issue... some 
version of z/OS allowed the system trace table size to be set much higher. I 
recently asked our guys to bump up to 12M and that seems to be working for now.

In article <2013103444541247.wa.ronmacraehotmail.co...@listserv.ua.edu> you 
wrote:
> Lizette,
>I can get the registers and PSW no problem.  The problem I have is 
> getting the TIME of the S0C4 so I can see which one is first.  So much 
> happens before LE gets round to taking a system dump that the z/OS trace has 
> wrapped and I can't tell which of the 6 S0C4 abends, on different TCBs, was 
> first. I don't think I can assume that the first to produce a CEE dump or the 
> first to produce a SYSMDUMP was the first as they seem to preempt each other.

> Anyway I got round the problem by slipping on the instruction that sets us up 
> to fail by setting a control block pointer to zero before any of the TCBs 
> S0C4ed.

> However it would have been nice to be able to tell the time of the S0C4s.

> Ron.

--
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

--
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: Getting timely dump out of LE

[Don Poitras]

I wouldn't think that more than one of the 0C4's in the system trace
would match the PSW in the MCH control block. You can display time
in the system trace by doing 'ip systrace time(local)'. For the wrapping
issue... some version of z/OS allowed the system trace table size
to be set much higher. I recently asked our guys to bump up to 12M
and that seems to be working for now.

In article <2013103444541247.wa.ronmacraehotmail.co...@listserv.ua.edu> you 
wrote:
> Lizette,
>I can get the registers and PSW no problem.  The problem I have is 
> getting the TIME of the S0C4 so I can see which one is first.  So much 
> happens before LE gets round to taking a system dump that the z/OS trace has 
> wrapped and I can't tell which of the 6 S0C4 abends, on different TCBs, was 
> first. I don't think I can assume that the first to produce a CEE dump or the 
> first to produce a SYSMDUMP was the first as they seem to preempt each other.

> Anyway I got round the problem by slipping on the instruction that sets us up 
> to fail by setting a control block pointer to zero before any of the TCBs 
> S0C4ed.

> However it would have been nice to be able to tell the time of the S0C4s.

> Ron.

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: Getting timely dump out of LE

[Martin Packer]

Clutching at straws here...

... Do control blocks related to the incident get created either from top 
of storage downwards or from bottom of storage upwards? (With other stuff 
interspersed no doubt.)

Like I said, clutching at straws. :-(

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Cloud & Systems Performance, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): 
https://developer.ibm.com/tv/category/mpt/



From:   Ron MacRae <ronmac...@hotmail.co.uk>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   25/05/2016 09:27
Subject:Re: Getting timely dump out of LE
Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>



Lizette,
   I can get the registers and PSW no problem.  The problem I have 
is getting the TIME of the S0C4 so I can see which one is first.  So much 
happens before LE gets round to taking a system dump that the z/OS trace 
has wrapped and I can't tell which of the 6 S0C4 abends, on different 
TCBs, was first. I don't think I can assume that the first to produce a 
CEE dump or the first to produce a SYSMDUMP was the first as they seem to 
preempt each other.

Anyway I got round the problem by slipping on the instruction that sets us 
up to fail by setting a control block pointer to zero before any of the 
TCBs S0C4ed.

However it would have been nice to be able to tell the time of the S0C4s.

Ron.

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



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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

Re: Getting timely dump out of LE

[Ron MacRae]

Lizette,
   I can get the registers and PSW no problem.  The problem I have is 
getting the TIME of the S0C4 so I can see which one is first.  So much happens 
before LE gets round to taking a system dump that the z/OS trace has wrapped 
and I can't tell which of the 6 S0C4 abends, on different TCBs, was first. I 
don't think I can assume that the first to produce a CEE dump or the first to 
produce a SYSMDUMP was the first as they seem to preempt each other.

Anyway I got round the problem by slipping on the instruction that sets us up 
to fail by setting a control block pointer to zero before any of the TCBs 
S0C4ed.

However it would have been nice to be able to tell the time of the S0C4s.

Ron.

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

Re: Getting timely dump out of LE

[Lizette Koehler]

I am actually thinking of the CAA DSA sub parms

II11016: HOW TO FIND PSW AND REGS AT TIME OF ERROR WITH LE

In most cases LE condition handling will trap original program checks (like 
ABEND0C4) and turn them into corresponding LE conditions (like CEE3204S). After 
storing information about the original program check, LE will terminate with an 
ABENDU40xx. When examining a dump of a U40xx, the PSW and Registers can be 
found in a control   block called the ZMCH. This will assist in identifying the 
failing module, offset within that module, and the register contents at the 
time of the error.

An oldie, but I still use it
http://www-03.ibm.com/systems/resources/servers_eserver_zseries_zos_le_conference_pdf_swa8208.pdf

And this 
http://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieac500/vble.htm?lang=en

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ron MacRae
> Sent: Wednesday, May 11, 2016 6:39 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Getting timely dump out of LE
> 
> Lizette,
>I'm familiar with "ip verbx ledata 'all,tcb(tt)' " If that's
> the one you mean. The trace in the SYSMDUMP starts almost a minute after the
> initial bunch of S0C4s but none of them are in the z/OS trace any more so I
> can't tell which is first.
> 
> Ron.
> 

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

Re: Getting timely dump out of LE

[Ron MacRae]

Robin,
 Production support won't run with TRAP(OFF) because of the warnings in 
the manual about unpredictable results if some conditions are not handled.

I think I'll do an IF slip trap when we load the register with zero.  
This is about a dozen instructions before the S0C4 trying to store into the 
PSA. 
It will be a bit of overhead, especially if it takes a while to fire, but I 
can't think of anything better.

Ron.

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

Re: Getting timely dump out of LE

[Ron MacRae]

Lizette,
   I'm familiar with "ip verbx ledata 'all,tcb(tt)' " If that's the 
one you mean. The trace in the SYSMDUMP starts almost a minute after the 
initial bunch of S0C4s but none of them are in the z/OS trace any more so I 
can't tell which is first.

Ron.

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

Re: Getting timely dump out of LE

[Robin Atwood]

I too have a large C and ASM LE application and I use TRAP(OFF,NOSPIE). That 
gets you an immediate dump on the first 0C4 and then you can use the IPCS 
command VERBX LEDATA 'TCB() CEEDUMP' to get the LE trace-back, which is 
useful if the abend was in C code.

Robin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: 05 May 2016 23:38
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Getting timely dump out of LE

Have you use IPCS with the LE VERBX function?

LE normally will have a handle routine that will capture the true abend and 
stuff it into storage before it allows the dump processing to continue.  I am 
not sure if this particular event will do that, but it might.

Otherwise I would open an SR To LE support and have them assist in debugging 
this.  It might be something they have not handled before.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Ron MacRae
> Sent: Thursday, May 05, 2016 9:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Getting timely dump out of LE
> 
> Hi all,
>  I've got a multi-tasking C & ASM LE application running 100+ TCBs.
> Occasionally I get an S0C4 abend, which quickly cascades into multiple 
> S0C4 abends.  By the time LE gets round to taking a SYSMDUMP the MVS 
> trace has wrapped and I can't determine what is the first S0C4. I end 
> up with multiple CEEDUMPs and SYSMDUMPs which don't all match up. The 
> first SYSMDUMP is produced 2 minutes after the first CEEDUMP starts 
> and the LE ZMCH data in the first SYSMDUMP doesn't match the Machine 
> State data in any of the CEEDUMPs so I'm confused.
> 
> I want a dump immediatly an S0C4 happens and before LE gets in the way 
> and spends several minutes generating CEEDUMPs with only partial information.
> From the CEEDUMP I can't tell which TCB is failing or the exact time 
> of the
> S0C4 to work out which was first.
> 
> I've had a look in the archives and found several options, which I 
> don't like or I don't think will work.
> 
> 1) I can't use a SLIP trap as there are phantom S0C4 abends that get 
> captured and resolved by the OS.
> 
> 2) I'm reluctant to use TERMTHDACT=(UAIMM),TRAP=(OFF,NOSPIE) as the 
> manual says that results of TRAP=OFF are "unpredictable" and this is a 
> large long running production application.
> 
> 3) ABPERC(S0C4) won't work as the doc says S0CX abends are ignored.
> 
> I'm thinking TERMTHDACT=(UAIMM) on it's own might be the best bet to 
> get an early SYSMDUMP showing the S0C4 in the trace. Would I get dumps 
> for other things that LE might normally be able to deal with?
> 
> Any other options?
> 
> Thanks, Ron.

--
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: Getting timely dump out of LE

[Lizette Koehler]

Have you use IPCS with the LE VERBX function?

LE normally will have a handle routine that will capture the true abend and 
stuff it into storage before it allows the dump processing to continue.  I am 
not sure if this particular event will do that, but it might.

Otherwise I would open an SR To LE support and have them assist in debugging 
this.  It might be something they have not handled before.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Ron MacRae
> Sent: Thursday, May 05, 2016 9:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Getting timely dump out of LE
> 
> Hi all,
>  I've got a multi-tasking C & ASM LE application running 100+ TCBs.
> Occasionally I get an S0C4 abend, which quickly cascades into multiple S0C4
> abends.  By the time LE gets round to taking a SYSMDUMP the MVS trace has
> wrapped and I can't determine what is the first S0C4. I end up with multiple
> CEEDUMPs and SYSMDUMPs which don't all match up. The first SYSMDUMP is
> produced 2 minutes after the first CEEDUMP starts and the LE ZMCH data in the
> first SYSMDUMP doesn't match the Machine State data in any of the CEEDUMPs so
> I'm confused.
> 
> I want a dump immediatly an S0C4 happens and before LE gets in the way and
> spends several minutes generating CEEDUMPs with only partial information.
> From the CEEDUMP I can't tell which TCB is failing or the exact time of the
> S0C4 to work out which was first.
> 
> I've had a look in the archives and found several options, which I don't like
> or I don't think will work.
> 
> 1) I can't use a SLIP trap as there are phantom S0C4 abends that get captured
> and resolved by the OS.
> 
> 2) I'm reluctant to use TERMTHDACT=(UAIMM),TRAP=(OFF,NOSPIE) as the manual
> says that results of TRAP=OFF are "unpredictable" and this is a large long
> running production application.
> 
> 3) ABPERC(S0C4) won't work as the doc says S0CX abends are ignored.
> 
> I'm thinking TERMTHDACT=(UAIMM) on it's own might be the best bet to get an
> early SYSMDUMP showing the S0C4 in the trace. Would I get dumps for other
> things that LE might normally be able to deal with?
> 
> Any other options?
> 
> Thanks, Ron.

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

Getting timely dump out of LE

[Ron MacRae]

Hi all,
 I've got a multi-tasking C & ASM LE application running 100+ TCBs.  
Occasionally I get an S0C4 abend, which quickly cascades into multiple S0C4 
abends.  By the time LE gets round to taking a SYSMDUMP the MVS trace has 
wrapped and I can't determine what is the first S0C4. I end up with multiple 
CEEDUMPs and SYSMDUMPs which don't all match up. The first SYSMDUMP is produced 
2 minutes after the first CEEDUMP starts and the LE ZMCH data in the first 
SYSMDUMP doesn't match the Machine State data in any of the CEEDUMPs so I'm 
confused.

I want a dump immediatly an S0C4 happens and before LE gets in the way and 
spends several minutes generating CEEDUMPs with only partial information.  From 
the CEEDUMP I can't tell which TCB is failing or the exact time of the S0C4 to 
work out which was first.

I've had a look in the archives and found several options, which I don't like 
or I don't think will work.

1) I can't use a SLIP trap as there are phantom S0C4 abends that get captured 
and resolved by the OS.

2) I'm reluctant to use TERMTHDACT=(UAIMM),TRAP=(OFF,NOSPIE) as the manual says 
that results of TRAP=OFF are "unpredictable" and this is a large long running 
production application.

3) ABPERC(S0C4) won't work as the doc says S0CX abends are ignored.

I'm thinking TERMTHDACT=(UAIMM) on it's own might be the best bet to get an 
early SYSMDUMP showing the S0C4 in the trace. Would I get dumps for other 
things that LE might normally be able to deal with?

Any other options?

Thanks, Ron.

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