Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Thomas David Rivers

Binyamin Dissen wrote:

What advantage do you see in an ESPIE over an ESTAE? 


IIRC, there are quite a few conditions where it doesn't get control. And no
clean way to percolate.



 


Mostly - catching an error (bad memory reference) in an ESTAE exit...

   - Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

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


Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Peter Relson
I'd say that no one should use ESPIE unless they have a valid performance 
reason to do so. 


And no clean way to percolate.

As of z/OS 1.12 there is:  you can set EPIEPERC

(E)STAI is the only recovery mechanism that comes to mind that applies to 
other work unit(s).

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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread David Crayford
In that case why does LE use ESPIE in condition handling?

> On 2 Apr 2020, at 9:53 pm, Peter Relson  wrote:
> 
> I'd say that no one should use ESPIE unless they have a valid performance 
> reason to do so. 
> 
> 
> And no clean way to percolate.
> 
> As of z/OS 1.12 there is:  you can set EPIEPERC
> 
> (E)STAI is the only recovery mechanism that comes to mind that applies to 
> other work unit(s).
> 
> 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

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


Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Seymour J Metz
One obvious use is to detect conditions for which there is an active ON unit. 
It's much easier with (E)SPIE.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
David Crayford 
Sent: Thursday, April 2, 2020 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

In that case why does LE use ESPIE in condition handling?

> On 2 Apr 2020, at 9:53 pm, Peter Relson  wrote:
>
> I'd say that no one should use ESPIE unless they have a valid performance
> reason to do so.
>
> 
> And no clean way to percolate.
> 
> As of z/OS 1.12 there is:  you can set EPIEPERC
>
> (E)STAI is the only recovery mechanism that comes to mind that applies to
> other work unit(s).
>
> 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

--
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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Charles Mills
Because Peter didn't write LE? 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of David Crayford
Sent: Thursday, April 2, 2020 8:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

In that case why does LE use ESPIE in condition handling?

> On 2 Apr 2020, at 9:53 pm, Peter Relson  wrote:
> 
> I'd say that no one should use ESPIE unless they have a valid performance 
> reason to do so. 
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


Important Update - Next meeting of the GSE UK Security Working Group

2020-04-02 Thread Mark Wilson
Greetings,

Last month we announced that the next meeting of the GSE UK Security Working 
Group, will take place on Thursday 11th June 2020, at the offices of RSM 
Partners in Bromsgrove, UK. Due to the current situation with COVID-19, we have 
taken the decision to convert the meeting to online only – the meeting will be 
hosted via Webex from 9am to 5pm (BST) on the date above.

We are still looking for presenters so If you would like to give a presentation 
at the meeting, please send us a presentation title and abstract – we offer 
sessions from 30 minutes to 1 hour.

