Then probably a script running that looks for sessions, cancels the
sessions, then loops around a node lock cmd until it works.

if sessions running for node X at wrong time
   cancel sessions
   loop
     lock node
     did lock work?
       yes - exit
       no - repeat loop





From:   Zoltan Forray <zforray AT VCU DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
Date:   09/26/2012 02:17 PM
Subject:        Re: Stopping backups from running during certain hours
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



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.
<deehre01 AT louisville DOT edu>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:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Alex Paschal
> Sent: Wednesday, September 26, 2012 12:41 PM
> To: ADSM-L AT VM.MARIST DOT 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
> > 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
> >
>



--
*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.