Re: SQL error - damaged index maybe??

Good thinking, thanks!

Clare

----- Original Message ----- From: <dkimmel@xxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Cc: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>; <midrange-l-bounces@xxxxxxxxxxxx>
Sent: Thursday, April 12, 2007 9:45 PM
Subject: Re: SQL error - damaged index maybe??

Remember you can RMVM and ADDLFM to rebuild an index without having the
source.

D Kimmel




Al Mac <macwheel99@xxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
04/12/2007 12:13 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: SQL error - damaged index maybe??






There's IBM ways to get source for a file. I do not remember the
particulars.
Provided the logicals are not damaged.
There may be an intellectual property issue with the notion of reverse
engineering BPCS to get source that was not supplied . purchased.

Depending on your client's relationship with INFOR, they may be able to
buy
copies of source code not for 100% of BPCS, just for the area in trouble.

Hi Al,

Yes, that's exactly the sort of thing I wanted them to try - but they

don't

have any source to recreate logicals etc (it isn't shipped with V6 BPCS).
However, Genyphyr Novak is looking at it now, so fingers crossed. If that
fails, I'll get onto Bob!

thanks,

Clare

----- Original Message -----
From: "Al Mac" <macwheel99@xxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Thursday, April 12, 2007 4:54 PM
Subject: 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.
>
>
> --
> 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.
>

--
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.

--
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.



--
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.