Not to suggest YOU should've done this but you can get useful statistics out of SMF 62 and 64 that would've told you how much "write" activity you had - and a lot else besides.
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: Frank Swarbrick <frank.swarbr...@yahoo.com> To: IBM-MAIN@bama.ua.edu, Date: 04/04/2012 16:59 Subject: Re: VSAM help wanted for random reads Sent by: IBM Mainframe Discussion List <IBM-MAIN@bama.ua.edu> Tested with DEFERW=YES (that is the proper syntax, by the way. Commas are optional.) It didn't gain me much, as I am only updating 32 of 61459 records, so I'm not going to worry about it at this time. With BLSR DEFERW=YES: 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 10649 3485 .04 .00 1.2 73938 TSTBAT 0 0 0 0 IEF404I ICM06F - ENDED - TIME=09.36.39 -ICM06F ENDED. NAME-ICM06 TOTAL TCB CPU TIME= .04 TOTAL ELAPSED TIME= 1.2 STATISTICS REC-TOTAL----------61459 SPLITS-CI--------------0 EXCPS----------------466 REC-DELETED------------0 SPLITS-CA--------------0 EXTENTS----------------1 REC-INSERTED-----------0 FREESPACE-%CI---------20 SYSTEM-TIMESTAMP: REC-UPDATED-----------32 FREESPACE-%CA---------10 X'C95EC792E74FAC04' REC-RETRIEVED------10103 FREESPC---------19886080 With BLSR DEFERW=NO: 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 10661 4459 .04 .00 1.2 74300 TSTBAT 0 0 0 0 IEF404I ICM06F - ENDED - TIME=09.53.06 -ICM06F ENDED. NAME-ICM06 TOTAL TCB CPU TIME= .04 TOTAL ELAPSED TIME= 1.2 STATISTICS REC-TOTAL----------61459 SPLITS-CI--------------0 EXCPS----------------471 REC-DELETED------------0 SPLITS-CA--------------0 EXTENTS----------------1 REC-INSERTED-----------0 FREESPACE-%CI---------20 SYSTEM-TIMESTAMP: REC-UPDATED-----------32 FREESPACE-%CA---------10 X'C95ECB3FB8134004' REC-RETRIEVED------10103 FREESPC---------19886080 I did a delete/define/repro from source for the ICMMSTR file before each run. Thanks for everyone's help! Frank ----- Original Message ----- > From: "Farley, Peter x23353" <peter.far...@broadridge.com> > To: IBM-MAIN@bama.ua.edu > Cc: > Sent: Wednesday, April 4, 2012 7:00 AM > Subject: Re: 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:IBM-MAIN@bama.ua.edu] On Behalf Of > Ron Hawkins > Sent: Wednesday, April 04, 2012 12:35 AM > To: IBM-MAIN@bama.ua.edu > 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 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
