From: RBN@C3PO.RTPNC.EPA.GOV (Bob Boyd(919-541-4441))
Subject: RE: databases in management products
Originator: server@ralph.rtpnc.epa.gov
Reply-To: <decmcc@ralph.rtpnc.epa.gov>
Organization: Environmental Protection Agency 
Date: Mon, 16 Nov 1992 15:45:57 GMT

Forwarded/Reply created @ 16-NOV-1992 10:33:22.54
============================== Original Message ==============================
>Date: Mon, 16 Nov 1992 10:21:29 -0500
>Message-Id: <9211161507.AA00610@enet-gw.pa.dec.com>
>Comment:  Discussion group for DECmcc related topics
>Originator: decmcc@ralph.rtpnc.epa.gov
>Errors-To: rbn@ralph.rtpnc.epa.gov
>Reply-To: <decmcc@ralph.rtpnc.epa.gov>
>Sender: decmcc@ralph.rtpnc.epa.gov
>Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
>From: Bill at MKO  16-Nov-1992 0928 <gassman@skibum.enet.dec.com>
>To: Multiple recipients of list <decmcc@ralph.rtpnc.epa.gov>
>Subject: databases in management products
>
>A recent poster made the remark about databases:
>	
>>My arguement is that at the moment I don't really care which db it uses.
>>I just don't want to be forced to pay for one in the future.
>>
>>Roger
>>--
>>brockie@golem.wcc.govt.nz
>
>I'd like to see other opinions on this.  Flat files are typically free
>with an operating system, and the "object oriented database and interface"
>comes with the DECmcc framework, however current trends in management
>software requires a relational database for the types of reports users want.  
>The open systems marketplace offers many different RDBs, meaning that no 
>matter which one Digital would standardize on, customers would have different 
>requirements.  One way to reduce costs is to pre-package some typical reports, 
>requiring that only the "run-time" license of the DB be purchased.  However, 
>many users will want to design their own reports, and require the full report 
>development license.  Another approach is for Digital to make an agreement 
>with a DB vendor to bundle appropriate parts of a DB with the management 
>package.  This however raises the costs, and many customers have already 
>purchased a DB.  
>
>In the DECmcc BMS license and above, the EXPORT function is designed to 
>bring data out of the object oriented database, and create a database that
>cna be used to create reports.  Should Digital revert to a flat-file option 
>to reduce the costs of those that don't want to buy a relational DB?
>
I don't really see this as an Either/Or discussion.  I see it as a both/and
issue.

I would like to see the EXPORT function have the flexibility to create 
flat files or database files at the user's option.  The MCC team has 
already done the code for VAX RDB and Ingres, so what would be so tricky
about providing a flat file interface?  There could be a logical name
flag and/or a qualifier on the EXPORT command to control HOW the data
is exported.

Here where I'm at I would like to be able to export the data from the
system that is running MCC to another system that is running SAS.  Since 
the site I'm at has NO reason to use RDB, it seems a bit much to ask them
to invest in getting a SAS-2-RDB interface (if it's even available) just
to be able to handle MCC data. 

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?

========================== End of Original Message ==========================

Bob Boyd	Unisys/EPA, RTP NC	919-541-4441
rbn@c3po.rtpnc.epa.gov
Newsgroups: vmsnet.networks.management.decmcc