Force schedule to start

[bcetin]

Hi there,

I'm not very experienced with TSM so please correct me for any mistakes. I'm developing a script to re-schedule the clients that failed during nightly backup to start immediately every morning. The script will run each morning and do this:

1- Check for failed backups yesterday:
"q ev * * begindate=today-1 exc=YES enddate=today f=d"

2- My script parses the output and get the node_name, domain_name, status (failed, missed, success.. etc) and whatever values necessary, then put them in variables.

3- Script constructs a re-schedule command for "failed" and "missed" backups and executes it on TSM Server:
"define schedule (domainname) (random created unique schedule name)ACTION=INCREMENTAL PRIORITY=5 STARTDATE=(today) STARTTIME=(2 minutes after the script run time) DURATION=1 DURUNITS=HOURS PERIOD=1 PERUNITS=ONETIME DAYOFWEEK=ANY EXPIRATION=(today)"

4- Script constructs an association command for missed and failed nodes, executes it on TSM Server.
"define association (domain_name)(unique schedule name from step 3)(node_name)

Now all is fine, my script correctly does all of the above, creates the schedules and associates them with nodes. As you can see, the schedule is set to start after 2 minutes and with a duration of 1 hour. However, some of my nodes does not start the schedule because of the schedule refresh time. When I look with dsmcad on these nodes, they list the schedule fine but the schedule does not appear in the dsmsched.log file until I restart the client service. Then my schedule is written to the log file and starts in a 1 hour time. On the other nodes, the reason that the schedule starts is that by chance, the schedule refresh time is just after the script run time.

Now I wonder how I can trigger the nodes to take up the schedule? The "session initiation" option is set to "Client or Server" which I thought would be useful but no chance. Why doesn't the TSM server tell the client to start when the schedule time comes? Or does it with some config?

Please ask if anything is unclear. Thanks.

 

[moon-buddy]

Try starttime=now or see "help define clientopt"

 

[bcetin]

Try starttime=now or see "help define clientopt"

Hi, thanks for the reply.

I have tried "starttime=now" and when it didn't work, i decided to pull it 2 minutes forward, so the starttime does not point to a past time (when the node gets the schedule form server) which I thought to be the problem. Seems it's not.

My problem here is the node does not refresh its schedule each minute and does not see my schedule until the refresh time, sometimes more than 6 hours. I can set this within the optfile but that will create a huge load as I'm talking about over 1000 nodes that will connect to TSM server each minute and check for new schedule.

I'm trying to find if there is a server-side method to trigger the node at the schedule start time to force the node to check for the schedule or something like that.

 

[chad_small]

Your problem it the clients are set to polling. If you want them to run "NOW" you need to have them set to SCHEDMODE PROMPTED. With that many clients it's actually better to have all the nodes set to PROMPTED since then the TSM server will regulate their start time. You can set the SCHEDMODE in a client option set and force it on the clients but a restart of the client scheduler service or process is required.

 

[dms19]

Also remember in many cases "failed" backups are backups that ran successfully with some type of error causing it to error out. Rerunning these will really only chew up your "backup" window and give you nothing gained.

For the clients that missed, even with the schedmode set to prompted, many times the scheduler doesnt exit gracefully and will not pick up the clientaction schedule anyway. You'll still have to jump onto each client and recycle the service.


my $0.02

 

[bcetin]

Your problem it the clients are set to polling. If you want them to run "NOW" you need to have them set to SCHEDMODE PROMPTED. With that many clients it's actually better to have all the nodes set to PROMPTED since then the TSM server will regulate their start time. You can set the SCHEDMODE in a client option set and force it on the clients but a restart of the client scheduler service or process is required.

Hi chad, I think you hit the point. My SCHEDMODE option is set to ANY. I understood from the document that ANY means either PRompted or POlling, am I wrong?. But it seems my nodes are only working in Polling mode.

And also from the help file of "define sched" command, I see that "options" can be defined. Can I use this to only make these schedules in "prompted" mode? If can be done, what is the syntax? From the help file it must be something like this:

def sched ...... options='-schedmode=prompted' .....

but I couldn't get it working.

@dms19

Thanks for your recommendation, but we have some specific node-side environmental problems that arise often and we solve by just starting a manual backup. This script will check these special situations and at least reduce the number of nodes I must step on every morning

 

[chad_small]

POLLING is the default so you need to set your SCHEDMODE to prompted directly. You can't set the schedmode from the client schedule only from the dsm.opt file or an client options set. Make the change and restart the processes or services and you should see a dramatic change.

 

[bcetin]

POLLING is the default so you need to set your SCHEDMODE to prompted directly. You can't set the schedmode from the client schedule only from the dsm.opt file or an client options set. Make the change and restart the processes or services and you should see a dramatic change.

Before I make that change, I would like to be sure about another point. In polling mode, my nodes pick up their nightly schedule, say at 22:00, and start it when it's possible, some of the nodes start about in 2 to 4 hours. I don't exactly know why this happens, but I think the node decides the best time to start the session by looking at server load or something. Whatever it does; this works pretty well. Will I keep this functionality when I switch to Prompted mode? Or will this just change the way of reminding the node that it schedule time arrived and again leave the start time decision to client?

 

[Kelvin]

There is an option on the tsm server where you can specify the randomization of the times the backup starts. All depends on your schedule duration, I think you prob have it set to one day..

Before I make that change, I would like to be sure about another point. In polling mode, my nodes pick up their nightly schedule, say at 22:00, and start it when it's possible, some of the nodes start about in 2 to 4 hours. I don't exactly know why this happens, but I think the node decides the best time to start the session by looking at server load or something. Whatever it does; this works pretty well. Will I keep this functionality when I switch to Prompted mode? Or will this just change the way of reminding the node that it schedule time arrived and again leave the start time decision to client?

 

[bcetin]

Hi Kelvin,

Yes Duration is set to 1 day in most of the schedules. If this is the reason of the randomization, then it won't be affected by Polling or Prompted modes.

Thanks for all the help people.

 

[sandeepkontham]

@bcetin

Duration which is defined in schedule ----> backup should start in that period ( 1 day => by the end of 24 hours)

Randomization => Different client schedules which are starting at same time are distributed by TSM server based on load.

I guess in your problem:

The best way is
1) define a client option set
2) define schedmode prompted with force=yes
3) associate to the relevant nodes


But i dont think a failed backup completes successfully next time without troubleshooting but yes 20-30% of backup will run fine ( which are failed bcoz of VSS, time/window bound issues).


you can also decrease queryschedperiod in polling mode or else if possible why dont you write a script to restart the TSM services of failed nodes.