The agenda, along with registration details will be published over the coming 
weeks. In the meantime, please stay tuned to your mailbox or our website 
(https://www.gse.org.uk/working-group/enterprise-security/) for updates.

Stay safe and well!


Regards

Mark Wilson and Jamie Pease

Jamie Pease CISA, CISM, CISSP, MBCS CITP

Chairman of the GSE UK Security Working Group

Website: www.racf.gse.org.uk
Email: jamie.pe...@gse.org.uk
Mobile: +44(0)7961 971938




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


Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Gord Tomlin

On 2020-04-02 11:03, David Crayford wrote:

In that case why does LE use ESPIE in condition handling?


An irreverent take would be that they enjoy obfuscating abends by 
transforming program checks into U4xxx abends.


The ESPIE can be eliminated using TRAP=(ON,NOSPIE), and we have not seen 
any adverse effects upon LE recovery from running that way.


--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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


Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Charles Mills
I had the same observation. Sending every condition through the same handler 
was advantageous for me.

You would want to keep the SPIE if program checks were expected: perhaps a 
report generator where you anticipated that users might declare fields to be 
packed when they were not always valid.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gord Tomlin
Sent: Thursday, April 2, 2020 10:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

On 2020-04-02 11:03, David Crayford wrote:
> In that case why does LE use ESPIE in condition handling?

An irreverent take would be that they enjoy obfuscating abends by 
transforming program checks into U4xxx abends.

The ESPIE can be eliminated using TRAP=(ON,NOSPIE), and we have not seen 
any adverse effects upon LE recovery from running that way.

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


Copy NON-SMS ZFS file to a pre-allocated SMS

2020-04-02 Thread Kenneth J. Kripke
I am posting this question to the group on behalf of a colleague who does
not have access to IBM-MAIN 

He is attempting to copy a ZFS file from a NON-SMS managed volume to a
pre-allocated and formatted SMS managed FILE.  

He has attempted to use the DFDSS COPY function, and, he does have Storage
Admin authority, but, his copy fails.  

What settings need to be set and what tools should be used to perform this
sort of task? 

 

k.kri...@comcast.net   


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


Re: Copy NON-SMS ZFS file to a pre-allocated SMS

2020-04-02 Thread Edgington, Jerry
You could setup a batch job:
- Allocate the new SMS zFS
- Mount the new SMS zFS
- Use PAX command to copy zFS
- Unmount new and old zFS


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kenneth J. Kripke
Sent: Thursday, April 2, 2020 2:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Copy NON-SMS ZFS file to a pre-allocated SMS

This message was sent from an external source outside of Western & Southern's 
network. Do not click links or open attachments unless you recognize the sender 
and know the contents are safe.


I am posting this question to the group on behalf of a colleague who does not 
have access to IBM-MAIN 

He is attempting to copy a ZFS file from a NON-SMS managed volume to a 
pre-allocated and formatted SMS managed FILE.  

He has attempted to use the DFDSS COPY function, and, he does have Storage 
Admin authority, but, his copy fails.  

What settings need to be set and what tools should be used to perform this sort 
of task? 

 

k.kri...@comcast.net   


--
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: Copy NON-SMS ZFS file to a pre-allocated SMS

2020-04-02 Thread Michael Brennan
There is no need to preallocate and format the new ZFS target data set.  Just 
do a copy with the RENAMEU option.  Below is an example.  In this example SYS1 
high level is not SMS managed.  SYS2 high level is SMS managed in this example:


//S3  EXEC PGM=ADRDSSU

//SYSPRINT DD SYSOUT=*

//SYSINDD *

 COPYDATASET(INCLUDE( -

   SYS1.ZFS.R23.OSPR01.SIZUUSRD.**)) -

 ALLDATA(*) -

 ALLEXCP -

 CANCELERROR -

 CATALOG -

 TGTALLOC(SOURCE) -

 WAIT(2,2) -

 RENAMEU((SYS1.ZFS.R23.OSPR01.**,SYS2.ZFS.R23.OSPR01.**))

//

Michael




From: IBM Mainframe Discussion List  on behalf of 
Kenneth J. Kripke 
Sent: Thursday, April 2, 2020 1:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Copy NON-SMS ZFS file to a pre-allocated SMS

[CAUTION: This Email is from outside the Organization. Do not click links or 
open attachments unless you trust the sender.]

I am posting this question to the group on behalf of a colleague who does
not have access to IBM-MAIN

He is attempting to copy a ZFS file from a NON-SMS managed volume to a
pre-allocated and formatted SMS managed FILE.

He has attempted to use the DFDSS COPY function, and, he does have Storage
Admin authority, but, his copy fails.

What settings need to be set and what tools should be used to perform this
sort of task?



k.kri...@comcast.net 


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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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


Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Gord Tomlin

On 2020-04-02 14:14, Charles Mills wrote:

I had the same observation. Sending every condition through the same handler 
was advantageous for me.


Same here.



You would want to keep the SPIE if program checks were expected: perhaps a 
report generator where you anticipated that users might declare fields to be 
packed when they were not always valid.


You can also recover program checks from ESTAE(X).
"You would want" -> "You might want".

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

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


Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Charles Mills
As Peter seems to imply, ESPIE interrupts are apparently noticeably lower 
overhead than ESTAE interrupts. If data or addressing exceptions were expected 
I definitely *would* use ESPIE. I would save ESTAE for unexpected (well, 
expected unexpected) conditions. My opinion: no benchmarks, no source code.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gord Tomlin
Sent: Thursday, April 2, 2020 12:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

On 2020-04-02 14:14, Charles Mills wrote:
> I had the same observation. Sending every condition through the same handler 
> was advantageous for me.

Same here.

> 
> You would want to keep the SPIE if program checks were expected: perhaps a 
> report generator where you anticipated that users might declare fields to be 
> packed when they were not always valid.

You can also recover program checks from ESTAE(X).
"You would want" -> "You might want".

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

--
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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Mike Shaw

On 4/2/2020 1:56 PM, Gord Tomlin wrote:


An irreverent take would be that they enjoy obfuscating abends by 
transforming program checks into U4xxx abends.




Good one Gord. I always wondered why LE did that. It makes_no_sense to me.

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd

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


Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Lennie Dymoke-Bradshaw
I think the reason that handling interrupts in ESPIE is faster than ESTAE is 
simply that ESPIE sets an exit to the FLIH, whereas ESTAE sets an exit to the 
SLIH.

Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
Web:  www.rsmpartners.com
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Charles Mills
Sent: 02 April 2020 20:59
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

As Peter seems to imply, ESPIE interrupts are apparently noticeably lower 
overhead than ESTAE interrupts. If data or addressing exceptions were expected 
I definitely *would* use ESPIE. I would save ESTAE for unexpected (well, 
expected unexpected) conditions. My opinion: no benchmarks, no source code.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gord Tomlin
Sent: Thursday, April 2, 2020 12:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

On 2020-04-02 14:14, Charles Mills wrote:
> I had the same observation. Sending every condition through the same handler 
> was advantageous for me.

Same here.

> 
> You would want to keep the SPIE if program checks were expected: perhaps a 
> report generator where you anticipated that users might declare fields to be 
> packed when they were not always valid.

You can also recover program checks from ESTAE(X).
"You would want" -> "You might want".

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: https://actionsoftware.com/support/

--
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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Binyamin Dissen
On Thu, 2 Apr 2020 17:28:05 -0400 Mike Shaw  wrote:

:>On 4/2/2020 1:56 PM, Gord Tomlin wrote:
:>

:>> An irreverent take would be that they enjoy obfuscating abends by 
:>> transforming program checks into U4xxx abends.

:>

:>Good one Gord. I always wondered why LE did that. It makes_no_sense to me.

Much worse when they attempt to percolate via

   ABEND  X'0C?',DUMP,,,SYSTEM

and it takes a while until I see that it is a fake abend.

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


Sometime

2020-04-02 Thread Steve Beaver
Sometime back I asked for recommendations for a small USB3 switch such that
I would not keep moving my dongle from my laptop to my tower and back.

Will the one I bought from Amazon arrived and it is self-powered courtesy of
The 2 USB A-A cables that came with it.

Now I just push a button on the HUG and it works like a champ
 

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


Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Seymour J Metz
That insanity dates all the way back to the Fortran runtime in OS/360. It used 
to make ABEND-AID output useless.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Mike Shaw 
Sent: Thursday, April 2, 2020 5:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

On 4/2/2020 1:56 PM, Gord Tomlin wrote:


> An irreverent take would be that they enjoy obfuscating abends by
> transforming program checks into U4xxx abends.



Good one Gord. I always wondered why LE did that. It makes_no_sense to me.

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd

--
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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Seymour J Metz
Of course dispatching a SPIE exit from the Program SLIH is less  overhead than 
calling ABTERM schedule ABEND, processing the ABEND and dispatching an 
(E)STA(E|I).


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Thursday, April 2, 2020 3:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

As Peter seems to imply, ESPIE interrupts are apparently noticeably lower 
overhead than ESTAE interrupts. If data or addressing exceptions were expected 
I definitely *would* use ESPIE. I would save ESTAE for unexpected (well, 
expected unexpected) conditions. My opinion: no benchmarks, no source code.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Gord Tomlin
Sent: Thursday, April 2, 2020 12:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

On 2020-04-02 14:14, Charles Mills wrote:
> I had the same observation. Sending every condition through the same handler 
> was advantageous for me.

Same here.

>
> You would want to keep the SPIE if program checks were expected: perhaps a 
> report generator where you anticipated that users might declare fields to be 
> packed when they were not always valid.

You can also recover program checks from ESTAE(X).
"You would want" -> "You might want".

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: 
https://secure-web.cisco.com/1dQ8bhXNpmvLa4NVcjmC2fB982Tui0X9JlHunCUBPv_aClibXfM6TLhPQP2WT5DcrTnQBpFc0RhGwxsaeDIpogh-Km5NukF3RJomWV60Bm0ZyCEwb8CbrnxZO2x6bpAn2IQV8S6w2Iw9_BBrpXVA80_V-Kt6hkUQbW-W0xsDYQTce0UBQV6ca459Hsl_V_LPlgAdwkyjMV6TMsAVD9lG1uVOfZOUBKoYEW_RzD6u2LObCFzRRPVd1V7Bo_M8SqE9czxV3GfpcwXX_vgio5vhQ03-IITFjOQ2ZFrrL1Hxosb4PreDIA5uDdPSQnVIn6BBvVnYdrAkLPaSRVe5LbKgF-etZhF-b2Cm3Zd42Q_5ZdF0HINGKX-2Tq0VgdbVzQgQ4XlZJ8W6j927m5XSfpo9acR5CpuqNwMDwzqOBUae9IMGvB_SZn9HHL0NGg73ZtFlL/https%3A%2F%2Factionsoftware.com%2Fsupport%2F

--
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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Seymour J Metz
Having a SPIE exit doesn't require them to mangle the dump.  They do that pour 
le sport.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Gord Tomlin 
Sent: Thursday, April 2, 2020 1:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

On 2020-04-02 11:03, David Crayford wrote:
> In that case why does LE use ESPIE in condition handling?

An irreverent take would be that they enjoy obfuscating abends by
transforming program checks into U4xxx abends.

The ESPIE can be eliminated using TRAP=(ON,NOSPIE), and we have not seen
any adverse effects upon LE recovery from running that way.

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507
Support: 
https://secure-web.cisco.com/1bIa5wBBg20RuLBWAzomV6eVKZcIkoQWycYrgdnCR8mBQ4GGfUKutxVeuc4NaxxmNPwdtjOdDWzJVkJqVq5mPYbfZJw8NIibHb_4IbTY_1d6yJ8FKwbDV2zgEVFPF3F4so3CXC44N7ROxcYVBMLgbkoMWWFYeerYLcHGYVOdZURH7CkuOrvdcAie2FlintY_ilGOEHUUSPAg7P4u6PQWA2UtkL93OPKTIGIJr1SLU2ApU1w4etL9i08KN9RV7Mny1nrJFipj7eptoGUZGJUscn758z5YWCIwwKJ25MS7eiwDznRubwTqvLpy04mK5D4cn8QA2vOTSxXnqNE4-KjXIthbyYhd5bMphXrNFwdUGkrqyPdBeszJcPIIzqyWJ-4AjAgETg7mwjJMBaE_ozCwLPUk2dgPhPHyJkD5AeAjRH_NFYm-otdYLcK2VaTBgdNmA/https%3A%2F%2Factionsoftware.com%2Fsupport%2F

--
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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Jim Mulder
 These are my results from a benchmark I did 4 years ago:

Testcases which loop  recovering/retrying from an 
operation exception.
Using default system trace size - 1MB per CPU,  with 
20 CPUs, so 20MB of data to snap)
z13 machine

