For an SQA request which needs to convert some multiple of 4K pages from CSA to SQA, the path length is longer. As to the question of whether or not it is dramatic, the answer is the same as for most performance questions - "it depends". One could construct an artificial workload where the SQA 4k multiple free page space is not fragmented, and the CSA multiple 4k page free space is highly fragmented, and then be doing a lot SQA getmains for a size which requires a long CSA search, and produce a measurable (even dramatic, for some definition of dramatic) performance effect.
For a particular customer's workload, the only way to tell whether or not there is a measurable difference is to measure it both ways. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> wrote on 06/26/2017 07:24:37 AM: > From: Barry Merrill <ba...@mxg.com> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 06/26/2017 03:38 PM > Subject: FW: common storage usage question > Sent by: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> > > My 2003 Newsletter has this note: > > 29. APAR OW54622 introduced an SQA overflow into CSA condition that > increased CPU time for many STCs over time; the new GETMAIN larger > than FREEMAIN was corrected by APAR OW55360. It has long been known > that when SQA is too small and expands into the CSA area, path > lengths are dramatically increased; you can detect this condition in > MXG dataset TYPE78VS variables SQAEXPNx. > > > Unfortunately, I do NOT know if that statement with regard to increased > CPU time due to path length when there is an overflow is still true, and > I can't find the "long known" source. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
