Here is a note on Performance and Ksam files. This may help with your testing. You are however testing apples and oranges....Ksam is not a SQL database. KSAM64: PRO AND CONS DocId: KBAN00001093 Updated: 20040622 DOCUMENT KSAM 64 has better performance the KSAM/XL. This is not a true statement. The real differences between KSAM/XL and KSAM 64 is that KSAM 64 will hold more records and the index is bigger. Is KSAM/XL faster than KSAM/3000? Is KSAM 64 faster than KSAM/3000 and or KSAM/XL? The answer is it depends. For the most part KSAM/3000 has a better write performance then KSAM 64 and KSAM/XL files [1653125344 and 1653042903}. Both KSAM 64 and KSAM/XL files have a better delete performance then KSAM/3000 All KSAM files use B-trees and that's the real penalty of a load or update, balancing those trees. XM Overhead Fcopying to a new KSAM 64 file avoids the XM overhead. So to avoid XM overhead the customer must do the following; File myfile;REC=,,,,KSAM 64;,,etc Fcopy from=KSAM/XL;to=(*myfile);NEW Building a file and then copying to it does not avoid the XM overhead. The following would have XM overhead. Build myfile;REC=,,,;KSAM 64,,,,etc Fcopy from=KSAM/XL;to=(myfile) Use OPTMBLK (better performance?) All this option would really do is more efficiently use disk space, and it has a bug, this option will cause a SYSTEM ABORT 614 ,not good. CR# [8606208699/STARS-ACTIVE/English] Other Known Problems CR# [8606356250/STARS-ACTIVE/English] patch [GR for 7.5] MPEMXP0. Problem is with the reuse option. The problem is that reuse does not work and the file appears to fill up, as if reuse was not used. CR# 8606216742 no patch. The problem listfile options 8,9,10,11 do not report the correct number of readers/writers nor the exclusive mode when performed on a KSAM 64 file. KSAM 64 files make a great "look up" tool but adding records to very large files can cause periodic performance hits when blocks split and trees have to be rebalanced. {This is also true for KSAMXL files). I would like to recommend. KSAM 64/XL: PERFORMANCE DocId: KBAN00000748 Blocking factors of a KSAM 64, how is this calculated: When building a KSAM/XL file, the system does not use user-specified blocking factors. The system computes an optimal blocking factor, based on the key structure. The KSAM/XL file includes the key structure. This is the same for KSAM 64. KSAM 64 uses the requested key blocking factor for all of your keys to determine the largest key block size. This size is then used to set the actual key blocking factor (which may be larger but never smaller than the requested (value). This method results in the best use of key file space. Blocking factors only really made a significant difference on MPE IV where there was no disk caching and disk i/o was such a big deal. In the olden days of classic MPE, data was read in blocks, determined by the blocking factor specified. MPE/iX reads a fixed number of bytes regardless of the blocking factor, and in that sense the blocking factor is "ignored". KSAM 64 TOOLs There are no tools for KSAM 64. KSCHKIX is for KSAM/XL files, it does not do recovery. This tool provides structure information only. KSAMUTIL is for KSAM/3000 files. It does do recovery and provides structure information on KSAM/3000 files only. XM XM does not seem to be a real factor when it comes to KSAM 64. A good note on xm: 6.5 and later is: XM: 6.5 changes to Transaction Manager DocId: KBAN00001073 BOTTOM LINE: Using KSAM 64 as a lookup tool is good, using KSAM 64 as a database is not good. Performance can be trouble because of the b-tree index...the more keys and duplicates the worst the performance. So the answer to KSAM Performance, KSAM64, KSAM/XL, KSAM/3000 is: it depends on how the file is going to be used.... Cathlene Mc Rae sr response center engineer * To join/leave the list, search archives, change list settings, * * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *