Finn, I don't know about manual starts of the client but for scheduled events the parameters MAXCMDRETRIES and RETRYPERIOD work together to control the number of times a client scheduler attempts to contact the server if the server is not responding - for whatever reason - at the allotted scheduled time. The client establishes that a connection cannot be made ( this in itself may take some time depending on O/S and network setup ) then counts down Retryperiod minutes, attempts to reconnect - if it fails it then counts down Retryperiod minutes and attempts again. This it does Maxcmdretries times. Note that these parameters only manage the behaviour of client schedules that have not yet started to backup or schedules that have completed the backup and are attempting to report the results back to the server. Note also that these parameters can be set at the server end as well and if so, override the settings at the client end.
If a scheduled session has already started and is interupted - for example network outage - the Commrestartduration and Commrestartinterval parameters specify the number of minutes and the interval in seconds that the client should attempt to reconnect. These are set just at the client end. Note that the operation of these parameters can mean that a scheduled backup can take place *outside* of the scheduled backup window at the server - something we've found difficult to handle. The 4.1 client documentation does say something about "the schedule fails if a communication failure occurs and the client cannot reconnect with the server before the startup window for the schedule ends". However, this is wrong - the schedule status in the events table now gets set to restarted at the server and the schedule will complete - this is documented by PC44954 anAPARs IC31350 and IC31464. This behaviour can be a complete pain if for example, your server hangs midway through a bunch of scheduled client backup sessions, you restart the server and probably want to do something to redress the conditions that caused the hang - maybe a BACKUP DB or MIGRATION or or .. however, clients retrying and reconnecting to start or restart their backups can seriously interfere with this. The solution is to set the MAXCMDRETRIES to zero or RETRYPERIOD to something like 0 and 720 - this will give you 12 hours free of client retries - and set COMMRESTARTDURATION to something small. HTH ------------------------------------------------------------------- Ian Smith Oxford University Computing Services, Oxford, UK. ------------------------------------------------------------------- ~>MIME-Version: 1.0 ~>Date: Thu, 7 Feb 2002 11:23:45 +0100 ~>From: "Leijnse, Finn F SITI-ITDSES31" <[EMAIL PROTECTED]> ~>Subject: connection retry from client. ~>To: [EMAIL PROTECTED] ~> ~>Hi all, ~> ~>I was wondering what is the setting in the dsm.opt to make a client retry ~>it's connection, if for example one of the two IP adresses to connect to the ~>TSM server fail. ~> ~>> met vriendelijke groeten, regards et salutations, ~>> ~>> Finn Leijnse ~>> ISES/31 - Central Data Storage Management ~>> Shell Services International bv. ~>>