Peter, I've had this conversation in a few sites, and I've actually never come across a KSDS opened and updated with NSR (the usual COBOL strategy) that maintains integrity across a crash. This is a problem for KSDS with or without LSR and Deferred Writes and your backup recommendation is a requirement whether you use deferred writes or not.
Remember the last time you recovered a KSDS that part way through a CA-split when the system pranged? VSAM NSR makes no attempt maintain Index and Data integrity to protect against a system or program crash. DEFERW does not change this exposure. Ron. > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Farley, Peter x23353 > Sent: Wednesday, April 04, 2012 6:01 AM > To: [email protected] > Subject: Re: [IBM-MAIN] VSAM help wanted for random reads > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
