Well of course! Thanks, John. I've used that many times in the past. So this is a clear case of Photographic Memory Syndrome (aka "PMS") -- symptoms are 1) out of focus; 2) over-exposed; 3) over-developed; sometimes 3) forget to load the film.
On Sun, 15 Mar 2009 19:33:42 -0500, John McKown <[email protected]> wrote: >On Sun, 15 Mar 2009, Larry Burch wrote: > >> Is there an equivalent to DCB's BUFNO subparm when dealing with VSAM? >> >> I need to initialize (actually write real data into every record) several >> fairly >> large VSAM RRDS datasets; would like it to proceed a bit faster. >> >> And I realize I don't know what to say. I even actually tried with BUFNO=200, >> expecting no observable difference. That was also the result . >> >> Even if there is something that would not work on my OS390.210 system, I >> would still like to know about it. >> >> Larry M. Burch lmburch [...@] cabq.gov 505-768-2948 > >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 ---------------------------------------------------------------------- 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