RecoveryIterations  CPU seconds  Ratio
--  ---  -
ESPIE   x'20'  3.531.0
FRR x'20' 45.66   12.9
ESTAEX (no SNAPTRC) x' 2' 98.95   28.0
ESTAEX (SNAPTRC)x'  1000'102.83   14,914.7


Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY
(845) 435-4741
D10JHM1@PLPSC  (MVS)   JMULDER@S390VM  (VM)

> From: "Lennie Dymoke-Bradshaw" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 04/02/2020 08:13 PM
> Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
> Sent by: "IBM Mainframe Discussion List" 
> 
> I think the reason that handling interrupts in ESPIE is faster than 
> ESTAE is simply that ESPIE sets an exit to the FLIH, whereas ESTAE 
> sets an exit to the SLIH.
> 
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd  
> Web:  www.rsmpartners.com
> ‘Dance like no one is watching. Encrypt like everyone is.’
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Charles Mills
> Sent: 02 April 2020 20:59
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd 
sub-tasks)
> 
> As Peter seems to imply, ESPIE interrupts are apparently noticeably 
> lower overhead than ESTAE interrupts. If data or addressing 
> exceptions were expected I definitely *would* use ESPIE. I would 
> save ESTAE for unexpected (well, expected unexpected) conditions. My
> opinion: no benchmarks, no source code.
> 
> Charles



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


Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Jim Mulder
 I meant to also mention that ESPIE requires an SRB 
