On Thu, 26 Mar 2009 09:55:57 -0500, Tom Harper <[email protected]> wrote:
>Frank, > >I should have explained that there is a reason for inserting the record >and then deleting it. When building the initial key for the VSAM KSDS >record for insertion and subsequent deletion, you should build a key of >all X'FF's. If you do not do this, then later, as subsequent keys are >inserted into the data set, performance is degraded. > >You mentioned also that you are doing this for indexes, and mentioned >VSAM ESDS data sets. Normally, IMS indexes are just VSAM KSDS data sets, >except when you have non-unique keys, and then the VSAM ESDS data sets >are required. If you a /SX to the secondary index key, then your keys >are unique and you can get rid of the VSAM ESDS data sets completely and >just have the VSAM KSDS data sets. Most customers have done this long >ago because the performance benefits are significant. Sorry, I thought I had looked at my define on my index and saw it was an ESDS. It is indeed a KSDS (how could it be otherwise!). I'm still confused about this performance degredation you mention. The "correct" (allegedly) process to restore an IMS database is do to an AMS DELETE/DEFINE of the index database cluster and then run DFSURGL0 to load the database. All I am doing is replacing the DELETE/DEFINE with my "VSAMINIT" process that just opens (for output) and closes the file. The DELETE/DEFINE doesn't do the insert/delete process (does it?). >You also might get some interesting responses if you post this question >to the IMS-LIST. I will do this. Thanks! Frank ---------------------------------------------------------------------- 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
