Jay,
Does Harry's suggestion to put the jobOwner in the jmJobIDTable
as another form of job submission ID>
Presumably, the jobOwner would also go in the jmAttributeTable too,
where it would be for any jobsubmission id format, ok?
The reason for duplicating the jobOwner in the jmJobIDTable is because
the persistence is longer (same as the jmJobTable) than in the
jmAttributeTable. This idea will work for those systems that don't
support the idea of a jobSubmissionID that is a unique ID generated by
the client or the server/printer.
So are there any applications that would need both the real job
submission id and the job owner, after the jmAttributeTable entry
as been deleted? If applications copy the jobOwner sometime while
the job is pending, processing, or completed, before the attributes
are deleted, there won't be a problem. But if applications are memoryless
and don't copy the attribute table, then the jobOwner would be lost,
except for systems that don't have a real job submission id and use
the job owner as the job submission id.
One BIG problem with Harry's solution is that if the same user submits
another job, the jobOwner will be the same, so that that would replace
the previous row in the jmJobIDTable, since jmJobSubmissionIndex is
a 32-octet index into the table. A solution would be to add another
index to the jmJobIDTable, which would be the jmJobIndex, so that the
agent could guarrantee that each entry wouldn't overwrite a previous
entry. We do this in our Xerox private Job Monitoring MIB.
Comments?
Tom
At 07:38 05/23/97 PDT, Harry Lewis wrote:
>Jay, I think you have answered my question... you *are* concerned about
>tracking job progress and notifying clients even though you are "out of band".
>Given this, I think I see why you need jobOwner to have the greatest
>persistence (although, honestly, I fear this is Pandora's box, and soon, we
>will learn that jobOwner is really not enough - if this is likely, I'd rather
>it surface NOW!).
>>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 at underscore.com> 05/22/97 05:56 PM
>Please respond to jkm at underscore.com @ internet
>>>To: Harry Lewis/Boulder/IBM at IBMUS>cc: jmp at 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 -
>>