Peter, Yes for your example I am recommending NCP=96, which means BUFNO=96. I habitually put both NCP and BUFNO on BSAM files because I've never been sure if BSAM calculates BUFNO using the NCP value from JCL.
Many years ago I tested this to death on uncached DASD and found that BUFNO/NCP of 16 was the point of diminishing return for QSAM and BSAM. While I don't think these double buffer by design like EFS I think it fit well with the chain length limit of eight blocks with BSAM and QSAM. I should revisit this as a study on FICON and Cached DASD as it is likely that the knee in the curve happens at eight buffers now as I've noticed CPU intensive utilities like IEBDG writing short chains when volumes are SIMPLEX, and full chains when TrueCopy synchronous delays are added with DUPLEX. It suggests to me that 16 is still a good number for when IO is delayed. Thirty-one would be something I would recommend for BUFND on a VSAM file with half track CISZ, but I don't think it does any harm on DSORG=PS. As far as I recall BSAM and QSAM for PS-E does not have the same SSCH data length and #CCW restrictions as PS, and media manager is probably limited to a CYL. I'd only wish I had time to research this as a "science project" right now, but at the moment I can only offer past experience with a spattering of senior moments. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Farley, Peter x23353 > Sent: Wednesday, January 27, 2010 11:51 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] why compression costs additional I/O? > > Ron, > > If a PS-E dataset has 6 stripes, are you recommending using NCP=96 (=16 > * 6)? If so, what BUFNO should be used in that case? > > A long time ago in a galaxy far, far away, a performance guru told me an > ideal combination for PS datasets was to use half-track blocking and > BUFNO=31 (1 cylinder's worth of buffers + 1). I'd appreciate updated > advice for the PS-E and compressed data world. > > Peter > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > > Behalf Of Ron Hawkins > > Sent: Wednesday, January 27, 2010 1:19 PM > > To: IBM-MAIN@bama.ua.edu > > Subject: Re: why compression costs additional I/O? > > > > Pawel, > > > > For a regular DSORG=PS dataset DFSORT and SYNCSORT use their own > access > > method to read and write the SORTIN and SORTOUT using very efficient > long > > chained Start Sub-Channels. The EXCP count reported for these datasets > is > > the Start SubChannel count. > > > > For DSORG=PS-E the sort products will use BSAM to read and write the > > SORTIN and SORTOUT datasets. BSAM on Extended Format Datasets can be > > efficient if you increase BUFNO and NCP, but the default of five is > not > > the worst thing that can happen. More importantly the EXCP count > reported > > for these datasets is the Block Count, and not the SSCH count. These > are > > usually mult-Cyl chains. > > > > One of the few problems with Extended Format datasets is that the > block > > chaining defaults are lousy. This is probably why your job is taking > > longer with compression. BSAM, and QSAM, always use double buffering, > so > > whatever you specify is halved for chaining. I suggest that you add > > DCB=NCP=n to your SORTIN and SORTOUT, where n=16 times number of > stripes. > > > > If you want to check the actual IO count look at the SSCH count in the > SMF > > Type 46 subtype 6 records. > > > > One last thing is make sure that your SORTIN is compressed and > buffered so > > you get the benefit at the start and end of the SORT. > > > > Ron > > > This message and any attachments are intended only for the use of the > addressee and > may contain information that is privileged and confidential. If the reader of > the > message is not the intended recipient or an authorized representative of the > intended recipient, you are hereby notified that any dissemination of this > communication is strictly prohibited. If you have received this communication > in > error, please notify us immediately by e-mail and delete the message and any > attachments from your system. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
