JMP Mail Archive: Re: JMP> Instantiation

Re: JMP> Instantiation

Tom Hastings (hastings@cp10.es.xerox.com)
Mon, 2 Jun 1997 18:09:29 PDT

At 07:10 05/29/97 PDT, Harry Lewis wrote:
>I had posted this topic earlier but I believe I only saw a response from one
>person (Jay) who agreed with me that it does not make sense to instantiate
>deviceAlertCode as soon as a job is "pending" because the device may never have
>an alert while producing that job. This may have become a mute point following
>our discussions about "printer-stopped" state etc.
>
>But, I still think we need to clarify the thread which was weaving during
>SanDiego which basically said... "mandatory attributes must be instantiated
>when the job enters pending state". One of the key attributes for which this is
>desired is jobOwner. This is due to the fact that "out of band" monitors will
>rely heavily on job owner for job identification.
>
>But, what should we do about multi-valued attributes like output bin? When the
>job is pending, there is no way to determine how many instances of output bin
>there will be!

Good point. However, output bin was agreed not to be mandatory.
So if the rule is that only mandatory attributes shall be instantiated
when the job is received, then it is only the jobOwner that need be
instantiated at submit time.

>
>I think we should investigate what is behind the "instantiation" rule and ways
>to alleviate the problems it may
>cause. Basically, I think we are trying to define a list of objects or
>attributes that will never cause a GET (Varbind List) to fail. Correct? This
>would allow the monitoring application to "pick and choose" among these
>"mandatory, instantiated" attributes using an SNMP GET.

Good point.

>
>For the Job Table, I agree that a GET on a row should reliably return a value
>for all objects in that row. I don't think it is necessary to achieve this
>level of instantiation, however, for the Attribute Table because, the
>monitoring application can use GET NEXT there, which will skip over any
>non-instantiated attributes.

I agree. So can we agree to say that only mandatory objects and attributes
shall be instantiated when the job is received?

>
>Based on this, I suggest we drop the "must be instantiated" rule as it relates
>to any attributes in the Attribute Table.

Except the jobOwner which is mandatory?

>
>
>Harry Lewis - IBM Printing Systems
>
>