I am responding to a note which is about 13 days old... sorry...
I want to agree with Tom regarding nested attributes... and suggest a
FAQ that says the agent will always replace ANY nested attribute
(regardless of why it got nested) with the most recent value encountered
in the job stream. This is the simplest agent implementation and I think
it works for all the cases we've discussed.
As an example, if the client attaches JobOwner (BillyBob) to the job but,
later, the server adds (ServItUp_01) to the front of the job... the JobOwner
object in the JobTable would have the value ServItUp_01 for a moment which
would be replaced by BillyBob. If the server added it's JobOwner at the end
of the job (not a good idea) then ServItUp_01 would be the final value for
JobOwner.
This scenario applies to any and all job attributes.
Harry Lewis - IBM Printing Systems
--------- Forwarded by Harry Lewis/Boulder/IBM on 07/16/97 02:48 PM -------
hastings at cp10.es.xerox.com
07/02/97 04:57 PM
Please respond to hastings at cp10.es.xerox.com @ internet
To: Harry Lewis/Boulder/IBM at IBMUS
cc: hastings at cp10.es.xerox.com @ internet, jkm at underscore.com @ internet,
rbergma at dpc.com @ internet, bpenteco at boi.hp.com @ internet
Subject: Re: Nested Attributes
At 08:49 07/02/97 PDT, Harry Lewis wrote:
>I think we failed to cover this topic at the meeting in Nashua. I hope we can
>come to quick resolution. I didn't bring it to the
>open JMP because I want to make sure we all agree it needs to be aired before
>doing so. In otherwords, if it's already documented but I'm missing something,
>please provide a pointer rather then allowing me to inject instability on the
>mail list.
Oops! We should have brought it up at Nashua.
But I don't think we really have a problem. See if you agree with
my analysis (though I may not be understanding the scenario where the
problem comes up).
>>Bob P. had made some suggestions in the past and I think the same could apply
>to all attributes, not just subID...
While it could apply to all attributes, the submissionID is unique in that
it is used as an index to find the job.
I think that we are talking about configuration 3 here, where the client
submits to a server and the server submits to the Printer and the
monitoring APP is monitoring the server with some protocol (such as PSERVER?)
that submits to the device and forgets about the job (in the server and
in the device) as soon as the job is submitted to the device. So that
management app has to use our Job Monitoring MIB in the device to finish
monitoring the job.
Correct?
It seems to me that in this case, since the server has forgotten about the
job in the device, there are two possibilities, depending on the client:
1. The client submitted the job with a jobsubmission ID to the server, so
the server should just pass it on and not make up a new one. Otherwise,
the client has no idea how to find the job in the device. (Having the
server pass back the new job submission ID to the client seems too hard
and would require new extensions to protocols, etc.). If this is
implemented in the server by the server just wrapping another layer of
PJL with a JOBSUBMISSIONID string, then the agent or the device needs to
ignore the outer ones and just keep the inner most one as the jmJobSubmissionID.
I think that having the agent ignore outer (or replace outer with inner)
JOBSUBMISSIONID works for both cases:
a. the client is going to depend on the server for all status and so the
client had better NOT also send a JOBSUBMISSIONID (otherwise, the
client's will override the server's ID). Configuration 2.
b. the client is going to use the server for status while the job is
queued and is going to use the job monitoring MIB in the device
for status after the server submits (and forgets) the job to the device.
Here the server is probably not going to wrap the job with
its own JOBSUBMISSIONID, since the server isn't going to use the
Job Monitoring MIB to track the job. If the server is going to use
the Job Monitoring MIB to track the job, then the server SHOULD provide
access to such data to the client (via either our Job Monitoring MIB
with an agent implemented in the server or via IPP, ...).
2. The client did NOT submit a job submission ID to the server, so the
server is free to make up one of its own and submit it to the device.
On the other hand, if the server really does forget about the job in the
server and the device, what is even the point?
The proper thing for servers to do is to NOT forget about jobs in the server
and the device and then the monitoring APP would just query the server,
using our Job monitoring MIB in the server. But this is configuration 2.
>>>1) The printer can keep track of the innermost JobSubmissionID (discard the
>>previous ID when a new one is received). Pro: Fewer jobs for the printer to
>>keep track of. Con: The spooler can't track its job.
But in configuration 3, the server isn't tracking its job in the printer.
If the server is tracking the job in the printer, why doesn't the server
show the job to the client and the client only bother talking to the server,
not the device? This is configuration 2.
>>>2) The printer could keep track of all ID's and have them point to the same
>>jmJobIndex. Pro: Fewer jobs for the printer to keep track of. Con: May
>>cause problems in that the job attributes would be a summary of all the
>>nested jobs.
>>>3) The printer could keep track of the nested jobs as separate jobs. Pro:
>>The attributes are separate for each job. Con: More jobs in the printer.
>>We think 1 is the easiest to do and have been looking into whether or not it
>makes sense to have the "spooler"
>actually replace jmJobSubmissionID if it finds it was assigned by the client.
I think that the spooler should NOT replace (or override or place an outer
wrap with a new JOBSUBMISSIONID), unless the server is keeping track of the
job in the device using the Job Monitoring MIB. If the server is, then
the server SHOULD also provide that information back to the client by
either: (1) implement the Job Monitoring agent in the server or (2)
implementing some other protocol for the clients to get status, such as IPP.
That is why I don't see that we have a problem.
I think we should add some statement/assumption like the above to the
MIB spec. What do you think?
>>Our prototype currently does (1) for all attributes.
>>Harry Lewis - IBM Printing Systems
>>
About other attributes that might have a value for the client-server hop
and a different value for the server-device hop:
We have doubled a few attributes in order to handle the few attributes
that might have different values for each hop, such as submission-time.
In a quick scan of the attributes we have:
jmJobSubmissionID serverAssignedJobName(22)
submittingServerName(27) jobOriginatingHost(29)
deviceNameRequested(30) queueNameRequested(31)
impressionsSpooled(110) impressionsSentToDevice(111)
jobSubmissionToServerTime(190) jobSubmissionToDeviceTime(191)
I'm not sure we have clearly defined when each is used, but the point it
that there are only 5 out of 70 that have a need for more than one value
because of two-hop systems.
So I think we don't need a general solution to the multi-hop problem.
Besides, I would hope that configuration 3 is only a interim thing.
The long term should be configurations 1 and 2.
CLARIFICATION ISSUE:
By the way, what about serverAssignedJobName(22)?
We agreed in Nashua to clarify that the name assigned by the server could
be either a name or a number. I assumed that when it was a number, that
the number was serving the purpose of a server-to-device submission ID
(except that this ID isn't used as the index in the jmJobSubmissionIDTable,
because the server isn't using the Job Monitoring MIB to track the job).
So shouldn't I replace the definition for serverAssignedJobName(22):
"Configuration 3: The human readable string name of the job as assigned by
the server that submitted the job to the device that the agent is
instrumenting with this MIB."
with "Configuration 3: The human readable string name, number, or ID of the
job as assigned by the server that submitted the job to the device that the
agent is instrumenting with this MIB."
Comments (before sending to JMP)?
Tom