On Sunday 26 February 2006 15:36, Eric Bollengier wrote: > Hi, > > I have to run jobs in a synchronous way for integrate them into a complex > network scheduler (RunBefore and RunAfter are not sufficient for me) > > I want to add 2 options on wait command. > - jobid=nnn > - job=xxx > > My patch allow to use "wait jobid=253" or "wait job=Client1" > > [EMAIL PROTECTED]:~$ ./bconsole > Connecting to Director zog:9101 > 1000 OK: zog-dir Version: 1.39.5 (20 February 2006) > Enter a period to cancel a command. > *run job=Client1 yes > Using default Catalog name=MyCatalog DB=bacula > Job started. JobId=161 > *wait jobid=161 > JobId=161 > JobStatus=OK (T) > ShellStatus=0 > > I will submit shortly a bacula_run.pl which use it. (to get > simple shell interface with a clean exit status) > > i hope i'll be useful to anyone else so i'd like it to be included. > > Regards.
I haven't yet looked at the patch, which I will do shortly. However, I have no problem extending the wait command to add such extensions. There is one problem that is an issue (not your fault) that has also come up in the list command as well. The problem is a sort of naming problem (and certain inconsistency) in referring to jobs. With each job, there are three things: 1. The Job name that is the name that appears on the Name directive in the Job resource. In your example above, "Client1" is a job name. 2. The JobId, which is a non-unique number assigned to the Job that ran. It is unique within a given director and within the life of the Job record in the database. Once the job is removed, the jobid can be reused for a different job. 3. The Job (a unique identifier for a job that runs). The Job looks something like kernsave.2006-02-25_12.38.07. I.e. it is a combination of the Job Name and the date/time the job ran. No two jobs start at the same time, so it is unique -- providing you never use the same JobName in a different director. If ever we support multiple directors, the algorithm for creating a unique Job can be enhanced. You can see these Jobs for yourself by looking at the output from any Job, or by doing the following: ./bconsole sql select job from job; Now before adding any additional code that uses a keyword Job, I would like to get a clear definition of these three items. The problem I have with the name "Job" is that for most users, that word means what I call the JobName. There is even a bug open on this issue because the reporter doesn't understand the distinction between Job and JobName. Probably the best solution to this problem is to use the words "Job" and "JobName" to refer to item 1 above, and to find a new name for item 3. If anyone has any suggestions on what to call it, please speak up. Best regards, Kern ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users