JMP> Question about assigning OIDs for the Job Monitoring MIB

[Tom Hastings]

Jeff,


Just to make sure that we are assigning our OIDs properly for the
Job Monitoring MIB we have:


ISSUE 82 - Change the OID assignment as Jeff Case suggests:
Quoted from Jeff Case's reply (lines without > are my understanding
of how we are to assign all of the OIDs to the Job Monitoring MIB):
>        jobmonMIB
>        jobmonMIB.1 jobmonMIBObjects
>        jobmonMIB.1.1 jmGeneral
         jobmonMIB.1.1.1 jmGeneralTable
         jobmonMIB.1.1.1.1 jmGeneralEntry
         jobmonMIB.1.1.1.1.1 jmGeneralNumberOfActiveJobs
         jobmonMIB.1.1.1.1.2 jmGeneralOldestActiveJobIndex
         jobmonMIB.1.1.1.1.3 jmGeneralNewestActiveJobIndex
         jobmonMIB.1.1.1.1.4 jmGeneralJobPersistence
         jobmonMIB.1.1.1.1.5 jmGeneralAttributePersistence
         jobmonMIB.1.1.1.1.6 jmGeneralJobSetName


>        jobmonMIB.1.2 jmJobID
         jobmonMIB.1.1.1 jmJobIDTable
         jobmonMIB.1.1.1.1 jmJobIDEntry
         jobmonMIB.1.1.1.1.1 jmJobSubmissionIDIndex
         jobmonMIB.1.1.1.1.2 jmJobSetIndex
         jobmonMIB.1.1.1.1.3 jmJobIndex


>        jobmonMIB.1.3 jmJobStateG
         jobmonMIB.1.1.1 jmJobStateTable
         jobmonMIB.1.1.1.1 jmJobStateEntry
         jobmonMIB.1.1.1.1.1 jmJobState
         jobmonMIB.1.1.1.1.2 jmJobStateKOctetsCompleted
         jobmonMIB.1.1.1.1.3 jmJobStateImpressionsCompleted
         jobmonMIB.1.1.1.1.4 jmJobStateAssociatedValue


>        jobmonMIB.1.4 jmAttribute
         jobmonMIB.1.1.1 jmAttributeTable
         jobmonMIB.1.1.1.1 jmAttributeEntry
         jobmonMIB.1.1.1.1.1 jmAttributeTypeIndex
         jobmonMIB.1.1.1.1.2 jmAttributeInstanceIndex
         jobmonMIB.1.1.1.1.3 jmAttributeValueAsInteger
         jobmonMIB.1.1.1.1.4 jmAttributeValueAsOctets


>        jobmonMIB.2    jobmonMIBConformance
         jobmonMIB.2.1  jobmonMIBCompliance
         jobmonMIB.2.2  jmMIBGroups
         jobmonMIB.2.2.1 jmGeneralGroup
         jobmonMIB.2.2.2 jmJobIDGroup
         jobmonMIB.2.2.3 jmJobStateGroup
         jobmonMIB.2.2.4 jmAttributeGroup




NOTE: I had to add "G" to the jmJobState group arc name, since the first
object (column) in the jmJobStateTable is also named jmJobState.


Some of us were wondering whether we could eliminate an arc, since
each of our groups is exactly one table, i.e., assign the table OID
instead of a group OID at the .1.1 position?:


>        jobmonMIB
>        jobmonMIB.1 jobmonMIBObjects
>        jobmonMIB.1.1 jmGeneralTable
         jobmonMIB.1.1.1 jmGeneralEntry
         jobmonMIB.1.1.1.1 jmGeneralNumberOfActiveJobs
         jobmonMIB.1.1.1.2 jmGeneralOldestActiveJobIndex
         jobmonMIB.1.1.1.3 jmGeneralNewestActiveJobIndex
         jobmonMIB.1.1.1.4 jmGeneralJobPersistence
         jobmonMIB.1.1.1.5 jmGeneralAttributePersistence
         jobmonMIB.1.1.1.6 jmGeneralJobSetName


>        jobmonMIB.1.2 jmJobIDTable
         jobmonMIB.1.1.1 jmJobIDEntry
         jobmonMIB.1.1.1.1 jmJobSubmissionIDIndex
         jobmonMIB.1.1.1.2 jmJobSetIndex
         jobmonMIB.1.1.1.3 jmJobIndex


>        jobmonMIB.1.3 jmJobStateTable
         jobmonMIB.1.1.1 jmJobStateEntry
         jobmonMIB.1.1.1.1 jmJobState
         jobmonMIB.1.1.1.2 jmJobStateKOctetsCompleted
         jobmonMIB.1.1.1.3 jmJobStateImpressionsCompleted
         jobmonMIB.1.1.1.4 jmJobStateAssociatedValue


>        jobmonMIB.1.4 jmAttributeTable
         jobmonMIB.1.1.1 jmAttributeEntry
         jobmonMIB.1.1.1.1 jmAttributeTypeIndex
         jobmonMIB.1.1.1.2 jmAttributeInstanceIndex
         jobmonMIB.1.1.1.3 jmAttributeValueAsInteger
         jobmonMIB.1.1.1.4 jmAttributeValueAsOctets




>
>Correct?


>yes, if
>	1.  jobmon is not somewhere under printmib
>	2.  you don't have something like 
>		jobmonMIB.2 jobmonNotifications
>	    in which case then
>		jobmonMIB.3 jobmonMIBconformance
>	    would move down one arc


Suppose that we were to add trapping in a future revision.  Would we
have a problem, since jobmonMIBConformace is already allocated as
jobmonMIB.2.  Would we then add jobmonMIBNotifications as jobmonMIB.3?


Thanks,
Tom