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).
Questions:
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
relational?
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?
ANSWER
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
development.
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