+1 for DEFERW. But understand it defers the writes :-) ... Once took a job down from 2M EXCPs to 0.5M with BLSR and then on down to 850 by adding DEFERW. 500 Control Intervals or so in the VSAM data set all the I/O was to.
Cheers, Martin Martin Packer, Mainframe Performance Consultant, zChampion Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Ron Hawkins <ronjhawk...@sbcglobal.net> To: IBM-MAIN@bama.ua.edu, Date: 04/04/2012 05:34 Subject: Re: VSAM help wanted for random reads Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> Frank, It is terrific that you are getting an improvement with BLSR. I suspect you are using a vanilla copy of an example in the BLSR manual similar to Peter Farley's example in his post. The problem is these parms do not get the best performance from BLSR. The missing value is DEFERW. This is explained at http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA5J600/3.1.1?SH ELF=iea2bkb3 < http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA5J600/3.1.1?S HELF=iea2bkb3&DT=19940301112926&CASE> &DT=19940301112926&CASE= about three quarters of the way down the page. Using Peter's example I would suggest you should use: //MYKSDS DD SUBSYS=(BLSR,'DDNAME=MYKSDS#','RMODE31=ALL', // 'MSG=I','BUFND=256','BUFNI=10' DEFERW) //MYKSDS# DD DSN=HLQ.MY.KSDS,DISP=SHR If you do omit DEFERW a CI will be written to the KSDS every time you update it. It will stay buffered for a read buffer hit, but if you update 100 records in the CI you will write that CI 100 times. Not a huge problem for most modern DASD, but if you are running synchronous remote copy it will be painful. With DEFERW an updated CI will written when the LSR algorithm decides it is no longer active enough to remain in the LSR pool. You'll also see an unusual effect where all changed CI are written to KSDS at end of job. DEFERW also helps the performance of sequential inserts that do not use SIS, and CI and CA splits. It's an often omitted must-have for BLSR. NB it's a good practice to set BUFNI to the number of records in the Index component of the KSDS, plus 10%. Again based on the example, if you have a three level index with 11 index set records your sequence set will pollute the buffer hits on the low level index set records (the high level index set record is probably the most touched CI in the KSDS). Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of Frank Swarbrick > Sent: Tuesday, April 03, 2012 4:33 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] VSAM help wanted for random reads > > Several good ideas given. > > My sysprog installed BLSR and I got very good results: > > Without BLSR: > - > -----TIMINGS > (MINS.)------ > -----PAGING COUNTS---- > -STEPNAME > PROCSTEP RC EXCP > CONN > TCB SRB > CLOCK SERV > WORKLOAD PAGE SWAP VIO SWAPS > -PROC01 > STEP01 00 1123K > 1121K > .83 .11 > 23.2 1599506 TSTBAT > 0 > IEF404I > ICM06F - ENDED - > TIME=16.43.46 -ICM06F ENDED. > NAME-ICM06 > TOTAL TCB CPU TIME= .83 TOTAL ELAPSED TIME= > 23.2 > > With BLSR: > CSR020I > BUFSI=1024, BUFSD=20480, BUFNI=10, BUFND=256, HBUFNI=0, HBUFND=0, > SHRPOOL=14. > DDNAME=ICMMSTR > CSR022I > STRNO=16, ACB RMODE31=ALL, RMODE31=ALL. > DDNAME=ICMMSTR > +CSR021I > ACB CONVERTED TO USE VSAM LSR. > DDNAME=ICMMSTR > - > -----TIMINGS > (MINS.)------ > -----PAGING COUNTS---- > -STEPNAME > PROCSTEP RC EXCP > CONN > TCB SRB > CLOCK SERV > WORKLOAD PAGE SWAP VIO SWAPS > -PROC01 > STEP01 00 10704 > 3532 > .04 .00 > 1.1 73844 > TSTBAT 0 > 0 0 0 > IEF404I > ICM06F - ENDED - > TIME=16.55.07 -ICM06F ENDED. > NAME-ICM06 > TOTAL TCB CPU TIME= .04 TOTAL ELAPSED TIME= 1.1 > 23.2 minutes versus 1.1 minutes. 1,123,000 EXCP versus 10,704 EXCP. > > BTW, to Steve Comstock, there is no AIX on this file. Just a 17 byte key > where the first byte is the "record type" ('0' - '5') and the remaining 16 is the > 'actual' key in the format appropriate for that particular record type. > > The idea of putting the record type at the end rather than the beginning is an > interesting idea. Unless there's some way of doing that without having to > change any programs I don't think we'd want to take the time. However I am > interested enough to try it with this one program and see what effect it has. > > Thanks! > Frank > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > <mailto:lists...@bama.ua.edu> lists...@bama.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
