So here is a start of the job submission protocols for which
unique job identifiers are generated for each job:
1. Jobs in BSD LPR/LPD have a unique job identifier. Here is the text from
RFC 1179:
Model of Printing Environment
A group of hosts request services from a line printer daemon process
running on a host. The services provided by the process are related
to printing jobs. A printing job produces output from one file.
Each job will have a unique job number which is between 0 and 999,
inclusive. The jobs are requested by users which have names. These
user names may not start with a digit.
2. ISO DPA, the server generates a unique job identifer (as a text string,
so it could have non-numeric characters in it, but the DPA implementations
that I'm aware of use stricgly ASCII digits for the identifer).
Here is the (wide) list from the old mapping we did last Spring:
Job Identification (I) ISO DPA Apple IPDS LPRLPD NDPS PJL PSERVER
SMB TIPSI
PAP
1. Job id on original client x x x x x x x
2. Job id on device (printer) x x x x x x
Perhaps we are getting tangled up in semantics here, because I see that you
labeled
LPR/LPD as an id coming from the original client. But the LPD client is NOT
free to make
up just any old job id; the BSD LPD client has to use the next available job
id on the
server or at least not use a job id already in use, correct?
Doesn't the client have to determine the next job id by looking at the file
names in the
server's directory? RFC 1179 is a little sketchy here.
However, the real issue here is how does a user find a job in the Job
Monitoring MIB,
if that user know the unique identifier for the job for that system (whether
generated
by the client as part of the submission proces or returned by the server as
a result
of the submission request. In BSD, I claim
that the jmJobIndex that the MIB agent uses to index jobs would be the handiest
way for a Job Monitoring MIB client to access a job. Then the client only
has to
make one Get request to get a jobs data. The client doesn't have to get
jobs one at
a time and look at a particular column to find a match for the job that the
client
is looking for. However, in BSD, a job can have "000" as its id, so that
the jmJobIndex
for such a job, would have to have a different value, say, the largest
positive integer.
Discussion (and its going to need a lot to understand one another)?
Thanks,
Tom
At 09:20 03/06/97 PST, Ron Bergman wrote:
>Tom,
>>On Thu Mar 06, 1997 you wrote:
>>Gee, I think just the opposite. Each job submission protocol has the
>recipient server or printer return an identifier to the submitter.
>So we need to know the *name* of the fundamental attribute in each
>job submission protocol that maps to the jmJobIndex object.
>>So it is vital that we understand which attribute (that is returned
>by the recipient) maps to the jmJobIndex.
>>By the way, we have the serious issue of what happens for a job submission
>protocol in which the job identifier generated by the server or printer
>is 0 (say for the first job after the system is booted). SNMP won't allow
>us to have a 0 value as an index. SO we need to know how many job
>submission protocols return 0 for a valid job identifier. If there are some,
>we need to figure out what to do. See the issues list. Map 0 to the highest
>index?
>>Tom
>>RB> None of the Job Submission protocols supported by a Dataproducts
>RB> NIC requres an identifier to be returned. I do believe that OS/2
>RB> does have this requirement from the server to the client. Could
>RB> you let me know what protocols you are aware of with this requirement?
>RB>
>RB> Also, a more fundamental issue is what Protocols that currently
>RB> have an index in the server and/or printer cannot conform to the
>RB> restrictions of jmJobIndex.
>RB>
>RB> As for the index of zero, is this a real problem and in what
>RB> protocols?
>>>>At 08:21 03/04/97 PST, you wrote:
>>The first object in the Template provided by Tom Hastings is jmJobIndex.
>>>>Since this object is defined and used by the device that is providing
>>the MIB it must always be present. IMHO, this object most likely will
>>not map into an existing parameter defined by the Job Submission
>>Protocol. I would recommend that this object be ignored by all who
>>are completing this template.
>>>>-----------------------------------------------------------------------
>> Ron Bergman
>> Dataproducts Corp
>>rbergma at dpc.com>> (805)578-4421
>>>>>>>