At 16:09 07/23/97 PDT, Harry Lewis wrote:
>Tom, in going over the Job MIB v.83, I was surprised to see the change
>to JobSumbissionID format 0.
>>Previously, format 0 was defined such that, if no submission ID was passed
>in, the agent would use whatever algorithm it desired to provide one. The
>recommendation was for the agent to simply reflect the jmJobIndex here.
>>I recall a lot of discussion at Nashua about moving JobOwner to the Job Table
>and providing a new (additional) JobSubmissionID format based on JobOwner. I
>was expecting this to be something like format 8, not a replacement for format
>0.
I think we also agreed that the agent could use any of the standard
formats, if the job submitter didn't submit a jobsubmissionid, rather
than constraining the agent to a particular format. So I deleted
format 0. The 0 format is no longer the default format that the agent
uses if the submitter didn't supply a jobsubmissionid. The agent is
free to use any format. Ok?
When adding the jobOwner format, I assigned it to 0, rather than the
end. It seems like a particularly useful and important format.
>There's a pretty big question in my mind exactly WHY we think JobOwner needs
>to be part of a default format 0, especially since jmJobOwner is a mandatory
>object in the Job Table. I only offer the following definition as a potential
>compromise. I would prefer to keep format 0 as previously defined... basically
>agent assigned.
I agree that it would be a problem if the spec says that a job owner has
to be part of the default format. That is why we got away from having
a single default format, I thought. So now the agent is free to use any
if the standard formats, not just the 0 format when the submitter doesn't
submit an ID.
>>If the desire is to have the agent use JobOwner (if supplied) in the default
>case, we could stipulate this within format 0 but then I would still like to
>see a separate format (8) for JobOwner passed in as a JobSubmissionID. This
>way, the decimal portions can overlap without danger of ambiguity.
>>So, to be more precise, we could define format 0 as
>>'0' octets 2-40: last 39 bytes of jmJobOwner.
>> octets 41-48: 8 decimal-digit sequential number (preferably equal to
> jmJobIndex).
>>'8' octets 2-40: last 39 bytes of jmJobOwner.
>> octets 41-48: 8 decimal-digit sequential number
Are you worrying that one client might not supply a job submission id
for a particular job owner, but that same user from another client
might. So that the second client might assign a sequence number that was
the same as the agent assigned for the first one and thereby be a collision?
That could happen with any of the formats, if the agent assigns
the trailing number sometimes and the submitter does other times.
Do we want to fix that?
We could make separate format numbers for assigned by agent, versus
assigned by the job submitter, for all the formats, thereby doubling
the number of format numbers.
>>Now... for all you agent developers out there... I should warn you that having
>the agent add JobOwner into the JobSubmissionID may not be as simple as it
>sounds. Think of the fact that JobOwner may start out "blank" when you first
>create the format 0 ID but may assume a value from the LPR control file at the
>end of the job. The agent should probably feel obliged to MODIFY
>JobSubmissionID
>with the new JobOwner information.
>>Note that, in my scenario, including JobOwner in the control file is not
>considered the same as passing in a format 8 jmJobSubmissionID with 8 digit
>sequential number. If this were to occur, then I'd say format 8 was in use.
>>>Harry Lewis - IBM Printing Systems
>>