I like Patricks proposal
>I would like to suggest:
>user at host+jobnumber
>For example:
>root at dickory+024 or root at dickory.sdsu.edu+024
>The job ID embeds the user, originating host, and job number id
>into one 'string'.
>The job ID would fix up the problem of conflicts in job numbers
>which could occur from different hosts, if there was not a distinguisher.
>In addition, I like to see the user's name in the id.
I agree with Jay, that this does not fully satisfy the desire for a reliable
attribute that indicates JobOwner.
>The question now might be: can this format serve as a useful way to
>identify the job owner, thereby eliminating the need to have the
>jobOwner object in the jobState table?
>I still think the answer is No, due to the length restrictions for the
>jmJobSubmissionID object. If that object were to increase in size to,
>say, 63 bytes, then maybe this could work. (I can hear Harry cringing
>even as I write this... ;-)
I would *strongly* object to making jmJobSubmissionID any larger (as Jay
predicted). I believe we MUST keep in mind that we are moving job
identification from the paradigm of an element in a (LPR/LPD) submission
control file to an object in a job MIB. This implies database storage in the
printer with some degree of persistence (to be useful). Yes, I am defending the
"low-end" embedded controller, but I don't think any of us really want to
design a job MIB that no printers take advantage of.
>If the submission ID object were increased to 63 bytes (hey, or even
>more! ;-), then it might very well be that jobOwner can stay in the
>quickly-aged-out jobAttribute table.
So I am in favor of an LPR/LPD jmJobSubmissionID format (along the lines of
Patricks proposal) plus keeping JobOwner as a *mandatory* job Attribute. As Jay
points out, the job MIB does allow separate
persistence between the Job Table and the Attribute Table and does insist that
Job Table will persist as long or longer than Attribute Table. But, no where,
does the job MIB imply that the Attribute table
should age "rapidly".
The notion of JobOwner being a *mandatory* attribute, coupled with the idea
that this attribute must be "instantiated" as soon as the job is Pending should
allow the management or accounting application to
make an association between the jmJobIndex (effectively the printer assigned
job id) and the jobOwner during the Pending and Processing states. It is only
*after* the job has reached the Completed state that the two persistence clocks
start ticking.
Harry Lewis - IBM Printing Systems