In a prior release 10.0 or earlier, I encountered a problem that could corrupt an index if a write was issued without an explicit readu preceding it. I don't think IBM ever corrected that because writing without explicitly locking is Bad Form. If I remember, when process A holds a lock on a record and then process B issues a write (w/o explicitly locking),by default B sits and waits for 20 minutes, then gives up with a write error. (In my opinion, the default lock.wait should either be forever, or a uvconfig parameter, not 20 minutes.)
If process B's write was to a file that had indexes, that complicated things - I don't recall the details - and we ended up with inconsistencies between the data files and the index files. How to proceed: - Monotor uv/errlog to see if you have write errors. - Look for programs that write without locking. - 20 minute wait limit is configurable. I set ours to one month (=2678400 seconds), effectively forever, since we'd bring UV down & up more frequently then that. To do so, execute a basic program from UV.LOGIN (that all uv processes execute on startup) that does ASSIGN 2678400 TO SYSTEM(1999). TCL command SET.SQL LOCK.WAIT 2678400 accomplishes the same. All that is from memory, by that's the gist of it. Completely separate, but did you know you can create an F-pointer to the index file itself and then select, ed, basic open/read/write it like any other file? The F-pointer would look something like this: F I_FILE/INDEX.00n D_your_debugging_index_dictionary_with trans()s to data file, etc. Sometimes that can help you troubleshoot or even manually correct a critical index on the fly. But be careful. You can easily introduce more corruption. Especially if you leave the F-pointer lying around after you're done. Chuck Stevenson ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
