Unless things have changed, a 26K CI size is better than 32K because two CIs fit on a track. If I'm understanding this application it:
1. reads everything from the first file 2. for each record in the first file, it attempts to do a random read to find a match in the second file 3. IF it finds a match in the second file, then it might need to read one or more _other_ records in the second file - positioned by some value in the record that matched? Seems to me you want a 26K CI size and at last BUFND=60 on the first file, to maximize sequential read of that file. Going too large on BUFND might be a waste, since your processing of the records in each CI are limited by what you're doing in the second file. You definitely want a large BUFNI= for the second file because you don't want to do I/O for the key values. I'm not sure how much a large BUFND buys you - it depends how the related records (the ones you are going to retrieve depending on program logic) are stored and how many of them you need to read. As someone else said, reading too many of them will cost you. Are the related records read using some alternate key? If so you might want a third 'file' that also reads that file, with index buffers for that alternate key. One other thing - are these updated a lot? If updates are infrequent, or if performance can stand it, reduce the free space in the VSAM files, so that you're not reading in a lot of "empty" space in the CIs. These are just suggestions, of course, without know a lot about your data. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
