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



On Tue, 31 Aug 2004 20:55:56 -0500, Alister Wm Macintyre
<macwheel99@xxxxxxxxxxx> wrote:
 
> I think I have found my smoking gun
> and BPCS_L was a big help this time.

Looks that way.

> I still not know if there is any problem with the data in those other files.
> there are only so many things I can check before I run out of daily wake time.
> 
> Using SQL I got a count of how many records in ITH do not have a match to
> IIM ... history on items that have been deleted = 144,149
> 
> I have some stuff I put on automatic some time ago, to help me monitor file
> sizes as needed.
> This info pretty much confirms for me that going into Monday transactions
> THE ONLY records in ITH were those on the deleted IIM items

Sure - the purge program looks at the closing data and backs out the
save window. Unless the save window is > 4 years the purge date is
greater than today!

> Currently I am thinking in terms of ignoring that problem, during this
> repair effort.
> I have to get the ITH restored from Fri 8/27 backup
> I have to get that combined with the ITH that is now on the system.
> The history on the deleted records will be doubled up, but dealing with
> that is for another day when I will write some SQL to remove ITH records
> that do not have a match to IIM
> and I suspect in that case the sequence numbers won't make a bit of
> difference

How about using a query (similar to my previous post) to build a file
of the restored ITH without the records for deleted IIM.  This will be
easier than the one in my previous post.  You can use SQL if you are a
masochist -- CREATE TABLE XXX AS SELECT * from RESTORE/ITH ....

> 
> I am hoping our BPCS tech support has already written a program to fix ITH
> vs. IIM sequence numbering, because this problem cannot possibly be unique
> to us.  Yes I could write it, but for me to research what is needed, how
> test it, etc. there are times it makes more sense to get help, and my boss
> has authorized me to call tech support for help with this problem.

I have one if you want.  Minor adjustment required because of date
formats (yymmdd vs cyymmdd).  Contact me off line if you want it.

> 2 bosses ago, decision was made to stop saving the ITH records that get
> wiped out by INV900 purge, so the last date in YTH is from 2003-01-31 EOM.
> It was never explained to me WHY this decision was made
> I suspect it might be related to all the problems we were having back then
> with bad tape media, and the fact that the IBM tape drive died 2 days
> before an EOM, and we had to get IBM service to replace the tape drive.
> 
> My feeling based on this latest episode is that we would probably be better
> off going back to the old way, any time we are not having that kind of tape
> problem, which we have not had in years.

The old way is a a poor solution.  If you are concerned about this
happening again, submit another request to the list and you will get a
ton of alternative selections.  My suggestion .. before monthend, copy
key files into a temp library, get them onto the monthend tape backup,
then delete the temp library.

-- 
Tom Jedrzejewicz
tomjedrz@xxxxxxxxx

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.