The VSAM buffer logic isn't that smart - one transaction that does scan of thousands of records will flush the buffers. If you have the memory and file size is small enough, a user maintained data table will keep the entire structure in memory. The other thing you might consider is making the ci size = 32K. If it is going to do massive sequential searches you might as well get the most data for each IO. In particuler, making the data size different from the index size will prevent sequential stuff from overlaying the index structures
Mike On 4/9/06, Ted MacNEIL <[EMAIL PROTECTED]> wrote: > > >So, a savings of 10K instructions (I/O cost minus look-aside cost) is > feasible. > > Thanks for the review. > I haven't done this kind of analysis for over 15 years. > I still think it's an application design problem, but the vendor has us by > the short ones. > There is no other packaged alternative. > > But, CPU justification isn't going to cut it. > 2000 I/O's at 10,000 per is only 20 MIP-like entities. > > - > -teD > > O-KAY! BLUE! JAYS! > Let's PLAY! BALL! > > ---------------------------------------------------------------------- > 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 > -- Mike ---------------------------------------------------------------------- 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