dispatch and and 2 TCB dispatches for each iteration, 
so there is uncaptured dispatcher time to consider 
when comparing performance.


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

> 
>  These are my results from a benchmark I did 4 years ago:
> 
> Testcases which loop  recovering/retrying from an
> operation exception.
> Using default system trace size - 1MB per CPU,  with
> 20 CPUs, so 20MB of data to snap)
> z13 machine
> 
> RecoveryIterations  CPU seconds  Ratio
> --  ---  -
> ESPIE   x'20'  3.531.0
> FRR x'20' 45.66   12.9
> ESTAEX (no SNAPTRC) x' 2' 98.95   28.0
> ESTAEX (SNAPTRC)x'  1000'102.83   14,914.7



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


Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Seymour J Metz
What's the timing on ARR?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of Jim 
Mulder 
Sent: Thursday, April 2, 2020 8:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

 These are my results from a benchmark I did 4 years ago:

Testcases which loop  recovering/retrying from an
operation exception.
Using default system trace size - 1MB per CPU,  with
20 CPUs, so 20MB of data to snap)
z13 machine

RecoveryIterations  CPU seconds  Ratio
--  ---  -
ESPIE   x'20'  3.531.0
FRR x'20' 45.66   12.9
ESTAEX (no SNAPTRC) x' 2' 98.95   28.0
ESTAEX (SNAPTRC)x'  1000'102.83   14,914.7


Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
Poughkeepsie NY
(845) 435-4741
D10JHM1@PLPSC  (MVS)   JMULDER@S390VM  (VM)

