Glad to help.
BTW, I forgot to mention (since Richard Sims usually responds very
quickly), that this plus other undocumented "show" commands are on the
ADSM Quickfacts webpage at:
http://people.bu.edu/rbs/ADSM.QuickFacts
There are 9-LOG related "show" commands listed !
PAC Brion Arnaud <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[email protected]>
09/09/2005 10:04 AM
Please respond to
"ADSM: Dist Stor Manager" <[email protected]>
To
[email protected]
cc
Subject
Re: [ADSM-L] Need tool to give evidence that "repair stgvol" command is
pinning the log
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: [email protected]
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" <[email protected]>
09/09/2005 09:45 AM
Please respond to
"ADSM: Dist Stor Manager" <[email protected]>
To
[email protected]
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
