Hi Robert, thanks for the followup.
This was reported by IBM as a known issue with 6.4. OC
http://www-01.ibm.com/support/docview.wss?uid=swg21640656#OC_641_known_issues__DISK_critical
Regards,
Hans Chr.
On Tue, Feb 10, 2015 at 8:16 PM, Robert Jose wrote:
> Hi Hans Chr.
> Thanks for the fee
Hi Hans Chr.
Thanks for the feedback on your experience with Operations Center. I
understand your frustration and would be frustrated in your shoes also. I
also wanted to explain why we decided to couple TSM Server with Operations
Center and why we think in the long run it is the correct choice. Th
Thanks Yann.
I had based my attempt on creating a server-side option set based on the help
in the client-side GUI.
Actually, I can't find the help item now.
I THOUGHT I had read that server could override those but apparently not.
Thanks again to all.
-Original Message-
From:
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.
Hi,
You can find a list of options available here :
http://www-01.ibm.com/support/knowledgecenter/?lang=fr#!/SSGSG7_7.1.0/com.ibm.itsm.client.doc/c_opt_setbyserver.html
I think the option COMMRESTARTDURATION is available on the client side.
Best Regards,
Yann MEUNIER
-Message d'origine-
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.vandeven...@ks.gov>:
> Thanks Francisco... I'll try your approach.
>
> One oth
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 .
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 c
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
COMMR
Hi,
maybe changing the tcpport of your tsm server temporarily
...
maintenance
...
etc
Ce message est confidentiel et est à l'usage exclusif du destinataire
identifié ci-dessus. Toute autre personne est, par les présentes, avisée
qu'il lui est strictement interdit de le diffuser, de le distribuer
I had used the CANCEL SESSION command from Admin Center Command prompt
line.
It continually re-established sessions and I finally let it roll to completion.
That was for a drive that had previously backed up, with almost no change, so
I wasn't too worried about bandwidth.
The node I'm tr
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
aggressi
Replying to my own post when you cancel a scheduled backup session,
here is what I would expect to see. Note the key message, ANS1369E.
-
Normal File--> ** Unsuccessful **
ANS1809W A session with the TSM server has been disconnec
You could always kill/stop the scheduler process/service on the client, then
start it up again later in the day or in the evening...
On 02/10/2015 10:25 AM, Vandeventer, Harold [OITS] wrote:
> I had tried to cancel by deleting the schedule; but sessions continued to
> re-fire.
>
> I'll try this
Go to the client and stop the scheduler process
> On Feb 10, 2015, at 8:28 AM, "Vandeventer, Harold [OITS]"
> wrote:
>
> I had tried to cancel by deleting the schedule; but sessions continued to
> re-fire.
>
> I'll try this on my workstation node, where "breaking things" is a bit more
> acce
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 m
In my experience, you can only LOCK the node if it isn't active/connected.
The automatic restarts/reconnects are part of the clients ability to handle
communications problems.
I would first DISABLE SESSIONS on the server and then LOCK the node and
then ENABLE SESSIONS
On Tue, Feb 10, 2015 at 11:2
I had tried to cancel by deleting the schedule; but sessions continued to
re-fire.
I'll try this on my workstation node, where "breaking things" is a bit more
acceptable.
Thanks.
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Rick
Adamson
S
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 th
The re-established connections probably occur because the scheduled backup
event is still active.
Take a look at the schedule duration and make sure that it expires before
undesirable hours.
For example:
Let's say you have a schedule for 5:00am and a duration of 6 hours.
You notice it is still r
"LOCK NODE" ought to do the trick. Or, if it's just a scheduled task,
expire the schedule - "UPD SCH EXPIR=today-1".
On Tue, Feb 10, 2015 at 03:47:22PM +, Vandeventer, Harold [OITS] wrote:
> I've been fighting a scheduled backup issue for one node. Probably a
> firewall issue.
>
> But, to
I've been fighting a scheduled backup issue for one node. Probably a firewall
issue.
But, to keep management happy, a successful TELNET 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 th
22 matches
Mail list logo
