Re: SQL error - damaged index maybe??

You guys know a hell of a lot about the 400 and BPCS such that my tips might have only marginal value, but here goes anyway. In the following check list you will have to substitute some library names, based on your version of BPCS.

In our case it was IIM item master that we managed to get damaged, and we managed to get it damaged several times before the hardware problem was resolved.
Here's how the damaged object got fixed by Bob Kohindorfer at UPI ... we added some of our own notes to the how-to steps since our expertise can't hold a candle to Bob's so we have to take more baby steps.

* Do an SQL over IIM file using ORDER BY ILEVL
* If this fails with an SQL error then we have the same problem.
* If this does not fail, then we have a different problem
* We don't want anyone signed onto BPCS while we are working Bob's magic
* Copy IIM file from OUR_BPCS_LIB to UPILIB
* Leave ERRLVL at 0
** so if there are damaged records the job will stop
in which case we have another problem
* Verify that the copy is Ok by running the same SQL as in step 1
SQL over IIM file using ORDER BY ILEVL
If this failed in OUR_BPCS_LIB but not now then the copy is a good one
Session one in SQL is now finished with interactive SQL needs
* Before deleting any files, double check we have the source to recover them & we know where that all is, since it might not all be in one consistent location.
* DSPDBR IIM F4
* Delete all logicals built over IIM in OUR_BPCS_LIB
(IIML* and KFPJ01)
* Delete IIM physical file in OUR_BPCS_LIB
* Copy IIM back from UPILIB to OUR_BPCS_LIB
* Recompile all IIML* logicals from BPCS405CDS/QDDSSRC to OUR_BPCS_LIB
* Copy KFPJ01 logical from OUR_TEST_LIB to OUR_BPCS_LIB
and make sure the created file is built over OUR_BPCS_LIB
* Tell end users Ok to sign onto BPCS again

A while back we had a different kind of crash (battery died in UPS & we did
not notice) ... have they done a 100% backup? If there are any damaged
objects, the backup will fail & you will get a log of which objects got
damaged. I'd have to drill down into our documentation, UPI had a quick
fix once the damaged file was identified. We went with an alternative to
IBM support that was more responsive, less expensive, and more flexible in
payment options.

Of course you don't know for a fact that the problem is a damaged object in
the IBM sense. If any BPCS processing was conducted between the time that
the consultant deleted libs & restored them, the programs might have done
malfunctioning things to corrupt the BPCS data base.

If you have a backup from before the original crash, can there be a
comparison of what's on tape vs. what is now on disk? Ignore reoords dated
added since crash should show if any prior records got scrambled.

>Hi all,
>
>I have been asked to look at this problem - customer filled up their disk
>and system crashed. Afterwards, consultant deleted a whole lot of libs, some
>were in the BPCS library list!
>He has restored the libs that were in the libl...but doesn't fix the error:
>Since then, pick confirm and BIL501 both issue error msgs MCH3402 and
>CPF4204, 'tried to refer to all or part of an object no longer there' and
>'internal failure in query processor'. Msgs are coming from QQQIMPLE and
>QQQQUERY (STARFC), also SQL0901 from QSQROUTE (CK_DEBUG) but no clue as to
>which object is affected.
>Tried RCLSTG and IPL, could try copyfile - but which file??
>Anyone have any other ideas? Get it to recreate access paths maybe?
>
>thanks,
>
>Clare


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.