Zoltan, Looks like you won gold medal on that one ! Many thanks. Regards.
Arnaud -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan Forray/AC/VCU Sent: Friday, 09 September, 2005 16:00 To: ADSM-L@VM.MARIST.EDU Subject: Re: Need tool to give evidence that "repair stgvol" command is pinning the log Have you tried: show logpinned PAC Brion Arnaud <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> 09/09/2005 09:45 AM Please respond to "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> To ADSM-L@VM.MARIST.EDU cc Subject [ADSM-L] Need tool to give evidence that "repair stgvol" command is pinning the log Hi all, Some weeks ago our TSM server (5.3.1.4 on AIX) had problems while performing reclamation, and began issuing lots of "ANR0102E asalloc.c(XXX): Error 1 inserting row in table AS.Segments" messages. I consequently opened a PMR, and got the advice to perform a "repair stgvol" command against the volume being reclamed, which solved the problem. However, on the same day, a new problem appeared : TSM's log began growing endlessly, although I had a database trigger defined at 50 %, which started to chain up Dbbackups, each of them resulting in a message in the activity log looking like "ANR4556W Attention: the database backup operation did not free sufficient recovery log space to lower utilization below the database backup trigger....". I had no other mean than restarting the server to get the log freed again ... Yesterday, same problem happened and I'm now 99,99% sure that this "repair stgvol" is guilty. However, before reporting this to IBM, I would like to have the certainty that my assertion is right. Does anyone know some command that would show which process is pinning the log ? Thanks in advance ! Regards. Arnaud