> From: "Lennie Dymoke-Bradshaw" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 04/02/2020 08:13 PM
> Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
> Sent by: "IBM Mainframe Discussion List" 
>
> I think the reason that handling interrupts in ESPIE is faster than
> ESTAE is simply that ESPIE sets an exit to the FLIH, whereas ESTAE
> sets an exit to the SLIH.
>
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
> Web:  
> http://secure-web.cisco.com/14zIVesGm0rwFithty33lbnIE3Scbd3DRMIpuywMf4rb2a2nixu-0JGkumv6EwxHI0zp_uFI9IoHhsUJIko1X3bWcGlsX1l7WeRGXPHUcjoz8IMmG2xonI19xycCnUkPdFGfBV-xJG6rGG2rSWvjBd3VtkYrb19Q4HFaMRr_amD_P9iA6ERmLecY-5qnCrai05W7nEfFTrjho-twyYM5Vv6EQ0f27Qe0_yOcRgqDGCiMDNWe3qSzmuH44hdTaV5vmW1ArAX25swG4LZP6dGV9Asqe1xE8mJPqoZriCy21EbqSbomQlDjLtyzCq_WnbDu1n-PhqGKo_H_4YR9vSI4WfMbti79f7Rcxw8Hk3fXJ2riMSL1DM8T-g5KXXA7h9PxqJAZthsXJz1atRR1d67_9_hdSDX9t0yOrF7cpZoneheUAlK4XbzwSv07YwlmFZwLl/http%3A%2F%2Fwww.rsmpartners.com
> ‘Dance like no one is watching. Encrypt like everyone is.’
>
> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Charles Mills
> Sent: 02 April 2020 20:59
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd
sub-tasks)
>
> As Peter seems to imply, ESPIE interrupts are apparently noticeably
> lower overhead than ESTAE interrupts. If data or addressing
> exceptions were expected I definitely *would* use ESPIE. I would
> save ESTAE for unexpected (well, expected unexpected) conditions. My
> opinion: no benchmarks, no source code.
>
> Charles



