|
Some details how Exporter FM creates an RDB:
1. Exporter tries to create an RDB every time when exporter background
process restarts ( note that the first time it's waiting for the
first Export directive).
An RDB file name is an argument to the Export command and to the
background process. It gives an ability to export data to the
different RDB files.
2. Exporter tries to create a table in every Export directive.
On VMS the table name is built from an entity class, for example,
MCC_NODE4 or MCC_NODE4_LINE.
The columns names and datatypes are obtained from the MCC Data Dictionary.
Same of the attributes are not returned by the corresponding AMs or their
data types are not supported yet by the Exporter so these columns are
empty.
3. When Exporter collects required data it INSERTs data into the
corresponding table.
I'm not an RDB expert so my question could be naive. Is it possible instead
of customizing Exporter's RDB file just to copy information you need to
another RDB file?
Sam
|
| re .1
Your naive idea might be a great one. I need to understand more to know.
>> 1. Exporter tries to create an RDB every time when exporter background
>> process restarts
I'm sorry this is chinese to me. How often does this happen? Does it happen
at fixed intervals or with any predictable schedule? What happens to the old
database when a new one is created?
>> ( note that the first time it's waiting for the
>> first Export directive).
??
>> The columns names and datatypes are obtained from the MCC Data Dictionary.
>> Same of the attributes are not returned by the corresponding AMs or their
>> data types are not supported yet by the Exporter so these columns are
>> empty.
How do I know which columns will always be empty? If I do create my own database
and move the data into it, all problems would be over (maybe) if I could omit
these fields from the tables.
Thanks very much,
Hagar.
|
|
>>> 1. Exporter tries to create an RDB every time when exporter background
>>> process restarts
>
>I'm sorry this is chinese to me. How often does this happen? Does it happen
>at fixed intervals or with any predictable schedule? What happens to the old
>database when a new one is created?
>
>>> ( note that the first time it's waiting for the
>>> first Export directive).
>
>??
Sorry, I thought that you are familiar with MCC at least in general.
The user can ask MCC to export data to the RDB file any time he wants.
He is able to specify an RDB file name in every export request.
So it's up to the user what RDB file to use, how many entities to export
in the same RDB file.
For example, if you want to export the information from 100 nodes it's
possible to use one RDB file for all of the nodes or to use a hundred
different files (the user has to define his strategy).
I'll not go into the details of the Exporter FM (an MCC functional module
responsible for exporting data out of MCC into the RDB) but the main point
is that an attempt to create an RDB file may occur several times and is not
predictable. If a given RDB file already exists (has been created earlier)
the Exporter uses this existing file.
Again, I'm not an RDB expert but it seems to me that it's possible to create
an RDB file prior to specifying export directive in MCC and let Exporter
to use this file. If this is correct you can create an RDB file in any way
you want (making it multi-file, choose the page size etc).
>>> The columns names and datatypes are obtained from the MCC Data Dictionary.
>>> Same of the attributes are not returned by the corresponding AMs or their
>>> data types are not supported yet by the Exporter so these columns are
>>> empty.
>
>How do I know which columns will always be empty? If I do create my own database
>and move the data into it, all problems would be over (maybe) if I could omit
>these fields from the tables.
On VMS every RDB table (table not a file!) corresponds to an object class,
for example, node4, snmp, or node4 line etc.
Every column in the RDB table represents a particular attribute for a given
object class.
The MCC Data Dictionary defines attributes, their names and datatypes for each
object class.
Not each instance of a given class returns ALL set of defined attributes.
It's impossible to predict which columns will be empty. It seems to me easier
to move only columns you need.
Hope this helps, if you need more information you can contact me directly at
TOOK::SHMUYLOVICH
Sam
|