Re: [help-gnubatch] Variable use

[Reuti]

Hi,

Am 12.03.2012 um 22:05 schrieb Wechsler, Steven:

> I’m still a little confused by the use of variables. Hopefully someone can 
> answer these questions:
>  
> 1.       Does a variable need to be defined before it can be assigned in 
> gbch-r?

yes.


> 2.       Many of our jobs are tied to specific database instances, which we 
> tend to shuffle around from host to host due to performance or space 
> requirements. Is there a way that variables can be defined as “global” so 
> that other jobs don’t need to know which host variables are located on, or do 
> I need to just set aside a single host that will hold all variables?
> 3.       If I want to set up a job dependent on the successful completion of 
> another job, how can the secondary job tell the difference between the 
> successful variable setting from yesterday’s run and today’s run? For 
> example, let’s say I have two jobs, job_master and job_slave. I have 
> job_master scheduled to run daily, and to set a variable called 
> MASTER_COMPLETE=1 when it finishes. Job_slave is also scheduled to run daily, 
> and to only start once it sees MASTER_COMPLETE=1. If job_ master  ran 
> successfully yesterday, when job_slave is scheduled, it will see that 
> MASTER_COMPLETE is still set to one, think thatjob_master finished 
> successfully, and will start running, even though job_master has not yet run. 
> If this is the case, then I can think of a couple of ways to get around this 
> problem, but none of them are ideal:

Also the job_slave could reset the variable MASTER_COMPLETE.


> a.       Make sure job_slave is scheduled to start after job_master. But can 
> job_master automatically unset MASTER_COMPLETE when it starts? This solution 
> is not ideal because it requires that any changes to job_master’s scheduled 
> time also be made to job_slave’s scheduled time.
> b.      Set up a separate job to unset MASTER_COMPLETE at some time after 
> job_slave finishes running. This is less than ideal because it adds a whole 
> new layer of complexity regarding all the additional jobs required to manage 
> this.
> BMC’s Control-M deals with this problem by having each variable get a new 
> copy at the start of a new day (And the new day can be defined to be any time 
> of day). Variables from previous days can also be referenced.

$ gbch-r -f S -s 'MASTER_COMPLETE=0' -f N -s 'tMASTER_COMPLETE=1' job_master
$ gbch-r -c 'MASTER_COMPLETE=1' -f N -s MASTER_COMPLETE=0' job_slave

At start the master will reset the variable for safety reasons, and to one on 
its normal completion.
The slave will also reset it upon exit.

You could also implement a small finite state machine, where MASTER_COMPLETE 
shows the actual state:

MASTER_COMPLETE=0 => idle
MASTER_COMPLETE=1 => running master
MASTER_COMPLETE=2 => master ended
MASTER_COMPLETE=3 => running slave
MASTER_COMPLETE=0 => slave ended

$ gbch-r -c 'MASTER_COMPLETE=0' -f S -s 'MASTER_COMPLETE=1' -f N -s 
'MASTER_COMPLETE=2' job_master
$ gbch-r -c 'MASTER_COMPLETE=2' -f S -s MASTER_COMPLETE=3' -f N -s 
'tMASTER_COMPLETE=0' job_slave

-- Reuti