Subject: JMP> JobSubmission ID Format 0

From: Harry Lewis <[email-masked]>
Date: Wed, 23 Jul 1997 19:09:29 -0400

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.

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.

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

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

---

From: Tom Hastings <[email-masked]>
Date: Fri, 25 Jul 1997 16:40:47 PDT

>was expecting this to be something like format 8, not a replacement for format

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.

>compromise. I would prefer to keep format 0 as previously defined... basically

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.

>      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.

---

From: Harry Lewis <[email-masked]>
Date: Mon, 28 Jul 1997 11:23:09 -0400

>free to use any format.  Ok?

No, This is not OK. We agreed the agent can use any scheme to derive the
jmJobSubmissionID, if not passed in, including URL's, jobOwner etc, if known.
But, if the agent does not use a unique format ID,  there is a high probability
that the sequential part of the ID's will intersect - something which I think
should be avoided. Sequential ID's are, by definition, fairly local constructs.
Keeping format 0 for the agent prevents the agent from "stepping on" the local
id's of a server, for example, because the server will always be using some
format ID other than 0.

>end.  It seems like a particularly useful and important format.

Formats will "come and go". I don't this the enum given to the format has any
significance in terms of indicating it's "importance".

>if the standard formats, not just the 0 format when the submitter doesn't

Here, we do agree. Format 0 was never supposed to be a "fixed" format, just
an enum that assured this ID was assigned by the agent. I thought I picked
up in Nashua that folks wanted JobOwner to be the primary choice if the agent
had to assign an ID. We can establish preferred conventions via FAQ, if this
would be useful, but format 0 is intended to be "open" for the agent to make
intelligent choices based on what information is available (given the absence
of a "legitimate" jmJobSubmissioID).

>the number of format numbers.

This really CAN'T happen with any format if the agent sticks to format 0.
That's the point. There is not need to double the number of format numbers!