[I have changed the Subject line to better reflect the topic]
Harry,
This statement has me somewhat bothered regarding which master we
are trying to serve with the Job MIB in general:
> Yes, we realized after Dave and Jay had left the meeting, that the size
> of jmJobOwner blows away the notion of keeping the Job Table terse.
What do you want? Good grammer or good taste?... ;-}
Seriously, some of us firmly believe in the importance of "out of band"
job monitors (ie, processes monitoring job progression without being
intrinsically part of the printing process, a la Unix and VMS). The
only consistent way to indentify jobs is through jobOwner, and hence,
this data must be available for as long as the job entry exists in the
agent.
Those who will be using the Job MIB as an intrinsic part of the
printing process are lucky (eg, Windows, OS/2, etc). (We envy you,
believe us!) If someone can state a justifiable case for being able to
monitor jobs with jobOwner, then great! (And please do so soon!)
Otherwise, we need that data for the duration of the job entry.
...jay
------------------------------------------------------------------------------
> >> Issue 76 - So should jobName, jobOwner, and one of deviceNameRequested or
> >> queueNameRequested be made Mandatory?
> >> Closed: Only jobOwner is made mandatory, but it will remain in the
> >> Attribute table, rather than being moved to the Job table.
>> >Hmmm... Is this really what we agreed to? I submitted that jobOwner
> >should be a fundamental part of job identification (and gave lots of
> >examples of existing systems where this value is the only meaningful
> >identification item across multiple types of spooling systems).
>> >By making jobOwner an "attribute", there is a serious risk of losing
> >this information when the agent "ages out" attribute information.
> >(The reader should recall that "attributes" are designed primarily
> >for accounting purposes, and these values are able to be removed from
> >the agent's store in a faster manner than the jobState values.)
>> >I worry that an agent will age-out the jobOwner too soon, thereby
> >making it impossible to identify jobs for a target user.
>> >Can we please discuss this issue on the list asap?
>> Yes, we realized after Dave and Jay had left the meeting, that the size
> of jmJobOwner blows away the notion of keeping the Job Table terse.
> In the minutes, which I posted this morning, I took the liberty to
> address this a bit. One, rather simple approach, if Job Owner really
> is a "meaningful id across multiple types of spooling systems", is to
> truncate it to 30 bytes and register it as one of the jmJobSubmissionID
> formats. I'm not sure how the format ID would get tacked on, however,
> but this can probably be worked out (have the NIC build it from the LPR
> control file?).
>> An excerpt from my minutes asks:
>> If the design point is to facilitate a job state notification broker that lives
> outside of the submission
> framework and correlates users (notification recipients) with print jobs
> strictly based on identification
> provided via LPR, we need to have this stated.
>> Is this what we are worried about? There seem to be only two other
> major scenarios. If the job Monitor is involved with submission (as in an
> NT Port Driver for example), there is a place to couple submission and
> monitoring via jmJobSubmissionID. If the monitor is fundamentally an
> accounting application, then leaving jmJobOwner in the Attribute table
> should not be a problem.
>> I guess we do loose the ability to guarantee showing the owners name in
> a simple overall queue view but this problem can be minimized by "fetching"
> the jmJobOwner from the Attribute table for Pending jobs and storing this
> association in the job Monitor application until the application is no
> longer concerned with the job. This assumes the owner's name is static,
> which will be the practical case.
>> I think, if this is still an issue, we need to get more examples on the
> table. I had proposed some additional alleviates in my complete set of
> minutes.
>> Harry Lewis - IBM Printing Systems