--
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: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread Jim Mulder
 ARR, ESTAE, and ESTAEX are all RTM2, so recovering from an event 
and retrying are pretty much the same processing.
 
 Establishing and deleting an ARR  is considerably 
faster than establishing and deleting an ESTAE or ESTAEX. 

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

> What's the timing on ARR?
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> From: IBM Mainframe Discussion List  on 
> behalf of Jim Mulder 
> Sent: Thursday, April 2, 2020 8:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
>  These are my results from a benchmark I did 4 years ago:
> Testcases which loop  recovering/retrying from an
> operation exception.
> Using default system trace size - 1MB per CPU,  with
> 20 CPUs, so 20MB of data to snap)
> z13 machine
> RecoveryIterations  CPU seconds  Ratio
> --  ---  -
> ESPIE   x'20'  3.531.0
> FRR x'20' 45.66   12.9
> ESTAEX (no SNAPTRC) x' 2' 98.95   28.0
> ESTAEX (SNAPTRC)x'  1000'102.83   14,914.7
> Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp.
> Poughkeepsie NY
> (845) 435-4741
> D10JHM1@PLPSC  (MVS)   JMULDER@S390VM  (VM)
> > From: "Lennie Dymoke-Bradshaw" 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 04/02/2020 08:13 PM
> > Subject: Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)
> > Sent by: "IBM Mainframe Discussion List" 
> >
> > I think the reason that handling interrupts in ESPIE is faster than
> > ESTAE is simply that ESPIE sets an exit to the FLIH, whereas ESTAE
> > sets an exit to the SLIH.
> >
> > Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
> > Web:  http://secure-web.cisco.com/
> 
14zIVesGm0rwFithty33lbnIE3Scbd3DRMIpuywMf4rb2a2nixu-0JGkumv6EwxHI0zp_uFI9IoHhsUJIko1X3bWcGlsX1l7WeRGXPHUcjoz8IMmG2xonI19xycCnUkPdFGfBV-
> xJG6rGG2rSWvjBd3VtkYrb19Q4HFaMRr_amD_P9iA6ERmLecY-5qnCrai05W7nEfFTrjho-
> 
twyYM5Vv6EQ0f27Qe0_yOcRgqDGCiMDNWe3qSzmuH44hdTaV5vmW1ArAX25swG4LZP6dGV9Asqe1xE8mJPqoZriCy21EbqSbomQlDjLtyzCq_WnbDu1n-
> PhqGKo_H_4YR9vSI4WfMbti79f7Rcxw8Hk3fXJ2riMSL1DM8T-
> 
g5KXXA7h9PxqJAZthsXJz1atRR1d67_9_hdSDX9t0yOrF7cpZoneheUAlK4XbzwSv07YwlmFZwLl/
> http%3A%2F%2Fwww.rsmpartners.com
> > Dance like no one is watching. Encrypt like everyone is.
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Charles Mills
> > Sent: 02 April 2020 20:59
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd
> sub-tasks)
> >
> > As Peter seems to imply, ESPIE interrupts are apparently noticeably
> > lower overhead than ESTAE interrupts. If data or addressing
> > exceptions were expected I definitely *would* use ESPIE. I would
> > save ESTAE for unexpected (well, expected unexpected) conditions. My
> > opinion: no benchmarks, no source code.
> >
> > Charles
> --
> 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: Sometime

2020-04-02 Thread Brian Westerman
Which one did you get?

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


Re: ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

2020-04-02 Thread David Crayford

On 2020-04-03 1:56 AM, Gord Tomlin wrote:

On 2020-04-02 11:03, David Crayford wrote:

In that case why does LE use ESPIE in condition handling?


An irreverent take would be that they enjoy obfuscating abends by 
transforming program checks into U4xxx abends.


The ESPIE can be eliminated using TRAP=(ON,NOSPIE), and we have not 
seen any adverse effects upon LE recovery from running that way. 


We do that too! Most of the hatred towards LE from assembler programmers 
is the condition handling!




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