Conference csc32::consolemanager

    Anna,
    
        Your idea of a merged database is definately a good one. We've 
    had small discussions on the possibility of doing this, but nothing
    formaly. If you'd really like to get the ball rolling, then I'd suggest
    that you start talking with the various product managers. Ann Dineen is
    a good place to start. It's no easy task and would probabily take a
    year or two to get all the products in sync. 
    
    Dave

    Dave,
    
    I am glad there is some one who shares my opinion. I really would like
    to get the ball rolling, but I do not know very much about the
    data/fields stored into the n databases envolved into the POLYCenter
    Solution.
    
    If you have some pointer to the schema documentation, any kind of
    documentation, please let me know or post it as a reply to this note. 
    
    Anyway, you must be sure that at this days, not further the end of this 
    POLYCENTER TEP I will contact the products managers to ask why not a 
    common database.
    
    Ciao.
    
    						Anna

    I forgot. 
    
    In the conference Inspect_srf, VARDAF::BERBIGIER has answered at the same
    note. Using different words, but it seems to me he share the same
    opinion about integration using different database!
    
    							Anna
    

    Anna,
    
       We don't have any documentation about the database schema. We use a 
    packed record format stored in binary. That is, all of our record
    fields are variable in length thus making the record format dynamic.
    You could have the header files (in C) but I doubt they would be of
    much use to you at this stage of your planning.
    
    Cheers,
    
       Dave

    Ok Dave,
    
    there is no documentation, but maybe you (or other people from the
    engineering) can list all the data collected into the db.
    
    I retrieve the data collect by the user guide and by playing with the
    product. Maybe I miss something and you can image it is a long work.
    And I think that engineering people should have at least a list of all
    the data the product uses and stores.
    
    This list could be very usefull for me to write the last part of my
    TEP white paper.
    
    have you, or anyone in this conference or anywhere, got this list?
    
    Ciao.
    
    						Anna

  The easiest way of getting this list, at least for
  Console Manager, would be to create an entity of
  each type with the editor, then doing an "export"
  this will produce a text file describing each entity
  and its attributes.

  I dont know if the other POLYCENTER products have
  this "export" facility, but if they do, you could
  probably do the same for them.

  You also need to be aware that products record data
  in their databaes which is not meant to be seen by
  anyone else, I know we do for Console Manager and
  those values could cause the product to not work if
  changed without understanding the full implications
  of such a change.


Cheers,
Phil

    
    Anna,
    
    And this is by no means a simple task. It may sound so up front, but in
    reality, it will prove to be a complex task. What will end up happening
    is that each product will keep part of it's data in the 'public'
    database and some data in it's own private database. 
    
    However, your idea od a client/server database is still a good one.
    The only advise I can give you is to keep it simple to start and
    keep it dynamic for future expansion. By keeping it simple,
    you'll get a lot more buy-in from your audience.
    
    Dave

    My $.02 worth:
    
    To build upon what Dave said in -1 let's look at 2 of the products
    you mentioned - Console Manager and System Census - from a nuts and
    bolts perspective. CM uses a very simple stream format file to store
    it's config data and is very easy to access from a programming
    perspective. System Census uses an RDB database and complex SQL
    calls to manipulate the data repository it gathers from it's agents.
    System Watchdog has yet another structure for storing data.
    
    The base problem is that none of these products use a common
    architecture. A few years ago the Enterprise Management Architecture
    was created to hopefully solve the common architecture problem. it was
    hoped that EMA would be adopted by OSF but it was not. So now we have
    complete anarchy.
    
    You seem somewhat amazed that several people share your thoughts. I think
    you'll find those that do not agree with your philosophy in the
    minority. There are no logical arguments against your ideas, only
    hurdles.
    
    Good luck!
    
    Dan

    Dan,
    
    anarchy is not the good way to continue to develop products!
    
    The market is requiring good and high quality products, expecially in
    the "integrated solution". We have good products, but they are not
    integrated! We will never have success to sell what we do not have!
    
    The businnes are not so good at this moment to leave that anarchy
    reigns.                                                     
    
    I do not feel myself very encouraged to learn that a lot of people
    share my idea, and nobody (marketing, engineering, software, ...) is 
    doing something to realize it. 
    
    I do not believe that the global costs, that Digital must substain now to 
    mantain and to develop all the products using a different architecture,
    is less of the cost needful to define and develop a strategy to migrate
    in the next future from anarchy to a really "integrated solution".
    
    You are right. Digital is living a true anarchy period. Unfortunately
    it means that everybody is thinking about his own profit instead of the 
    common profit of the company!
    
    Hoping in better time in the future,
    
    							Anna

    Yes anarchy is not good, for sure.
    
    But making plans and plans and plans and plans and ... something I've
    seen a lot at Digital. In the Unix world, if we had to wait that Unix
    engineering & VMS engineering were agree to find a common way to have a
    file system, a backup engine, ... we would simply be dead today.
    
    I don't say that integration is not important, it definitevely is. But
    on the other hand, you have to find solutions in such a timeframe that
    you cannot afford you to 'loose' your time in big discussion.
    
    PCM is a good example of making a product available whatever platform
    it has been developed on. Same code, same doc, ... is simply a success
    in the first step of integration.
    
    Asking all Digital enginnering groups to document their console output
    is another positive step.
    
    Making a common DB to share information as we did with MCC (using
    Ingres on Ultrix), UDM, ... was not in my eyes the way to integrate
    stuff. Too heavy, too difficult, ... People didn't like it !
    
    Anarchy ? yes, for sure ... today, it seems no one has anymore the control
    of what happens inside Digital !

       <<< NOTED::DISK$NOTES7:[NOTES$LIBRARY_7OF4]SYSTEM_CENSUS.NOTE;1 >>>
                         -< POLYCENTER System Census >-
