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

Reply via email to