Re: [ADSM-L] Stopping a client backup

An update for everyone...

Success.... I used CANCEL SESSION and it worked.  Didn't have to go so far as 
LOCK NODE.

I created a schedule via DEFINE CLIENTACTION.

As soon as I saw the first connection come up, I cancelled that session.

Act log reported the session was cancelled by administrator.

A new session was immediately created.  But that session lasted only a few 
seconds.

My assumption is it was reporting back to the node sched.log or error.log.

Anyway, no additional sessions created.

How this differs from yesterday:

The node yesterday had proceeded far enough to be actively backing up data.

The node today (a different one) was only in the initial session and had not 
yet started any backup of data.

Thanks to everyone for all the suggestions... this is a great team!

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Francisco Javier
Sent: Tuesday, February 10, 2015 11:39 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Stopping a client backup

If the memory don't fail me you cann't modify the option file while the session 
is active. And yes it's only will affect to the node in question.

Regards


2015-02-10 11:36 GMT-06:00 Vandeventer, Harold [OITS] <
Harold.Vandeventer AT ks DOT gov>:

> Thanks Francisco... I'll try your approach.
>
> One other suggestion also mentioned lock node.
>
> It will impact only the one node, not all the  others that may be 
> connecting.
>
> As you say: patience is a virtue.
>
> And, no problems understanding your English.  Thanks again.
>
> PS: I can't DEFINE CLIENTOPT <name> .... the command line error returns:
>
> define clientopt STOPCOMM COMMRESTARTDURATION 0 FORCE=YES SEQ=1 
> ANR2056E DEFINE CLIENTOPT: Invalid option name - COMMRESTARTDURATION.
> Retry using the full optionname.
>
> I copied the option name from my own DSM.OPT....<argh>.
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of Francisco Javier
> Sent: Tuesday, February 10, 2015 11:28 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Stopping a client backup
>
> Try to:
> 1.- lock node
> 2.- cancel ses
>
> While the node are trying to send the data always will try to connect 
> at the TSMSERVER, in your case you are  backing Domino databases, in 
> this case the data is large and the node  could try for long time the 
> retry connect to TSM, be patient until the session cancel by himself 
> =)
>
> My apologies for my english I still learning ..
>
> Regards
>
>
>
> 2015-02-10 11:16 GMT-06:00 Vandeventer, Harold [OITS] <
> Harold.Vandeventer AT ks DOT gov>:
>
> > I'd not tried to DISABLE SESSIONS.....
> >
> > It seems the node side COMM settings would continue to reconnect 
> > every
> > 15 seconds (default) for the 60 minute (default) period.
> >
> > I can't keep DISABLE SESSIONS in place for that long.
> >
> > Since I can't get Admin Center to let me create an option set with 
> > COMMRESTARTDURATION and COMMRESTARTINTERVAL I'll look up the command 
> > line approach to creating an option set.
> >
> > My TSM server is doing all kinds of stuff..... can't be too 
> > overpowering or I blow off a few hundred node managers.
> >
> >
> >
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On 
> > Behalf Of Zoltan Forray
> > Sent: Tuesday, February 10, 2015 11:03 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: [ADSM-L] Stopping a client backup
> >
> > I will add my $.02 worth since I just went through this not 2-hours ago.
> >
> > I needed to perform special maintenance on my TSM servers.  I do a 
> > DISABLE SESSIONS on all servers and then I CANCEL SESSIONS from the
> server side.
> > The sessions immediately try to reconnect.  TDP clients are the most
> > aggressive:
> >
> > 02/10/2015 09:57:51  ANR2017I Administrator ZFORRAY issued command:
> > DISABLE SESSIONS  (SESSION: 66755)
> >
> > ..................
> >
> > 02/10/2015 10:01:32  ANR2017I Administrator ZFORRAY issued command:
> > CANCEL
> >
> >                       SESSION 65935  (SESSION: 66792)
> >
> > 02/10/2015 10:01:32  ANR0490I Canceling session 65935 for node 
> > OAK4.VCU.EDU
> >
> >                       (TDP Domino SUN) . (SESSION: 66792)
> >
> > 02/10/2015 10:01:32  ANR0524W Transaction failed for session 65935 
> > for node
> >
> >                       OAK4.VCU.EDU (TDP Domino SUN) - data transfer
> >
> >                       interrupted. (SESSION: 65935)
> >
> > 02/10/2015 10:01:32  ANR0405I Session 66792 ended for administrator 
> > ZFORRAY
> >
> >                       (WinNT). (SESSION: 66792)
> >
> > 02/10/2015 10:01:32  ANR0483W Session 65935 for node OAK4.VCU.EDU 
> > (TDP Domino
> >                       SUN) terminated - forced by administrator.
> (SESSION:
> >
> >                       65935)
> >
> > 02/10/2015 10:01:33  ANR0406I Session 66793 started for node 
> > OAK4.VCU.EDU (TDP
> >                       Domino SUN) (Tcp/Ip 192.168.20.139(32771)).
> (SESSION:
> >
> >                       66793)
> >
> > 02/10/2015 10:01:33  ANR0420W Session 66793 for node OAK4.VCU.EDU 
> > (TDP Domino
> >                       SUN) refused - server disabled for user access.
> > (SESSION:
> >                       66793)
> >
> > 02/10/2015 10:01:33  ANR0406I Session 66794 started for node 
> > OAK4.VCU.EDU (TDP
> >                       Domino SUN) (Tcp/Ip 192.168.20.139(32772)).
> (SESSION:
> >
> >                       66794)
> >
> > 02/10/2015 10:01:33  ANR0420W Session 66794 for node OAK4.VCU.EDU 
> > (TDP Domino
> >                       SUN) refused - server disabled for user access.
> > (SESSION:
> >                       66794)
> >
> > 02/10/2015 10:01:35  ANR0406I Session 66795 started for node 
> > OAK4.VCU.EDU (TDP
> >                       Domino SUN) (Tcp/Ip 192.168.20.139(32774)).
> (SESSION:
> >
> >                       66795)
> >
> > 02/10/2015 10:01:35  ANR0420W Session 66795 for node OAK4.VCU.EDU 
> > (TDP Domino
> >                       SUN) refused - server disabled for user access.
> > (SESSION:
> >                       66795)
> >
> > 02/10/2015 10:01:35  ANR0406I Session 66796 started for node 
> > OAK4.VCU.EDU (TDP
> >                       Domino SUN) (Tcp/Ip 192.168.20.139(32775)).
> (SESSION:
> >
> >                       66796)
> >
> > 02/10/2015 10:01:35  ANR0420W Session 66796 for node OAK4.VCU.EDU 
> > (TDP Domino
> >                       SUN) refused - server disabled for user access.
> > (SESSION:
> >                       66796)
> >
> > 02/10/2015 10:01:35  ANR0406I Session 66797 started for node 
> > OAK4.VCU.EDU (TDP
> >                       Domino SUN) (Tcp/Ip 192.168.20.139(32776)).
> (SESSION:
> >
> >                       66797)
> >
> > 02/10/2015 10:01:35  ANR0420W Session 66797 for node OAK4.VCU.EDU 
> > (TDP Domino
> >                       SUN) refused - server disabled for user access.
> > (SESSION:
> >                       66797)
> >
> > 02/10/2015 10:01:35  ANR0406I Session 66798 started for node 
> > OAK4.VCU.EDU (TDP
> >                       Domino SUN) (Tcp/Ip 192.168.20.139(32777)).
> (SESSION:
> >
> >                       66798)
> >
> > 02/10/2015 10:01:35  ANR0420W Session 66798 for node OAK4.VCU.EDU 
> > (TDP Domino
> >                       SUN) refused - server disabled for user access.
> > (SESSION:
> >                       66798)
> >
> > 02/10/2015 10:01:36  ANR0406I Session 66799 started for node 
> > OAK4.VCU.EDU (TDP
> >                       Domino SUN) (Tcp/Ip 192.168.20.139(32778)).
> (SESSION:
> >
> >                       66799)
> >
> > 02/10/2015 10:01:36  ANR0420W Session 66799 for node OAK4.VCU.EDU 
> > (TDP Domino
> >                       SUN) refused - server disabled for user access.
> > (SESSION:
> >                       66799)
> >
> > 02/10/2015 10:01:36  ANR0406I Session 66800 started for node 
> > OAK4.VCU.EDU (TDP
> >                       Domino SUN) (Tcp/Ip 192.168.20.139(32779)).
> (SESSION:
> >
> >                       66800)
> >
> > 02/10/2015 10:01:36  ANR0420W Session 66800 for node OAK4.VCU.EDU 
> > (TDP Domino
> >                       SUN) refused - server disabled for user access.
> > (SESSION:
> >                       66800)
> >
> > 02/10/2015 10:01:36  ANR0406I Session 66801 started for node 
> > OAK4.VCU.EDU (TDP
> >                       Domino SUN) (Tcp/Ip 192.168.20.139(32780)).
> (SESSION:
> >
> >                       66801)
> >
> > 02/10/2015 10:01:36  ANR0420W Session 66801 for node OAK4.VCU.EDU 
> > (TDP Domino
> >                       SUN) refused - server disabled for user access.
> > (SESSION:
> >                       66801)
> >
> > 02/10/2015 10:01:36  ANR0406I Session 66802 started for node 
> > OAK4.VCU.EDU (TDP
> >                       Domino SUN) (Tcp/Ip 192.168.20.139(32781)).
> (SESSION:
> >
> >                       66802)
> >
> > 02/10/2015 10:01:36  ANR0420W Session 66802 for node OAK4.VCU.EDU 
> > (TDP Domino
> >                       SUN) refused - server disabled for user access.
> > (SESSION:
> >                       66802)
> >
> > 02/10/2015 10:01:37  ANR0406I Session 66803 started for node 
> > OAK4.VCU.EDU (TDP
> >                       Domino SUN) (Tcp/Ip 192.168.20.139(32783)).
> (SESSION:
> >
> >                       66803)
> >
> >
> >
> >
> >
> > On Tue, Feb 10, 2015 at 11:28 AM, Andrew Raibeck 
> > <storman AT us.ibm DOT com>
> > wrote:
> >
> > > Hi Harold,
> > >
> > > This is interesting... what method are you using the cancel the 
> > > client sessions? If you cancel the session from the admin client 
> > > (CANCEL SESSION command), then the client should recognize that 
> > > the session was cancelled by a TSM server administrator and not 
> > > re-try the backup (though it may reconnect to report backup status).
> > >
> > > - Andy
> > >
> > >
> > > __________________________________________________________________
> > > __
> > > __
> > > ______
> > >
> > > Andrew Raibeck | Tivoli Storage Manager Level 3 Technical Lead | 
> > > storman AT us.ibm DOT com
> > >
> > > IBM Tivoli Storage Manager links:
> > > Product support:
> > >
> > > http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/T
> > > iv
> > > ol
> > > i_Storage_Manager
> > >
> > > Online documentation:
> > > http://www.ibm.com/support/knowledgecenter/SSGSG7/welcome
> > > Product Wiki:
> > >
> > > https://www.ibm.com/developerworks/community/wikis/home/wiki/Tivol
> > > i%
> > > 20
> > > Storage%20Manager
> > >
> > > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 
> > > 2015-02-10
> > > 11:21:16:
> > >
> > > > From: "Vandeventer, Harold [OITS]" <Harold.Vandeventer AT KS DOT GOV>
> > > > To: ADSM-L AT VM.MARIST DOT EDU
> > > > Date: 2015-02-10 11:23
> > > > Subject: Re: Stopping a client backup Sent by: "ADSM: Dist Stor 
> > > > Manager" <ADSM-L AT VM.MARIST DOT EDU>
> > > >
> > > > I'll investigate LOCK NODE.
> > > >
> > > > I've tried creating an Option Set with COMMRESTARTDURATION and 
> > > > COMMRESTARTINTERVAL but Admin Center 6.3.4.300 insists those are 
> > > > invalid options.
> > > >
> > > > I'm experimenting with my workstation node, and modified my 
> > > > preferences for those comm settings.  Then tried to copy the 
> > > > option name into Admin Center.... but not a valid option name
> apparently.
> > > >
> > > > Help in the baclient GUI indicates a server side option can 
> > > > override the node dsm.opt value.
> > > >
> > > > I'll try the new Operations Center, but not holding my breath there.
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On 
> > > > Behalf Of Skylar Thompson
> > > > Sent: Tuesday, February 10, 2015 9:52 AM
> > > > To: ADSM-L AT VM.MARIST DOT EDU
> > > > Subject: Re: [ADSM-L] Stopping a client backup
> > > >
> > > > "LOCK NODE" ought to do the trick. Or, if it's just a scheduled 
> > > > task, expire the schedule - "UPD SCH <domain> <sch-name>
> > EXPIR=today-1".
> > > >
> > > > On Tue, Feb 10, 2015 at 03:47:22PM +0000, Vandeventer, Harold 
> > > > [OITS]
> > > wrote:
> > > > > I've been fighting a scheduled backup issue for one node.
> > > > Probably a firewall issue.
> > > > >
> > > > > But, to keep management happy, a successful TELNET <ip>
> > > > <portnumber> will not suffice.
> > > > >
> > > > > I need to cancel the backup due to bandwidth issues across the
> > > > wire during daytime hours.  The normal schedule won't run until 
> > > > late in the evening.
> > > > >
> > > > > I've tried cancelling sessions, but the node end is re-
> > > > establishing sessions to keep the backup running.
> > > > >
> > > > > So, the question: How can I start a scheduled backup, then, 
> > > > > once I
> > > > see it is working, cancel it?
> > > > >
> > > > > Thanks.
> > > > >
> > > > > ------------------------------------------------------------
> > > > > Harold Vandeventer
> > > > > Systems Programmer
> > > > > State of Kansas - Office of Information Technology Services 
> > > > > STE 751-S
> > > > > 910 SW Jackson
> > > > > (785) 296-0631
> > > > >
> > > > >
> > > > > [Confidentiality notice:]
> > > > > **************************************************************
> > > > > **
> > > > > **
> > > > > ***** This e-mail message, including attachments, if any, is 
> > > > > intended for the person or entity to which it is addressed and 
> > > > > may contain confidential or privileged information.  Any 
> > > > > unauthorized review, use, or disclosure is prohibited.  If you 
> > > > > are not the intended recipient, please contact the sender and 
> > > > > destroy the original message, including all copies, Thank you.
> > > > > **************************************************************
> > > > > **
> > > > > **
> > > > > *****
> > > >
> > > > --
> > > > -- Skylar Thompson (skylar2 AT u.washington DOT edu)
> > > > -- Genome Sciences Department, System Administrator
> > > > -- Foege Building S046, (206)-685-7354
> > > > -- University of Washington School of Medicine
> > > >
> > >
> >
> >
> >
> > --
> > *Zoltan Forray*
> > TSM Software & Hardware Administrator BigBro / Hobbit / Xymon 
> > 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
> >
>