================================================================================
Note 320.2           Configuration/Profile Database Schemas?              2 of 2
WOTVAX::ELLISM "Are you all sitting too comfybold square on your botty? - Then we'll begin"  42 lines  17-FEB-1994 12:11
--------------------------------------------------------------------------------
Mark,

Reading your reply was interesting. Whilst I agree with some of your reasons, I must
differ with some.

Yes, a common database is one way to integrate, another is to use common agents, not
to be confused with THE common agent. Would it not be possible to write a single
agent for multiple products, and turn on parts of the super set, depending on the
functionality licensed? After all, why have multiple agents on a system when 1 will
do? Surely, this will impact performance less, and reduce wasted effort in engineering
(which could be re-directed to enhancing functionality), it would also mean that if
an enhancement, in terms of collection criteria, was required, this would then be
available to all products. This approach does not require a framework either and, 
remember, not all customers will buy a framework (At $15,000 a shot you have to be
a reasonably large customer just to justify the software cost, without the platform.) 

We can take this conversation wider to include Console Manager, PSW, DECamds, Performance
Solution and System Census. All these product use similar information, especialy the
last 4, and the last 4 have, at some time or another been engineered from a previous
incarnation of the group that produces PSC & PPS. If the goal is to unify under a 
framework then I still do not understand why a common database cannot be created now.
Any Framework, worth its salt (Netview is NOT a framework, it's a fancgy GUI to SNMP
with a callable interface), has a MIR (Argh, dare I bring in DECmcc....no, we'll call
it DME). If we develop a common database for multiple products, surely this will make
the effort to migrate to a framework easier for those products, and you have to
perform one database migration, not 4 or 5! Again, this would save development effort.

I think I'll just point out that this was recommended some years ago buy the group that
I work for, and we were no heeded then.

I agree with all your marketing driven reasons, but are marketing actualy asking the
customers if they want a common database for their product? Have they performed a QFD
or real market analysis? If you don't ask the questions in the correct way, then you 
can get duff answers.

Regards

Martin

P.S. Someof this work is going to be done by the European OSC tools development group,
but it should be done as part of the product. Retro-fitting solutions is not as elegant
and as efficient as architected solutions.

       <<< NOTED::DISK$NOTES7:[NOTES$LIBRARY_7OF4]SYSTEM_CENSUS.NOTE;1 >>>
                         -< POLYCENTER System Census >-
================================================================================
Note 320.1           Configuration/Profile Database Schemas?              1 of 2
ZENDIA::PRATT "Mark Pratt  (DTN 227-3137)"           59 lines  16-FEB-1994 17:27
--------------------------------------------------------------------------------
>My idea is that a lot of products collect the same data or very similar data.
>Unfortunatly all the products use their own database.

You are correct about this although I'm not sure how much 
overlap there is between the data that the products gather.

