The rule of thumb is to look at your hot spots first. If the monitoring doesn't narrow it down enough, you can always use SLIP PER SA on the address range.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bernd Oppolzer [bernd.oppol...@t-online.de] Sent: Monday, February 8, 2021 1:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: LINK vs LOAD/CALL Thanks a lot, I didn't think of this ... of course it is very important when fixing such SIIS issues to check if the store is indeed done a significant part of the time or - as in this case - only once a day. In my customer's case there were/are other places to fix, but probably not these. Kind regards Bernd Am 08.02.2021 um 19:44 schrieb Farley, Peter x23353: > There is a potentially meaningful performance hit only if the load module / > program object is marked refreshable. For the non-refreshable case, the > one--time performance hist (the first time ST R15,PTR is executed) is trivial > compared to the potential cost of getting the called program address. > > Don't mark such code refreshable and you will be fine. > > This is an old, old technique used in probably thousands or more of "dynamic > call" assembler stub programs. Yes there are modern, reentrant and > refreshable techniques now - name/token pair comes to mind - but they are not > without their own cost in CPU time. > > I wouldn't call the technique ugly, just necessary and (relatively) efficient. > > If it ain't broke, don't fix it. > > Peter > ---------------------------------------------------------------------- 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
