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