John, I believe what you have described is the behavior for NSR buffers, not LSR. My recollection is that no matter how many BUFND are allocated and used, the string only checks the last buffer it used, and will then read the CI required, along with additional CI based on the BUFND you have specified - just as it would for sequential access.
For random access to a KSDS the BUFND should be set to number of strings plus one for CI splits. Anything beyond that causes CI to be read that are never used. The CI required may be the Data Buffers, but the String will never look beyond the first CI. Back before the days of cache I reduced a job from 48 hours to two hours run time by reducing BUFND from 64 to 2. This was simply a case of a programmer thinking that all KSDS was processed as LSR and that BUFNI and BUND were used to control the LSR buffers. All academic for Larry's question, as he just wants to do sequential writes. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of > John McKown > Sent: Sunday, March 15, 2009 5:34 PM > To: [email protected] > Subject: Re: [IBM-MAIN] Is There VSAM Equivalent for BUFNO? > > On Sun, 15 Mar 2009, Larry Burch wrote: > > > One or both of BUFNI (for Index buffers - KSDS only) or BUNFD (for Data > buffers) > > // AMP='AMORG,BUFNI=n,BUFND=m' > > replace "n" and "m" above with the proper values for your application. > Please note that, depending on the application, increasing one or the > other or both can actually DECREASE efficiency and INCREASE run time! Know > what you're doing in the application! > > Case in point: Program used LSR buffering and had a huge BUFND. However, > most of the direct retrievals were for keys which did not exist in the > file (weird, I know). This caused LSR to read in BUFND records on every > GET, then immediately invalidate those buffers due to "record not found". > This was in a loop where 90%+ of the keys were "not found". This was a > huge I/O load. The program ran for over 10 hours (as I recall). I looked > at the program and rewrote it. The rewritten program ran in about 5 > minutes (again, as I recall). No offense, but "modern" programmers are not > very smart about old tyme techniques (anybody else remember the old sorted > master and transaction files? That was this was, but done in a "modern" > way that did not require any sorting. This despite the fact that the keys > in VSAM are always "sorted" in ascending sequence anyway. My replacement > was basically a "read each file and do a 'match merge' of the transaction > with the master'". > > > -- > Q: What do theoretical physicists drink beer from? > A: Ein Stein. > > Maranatha! > John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
