Be very cautious using DEFERW with BLSR unless you already have a good backup of the KSDS immediately before the program starts. Recovery after a crash (program or system) will require a restore of the file, since DEFERW with a crash can leave the KSDS corrupted and sometimes unreadable, in part or in whole. BTDTGTTS.
But it does speed up the update process substantially. If you decide to use it, add the measurements of both the time to take a backup just before starting the program and the program update time to compare to the non-DEFERW time. If you can allocate sufficient memory for buffers that will hold ALL of the CI's in the file, or at least all of the CI's that need an update (not always practical, of course), all of the updating will occur at CLOSE. Also note that I added a comma before the DEFERW in Ron's example. HTH Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Ron Hawkins Sent: Wednesday, April 04, 2012 12:35 AM To: [email protected] Subject: Re: VSAM help wanted for random reads 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). -- 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 [email protected] with the message: INFO IBM-MAIN
