From: Colin Strutt LKG2-2/T2 DTN:226-5340 <strutt@took.enet.dec.com>
Subject: RE: databases in management products
Originator: server@ralph.rtpnc.epa.gov
Reply-To: <decmcc@ralph.rtpnc.epa.gov>
Organization: Environmental Protection Agency 
Date: Tue, 17 Nov 1992 19:00:53 GMT

Bob Boyd continues to enquire:
* >
* >Bob Boyd writes:
* >
* >> Right now it looks to me that the only way we can export the data to SAS is
* >> by running MCC commands to SHOW the data and then reformatting it into some
* >> form we would then use for SAS processing.  Is there anyone else on the
* >> list who has already conquered this one?
* >
* >I would be interested to know exactly how the data should appear, if it is
* >not in a SQL form.  For example, would you like it to be encoded in the same
* >way that it is encoded in the MIR? (Seems unlikely, as the program(s) that
* >would decode that information would have to be quite complex).  Would you
* >like to see it in ascii - and if so, formatted how?  (This seems similar to
* >what you would get with a 
* >	SHOW xxx, TO FILE yyy
* >except that your ascii parsing would be a little different).  Is there
* >another approach that I've omitted?
* >
* Colin,
* 
* I'm a little bit at a disadvantage here since I have not gotten real
* interested in looking at the guts of records in the MIR.  So, I don't 
* really have a clear sense of how gnarly it might be to decode the stuff
* that's out there.  I can sort of imagine from looking at the DECmcc System
* Reference Manual that it might be interesting.  I assume the complexity 
* you're suggesting is due to the degree to which the information is encoded
* -- not because of the organization of the database.
Absolutely! The MIR data (eg. the historical data) is stored for the
convenience of DECmcc to use, not for external access. Thus it is stored
in an ILV-encoded manner, so that it may be passed across the mcc_call
interface efficiently. We envisioned Exporting the data, to Rdb, or outputting
the data via a command line PM, to be parsed in text, as the means to process
the management data outside DECmcc

* 
* I'm curious about what the schema for the data looks like with Rdb or
* Ingres.  I've looked at the Historical Data Services Use manual and see
* that the records are fairly simply organized, but could get quite large --
* especially with SNMP or CMIP managed objects.
Right again.

* 
* This does sound like an interesting problem -- I can think of some
* alternatives but all of them have drawbacks of some sort.  Seems like one
* major complication comes around the possibility of having data from
* disimilar entity types being exported to the same data file(s).  Because of
* this, it seems that all of the identifying information has to appear in the
* record itself instead of appearing in some kind of header block.
* 
* Of course if the file(s) could be separated on the same basis as the tables
* -- then it might be feasible to have a header record at the beginning of
* the file that gives the structure of the records in the rest of the file.
* Then the rest of the records would be an ASCII representation of the data
* with some sort of delimiter between fields -- essentially just another form
* of a table.
* 
* This might be a good compromise between the ASCII format of the SHOW 
* command and a pure "internal" format.  Comments?
One concept we had discussed, but have not implemented is adding table output
support to the FCL PM (similar to that done for the IM PM). This would
allow any output command to have the qualifier:
	, As Table
to cause the output to be formatted in a tabular manner, with column titles.
Perhaps *this* would also address your problem?
Certainly readability of the output is not great (and one reason why we
haven't implemented it) - but if you want that form of output in order
to process by another program, using
	, Ad Table, To File yyy
you may not care if the lines get too long.

It would involve a modest (ie. not a trivial!) amount of work to add this
capability to the FCL PM - we cannot guarantee that this work would get done
for a particular release.

Comments?

Colin Strutt
DECmcc Technical Director
Newsgroups: vmsnet.internals