>In my opinion, "integration" means the sharing of information and data through
>only one database. Moreover to handle only one database should be less 
>expensive and easier to mantain either for Digital and for the customer.


(I'm going to try to keep my response short here and not let it
 get too long winded!)

That is one form of integration. I also agree that is advantageous
to only support one common database. And I think that each of the 
groups working on those products would agree as well. Unfortunately
there has not been a lot of progress in integration of the point 
products. 

We in NSM/DSM (as well as the rest of engineering) began trying to 
correct the situation. A lot of work has gone into resolving many 
of the issues of overlapping and/or competing products, and many of 
the engineers of those products now work together in the same organization. 
This is goodness. And we all had great ideas to make our point products work
together. At the same time engineering has become much more driven by 
marketing. And this is goodness too. 

But because we are market driven now, the focus of integrating the
point products together has now taken a back seat to expanding on
other platforms and integrating with frameworks (such as Netview 
or Microsoft Hermes). This is not a bad idea either. And I'm sure that
there are many people that will say is the best way to integrate the 
point products. 

With respect to PSC, we are integrating PSC and PSD (software distribution)
together but are being tied together using a framework... Hermes. 

I would like to see it happen but to be honest, I don't think we'll 
ever have a common database or even much (direct) integration of our 
(existing) point products. Due to the way that the industry is heading,
the direct integration of the point products may not even make sense 
anymore. I'm sure that there are many people that would say that the best 
way to integrate the products is thru industry de facto standard 
frameworks. 

>There is some one who can describe me the schemas of the databases involved? I
>would like to know the architecture and the design of the database.

The PSC schema is documented in the PSC user guide atleast to the point
of describing the tables and the fields. It does not document the table 
relationships however. If you have questions, I'd be glad to answer them.

-- Mark




 

Ahhh, Marc, so we have the same discussion again.

You are correct in that we shouldn't wait until we have the final solution.
Digital has killed many good ideas by over-architecting before the product
is even coded (remember Event-Central ?)

However, when we do have an architecture in place, or we have the same group
developing a product set we should have some commonality. take MLM for VMS and Tyee
for UNIX. Both came from the same architecture - they now don't talk to each other, 
so now money is going to be spent developing a gateway so that they do talk - if
they had both followed the same architecture from day 1, we wouldn't be wasting
this money!

Even if products are from disperate groups, there is no reason why a commonality
cannot be discussed and agreed on after the fact, but so little of this is 
hapenning today, thus the success of OSCINT (Which, in its very existence, is
really an admission of failure).

Yes we used to have EMA but it didn't get taken up by OSF, they created DME - it
looked exactly like EMA - so there is agreement that a common database is essential.

In a company that is startved of money, because we no longer make a profit, let's
maximise our engineering expertise to develop better products with more 
functionality that integrate, instead of re-inventing the wheel. 

Martin

  ahemmmm, can I interupt here before this starts ratholing...

  As much as I agree with a lot of what has been said, I dont
  beleive this is the correct forum for getting something done,
  can I suggest that you move your discussions to the correct
  forum where you will get maybe a wider and better suited
  audience.

  May I be so bold as to suggest the POLYCENTER notes conference?

Cheers,
Phil

Phil,

why would we want to do that, we'll be ignored there!

Martin :-)

	Phil , 


	Let me add one more comment linked to your product.
	I have spent some time looking for what an integration of Polycenter products
	might be. I went thru PCM , Decnsr, Fullsail, PSW , PSC documentation and kits.
	i've retrieved the corresponding data models inherited from physical schema
	or flat files. One year ago i have been answered to this question that making
	several development groups working together was impossible.

	So what ? Instead of building a new database i've gathered all the data models
	trying to see which one holds the more data and might be expanded. PSC is the
	right one. From that point of view Integration can be seen as Feeding and Extracting
	information form Census thru Api's. The OSCint group and ours have partly
	been working on that (and some other groups too). For example : Backup events 
	are trapped by PCM , the corresponding action routine runs the API that stores
	 the information in the configuration notes of the Disk (no matter where the 
	Census database is located) The user clicks on the disk thru GUI and the last backup information are 
	displayed. The coming Oscint Kit will retrieve some config information from 
	Census to feed PSW...

	PSC can support integration thru data , PCM and OSCINT can make it work thru
	actions/procedures.

	Pierre