I gave the wrong file name to the analysis paper. I've also added a .txt
form:
ftp://ftp.pwg.org/pub/pwg/jmp/contributions/
-rw-r--r-- 1 pwg pwg 39936 May 15 09:37 sepstate.doc
-rw-r--r-- 1 pwg pwg 43087 May 15 09:38 sepstate.pdf
-rw-r--r-- 1 pwg pwg 26237 May 16 05:01 sepstate.txt
Tom
>Return-Path: <jmp-owner at pwg.org>
>X-Sender: hastings at zazen (Unverified)
>Date: Thu, 15 May 1997 02:46:34 PDT
>To: jmp at pwg.org>From: Tom Hastings <hastings at cp10.es.xerox.com>
>Subject: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable Issues
>Sender: jmp-owner at pwg.org>>I've posted an 8-page analysis of the utlization of the jmJobStateTable
>and the jmAttributeTable in:
>>ftp://ftp.pwg.org/pub/pwg/jmp/contributions/>-rw-r--r-- 1 pwg pwg 34304 May 9 09:35 attr-tab.doc
>-rw-r--r-- 1 pwg pwg 48490 May 9 09:36 attr-tab.pdf
>>in order to attempt to resolve the biggest issues remaining in the
>Job Monitorng MIB regarding the redundance between the jmJobStateTable and
>the jmAttributeTable and whether we could get rid of the jmJobStateTable and
>use just the jmAttributeTable or not.
>>Harry, Ron, and I discussed the issue over lunch today. Then I wrote this
>paper to capture the discussion, but they have not had a chance to review
>the paper. If there are mistakes in the paper, they
>are mine. Please review the paper to see if my understanding of SNMP
>Get and Get Next is correct when used with tables.
>>Please send comments on this paper today, Thursday, 5/15, so that we
>may consider them during our JMP meeting, tommorrow, Friday, 5/16.
>>One way to send comments is to use MS-WORD, turn on revision marks,
>and may comments directly in the .doc file. If the comments are
>sparse, an e-mail will do. The .pdf file has line numbers, so that you
>can refer to specific lines in an e-mail mesage, perhaps even cutting
>and pasting the relevant paragraph.
>>>The conclusions in the paper are:
>>The jmJobStateTable is very useful because its lowest order index is
>jmJobIndex, so that any number of selected objects can be obtained using
>multiple Get Next operations in a single PDU for the *next* job, skipping
>over jobs that have been removed from the table. A subsequent PDU can
>contain multiple Get operations for any attributes desired using the
>returned jmJobIndex value.
>>If the mandatory attributes are all put into the jmJobStateTable as objects,
>and not in the jmAttributeTable as attributes, it is clear by SNMP rules
>that all of the mandatory objects shall be instantiated at the same time
>when the new job row is put into the jmJobStateTable. Also the persistence
>time is clearly separated by which table the information is contained.
>>The jmAttributeTable only contains conditionally mandatory attributes, no
>mandatory attributes, so that the jmAttributeTable itself can be
>conditionally mandatory, thereby allowing a very small implementation to
>only implement the jmJobStateTable and not the jmAttributeTable.
>>>