Subject: Re: JMP> Changes agreed to for Job Monitoring MIB last week,

From: Harry Lewis <[email-masked]>
Date: Thu, 22 May 1997 17:44:35 -0400

Somehow, I've received Jay's reply prior to Tom's summary... but I will try to
address some of the questions raised by Jay.

>> In JMP, jmJobState object is mandatory, but the jobStateReasons1
>> attribute is conditionally mandatory, while in IPP, both the job-state
>> and the job-state-reasons attributes are mandatory.

>You know, not mandating a "reason" string with the job state doesn't
>feel good, given that the state may not really say what's going on
>with the job.  This topic was touched on during yesterday's IPP telecon
>in which we talked about job attributes wrt IPP vs. JMP definitions.

>We might want to mandate jobStateReasons1, and not let it fall into
>the "conditionally mandatory" void, since it supports the #1 target
>requirement for "tell me what my job is doing".

>Comments on this?

Yes, "Tell me what my job is doing", but please, just tell me what
I want to know in a simple form that I can understand! Not 93
possible reasons for 7 possible states in 4 seemingly arbitrary
categories! PENDING, PRINTING, CANCELED, COMPLETE. Obscure PRINTING
by calling it PROCESSING and throw in HELD and NEEDS ATTENTION (with
alert code) for good measure - isn't this enough? Jay, have you looked
at the 7.5 page list of Job State Reasons in the Job MIB? I'm behind
on mail so maybe this has all been changed but... given the current state,
of the specification, I prefer to keep the reasons OPTIONAL!

>> Issue 76 - So should jobName, jobOwner, and one of deviceNameRequested or
>> queueNameRequested be made Mandatory?
>> Closed:  Only jobOwner is made mandatory, but it will remain in the
>> Attribute table, rather than being moved to the Job table.

>Hmmm...  Is this really what we agreed to?  I submitted that jobOwner
>should be a fundamental part of job identification (and gave lots of
>examples of existing systems where this value is the only meaningful
>identification item across multiple types of spooling systems).

>By making jobOwner an "attribute", there is a serious risk of losing
>this information when the agent "ages out" attribute information.
>(The reader should recall that "attributes" are designed primarily
>for accounting purposes, and these values are able to be removed from
>the agent's store in a faster manner than the jobState values.)

>I worry that an agent will age-out the jobOwner too soon, thereby
>making it impossible to identify jobs for a target user.

>Can we please discuss this issue on the list asap?

Yes, we realized after Dave and Jay had left the meeting, that the size
of jmJobOwner blows away the notion of keeping the Job Table terse.
In the minutes, which I posted this morning, I took the liberty to
address this a bit. One, rather simple approach, if Job Owner really
is a "meaningful id across multiple types of spooling systems", is to
truncate it to 30 bytes and register it as one of the jmJobSubmissionID
formats. I'm not sure how the format ID would get tacked on, however,
but this can probably be worked out (have the NIC build it from the LPR
control file?).

An excerpt from my minutes asks:

If the design point is to facilitate a job state notification broker that lives
outside of the submission
framework and correlates users (notification recipients) with print jobs
strictly based on identification
provided via LPR, we need to have this stated.

Is this what we are worried about? There seem to be only two other
major scenarios. If the job Monitor is involved with submission (as in an
NT Port Driver for example), there is a place to couple submission and
monitoring via jmJobSubmissionID. If the monitor is fundamentally an
accounting application, then leaving jmJobOwner in the Attribute table
should not be a problem.

I guess we do loose the ability to guarantee showing the owners name in
a simple overall queue view but this problem can be minimized by "fetching"
the jmJobOwner from the Attribute table for Pending jobs and storing this
association in the job Monitor application until the application is no
longer concerned with the job. This assumes the owner's name is static,
which will be the practical case.

I think, if this is still an issue, we need to get more examples on the
table. I had proposed some additional alleviates in my complete set of
minutes.

Harry Lewis - IBM Printing Systems

---

From: JK Martin <[email-masked]>
Date: Thu, 22 May 1997 18:49:59 -0400 (EDT)

[I have changed the Subject line to better reflect the topic]

Harry,

This statement has me somewhat bothered regarding which master we

> of jmJobOwner blows away the notion of keeping the Job Table terse.

What do you want?  Good grammer or good taste?...  ;-}

Seriously, some of us firmly believe in the importance of "out of band"
job monitors (ie, processes monitoring job progression without being
intrinsically part of the printing process, a la Unix and VMS).  The
only consistent way to indentify jobs is through jobOwner, and hence,
this data must be available for as long as the job entry exists in the
agent.

Those who will be using the Job MIB as an intrinsic part of the
printing process are lucky (eg, Windows, OS/2, etc).  (We envy you,
believe us!)  If someone can state a justifiable case for being able to
monitor jobs with jobOwner, then great!  (And please do so soon!)
Otherwise, we need that data for the duration of the job entry.

	...jay

------------------------------------------------------------------------------

---

From: Harry Lewis <[email-masked]>
Date: Fri, 23 May 1997 10:38:04 -0400

Jay, I think you have answered my question... you *are* concerned about
tracking job progress and notifying clients even though you are "out of band".
Given this, I think I see why you need jobOwner to have the greatest
persistence (although, honestly, I fear this is Pandora's box, and soon, we
will learn that jobOwner is really not enough - if this is likely, I'd rather
it surface NOW!).

So, what about my proposal to add a new jmJobSubmissionID format for LPR
JobOwner? The owner information would have to be truncated to 30 bytes and
someone, most likely the NIC, would have to prepend the assigned
jmJobSubmissionID format number to the attribute.

By definition, the JobID table has the same persistence as the Job Table - each
guaranteed to have the longest persistence.

---------------------- Forwarded by Harry Lewis/Boulder/IBM on 05/22/97 06:11 PM
 ---------------------------

        [email-masked]
        05/22/97 05:56 PM
Please respond to [email-masked] @ internet

To: Harry Lewis/Boulder/IBM@IBMUS
cc: [email-masked] @ internet
Subject: Re: JMP> Changes agreed to for Job Monitoring MIB last week,

Harry,

 ...jay

Harry Lewis -