Oops! I think you meant:
ftp://ftp.pwg.org/pub/pwg/jmp/contributions/sepstate.doc
ftp://ftp.pwg.org/pub/pwg/jmp/contributions/sepstate.pdf
NOT:
ftp://ftp.pwg.org/pub/pwg/jmp/contributions/attr-tab.doc
ftp://ftp.pwg.org/pub/pwg/jmp/contributions/attr-tab.pdf
I agree with all of your conclusions and was just about to type up a
long mailnote with a similar argument. Thanks for saving me the work.
I do have some additional comments, also. I will send these in a
seperate note.
Ang
----------
From: jmp-owner@pwg.org
To: jmp@pwg.org
Subject: JMP> Analysis paper on jmJobStateTable vs. jmAttributeTable Issu
Date: Thursday, May 15, 1997 12:00AM
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.