Re: Adding a 'chasEnvironSlotIndex' to the chasEnvironTable.

"David L. Arneson (" <> Wed, 30 December 1992 16:01 UTC

Return-Path: <owner-chassismib@CS.UTK.EDU>
Received: from localhost by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA12595; Wed, 30 Dec 92 11:01:03 -0500
X-Resent-To: chassismib@CS.UTK.EDU ; Wed, 30 Dec 1992 16:01:02 GMT
Errors-To: owner-chassismib@CS.UTK.EDU
Received: from by CS.UTK.EDU with SMTP (5.61++/2.8s-UTK) id AA12587; Wed, 30 Dec 92 11:01:00 -0500
Received: from by id aa27817; 30 Dec 92 11:00 EST
Received: from ctron ([]) by (4.1/SMI-4.1) id AA25481; Wed, 30 Dec 92 11:02:14 EST
Received: from yeti.ctron by ctron (4.1/SMI-4.1) id AA11047; Wed, 30 Dec 92 10:57:34 EST
Received: by yeti.ctron (4.1/SMI-4.1) id AA01635; Wed, 30 Dec 92 10:57:20 EST
Message-Id: <9212301557.AA01635@yeti.ctron>
Subject: Re: Adding a 'chasEnvironSlotIndex' to the chasEnvironTable.
In-Reply-To: Your message of "Wed, 30 Dec 92 10:31:34 EST." <>
Date: Wed, 30 Dec 92 10:54:03 -0500
From: "David L. Arneson (" <>

>These objects are fine for 'chassis wide' sensors, like a sensor which 
>represents the temperature of the chassis.  But what of cases where there 
>are sensors within each module occupying a slot?  For example, what if 
>there were a temperature sensor on each module?  What each module had 
>built-in fans which were monitored using a 'sensorFans'?
>A new object could be added to this table to solve this problem.
>'chasEnvironSlotIndex' could be added to represent the slot in which the 
>sensor resides.  The ChasEnvironTable would then be indexed using both 
>chasEnvironIndex and chasEnvironSlotIndex.  chasEnvironSlotIndex could be 
>zero for 'chassis wide' sensors.
>						-Shawn

This sounds like a good idea to me, unless I hear complaints I will add this.
It is really no more difficult in the basic case and adds functionality for
those that need it.

/David Arneson