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 > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Pawel Leszczynski > Sent: Wednesday, January 27, 2010 2:56 AM > To: IBM-MAIN@bama.ua.edu > Subject: [IBM-MAIN] why compression costs additional I/O? > > Hello everybody, > Recently we are reviewing our EndOfDay jobs looking for potential performance > improvements (reducing CPU/elapsed time). > We have several jobs sorting big datasets where output is SMS-compressible > (type: EXTENDED) datasets. > When we compare such sorting with sorting on non-compressible output we > can see this: > EXCP TCB SRB el.time > TESTXWP5 STEP110 00 757K 3.51 .70 9.01 <-- w/o compression > TESTXWP5 STEP120 00 1462K 3.62 2.89 10.45 <-- w. compresion > > We guess that big SRB in (2) goes for compression (that we understand - we > probably quit compression at all), but we don't understand 2 times bigger EXCP > in second case. > > Any ideas will be appreciated, > Regards, > Pawel Leszczynski > PKO BP SA > > ---------------------------------------------------------------------- > 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
