On Sunday 27 November 2005 07:08, Ross Boylan wrote:
> On Fri, Nov 25, 2005 at 11:08:50PM +0100, Kern Sibbald wrote:
> > On Friday 25 November 2005 22:32, Ross Boylan wrote:
>
> ....
>
> > > What should we call those things that are scheduled but have not yet
> > > run?
> >
> > Good question. I don't know. Maybe Scheduled Jobs as opposed to Running
> > Jobs. This may be the terminology I use in the status output ???
>
> Yes, it is.
>
> > > >When a job is deleted, it is removed from the
> > > > database, so delete is not a term to use in this Bacula context. The
> > > > scheduling of a job could be skipped (perhaps the user would like to
> > > > consider this canceling, that is OK).
> > >
> > > Is "cancel" the right word to describe what I'm looking for? I want
> > > the thing that is scheduled not to run, and to be removed from the
> > > list of things scheduled?
> >
> > More suitable word might be "skip" if you want the next scheduled time
> > for a job to be skipped, or "disable" if you want to turn off all future
> > scheduling ...
>
> This exposes an ambiguity in the use of "job." On the one hand, it
> can refer to a particular piece of work, which would be identified
> with a jobid if it succeeded. On the other hand, it refers to a
> general request for work. In the first sense, the job is killed; in
> the second sense, it is only skipped or postponed.
>
> In support of interpretation one (job = pariticular work at a
> particular time):
> 1) the output of bconsole status dir, which refers to scheduled,
> terminated and running jobs (which make little sense if job has the
> second sense);
> 2) The use of job, and the Job class, in the discussion of python
> scripting in the current manual (1.38);
> 3) the usual useage with computers of job (IMHO).
>
> In support of the second interpretation (job = general request for work):
> 1) The meaning of the Job keyword in the director file;
> 2) the use of the Job attribute in python scripting ("The following
> read-only attributes are available with the Director for the job
> object.");
> 3) The terminology entry for "job" in the current manual: "A Bacula
> Job is a configuration resource that defines the work that Bacula must
> perform to backup or restore a particular Client."
>
> I'd say that none of this matters, except that I seem to be getting
> tripped up a bit by it :) And the presence of python scripting seems
> to be exposing more of these clashing interpretations.
Well, I think this ambiguity has been around since the beginning of computers
when I held my job in my hands (a stack of punched cards), and later my job
was running, and I got my job output, then I ran it again and got a different
job output with the same name.
It is the same with C++ classes. There is a class named x, then when running
there are lots of invocations of class x all with different names. I
probably should have called Jobs "Classes", but that would have been too
abstract ...
>
> Ross
>
> > We might be able to do something like:
> >
> > skip job=Job-name
> >
> > which would skip the next scheduled time for Job-name
> >
> > and
> >
> > disable job=Job-name
> >
> > which would turn off all future scheduling of Job-name until:
> >
> > enable job=Job-name
> >
> > but this is a Feature Request that someone would need to submit ... :-)
> >
> > Oh, yes, disable and enable should probably work for other things such as
> > Autochangers and Devices too -- hmmm perhaps even someday Storage daemons
> > and Clients ...
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
