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:ADSM-L@VM.MARIST.EDU] On Behalf Of Alex Paschal Sent: Wednesday, September 26, 2012 12:41 PM To: ADSM-L@VM.MARIST.EDU 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 > zfor...@vcu.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 >