home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / vmsnet / networks / manageme / decmcc / 183 < prev    next >
Encoding:
Text File  |  1992-11-16  |  3.8 KB  |  81 lines
  1. Newsgroups: vmsnet.networks.management.decmcc
  2. Path: sparky!uunet!stanford.edu!agate!spool.mu.edu!caen!uvaarpa!concert!epa-rtp!decmcc@ralph.rtpnc.epa.gov
  3. From: RBN@C3PO.RTPNC.EPA.GOV (Bob Boyd(919-541-4441))
  4. Subject: RE: databases in management products
  5. Message-ID: <921116104150.803@C3PO.RTPNC.EPA.GOV>
  6. Originator: server@ralph.rtpnc.epa.gov
  7. Sender: decmcc@ralph.rtpnc.epa.gov
  8. Nntp-Posting-Host: ralph.rtpnc.epa.gov
  9. Reply-To: <decmcc@ralph.rtpnc.epa.gov>
  10. Organization: Environmental Protection Agency 
  11. Date: Mon, 16 Nov 1992 15:45:57 GMT
  12. Lines: 67
  13.  
  14. Forwarded/Reply created @ 16-NOV-1992 10:33:22.54
  15. ============================== Original Message ==============================
  16. >Date: Mon, 16 Nov 1992 10:21:29 -0500
  17. >Message-Id: <9211161507.AA00610@enet-gw.pa.dec.com>
  18. >Comment:  Discussion group for DECmcc related topics
  19. >Originator: decmcc@ralph.rtpnc.epa.gov
  20. >Errors-To: rbn@ralph.rtpnc.epa.gov
  21. >Reply-To: <decmcc@ralph.rtpnc.epa.gov>
  22. >Sender: decmcc@ralph.rtpnc.epa.gov
  23. >Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
  24. >From: Bill at MKO  16-Nov-1992 0928 <gassman@skibum.enet.dec.com>
  25. >To: Multiple recipients of list <decmcc@ralph.rtpnc.epa.gov>
  26. >Subject: databases in management products
  27. >
  28. >A recent poster made the remark about databases:
  29. >    
  30. >>My arguement is that at the moment I don't really care which db it uses.
  31. >>I just don't want to be forced to pay for one in the future.
  32. >>
  33. >>Roger
  34. >>--
  35. >>brockie@golem.wcc.govt.nz
  36. >
  37. >I'd like to see other opinions on this.  Flat files are typically free
  38. >with an operating system, and the "object oriented database and interface"
  39. >comes with the DECmcc framework, however current trends in management
  40. >software requires a relational database for the types of reports users want.  
  41. >The open systems marketplace offers many different RDBs, meaning that no 
  42. >matter which one Digital would standardize on, customers would have different 
  43. >requirements.  One way to reduce costs is to pre-package some typical reports, 
  44. >requiring that only the "run-time" license of the DB be purchased.  However, 
  45. >many users will want to design their own reports, and require the full report 
  46. >development license.  Another approach is for Digital to make an agreement 
  47. >with a DB vendor to bundle appropriate parts of a DB with the management 
  48. >package.  This however raises the costs, and many customers have already 
  49. >purchased a DB.  
  50. >
  51. >In the DECmcc BMS license and above, the EXPORT function is designed to 
  52. >bring data out of the object oriented database, and create a database that
  53. >cna be used to create reports.  Should Digital revert to a flat-file option 
  54. >to reduce the costs of those that don't want to buy a relational DB?
  55. >
  56. I don't really see this as an Either/Or discussion.  I see it as a both/and
  57. issue.
  58.  
  59. I would like to see the EXPORT function have the flexibility to create 
  60. flat files or database files at the user's option.  The MCC team has 
  61. already done the code for VAX RDB and Ingres, so what would be so tricky
  62. about providing a flat file interface?  There could be a logical name
  63. flag and/or a qualifier on the EXPORT command to control HOW the data
  64. is exported.
  65.  
  66. Here where I'm at I would like to be able to export the data from the
  67. system that is running MCC to another system that is running SAS.  Since 
  68. the site I'm at has NO reason to use RDB, it seems a bit much to ask them
  69. to invest in getting a SAS-2-RDB interface (if it's even available) just
  70. to be able to handle MCC data. 
  71.  
  72. Right now it looks to me that the only way we can export the data to SAS is
  73. by running MCC commands to SHOW the data and then reformatting it into some
  74. form we would then use for SAS processing.  Is there anyone else on the
  75. list who has already conquered this one?
  76.  
  77. ========================== End of Original Message ==========================
  78.  
  79. Bob Boyd    Unisys/EPA, RTP NC    919-541-4441
  80. rbn@c3po.rtpnc.epa.gov
  81.