Ended up going to level2 support and we were able to edit the records back to 2002. Interesting process. I've been out for a couple of days but I see that the next problem is that TDS has stored the last entry it was using in the summary table...So it is still issuing the query for records after 2021.
Kind of thought that might happen but it was to late last Friday to do anything about it. Will be working with the folks that support the Oracle database that is collecting all of the data in the morning. Hopefully it won't take much to "fix" it. Thanks for the different ideas. Curt Magura Lockheed Martin EIS Gaithersburg, Md. 301-240-6305 -----Original Message----- From: Don France (TSMnews) [mailto:[EMAIL PROTECTED]] Sent: Monday, April 01, 2002 4:59 PM To: [EMAIL PROTECTED] Subject: Re: Purge Summary Table Curtis, Try setting summaryretention to 1, stop the server, change system date to 2 days later than the bad date, start dsmserv, ACCEPT DATE -- all of this with sessions and schedules disabled, to prevent further records; after purge processing, stop the server, reset system date, start dsmserv, set retention to desired interval, maybe 30 --- did you already do an ACCEPT DATE cmd (after the accidental time-source problem)? This sounds like you need a debug command to clear up; did you get any help from TSM Support folks? I'd guess other folks have this problem, but might not notice until they run an open-ended date on their query (like TDS does). Regards, Don Don France Technical Architect - Tivoli Storage Manager Professional Association of Contract Employees (P.A.C.E.) San Jose, CA (408) 257-3037 [EMAIL PROTECTED] ----- Original Message ----- From: "Magura, Curtis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 28, 2002 5:28 AM Subject: Purge Summary Table > I plan to call the support center in a bit but thought I'd throw this out to > the experts and see if anyone has any thoughts. > > TSM Server 4.2.1.7 on AIX 4.3.3 ML6. > > The time source that we use for our machines got set to the year 2021 > recently (that's another whole story!). As a result we have a record in the > summary table from 2021. We are in the process of setting up TDS reporting > and it turns out that is uses the summary table as part of the input. The > command below gets issues when you run the TDS loader. > > 03/28/2002 06:52:29 ANR2017I Administrator ISMBATCH issued command: DEFINE > CURSOR C3330188 SQL="SELECT * from SUMMARY where END_TIME >= '2021-08-18 > 06:02:19' order by END_TIME" > > As a result a majority of the cubes that get built as part of TDS are empty. > We have been running with the summaryretention set to 30. I reset it to 0 > hoping it would reset the table. No luck. Started and stopped TSM while it > was set to 0...still no luck. > > Looking for a way to purge the record from the database. Here's the > offending record: > > START_TIME: 2021-08-18 06:00:06.000000 > END_TIME: 2021-08-18 06:02:19.000000 > ACTIVITY: STGPOOL BACKUP > NUMBER: 440 > ENTITY: BACKUPPOOL -> OFFSITE > COMMMETH: > ADDRESS: > SCHEDULE_NAME: COPY_BACKUPPOOL_OFFSITE > EXAMINED: 162 > AFFECTED: 162 > FAILED: 0 > BYTES: 28143616 > IDLE: 0 > MEDIAW: 62 > PROCESSES: 1 > SUCCESSFUL: YES > VOLUME_NAME: > DRIVE_NAME: > LIBRARY_NAME: > LAST_USE: > > Thoughts? > > Curt Magura > Lockheed Martin EIS > Gaithersburg, Md. > 301-240-6305
