× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.