Subject: Re: JMP> ISSUE: Putting jobOwner in the jmJobIDTable?

From: Tom Hastings <[email-masked]>
Date: Tue, 27 May 1997 14:35:13 PDT

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
> ---------------------------
>
>        [email-masked]
>        05/22/97 05:56 PM
>Please respond to [email-masked] @ internet
>
>
>To: Harry Lewis/Boulder/IBM@IBMUS
>cc: [email-masked] @ 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 -
>
>

---

From: JK Martin <[email-masked]>
Date: Thu, 29 May 1997 19:01:42 -0400 (EDT)

Tom,

Sorry for not responding sooner on your posting (and questions).

> as another form of job submission ID>

Sorry, but this sentence is incomplete (no?).  Restate the question?
(This may not be necessary if the rest of this message addresses your
thought.)

> the client or the server/printer.

I don't think the jobOwner variable has to exist in two places.  No
data should be replicated in any other part of a MIB-based model (as
recommended by the SNMP/MIB gurus), right?

> the job owner as the job submission id.

Look, if certain informational components of a job can be "aged out" over
time, then applications must have a way to uniquely identify jobs while
the remaining info is available.  It really has nothing to do with the
infamous "memoryless" application design--if the app doesn't get to the
agent before the data is aged out, then it doesn't matter how much state
baggage the app carries around.

In other words, jobOwner must be available for the life of the job in
the agent.

	...jay