Good question Jay, where is the lastest Job MIB draft?
My thoughts:
>>> JK Martin <jkm at underscore.com> 09/27/96 09:45am >>>
Some comments about your posting:
> I propose that jobCopiesRequested" be change to
> "jobCopiesCompleted" and moved into the accounting group. The
> remaining items should be removed.
Could it be that both kinds of objects are desirable? (Yeah, this
coming from the person who says "No more than 20 objects!!"...)
If we support both, then would we have reasonable measure of relative
completion for the job? (Or is "job progress" better denoted from
other proposed objects?)
>>> JK Martin <jkm at underscore.com> 09/27/96 09:45am >>>
Yes, both are desirable.
>>> JK Martin <jkm at underscore.com> 09/27/96 09:45am >>>
> 4. What value does "jobName" add to the identification group? Is
> this value sufficient to warrant the inclusion of this object?
> I propose that this object be removed.
Just as in our recent discussions about the need for an "administrative
name" for a printer (in the Printer MIB), it would seem both natural and
useful to have an equivalent object for a job. Anyone else out there
have a similar feeling? (Or counter-feeling?)
>>> JK Martin <jkm at underscore.com> 09/27/96 09:45am >>>
It seems to me that it is useful to have a Job name. This is often
something that was generated by the client (application or redirector)
that gives the end user some comfortable feeling about what the job is
rather than a cold, and impersonable Job ID. A user communicating with
some operator naturally wants to use the name rather than the ID.
> 5. Are items #2 and #3 in the identification group needed? These
> objects appear to provide only routing information. I do not
> feel that routing information adds any value for job monitoring.
> These objects do not add any significant information required
> for job identification.
Quite frankly, tackling the problem of "job routing" is pretty scary
to me. My biggest fear along this line is that in order to maintain
integrity of the MIB data for a job, several (relatively) independent
processes--quite likely on different network hosts--will have to update
certain job values at certain times. This could be a real killer, both
in terms of implementation and access control.
Anyone else share these feelings?
>>> JK Martin <jkm at underscore.com> 09/27/96 09:45am >>>
One last comment, of a general nature. Could it be that in order to
satisfy DPA-related capabilities, we should define TWO Job MIBs, one
for "basic" needs, and a second version that augments the "basic"
version?
>>> JK Martin <jkm at underscore.com> 09/27/96 09:45am >>>
No. We just need to work out the basic one that is the largest subset of
the interesection all job submission protocols attributes and properties.
Scott I.