ADSM-L

Re: [ADSM-L] Log issues and scheduled commands and CHANGINGRETRIES

2010-04-09 12:39:17
Subject: Re: [ADSM-L] Log issues and scheduled commands and CHANGINGRETRIES
From: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 9 Apr 2010 12:38:11 -0400
I guess in V6 this isn't a problem - just different?



From:
Richard Rhodes <rrhodes AT FIRSTENERGYCORP DOT COM>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
04/08/2010 09:54 PM
Subject:
Re: [ADSM-L] Log issues and scheduled commands and CHANGINGRETRIES
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



It's intersting how many people implement the same management functions
over and over.
We have our own version of  kill_pinning_session_when_log_gets_x%_full.
You would
think IBM would implement this as a feature.  I'm sure we could think of
others!

Rick





             Jean-Paul Duyx
             <jean-paul.duyx@S
             ARA.NL>                                                    To
             Sent by: "ADSM:           ADSM-L AT VM.MARIST DOT EDU
             Dist Stor                                                  cc
             Manager"
             <[email protected]                                     Subject
             .EDU>                     Re: Log issues and scheduled
                                       commands and CHANGINGRETRIES

             04/08/2010 10:31
             AM


             Please respond to
             "ADSM: Dist Stor
                 Manager"
             <[email protected]
                   .EDU>






Hi Zoltan,

We have similar issues on one of our TSM instances that has some clients
behind a slower connection.
We cancel the sessions that pins the logs. And we are in a process of
moving some nodes away from this instance, to another instance.

We have put a script in CRON that checks every 15 minutes and cancels the
session that is pinning the log when the log is over 55 percent full.
We want to keep our TSM server alive, and are forced to cancel sessions
that keep the log pinned.
Maybe canceling at a higher percentage filled log could work for you.

{{{

#!/usr/bin/sh
PROCENT=`/usr/bin/dsmadmc  -se=cestino -id=admin -pa=<****> -dataonly=y
"select '##',cast(PCT_UTILIZED as int) from log" |grep "##"|grep -v grep|
awk '{ print $2 }'`
if [ $PROCENT -gt 55 ]; then
   echo "Recovery Log is $PROCENT procent"
   echo "Issuing show logpinned cancel"
   /usr/bin/dsmadmc  -se=cestino -id=admin -pa=<****> -dataonly=y show
logpinned cancel
Fi

}}}

Line that starts with PERCENT=
Should be on one line, but I am afraid mailers will break it.


Good luck !

Jean-Paul Duyx

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: donderdag 8 april 2010 16:17
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Log issues and scheduled commands and CHANGINGRETRIES

Ever since I upgrade one of our busy TSM servers from 5.5.3 to 5.5.4.1, I
have been having constant problems with the log being pinned and filling.

While I was able to determine and fix 2 problem nodes (long/large Oracle
backup and another node that is compressing and backing up a 280GB log
file, 5-times and thus running for 10-hours), I am still having problems.
The log went to 90% last night.

I see there is a 5.5.4.2 server patch but none of the fixes I saw
addressed such issues.

So, I would like to schedule a "show logpinned" command every 15-minutes
and send the output somewhere so it can be emailed to me.

I have never messed with server scripting so this is new territory for me.

Does anyone have a script/process they can share, to deal with this?   The
TSM servers are RedHat Linux 5.


One a related topic,  I am constantly finding folks who have live/changing
files being backed up multiple times (yes, I know - server owners should
be more responsible for what they are backing up....), since the default
is "CHANGINGRETRIES 5".  I am seriously thinking of pushing
"CHANGINGRETRIES 0" via CLOPTSET.  Is there and real value to the default
of "5"?  What do folks out there set this to and why?
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html


-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.