At 21:39 02/19/97 PST, Harry Lewis <harryl at vnet.ibm.com> wrote:
>Tom wrote (somewhat paraphrased - my response brackted by HRL -):
>>>There is one additional issues raised ... (moving)
>>jmJobSubmissionTime from the JobTable to the QueueTable (or)
>>to the ResourceTable.
>>>>There are pros and cons with each:
>>>>Moving jmJobSubmissionTime to the QueueTable means that an implementation
>>that queues, shall implement the time, which is probably not a burden
>>on something that queues and means that jobs will get a time stamp
>>as they are entered into the MIB. On the other hand, a Printer
>>that doesn't queue, cannot have a jmJobSubmissionTime at all.
>>HRL - I think the system that queues sets the submission DateTime
>HRL - as you say. For *printers* that don't queue, the DateTime must
>HRL - be passed in on submission from the server queue.
>>>The advantage of putting it in the ResourceTable is for implementations
>>that don't have concept of time. But our experience with alerts in
>>the Printer MIB say it was a mistake not to require time stamps
>>on alerts, so we changes prtAlertTime to become mandatory. Same
>>should be true for JobSubmissionTime, shouldn't it?
>>HRL - Another advantage of putting it in the ResourceTable is that
>HRL - not Time becomes an enumerated resource. The submission DateTime
>HRL - passed in from the server can be "stashed" as one TIME Resource
>HRL - and additional TIME Resources can be defined, as TimeTick that
>HRL - can be used to roughly correlate and track progress as follows
>HRL - in response to your final question.
>>>And shouldn't the job submission time be recorded whether
>>the implementation queues or not?
>>HRL - As I was saying. If submission DateTime is passed in with the
>HRL - submission protocol, the jmResourceType TIME could be defined
>HRL - as follows: (shorthand notation)
>HRL -
>HRL - jmResourceType - TIME
>HRL -
>HRL - 1 - Other
>HRL - 2 - Unknown
>HRL - 3 - jobSubmssionTime - DateTime
>HRL - 4 - jobSubmissionTick - TimeTicks
>HRL - 5 - jobStartTick - TimeTicks
>HRL - 6 - jobCompleteTicks - TimeTicks
>HRL -
>HRL - Using these TIME resources as entries in the Resource table,
>HRL - and assuming the agent closely correlates Time and Ticks on
>HRL - job submission (within a second or two?) then, using just
>HRL - Ticks (derived from sysUpTime) the Job Management App can
>HRL - determine how long the job waited on the printer and how long
>HRL - it took to print.
>HRL -
>HRL - One disadvantage I see is number of Resource table entries, but
>HRL - it seems we've created this table as a collector of sorts AND
>HRL - we've at least cleverly provided the jmResourceType providing
>HRL - coarser granularity for more efficient data gathering.
In re-reading you e-mail, I missed the point that you wanted the
jobSubmissionDateAndTime to be the submission time to the server
and the jobSubmissionTimeStamp to be the submission time to the printer.
It would seem to me that we would need to specify in the semantics of the
attribute whether the time was when the job was submitted to the server
vs. the printer. So I would think that we would need another attribute.
Presumably a server would always have access to a date and time clock, so
would not need the TimeStamp form for the server. So we should replace:
jobSubmissionDateAndTime
JobSubmissionTimeStamp
with:
jobSubmissionToServerDateAndTime
jobSubmissionToPrinterDateAndTime
JobSubmissionToPrinterTimeStamp
If you are implementing just a printer and don't know when the job was
submitted to the server, you would not implement the
jobSubmissionToServerDateAndTime attribute, correct?
What other attributes do we need separate instances for the server vs.
the printer in order to handle configuration 2 and 3?
I've added this issue as issue 66 to the issues list (but I just sent
the issues list, so this is a new one).
Tom
>>Harry Lewis - IBM Printing Systems.
>>>