Using NetView for controlling and managing non-NetView objects

ITEM: RTA000067407

We have some                                                                    
questions regarding using NetView for controlling and managing                  
non NetView objects, like process, Queues, shared memory and more               
application specific objects:                                                   
We are using NetView's DB (object DB) to hold the information we need           
for these objects (e.g. topology, status, timing information). Most of          
this is for the use of our application and is not used by NetView.              
The objects have hierarchic relationships among them. The hierarchic            
relationship info is maintained in the objects DB as well (as parents           
and sons fields).                                                               
1.What do you think about using NetView's DB for holding a large amount         
  of information? Essentially we are mimicking the topology database            
  of IPMap.                                                                     
2.What about using the DB as a topology DB?                                     
3.Why does IPmap uses a topology database in addition to the NetView            
DB?  Why didn't IPMap use NetView's DB?                                         
4. Why in NetView Version 3 is the IP topology DB relational and                
   NetView's DB isn't?  And when is NetView's DB going to be                    
A question about maps:                                                          
5. Why can't a map be opened from an application (why only from the             
   mmi)? Will it be changed in the near future?                                 
1. It depends, of course, on what you call "a large amount" of                  
   information. There is no theoretical maximum to the number of                
   objects recorded in the database, but there are some inefficiencies          
   in the ovwdb process that become a concern at higher numbers.                
   Anything up to 20000 objects should be OK, as long as you have               
   sufficient memory on the machine. You should also look in the SMIT           
   configuration options for ovwdb. There is an option to modify the            
   number of objects to hold in cache, which defaults to 5000. Ideally          
   the cache should be expanded so that it is large enough to hold the          
   whole object database, for performance reasons.                              
2. "What about using the DB as a topology DB"? No problem, so long as           
   you can get the degree of cross-linking of objects that you need.            
   The object database can be used for any data.                               
3. "Why does ipmap use a separate topology database"? I believe the             
   reason for this is partly historical. The IP discovery and mapping           
   function in NetView for AIX pre-dates the object database, and was           
   not re-written when V2 arrived. If you want a more detailed                  
   explanation of why this is, please re-queue the question and we will         
   refer it to development.                                                     
4. "Why in V3 is the object database not relational"? Two reasons for           
   this, one technical, the other practical. The technical reason is that       
   the object database does not have any fixed schema. That is, the             
   fields available are defined dynamically when NVAIX is configured,           
   and all fields do not exist for every object. This does not fit              
   well with the relational model, which is of tables with a fixed              
   set of columns. The practical reason is that development asked               
   customers what information they wanted accessible via SQL, and               
   all the information was already in the IP topology tables. In a             
   soon-to-be available redbook, we show an example of taking the               
   current configuration of the object database, building a relational          
   DB table from it, and then dumping the object data to it. I doubt            
   whether the object database will be "officially" available in                
   relational form (I am not aware of any plans for it). The direction          
   is to exploit O-O technologies in this area, as part of the Karat            
5. When you ask "why can't a map be opened from an application", I              
   assume you really do mean "map" and not "submap"? The reason for this        
   is the structure of the OVW API, which does not allow access to              
   the map database unless the EUI has opened it. This API will be              
   maintained in future releases. There are no plans currently to remove        
   the restriction that requires the EUI to be active.                          
S e a r c h - k e y w o r d s:                                                 
OVWDB OBJECT NVAIX NV6000                                                       

WWQA: ITEM: RTA000067407 ITEM: RTA000067407
Dated: 07/1995 Category: ITSAI6000NV
This HTML file was generated 99/06/24~12:43:25
Comments or suggestions? Contact us