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