Re: oncheck -cI

Just to update anyone who might be following this thread. After trying a few suggested fixes from IBM support they have come up with 2 options as next steps. (the attempted fixes mostly involved oncheck -cI -y online and in quiescent mode) 1) dbexport database(s), drop database(s) and dbimport database(s) 2) Have IBM Down Systems Dept. connect to our server and fix the indexes. We are evaluating which one option to choose as our next step. The first would probably be more down time then the second, but I think a more safe approach. Not sure what the final decision will be, if this was closer to our 3rd party software vend releasing IDS 10 to us I would say just limp along until then and deal with it when down for the upgrade. But, that will be about another 2 months. Then again might be nice to not mix the two. I will update the thread once we decide and then once it is fixed and what worked. Jonathan - how do I find the table name from the tabid? John

On Thu, 2006-02-23 at 21:19, jda wrote: > Jonathan - how do I find the table name from the tabid? > Different Jonathan but it's select tabname from systables where tadbid = <tabid> /J\\ -- This e-mail is sponsored by http://www.integration-house.com/

Final update on this thread (I hope and pray): Over the weekend I tried to dbexport our database and the dbexport failed with the following errors when it got to systabauth *** load table *** -211 - Cannot read system catalog (systabauth). -103 - ISAM error: illegal key descriptor (too many parts or too long). So IBM's option 1 to fix it went out the window, and we started to see that the corruption was getting worse as in more rows affected. This morning when our users started work some of them where getting access and other strange errors, after a little investigation it seems the systabauth index corruption had gotten to the point where it was preventing people from access our tables. So got everyone off the system and got IBM involved. IBM Down Systems Department was able to log on and fix the corrupt indexes. Took IBM over an hour to fix the indexes and a couple of different attempts but they saved the day. Yaaaaaah!!!! Things learned for this problem: 1 - When a sys table is involved get IBM support helping out sooner then later. 2 - Don't try to drop/rebuild any tables matching the tabids that are corrupt systabauth index. (will leave records of the old tabid and also add the new tabid) - get the indexes fix first. John