Suggest you create a script that first does a disa ses client then does a can sess all. Then ena ses client some time later.
Regards, Joerg Pohlmann ----- Original Message ----- From: "Zoltan Forray" <[email protected]> To: [email protected] Sent: Wednesday, September 26, 2012 3:45:18 PM Subject: Re: [ADSM-L] Stopping backups from running during certain hours All of this discussion is great but the bigger picture/issue is being missed. Yes, I would like to automate it but isn't really possible since it is subjective to which one is eligible to be canceled. If I (or an operator) figure out which to cancel and then cancel it, backup session will automatically restart and keep on going. I want to be able to stop it from restarting, as well! On Wed, Sep 26, 2012 at 1:28 PM, Ehresman,David E. <[email protected]>wrote: > You would want to grep for Node in the q sess output so that you don't > cancel Admin sessions. > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of > Alex Paschal > Sent: Wednesday, September 26, 2012 12:41 PM > To: [email protected] > Subject: Re: [ADSM-L] Stopping backups from running during certain hours > > As far as killing those sessions goes, something like this might do the > job. Just put it in a script, cron it for 7am. > dsmadmc -id=id -pa=pa cancel session all > Heheh - talk about a big stick. > > If you need it to cancel only certain nodes' sessions, you could try > something like this. Put the node names in a text file, and ... > dsmadmc -id=id -pa=pa -dataonly=yes -tab query session | grep -wf > nodes.txt | awk -F\asdf '{print $1}' | tr -d , | awk '{print "cancel > session ", $1}' | dsmadmc -id=id -pa=pa > Note: The "asdf" is actually a typed tab character. > > It will definitely need polishing before being ready for production, > error checking, logging, notifying, stuff like that, but that's the > essense of the script. > > On 9/26/2012 7:32 AM, Zoltan Forray wrote: > > *"Could you monitor the TSM sessions and ensure that if one is still > going > > it it put on hold from 7:00 am to 11:00 pm during the work week."* > > > > Yes, the above sentence is what I have been tasked with. > > > > Some back-story........ > > > > We have some non-local nodes that often backup terabytes of data, thereby > > sometimes running for >16-hours and often many days. Unfortunately, due > to > > their physical location and other networking issues, their traffic comes > > across a 10/100 connection. We recently had some "networking slowdowns" > and > > someone noticed a large amount of traffic across this switch (never mind > > the problem was actually diagnosed to be a firewall problem....) ..... > > even-though this has been happening for a long, long time. So, TSM has > > become the whipping-boy for network related slowdowns (<2% of the TSM > nodes > > are not local/on private GB connection) > > > > I am not aware of a server-side function/process that can kill a running > > backup (never-mind that a physical body will have to check active backup > > sessions and figure out which might cause problems) and stop the node > from > > reconnecting almost immediately (unless something has changed, you can't > > update a node to lock it while it is active). > > > > Thoughts.....suggestions.......ideas......rants................ > > -- > > *Zoltan Forray* > > TSM Software & Hardware Administrator > > Virginia Commonwealth University > > UCC/Office of Technology Services > > [email protected] - 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 > > > -- *Zoltan Forray* TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services [email protected] - 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
