Updated Definitions for the Job Monitor Project

Updated Definitions for the Job Monitor Project

Updated Definitions for the Job Monitor Project

rbergma at dpc.com rbergma at dpc.com
Wed Oct 2 11:33:22 EDT 1996


Tom,


Some additional thoughts regarding your recent posting:
 
TH> I agree that our actual MIB wants to have concise definitions 
TH> along the lines that you propose.  But I want to first get agreement 
TH> on what objects we want and then we can refine, simplify, etc. 
TH> But if we attempt to worksmith the descriptions at the same time 
TH> as we are trying to decide what objects we need, we will have too 
TH> difficult time and progress will be too slow.   


TH> Also some of these definitions are actually different from the ISO  
TH> DPA semantics. 
 
TH> Also I don't want to debate names of the objects, until we have 
TH> the definitions agreed to.  Naming should come last.  Also we need 
TH> to understand what information a single job will have in a  
TH> (doubly indexed) table as opposed to a scaler (one column in the job 
TH> table) for the job.  Separate tables may want to have a different 
TH> significant word, such as "job" for the scalars and something else 
TH> for the tables, such as "doc", or "acc". or something.   
TH> So we need to wait to name our objects until after we agree on the 
TH> specification and the number of instances per job. 
TH> Also we may want to have a common prefix on each object, such as 
TH> "jm" for job monitoring, like so many other MIBs. 
 
TH> So the order for processing should be: 
TH> 1. What objects do we want using DPA definitions to indicate what  
TH> we mean using jm-spec.doc and jm-spec.psr. 
TH> 2. What objects are mandatory, what are conditionally mandatory, 
T>     what are in a second MIB. 
TH> 3. Which objects are one instance per job and which are multiple 
TH>    per job. 
TH> 4. What is the syntax for each object. 
TH> 5. What is the simplified description text for each object. 
TH> 6. What is the name for each object. 
 
I agree that the meeting agenda should follow the plan as outlined.
However, I believe that it will be beneficial in the long run to have
discussions on the reflector that are either ahead or behind the 
progress in the meeting.  This can only help future progress, since
some of the sticky issues can be resolved outside of the meeting and
it also gives everyone time to ponder the issues.


The DPA definitions that you presented are very good starting points
for this task.  They give everyone a chance to pick and choose those
features desired for the PWG MIB.  I generated my definitions as a 
result of the discussions in both Montreal and Portland to present an
update to the DPA definitions.  I am not proposing that they become the
final document.  I know they need a generous amount of work.  I have 
accomplished my goal of generating some reflector activity.


I trust that the meetings are progressing well!


-----------------------------------------------------------------------
	Ron Bergman
	Dataproducts Corp
	rbergma at dpc.com



More information about the Pwg mailing list