Watch out - ARR has been ... pirated ...

Thank You,
Chris Hoelscher| Lead Database Administrator | IBM Global Technical Services| T 
502.476.2538  or 502.407.7266

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Jim 
Mulder
Sent: Thursday, April 2, 2020 8:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] ESPIE question (does ESPIE "cover" ATTACH'd sub-tasks)

 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
> https://nam03.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.g
> mu.edu%2F~smetz3&amp;data=02%7C01%7Cchoelscher%40humana.com%7Cca76ea76
> a7474e2ac5cf08d7d76892fe%7C56c62bbe85984b859e511ca753fa50f2%7C1%7C0%7C
> 637214716450807351&amp;sdata=5aPAm4%2BEpwEyF42MI1FjqwfdZgnlpbdceEnvKZr
> ChqI%3D&amp;reserved=0 ________________________________________
> From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on 
> behalf of Jim Mulder <d10j...@us.ibm.com>
> 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
> Recovery            Iterations  CPU seconds  Ratio
> ----------------    ----------  -----------  -----
> ESPIE               x'200000'      3.53        1.0
> FRR                 x'200000'     45.66       12.9
> ESTAEX (no SNAPTRC) x' 20000'     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" <lenni...@rsmpartners.com>
> > 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" <IBM-MAIN@LISTSERV.UA.EDU>
> >
> > 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:              
> > https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsecure-web.cisco.com%2F&amp;data=02%7C01%7Cchoelscher%40humana.com%7Cca76ea76a7474e2ac5cf08d7d76892fe%7C56c62bbe85984b859e511ca753fa50f2%7C1%7C0%7C637214716450807351&amp;sdata=bgEqET4XWGpCx691NcY0f7YeH1Zd8x8Zur15ssuafZM%3D&amp;reserved=0
> 
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 <IBM-MAIN@LISTSERV.UA.EDU> 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

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

Reply via email to