So, what about my proposal to add a new jmJobSubmissionID format for LPR
JobOwner? The owner information would have to be truncated to 30 bytes and
someone, most likely the NIC, would have to prepend the assigned
jmJobSubmissionID format number to the attribute.
By definition, the JobID table has the same persistence as the Job Table - each
guaranteed to have the longest persistence.
Harry Lewis - IBM Printing Systems
---------------------- Forwarded by Harry Lewis/Boulder/IBM on 05/22/97 06:11 PM
---------------------------
jkm@underscore.com
05/22/97 05:56 PM
Please respond to jkm@underscore.com @ internet
To: Harry Lewis/Boulder/IBM@IBMUS
cc: jmp@pwg.org @ internet
Subject: Re: JMP> Changes agreed to for Job Monitoring MIB last week,
[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
Harry Lewis -