Harry,
Sorry for not responding to your question sooner...
> 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.
Your proposal (as documented in the San Diego meeting minutes, page 4)
suggested this encoding of the 30 available octets:
Job owner: 6
Owner's host: 8
Server job ID: 16
This doesn't look like it will work, as the owner/host values are too
severely truncated. To ensure the required uniqueness, the server job
ID must be at least 12 bytes to cover the Unix case; many (but not all)
Unix systems restrict queue names to 9 bytes, and when combined with
the 3 bytes required for the job number (0-999), this makes a total of
12 bytes. This means we have 4 more bytes to use for either the owner
and/or host components. This is still too restrictive, unfortunately.
We need the jobOwner field. (Sorry!) However, I don't think we need
to take Tom's suggestion of changing the JobID table to include
jobOwner and make the table indexed by *both* the submission ID *and*
the jobOwner values, as this makes life more complex for ALL other
environments.
If jobOwner is added to the jobID or jobState tables, then those
monitoring apps that need to key off of jobOwner will simply have
to do their own indexing on the jobOwner value in each job entry.
Comments?
...jay