Re: SQL error - damaged index maybe??

Based on your info, there is still speculation what problem(s).

SAVE ought to identify damaged objects, if you have any.
I had an e-mail on baby steps how to fix when we had a dnamged BPCS file.
If you have no damaged objects, then the problem(s) obviously elsewhere.
If you do have damaged objects, fixing them might not fix all the problem(s).

There are more possibilities as to what the problem might be.

I know a hell of a lot more about BPCS and 400 today than I knew at time of original installation, when decisions were made that in retrospect included some unwise choices.

We have libraries with vanilla objects that came with BPCS.
We have other libraries with stuff we added, and which came as fixes ... PTFs BMRs Rels whatever.
In some cases we have logicals in one library that point at physicals in another.

This has an impact on restore from save.
If you restore library containing logicals before you restore library containing physicals, the logicals do not get restored for physicals that do not yet exist at the time you trying to do this. This rule of thumb may apply to other kinds of objects.

BPCS files can get scrambled in ways that are not IBM problems but are problems from perspective of how BPCS software accesses those files. Do you have duplicate index records in files not supposed to have any? Do you have any Data Quality Assurance tools to tell you if records in different files are not in sync with each other?

Often running full gamut of BPCS file reorganization programs, that are safe to run when not at end fiscal time, will solve a lot of problems.

A lot of BPCS architecture involves files with records identified by sequence #s.
Some programs read some detail records on some item order, by going through the sequence #s sequentially, always expecting incremented by one.

In a crash, the incrementation can be damaged ... we recently had something else go wrong (screwed up the fiscal calendar) that led to more than one General Ledger batch with identical Journal numbers (different contents, same control #s).

I not now remember exact circumstances but we have had the opposite circumstance ... something supposed to have a string of sequence #s 1 2 3 4 5 etc. but there is like a record # missing in the string & BPCS stops when it gets to the hole ... the software thinks it is done processing that item order whatever, but there's really more to do.

These sequence #s get propagated across many files ... customer orders ... shipping records ... billing invoicing ... receivables ... then various BPCS programs use the sequence #s of one file to access the corresponding data in another file.

But in a crash, those sequence #s might not have got updated properly, so now you can have records in different files without proper pointers to each other.s

Al Mac