Sorry, I do not have details about that problem any longer. I experienced it some weeks ago and gave up. After changing the default queries and my customized one's according to the tsm blog they work again :-)
Thanks a lot Stefan Holzwarth > -----Ursprüngliche Nachricht----- > Von: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] Im > Auftrag von Wanda Prather > Gesendet: Montag, 14. Dezember 2009 20:16 > An: ADSM-L@VM.MARIST.EDU > Betreff: Re: AW: 6.1 experience so far > > 1) When you say "hang": if you enter q session, do you see a > hung session > for the admin id the reporter uses? > 3) If you look at the actlog, is the last query the Daily > Reporter issues > before it hangs a SELECT against the EVENTS table? > > If so it may be a known bug querying the events table, I can > send you more > info to get around it... > > > > On Mon, Dec 14, 2009 at 3:08 AM, Stefan Holzwarth > <stefan.holzwa...@adac.de>wrote: > > > What changes did you made to tsm operational reporting ? > > In our environment most of the reports hang and gave no result. > > Regards > > Stefan Holzwarth > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] Im > > > Auftrag von Sam Sheppard > > > Gesendet: Samstag, 12. Dezember 2009 01:44 > > > An: ADSM-L@VM.MARIST.EDU > > > Betreff: 6.1 experience so far > > > > > > After viewing the experiences of others on the list > (particularly Mr. > > > Forray's) and fearing I would jinx myself, I hesitated to > > > post this, but > > > decided to go ahead and post our adventures so far. > > > > > > We had a visit from our Servergraph rep a couple of weeks ago > > > and during > > > the conversation discovered that we seemed to be alone, > at least among > > > their Southern California customers, in implementing TSM > Version 6 in > > > production. We began in September and started with > Version 6.1.2. We > > > are approaching completion of our project to migrate our > existing TSM > > > 5.5.3 servers, two on z/OS and one on Solaris, to TSM Version > > > 6 on a new > > > AIX 6.1 P-520 server. > > > > > > Our total database size for the three existing servers is > about 120GB. > > > We are sharing a 3494 ATL with 8 TS1120 drives between > the Solaris box > > > and the Version 6 server, with the Version 6 server acting as the > > > library manager. So we may be somewhat on the small end > of the average > > > customer. > > > > > > Since we started on a fresh box, it looks like we have > avoided many of > > > the pitfalls associated with upgrading in place from > version 5, but we > > > did experience what in hindsight look like fairly minor problems: > > > > > > IC62978 - active logs fill up due to DB2 table reorg > > > processes. Fix > > > was to specify the undocumented ALLOWTABLEREORG NO option. > > > > > > IC63373 - while running a large image backup (around > 600GB) and > > > several other clients, received message ANS1316e and ANR0526W, > > > indicating recovery log out of space, even though we > have 30GB and > > > it's not even close to full. Solution is to do the > following to > > > change a DB2 variable from its standard setting: > > > > > > 1. Use the following db2 command to determine the > number of log > > > volumes used: > > > db2 get db cfg for TSMDB1 > > > 2. Multiply the value for the LOGPRIMARY parameter > by 90%. This > > > value should be reflected in NUM_LOG_SPAN. > > > > > > Update NUM_LOG_SPAN by issuing the following db2 command: > > > db2 update db cfg for TSMDB1 using NUM_LOG_SPAN > <newValue> > > > You may need to restart the TSM server, which will > restart the > > > db2 database as well. > > > > > > IC63637 - We have a large (30-40TB) amount of archived > > > data to move > > > from our existing server(s) to version 6. The good news > > > is that the > > > large archived image backups exported > server-to-server very fast, > > > around 60MB/sec. The bad new is, the Version 6 library manager > > > function periodically reclaims a tape drive being used by the > > > library client, in our case, causing the large > > > EXPORT/IMPORT process > > > being run to fail and mark the file being exported at the > > > time to be > > > flagged, causing a copy pool tape to be requested if the > > > process is > > > restarted. The fix for this was to install version > > > 6.1.2.1 and then > > > replace the DSMSERV module with a fix version. > > > > > > Database backups suddenly failed for 5 days in a row, but then > > > started working again when support requested various > > > documentation. > > > Looks like DB2 communicates with the TSM server with > its own OPT > > > file, specifying 'localhost' as the TCPSERVERADDRESS, > > > which appeared > > > to be failing even though all other functions in the TSM > > > server were > > > working fine. Waiting for reoccurence. > > > > > > Export Node function apparently does not copy the > > > MAXNUMMP setting. > > > > > > A (relatively) long list of quirks in the ISC, which we forced > > > ourselves to use while our Servergraph license was > updated. Some > > > of these were only related to Firefox 3.5.4. The > worst was a Java > > > problem that 'unchecked' the 3 'enable sessions' boxes in the > > > 'Sessions' display of the Server Properties window when > > > you left the > > > display and then came back, causing all sessions to > be disabled > > > necessitating a server restart. Using IE, however, the ISC has > > > become almost bearable and performs much better than previous > > > versions. > > > > > > The Operational Reporter is not officially supported > in Version 6, > > > something we missed, but is easily modified to supply > most of the > > > info needed. > > > > > > We have not seen the dreaded huge increase in database > size and after > > > the setting of the ALLOWREORGTABLE option, we haven't had any log > > > problems either. We are currently running full database backups on > > > Monday, Wednesday, and Friday, with incrementals in > between. Full DB > > > backup of the 45GB database takes about 6 minutes to a > TS1120 drive. > > > As noted, the current size of our DB is around 45GB with > about 2/3 of > > > our 350 client having been moved. However, the largest of > > > them, several > > > Windows file/print servers containing in the neighborhood of > > > 40 million > > > files, are still to be moved. We begin testing next week > on an NDMP > > > solution for these, or perhaps experiment with the new > > > SnapDiff feature. > > > > > > Sam Sheppard > > > San Diego Data Processing Corp. > > > (858)-581-9668 > > > > > >
