I have taken a very long and hard look at the Job MIB over the last
couple weeks, including my design team in the process. We are fairly
pleased with the current state of the job MIB but have some comments which
suggest significant change in the structure of a couple tables. I don't
think our recommendations are any more severe than what we've been doing
recently with the Resource table and I hope you will perceive the added
benefit. I think the recommended changes (or something similar) are needed to
really make the job MIB USEFUL!
I've posted a text version of my comments:
ftp://ftp.pwg.org/pub/jmp/contributions/hrl_comments.txt
For the convenience of anyone without ftp access, I will attach
the same comments below:
============================================================
March 05 1997 Job MIB comments
Letter to the PWG/JMP
Harry Lewis - IBM Printing Systems
I have the following observations and recommendations regarding
use and structure of the Job MIB.
1. Job Table is not structured to allow a jobID (called jobIndex
in the PWG Job MIB) to be obtained without "walking" the
entire jmJobTable.
The jmJobTable is indexed by jmJobSet and jmJobIndex (the "printer assigned
job ID - if you will) and contains a lot more identification type objects
like jmJobName (owner assigned), jmJobNameID (spooler assigned), jmJobNumberID
(spooler assigned) etc.
I think one use of the jmJobTable should be to DETERMINE your
printer assigned jobID (jmJobIndex) which you can use, then, to
index the Accounting and other tables. To facilitate this
function, however, the jmJobTable would have to be indexed by
jmJobName, jmJobNameID etc., *not* by jmJobIndex. This has
already been demonstrated by HP's Netware Mopier solution and HP has also
requested objects which I will arbitrarily name jmJobServerName
and jmJobQueueName as indexes to the jmJob table.
Objects like jmJobNameID, jmJobNumberID, jmJobServerName etc...
should also be available in the Resource table for accounting applications who
want to correlate this information with other resources for the job.
2. Restructuring the jmJob table, however, would make it
difficult to obtain job State from the Job Group.
We have been moving many objects away from the Job Group into
the Resource Group. I recommend we investigate use of the Job
Completed table as a Job State table. Completed is just one
possible state. Why create the entry only when this particular
state has been achieved? Why not create the entry at the same
time the jmJobTable entry is created and track the state there.
Since one key attribute of the Job Completed table is small size
for greater persistence, I also recommend doing away with the
cumbersome jmJobCurrentState / jmJobStateReasons pair and simply
enumerating a list of possible job states.
Today's jmJobCompleted table looks like this:
jmJobSetIndex (4 bytes)
jmCompletedIndex (4 bytes)
jmJobIndex (4 bytes)
My proposed jmJobState table would look like this:
jmJobSetIndex (4 bytes)
jmJobIndex (4 bytes)
jmJobState (4 bytes)
Note that the jmJobCompleted table is (again) navigated by a
sequential index which means you have to go get the whole table to
learn which jobs have completed. The jmJobState table is indexed by
JobIndex so you can go right to the job you are interested in (you
may have learned the id from the re-vamped jmJobTable!) and determine
it's current state (which could very well be COMPLETED)!
3. Octets
If we followed these two recommendations, I think we'd have a
much more useful Job MIB. The jmJobTable could be renamed the
jmJobIDTable, because it's sole purpose would be to locate your printer
assigned job ID for use in other parts of the MIB. The
Resource table is already indexed by jmJobIndex (the job ID) and
so would be the new jmJobStateTable.
We would have to make sure any other information that *was* in
the jmJobTable has a home. We've moved most accounting and
progress indications into the Resource table (I think). Octets
is the only thing I'm not sure of. There is a tendency to want
to put jmJobTotalKOctets and jmJobKOctetsCompleted in the
jmJobState table. Then, this one table, indexed by job ID could
be used to give the overall STATE and PROGRESS of the job.
However, this would add 8 bytes to a 12 byte table, and should
be considered carefully with regard to what type of persistence
and storage overhead we intended for this table. The other place
we could put octets is in the Resource table. I think it would
work fine, just not as eloquently as having it in the jmJobState
group.
4. jmGeneralJobCompletePolicy
This object says how long entries will be kept in the jmJobTable
and jmCompletedTable.
Couple observations:
- Why don't we care how long entries will be kept in the
jmResourceTable?
- Why makes us think the time will be the same for each table?
I thought the jmJobCompleted table was intentionally short so
it could be real deep (longer persistence).
What is the intended use of jmGeneralMaxNumberofJobs and
jmGeneralCurrentNumberofJobs? Is it storage allocation? If we
have a time based object (above) then we don't need these
"max's" to help figure out persistence. These may be great
objects, I just need someone to help me with the scenario. And,
I wonder why we don't want max size of other things like
Resource table and/or jobCompleted (State?) tables.
I think the job MIB is really converging. These comments are
meant to encourage this, not to throw a wrench in the process.
Please let me know if you agree that these changes would make the
job MIB more realistic and more useful!
Harry Lewis - IBM Printing Systems