Tom,
First, since I always view the world as 'printer centric', I will
provide my LPD scenario and an explanation of why I listed the LPD
Ids as Client Ids.
The client submits his job to an LPD server which spools the job
and submits it to the printer. The printer contains an SNMP
agent. The client identifiers for the job are assigned by the LPD
server. The client obtains the server assigned identifiers from
the server and uses these to find his job on the printer. The
printer is not aware that the identifiers were assigned by the
server and not the client.
If the Job Monitoring MIB was implemented on an LPD server it would be
conceivable to use the LPD Server Job Id Number as jmJobIndex. This
would, as you stated, "be the handiest way for a Job Monitoring MIB
client to access a job" from the server. This may be a better approach
than my proposal to implement an independent jmJobIndex.
In this case, the solution to the zero index problem would be to use
1000 as the equivalent of a Job Id Number of zero. The value 1000 is
well within the acceptable range for a table index and would be an
easy conversion within an SNMP manager.
However, a printer must be capable of receiving jobs from multiple LPD
servers and multiple protocols. So within a printer SNMP agent
jmJobIndex must be independent of the LPD Server Job Id Number.
Now what problem are we trying to solve? Implementation of the Job
Monitoring MIB in the printer should be our prime goal. This is
where the necessary job information must be obtained. What benefit
is obtained by implementing the MIB on an LPD Server? The LPD
protocol provides all the information needed while the print job
is queued on the server. We have already eliminated the scenario of
an intermediate server collecting Job information. So why would
anyone implement the Job Monitoring MIB on an LPD server?
I am not as familiar with DPA implementations, but I believe that they
also include a method to return job status to the client. The real
problem then is how to get the information from the printer.
I hope this sheds some light on my position.
...Ron
At 07:38:47 Thu Mar 06 1997, Tom Hastings 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
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