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!