TSM Topics Feed

Thursday, July 23, 2009

TSM Server Scripts Sleep Option

I have been frustrated with the lack of a sleep command with TSM scripts for a long time and just today a co-worker sent me this link which I think sums up how we've had to get around the it within TSM server scripts. The WAIT=YES option is only good for commands that allow it, and is not exactly what many of us need in certain situations. Since this document's modified date shows as 7-23-2009, I will take it that there is no respite from the issue with TSM 6.1. Basically IBM recommends you break the script in two and where you need the sleep you have the script schedule a onetime schedule of the secondary script for X number of minutes in the future. It does work. I've use this process on some scripts, but you'd think they would have added a sleep option by now. So I assume when it's absolutely needed many of you resort to a regular shell script to execute tasks, any alternate processes than that? I'd like to hear about it.


  1. Hi Chad, in Richard Simms' Quickfacts there is some information about this:

    There are occasions in server scripts where you need to introduce a delay between operations; but there is no TSM "Sleep" command or the like. A simple way is to add a Query or SHow command within your server script, which know in your environment to take some time. One example is SHow VOLUMEUSAGE, which we know to take time but produce little output. A more sophisticated but complex method is to define another server script named SLEEP, which performs: DEFine CLIENTAction NodeName ACTion=Command OBJects='sleep ""$1""' Wait=Yes which can then be used within a server script like: RUN SLEEP 30.

    In this case, he uses a command schedule to trigger the sleep command on the OS with the amount of seconds as a parameter. Pretty clever.

    As we all know, Richards' Quickfacts can be found here:

  2. Best regards,
    Tommy Hueber

  3. Hi Chad!
    Whenever you have more comples scripting and scheduling stuff to do I'd recommend "outtasking" this to a shell script on the OS level. Running on an non-UNIX OS this may imply installing something like cygwin, perl etc.
    Some of my clients also use external schedulers for admin and client tasks instead of the TSM built-in solution in order to have only one scheduler in task for every automation task in their environment.

    Best regards,
    Michael Abel