IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU> wrote on 02/08/2006 06:53:16 PM:
> Jim wrote on 09/02/2006 08:29:55 AM: > > > > I suspect that they discovered that on modern systems, the time savings > > > > from the suspended I/O was not sufficient to justify it and the > > > associated issues like OA09675. > > > > Exactly correct. > > No doubt true for the "latest and greatest" kit with all the go-fast > goodies. > Looks like that APAR is targeted at z/OS 1.4+. Given that it's HIPER I > guess most people will pick up the PTF as soon as it's published. > How is this going to affect customers on DASD without PAV ???. Maybe ESCON > attached even ... > > What about those on non-z kit that are still running 31-bit ???. Some of > them are liable to be doing substantial paging to disk. > I don't expect anyone to see a measurable difference. It may have been possible to continue to use Suspend/Resume for paging to non-PAV capable DASD, but I think that the benefit of Suspend/Resume is so negligible that this would not be worthwhile. Suspend/Resume was introduced in MVS/370 SP1.3, at the same time that dynamic tack-on to a running channel program was implemented in ASM. SP1.3 also had other perfomance enhancements (such as path length reduction on commonly used paths in Getmain/Freeemain). When doing performance measurements on a release with multiple performance enhancements, it can be difficult to ascertain how much benefit is due to which enhancement. Seeing as this was 25 years ago, I don't recall what the projected benefit of Suspend/Resume was, nor how accurately it was measureable. On the 3033 machine, I think there was supposed to be some benefit to RIO over SIO. There was (and still is) a somewhat shorter pathlength through IOS for RSCH vs. SSCH. However, when considering the total path length to process a page fault/page-in through program check handler, RSM, ASM, I/O interrupt handler, and IOS, I expect the RSCH vs SSCH difference to be negligible. Much of the benefit to the SP1.3 paging enhancements may have come from dynamic tack-on to already running channel programs, and we are not removing that function. When there is enough paging activity to keep the page data set busy, then many requests are handled via the dynamic tack-on, with neither an RSCH or SSCH. On the other hand, if there is little paging activity, then there isn't much RSCH or SSCH. So the maximum RSCH or SSCH for paging would occur when there is just the right amount of activity such that another request comes along just after the previous request completed (but a bit too late for a dynamic tack-on). If one were able to construct such a workload, then it could be used to measure an upper bound on the benefit of Suspend/Resume. However, I would contend that such a workload is atypical today. Most systems I see do little paging (so not much SSCH/RSCH for paging), except when there are spikes due to things like SVC dump (in which case mostly tack-on, so again not much SSCH/RSCH for paging). > And does this mean another hoary old ROT - don't assign non-page datasets > on page volumes - can be assigned to the dustbin of history ???. If you were avoiding putting other data sets on page volumes only for the purpose of avoiding the need to terminate a suspended paging channel program in order to initate I/O to the other data sets, then yes. If you were also trying to avoid paging delays by avoiding having the initiation of paging I/O being queued due to an active channel program to another data set on non-PAV DASD, then no. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
