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

Reply via email to