Tom,
Sorry for not responding sooner on your posting (and questions).
> Jay,
>> Does Harry's suggestion to put the jobOwner in the jmJobIDTable
> 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.)
> 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.
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?
> 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.
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