Not all commands have a WAIT=YES option available. If the command has
WAIT=YES, use it. It's really the easiest way. PITFALL: A TSM script
containing a long-running command with WAIT=YES should never be run from
a live console, not even for testing and debugging. It should only be
started by an administrative (T=A) schedule. If you accidentally start
it from a live dsmadmc console session, your terminal session will be
stuck until it finishes. Attempts to break out can result in an infinite
loop on your client machine. Last time I did this, my SSH client crashed
and it was ugly. Unix tricks like <ctrl>Z and bg don't work.

One in particular which lacks WAIT=YES that I have posted here in the
past is AUDIT VOL. I had to invoke it from a Unix script that loops with
a 60-second sleep that checks if it's still running, and if it is no
longer there, it queries the actlog to see if it ended OK.

Crude, but it works.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
=================== Beware of Geeks bearing grifts. ====================


On Mon, 24 Dec 2012, Nick Laflamme wrote:

>On Dec 24, 2012, at 12:31 PM, nkir <tsm-forum AT BACKUPCENTRAL DOT COM> wrote:
>
>> Thank you! I know about these options. But how exactly I can apply them?
>> How to check that DB backup was successful and I can proceed next task?
>>
>> +----------------------------------------------------------------------
>> |This was sent by knikonor AT gmail DOT com via Backup Central.
>> |Forward SPAM to abuse AT backupcentral DOT com.
>> +----------------------------------------------------------------------
>
>I'm not sure what you mean by "these options," so I'll start with the obvious 
>ones and let you tell us if these are what you already know.
>
>Presumably you're talking about running a script as an administrative schedule.
>
>Scripts can run in two modes: parallel and serial. If you want to make sure 
>one command finishes before another starts, you must be in serial mode. Also, 
>my observations make me doubt that serial mode is honored if a script calls 
>another script.
>
>A script can branch based on the return code from a command. One way to do it 
>would be to branch for a successful backup, where the non-branch code-path 
>would be a very general error routine. Alternately, you could branch on 
>various return codes you expect to get and have different error routines for 
>each error, but that is more than I do.
>
>Finally, remember that many commands by default run in the background. BACKUP 
>DB by default only tells you that it started. If you want to wait for it to 
>finish and check its return code then, you need to use the WAIT=YES option on 
>it. This is true for many long-running administrative commands.
>
>Nick