| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 799.1 | answers | TOOK::SHMUYLOVICH | | Mon Mar 18 1991 14:16 | 71 |
|
RE: .1
> After reading the two chapters in the final BMS Use manual I found that
> I did not understand which relationships there were between the two
> functions other than the simple case of wanting to export past data
> (which obviously uses the recorded data).
There is NO relationship between Historical Data Recording and
Data Exporting.
> Is there a way to ask the exporter to just get data from the historian
> every so often?
The only way to get historically recorded data is using Show directive
with corresponding scope of interest time.
> I want to record data on a set of entities every 15 minutes so the
> operations folk can check back to see what things looked like a while
> ago in the case of observing an anomily in current data (or perhaps a
> fault occured). I also need to export data frequently (each 15 min) so that
> operations management can do online queries when they wish. The
> exported data shouldn't be more than say 15 minutes out of sync than
> the recorded data.
>
> If I read the manual right, I get each entity polled twice every 15
> minutes in order to acomplish this.
In general you are right. Historian and Exporter are two independent FMs
and they can not exchange data.
If you don't want to poll entity twice you can use past time Export.
For example, it can be done from DCL procedure:
1. assign:
time_1 = current_time ;
time_2 = current_time + sleep_time.
2. $ manage export node4 foo begin time = time_1, end time = time_2,-
export period = interval
3. sleep sleep_time and go to step 1.
NOTE: interval must be <= sleep_time
Using this schema each entity is polled only by Historian and Exporter
uses Historical data from Historian's previous polls.
> Another question;
>
> For recording data I specify which partion(s) I want recorded.
>
> For Exporting, there doesn't seem to be any such specification.
>
> Does that mean that if I am recording many partions, I have to export
> them all? What is exported if nothing is being recorded?
From Use manual (page 4-2):
"An export job for current data exports the values of all attribute
partitions for the specified entity. You can also export historical
data which has been stored in the MIR by a Record directive."
It means that you have no choice. Exporter exports ALL ATTRIBUTES.
If you ask for exporting historical data, only available data are
exported. If nothing have been recorded nothing is exported.
Sam
|
| 799.2 | Question on Exporter files | NSSG::R_SPENCE | Nets don't fail me now... | Fri Mar 22 1991 13:01 | 22 |
| There are several files created in MCC_COMMON for the exporter to use.
They look like the following;
MCC_1116000400AA000001C9E556F679DEE0.MCC_EXP_ATTR011_P;1
MCC_1116000400AA000001C9E556F679DEE0.MCC_EXP_ATTR011_PH;1
MCC_1116000400AA000001C9E556F679DEE0.MCC_EXP_INST011_P;1
MCC_1116000400AA000001C9E556F679DEE0.MCC_EXP_INST011_PH;1
MCC_1116000400AA000001C9E55B3807F500.MCC_EXPO_Q11_Q;1
MCC_1116000400AA000001C9E55B3807F500.MCC_EXP_ATTR011_P;1
MCC_1116000400AA000001C9E55B3807F500.MCC_EXP_ATTR011_PH;1
MCC_1116000400AA000001C9E55B3807F500.MCC_EXP_INST011_P;1
MCC_1116000400AA000001C9E55B3807F500.MCC_EXP_INST011_PH;1
How do I determine which of these files are actually in use and which
ones may have been created through experimenting with export but are no
longer needed?
Also, is there an explanation of what each of the files is used for?
This could be helpful in diagnosing problems.
Thanks
s/rob
|
| 799.3 | More Exporter questions... | MCDOUG::MCPHERSON | i'm only 5 foot one... | Thu Jun 13 1991 17:59 | 29 |
| <<< ISVNET::DISK$SHARED:[NOTES$OTHER]DECMCC.NOTE;1 >>>
-< DECmcc Conference >-
================================================================================
Note 22.0 Questions about EXPORTER 1 reply
VAXWRK::HRONIK 23 lines 11-JUN-1991 16:29
--------------------------------------------------------------------------------
We have some questions about the exporter.
1. The section in the BMS Use manual titled "Getting Started with the Exporter"
says that "The entity for which you export data and all of its parent entities
must be registered." We were thinking about exporting data for possibly any
network object, but we are registering only the global network object. It
doesn't seem reasonable (or even possible) to register every network object.
2. Can a wild card be used as the entity_specification in the EXPORT command?
If a wild card is used in a request for current data, will the export be
done by a single backgound process or multiple background processes?
3. Will the Exporter pass the BEGIN_TIME and END_TIME parameters to a
FM for access to information in a private MIR?
4. Into what format does the Exporter convert the constructed data types?
Specifically what does an AES get converted into? What is the schema for
exported data types?
5. We would like to export a single entity instance. In other words,
from an FM, call the EXPORTER, identify a specific entity instance, and
definitely know that the export is completed when the call returns. Can
this be done?
|
| 799.4 | No, I'm not talking to myself! ;^) | MCDOUG::MCPHERSON | i'm only 5 foot one... | Fri Jun 14 1991 10:22 | 272 |
| Sam answered these questions in a mail message I sent him, so I'll post it
here. Seems like portions of Sam's answer maight have been contained as
answers to previous questions here in the MCC conference, but since a little
redundancy is preferable to a little incompleteness, I'll go ahead and post the
entire reply below.
thanks again, Sam!
/doug
From: TOOK::SHMUYLOVICH "Samuil Shmuylovich LKG2-2/T2 DTN: 226-5351" 13-JUN-1991 19:18:17.37
To: TOOK::MCPHERSON
CC: SHMUYLOVICH
Subj: RE: Questions about Exporter from BBN
Hi Doug,
This is my answers. You can put them all as a reply to note 22 or edit them
if you think they are too long.
Regards Sam
>1. The section in the BMS Use manual titled "Getting Started with the Exporter"
>says that "The entity for which you export data and all of its parent entities
>must be registered." We were thinking about exporting data for possibly any
>network object, but we are registering only the global network object. It
>doesn't seem reasonable (or even possible) to register every network object.
There are several reasons why entity being Exported must be registered.
One of them is renaming of the entity when exporting operation is in progress.
Note about "registering only the global network object". When you
register a global entity all its nondynamic subentity (defined in the .MS as
DYNAMIC = FALSE) are autoregistered.
>2. Can a wild card be used as the entity_specification in the EXPORT command?
>If a wild card is used in a request for current data, will the export be
>done by a single background process or multiple background processes?
Yes, a wild card can be used in the entity in the EXPORT command.
In order to expend wild card Exporter FM does "SHOW specified_entity ALL
Identifiers" and create create one exporting request for EACH single
entity.
There is only one background process per RDB file.
>3. Will the Exporter pass the BEGIN_TIME and END_TIME parameters to a
>FM for access to information in a private MIR?
No. Begin and End time parameters mean time when to enable and
disable exporting request.
>5. We would like to export a single entity instance. In other words,
>from an FM, call the EXPORTER, identify a specific entity instance, and
>definitely know that the export is completed when the call returns. Can
>this be done?
Yes, this can be done but using the different schema. Exporter FM
is designed to return from mcc_call after it accepts a request but not
when all exporting job is done. This is the main idea why Exporter FM has
a background process. From your FM you can do Export command and after
this do Show Exporting several times watching argument you are interested
in (I think it will be "number of successful polls" or/and "status").
>4. Into what format does the Exporter convert the constructed data types?
>Specifically what does an AS get converted into? What is the schema for
>exported data types?
Exporter FM does not support constructed data types.
The following is a brief description of the database created by the
Exporter FM. Hope this will help.
1. RDB file/Database name
The RDB file name (on VMS) and Database name (on Ultrix) are provided
by user by specifying the "export target" argument in the Export directive
or by using the default.
The default RDB file/Database name is as follow:
a. VMS - defined by logical MCC_EXPORT_RDB_NAME,
MCC_EXPORT.RDB if this logical is not defined;
b. Ultrix - defined by environmental variable
MCC_EXPORT_RDB_NAME, MCC_EXPORT_RDB if
this variable is not defined.
Note: On Ultrix Database other that MCC_EXPORT_RDB must be
created by SQL System Administrator.
2. Table types and names
There are two types of RDB tables supported by the Exporter FM:
a. - entity based table (EBT);
b. - partition based table (PBT).
Every row (record) in the EBT contents all information about the entity
and all of its attributes for the given time.
Every row (record) in the PBT contents identification information
about the entity and all of its attributes belong to this partition.
The following table shows how this types of the RDB tables are
supported by the different versions of the Exporter FM.
-------------------------------------
| Version | Table type |
-------------------------------------
| DECmcc V1.1 | EBT |
| DECmcc V1.2/VMS | EBT & PBT |
| DECmcc V1.2/Ultrix | PBT |
-------------------------------------
Note: The EBT in DECmcc V1.2/VMS contents several additional
columns.
EBT name is constructed from the class name(s) of entity whose data
are exported preceded by prefix "MCC_". For example, a table name for
node4 entity is "MCC_NODE4"; for node4 line entity - "MCC_NODE4_LINE".
PBT name is constructed by appending a partition code to the
corresponding EBT name. For example, PBT which contents counters for
node4 line entity is "MCC_NODE4_LINE_3".
3 Structure of the RDB tables
Any record in both RDB tables can be logically divided into two parts:
1 - entity identification information and
2 - attribute information.
3.1 Entity identification information
Entity identification information is not depending on RDB table type
and contains from the following columns:
------------------------------------------------------------------------------
| Column name | MCC data type | Comment |
------------------------------------------------------------------------------
|"Time_Stamp" |MCC_K_DT_BIN_ABS_TIM |Schedule time |
| | | |
|<Entity class/subclass |defined by identifier|One column per subentity |
| presentation name> |returned from |level. The names of the |
| |SHOW entity ALL IDENT|columns are taken from |
| | |the data dictionary |
| | | |
|"MCC_EXPORT_SEQUENCE" |MCC_K_DT_LATIN1STRING|User defined string |
| | |(default EXPORT) |
| | | |
|"MCC_EXPORT_SEQUENCE_NUMBER"|MCC_K_DT_UNSIGNED32 |Reflect numbers of polls,|
| | |starting value is defined|
| | |by user(default 0) |
| | | |
|"MCC_Export_Poll_Status" *|MCC_K_DT_UNSIGNED32 |Indicates success/failure|
| | |of the current poll |
| | |(1 - data available; |
| | | 0 - data not available) |
| | | |
|"MCC_EXP_CVR" *|MCC_K_DT_UNSIGNED32 |CVR returned from the |
| | |current mcc_call to get |
| | |identifiers |
| | | |
|"MCC_EXP_CVR" *|MCC_K_DT_UNSIGNED32 |Additional information |
| | |if returned CVR is an |
| | |exception |
| | | |
|"MCC_EXP_Time_Duration" *|MCC_K_DT_BIN_ABS_TIM |Time of computing the |
| | |duration for statistics |
| | |(only is statistics |
| | | partition is valid for |
| | | the specified entity) |
| | | |
|"MCC_EXP_Export_Time" *|MCC_K_DT_BIN_ABS_TIM |Time when record is |
| | |written in the table |
------------------------------------------------------------------------------
Note: * in column name indicates that this column is not available in
the DECmcc V1.1
3.2 Attribute information
Attribute information can be logically divided into attribute sections
containing information about a particular partition. Depending on the
table type attribute information contains information about one particular
partition (in the case of PBT) or all available partitions (in the case
of EBT).
An attribute section contains from the following columns:
------------------------------------------------------------------------------
| Column name | MCC data type | Comment |
------------------------------------------------------------------------------
|"Time_<presentation name of |MCC_K_DT_BIN_ABS_TIM |Presentation name is taken
| the partition>" | |from the dictionary. |
| | |Represents a time stamp |
| | |from the corresponding |
| | |mcc_call to get data. |
| | | |
|<presentation name of the |defined by data type |One column per attribute.|
| attribute> |of the attribute in |Presentation name is taken
| |the data dictionary |from the dictionary. |
------------------------------------------------------------------------------
Note: See section 5 Name limitation.
4. Data type conversion
The following table represents the conversion of the MCC data types to
the the equivalent SQL data types:
-------------------------------------------------------------------------------
| | SQL data type | | |
| MCC data type |-----------------| SQL field length | Comment |
| | VMS | Ultrix | | |
|-----------------------------------------------------------------------------|
|MCC_K_DT_BOOLEAN |SMALLINT|SMALLINT| - | |
|MCC_K_DT_INTEGER8 |SMALLINT|SMALLINT| - | |
|MCC_K_DT_INTEGER16 |SMALLINT|SMALLINT| - | |
|MCC_K_DT_INTEGER32 |INTEGER |INTEGER | - | |
|MCC_K_DT_INTEGER64 |QUADWORD|INTEGER | - | |
|MCC_K_DT_UNSIGNED8 |SMALLINT|SMALLINT| - | |
|MCC_K_DT_UNSIGNED16 |INTEGER |INTEGER | - | |
|MCC_K_DT_UNSIGNED32 |QUADWORD|INTEGER | - | |
|MCC_K_DT_UNSIGNED64 |QUADWORD|INTEGER | - | |
|MCC_K_DT_COUNTER16 |INTEGER |INTEGER | - | |
|MCC_K_DT_COUNTER32 |QUADWORD|INTEGER | - | |
|MCC_K_DT_COUNTER48 |QUADWORD|INTEGER | - | |
|MCC_K_DT_COUNTER64 |QUADWORD|INTEGER | - | |
|MCC_K_DT_COUNTER16 |INTEGER |INTEGER | - | |
|MCC_K_DT_COUNTER32 |QUADWORD|INTEGER | - | |
|MCC_K_DT_ENUMERATION |QUADWORD|INTEGER | - | |
|MCC_K_DT_FILE_SPEC |CHAR |CHAR | 255 | |
|MCC_K_DT_LATIN1STRIN |CHAR |CHAR | 132 | |
|MCC_K_DT_SIMPLE_NAME |CHAR |CHAR | 255 |dns$k_simplestrmax
|MCC_K_DT_FULL_NAME |CHAR |CHAR | 512 |dns$k_fullstrmax |
|MCC_K_DT_VERSION |CHAR |CHAR | 12 | |
|MCC_K_DT_PHASE4NAME |CHAR |CHAR | 7 | |
|MCC_K_DT_PHASE4ADDRESS|CHAR |CHAR | 7 | |
|MCC_K_DT_REAL |FLOAT |FLOAT | - | |
|MCC_K_DT_BIN_ABS_TIM |TIME |CHAR | -/40 | |
|MCC_K_DT_BIN_REL_TIM |TIME |TIME | - | |
|MCC_K_DT_ADDRESS_DTE |CHAR |CHAR | 44 | |
|MCC_K_DT_ID802 |CHAR |CHAR | 17 | |
|MCC_K_DT_ID802_SNAP |CHAR |CHAR | 14 | |
|MCC_K_DT_ID802_SAP |CHAR |CHAR | 2 | |
|MCC_K_DT_IDENETV2_TYPE|CHAR |CHAR | 5 | |
|MCC_K_DT_IPADDRESS |CHAR |CHAR | 15 | |
|MCC_K_DT_INTERNET_NAME|CHAR |CHAR | 255 | |
-------------------------------------------------------------------------------
5 Name limitation
Due to the SQl limitation column and table names can not be longer
that 31 symbols on VMS and 23 symbols on Ultrix. Ultrix SQL has an additional
limitation on the number of columns in each table (not more that 127).
The column and table names are abbreviated by truncating the longest
words of the presentation name until the overall name is of the required
length.
6 Data processing
When Exporter FM creates a table for a specified entity it uses the
data dictionary to define all valid attributes for a specified entity class.
It creates a column in the table for each valid attribute.
Every time when Exporter FM writes data in the table it writes only
data received from the mcc_call "Show <entity> all <partition>". If not all
attributes are returned the corresponding columns in the table will be empty.
|
| 799.5 | Some more questions on the exporter? | TENERE::SILVA | Carl Silva - Telecom Eng - DTN 828-5339 | Tue Jul 16 1991 09:26 | 14 |
| RE: .4,
This may have already been asked but I could not find it.
Regarding the data type conversions that the exporter performs, with
ULTRIX/SQL how does it translate:
1. "SET OF" attributes?
2. User defined data types?
3. Enumerated data types?
Carl
|
| 799.6 | re:.5 see 1258.1 | TOOK::SHMUYLOVICH | | Wed Jul 17 1991 10:54 | 1 |
|
|