Subject: JMP> Job Mib Assessment

From: [email-masked]
Date: Tue, 4 Feb 97 15:39:27 CST

JMP Team,

Here is my belated assessment of the Job Monitoring MIB
document (version 0.6, dated 01/23/97) which we can discuss
further at our JMP meeting in San Jose.  Thanks to Tom
Hastings for producing this document!

*  Page 7 - Job Object Lifecycle Summary:  Please add a
State for "Printing" to indicate that the job is currently
printing on the printer.

*  Page 22 - MIB Datatype specifications:  This is a nit,
but it would be helpful to give an example of the format for
DateAndTime. For example, how does one specify 12:01:00AM on
Thursday, January 30, 1997?

*  Page 25 - jmQueueAlgorithmTC:  I agree with the
resolution of issue 15 and 16 which states that this object
will be removed from the Job MIB.

*  Page 28 - jmJobStateTC:  Please add a State for
"printing" to indicate that the job is currently printing on
the printer.

*  Page 31 - jmJobStateReasonsTC:  Please confirm that state
"completion" plus reason "successfulCompletion" means that
all pages of the print job have been successfully printed
and stacked in the output bin.  If so, we're set.  If not,
then please add "jobStacked" to indicate the reason for the
"completion" state is that all pages in the job have been
stacked in the output bin of the printer.

*  Page 42 - jmResourceTypeTC:  I agree with the resolution
of issue 22 which states that "faxPhoneNumber" will be
removed from the Job MIB.

*  Page 42/43 - impressionsCompleted and sheetsCompleted:
How does number of copies affect these values?

*  Page 43 - jmResourceTypeTC:  In OS/2 Warp,
"pagesSpooled", "pagesSentToDevice" and "pagesCompleted"
mean "impressions" - not "logical pages".  Therefore, please
change the name of these resources to "impressionsSpooled"
and "impressionsSentToDevice".  Please change the
description from "logical pages" to "impressions".  Please
indicate that "impressionsSpooled" is for 1 copy of a job
and "impressionsSentToDevice" is reset to 1 for each copy.
"pagesCompleted" can be removed since it equals
"impressionsCompleted".  In OS/2 Warp,
"impressionsCompleted" is reset to 1 for each copy of a job.

*  Page 43 - jmResourceTypeTC:  Does "processingTime" count
operator intervention time?  (e.g. the time a job was held
up due to a paper jam on the printer)

*  Page 49 - Should MIB provide jmGeneralNumberOfJobsQueued
and jmGeneralNumberOfJobsComplete so a network management
application can summarize the current status of the printer?

*  Page 49 - jmGeneralQueuingAlgorithm:  I agree with the
resolution of issue 28 which states that this object will be
removed from the Job MIB.

*  Page 53 - jmJobMessageToOperator:  It doesn't appear
anyone supports this.  Should this object be removed from
the Job MIB?

*  Page 58 - jmJobName, jmJobIdName, jmJobIdNumber,
jmJobComment:  Clarify the use of these objects.  Here is an
example.  A user submits a print job.  The file name of the
job is "C:\MYJOB.PS".  The user specifies a comment of
"Status Report 1/31/97".  The print job is queued on server
"SERVER1" in print queue "PSQUEUE".  The numeric job id is
1234.  What value is the value of each object?  Do we need a
specific object for source server and source queue to
accommodate management applications such as the management
application provided by HP that correlates jobs in a printer
with jobs in a print queue on a print server?

*  Page 59 - jmJobIdNumber:  OS/2 uses -1 to indicate there
is not a job id.  I recall seeing -2 in one of the Job MIB
specs.  Why not use -1 instead of -2?

*  Page 59 - jmJobTypes:  It doesn't appear anyone supports
this object.  Is this object intended for a multi-function
device (MFD) so the host can inform the MFD which of its
devices to direct the job?

*  Page 60 - jmJobDeviceNameRequested:  What is the purpose
of this object?  Is this the name of the printer (e.g.
make and model)?

*  Page 60 - jmJobDeviceIndex:  What value should a print
server return if it doesn't support the printer mib?

*  Page 61 - jmJobSourceChannel:  What are the enum values
referred to in issue 37?

Keith