Hi, as I mentioned, put in presched .bat file that runs RMAN backup and once it is finished run backup of the files produced by RMAN ... It works, I am using ....
On Tue, Dec 25, 2012 at 7:56 AM, Roger Deschner <rog...@uic.edu> wrote: > 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 rog...@uic.edu > =================== Beware of Geeks bearing grifts. ==================== > > > On Mon, 24 Dec 2012, Nick Laflamme wrote: > >>On Dec 24, 2012, at 12:31 PM, nkir <tsm-fo...@backupcentral.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 kniko...@gmail.com via Backup Central. >>> |Forward SPAM to ab...@backupcentral.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