Re: Suggestions for improving the 7.x OnLine Engine installation and configuration

First: Be a *little* carefull because the issues here aren't necessarily the biggest of issues. Still it is interesting. Tim Schaefer <tschaefe@mindspring.com> wrote: :Nils Myklebust wrote: :> David Williams <djw@smooth1.demon.co.uk> wrote: :> :> :>What would you like to see improved in the 7.x ONCONFIG and operation? :> : :> : Automatic creation of sqlhosts, automatic addition to /etc/services. :> : Program to verify the about (gets $INFORMIXSERVER, checks entry exists :> : in $INFORMIXDIR/sqlhosts, does gethostbyname() to check host exists, :> : does getservbyname fo check services exists). :> :> When even the king of configuration and management can want this I may :> perhaps also chime in. Although the above haven't been too hard for us :> on single machines setup only, we still want it even for that purpose. :> We are also soon going to start setting up multiple networked servers :> and a tool would make it so much easier. :> : :Well, I think the biggest impression I have from the install is the :"right of passage" one goes through, in order to install the software. :Maybe it's intentionally a bad install to help keep the consulting :market going? I mean this whole idea of having to set up the physical :and logical logs is abit absurd. >> I << have to move the logical :logs out of the root dbspace? Why put them there in the first place? :And the physical logs. I mean why can't this be done at the outset? :HELLO! And what of this TEN business? ( tools - engine - network ) This TEN bussiness stinks. With a new version of allmost anything we have to reinstall everything. What it should have been of course is a simple copy of the current informix directory tree to a new one (using tar or whatever), and install any product on top of that. The risk of doing anything wrong would deminish, and we wouldn't have to install again the old software that we didn't upgrade this time. There may be a problem of course in that Informix must make sure that needed existing files aren't overwritten, but that's realy minor. :This stuff was all cute early on in the romantic phase of Informix :software, but does it need to persist like some sort of twisted :tradition? : :I am developing my article on these premises: : :1. If the install is acceptable, then why do so many people have so : many problems with it? I would leave out the last "so many" :-) : Why can't the distribution change to make : it easier to install. What difference should the order of the : install make? Tools Engine Network. How about we revise the : damn directory structure to make things so this doesn't matter? : Please don't give me romantic notions of how we did it in the old : days. The old days show me some really silly sh**. Well... :2. If you have good software, this should reduce the need for a help : desk. To rave about your customer service is one thing, but ask : yourself if the need for more help desk people isn't really an : indication that the software is not being properly distributed. : ( Yes, Oracle has the same problems, and so do other companies. ) Yes, the problems anyone else have are inconsequential. Also it's allways important to remember: One shouldn't be best, that may not be good enough. : And what about the techlink site? When's the last time somebody : did some serious design on <that> mess? I have talked to them several times. They do relize the problems and are working on it. I don't know when they will come up with something better. :3. If the configuration is acceptable, then why do so many people : have problems with it? Is <this> an accurate question? That's what I said above :-) :4. If the configuration and installation are <unacceptable> then why : does Informix continue to offer products that are not substantially : improved over the last release? Why hasn't the directory structure : changed to show improvement? Did we put any thought into the idea : that log-files shouldn't go into the software distribution directory? : C'mon folks, this is not only sloppy, it's just L A Z Y. Well... strenght of words may make you loose an argument. :5. Where does the line begin between installation technician and : dba? Don't get so smug that you can configure the living daylights : out of the 7.x product, and are now an elitist because you chased : down more "secrets" of the product than the next guy. It doesn't : make you a better DBA to be a configuration expert--you're a better : configuration expert but totally distracted from the core responsibility : of dba. Here I would easily be tempted into using *far* stronger words. (I just did.) It's the same problem so many Unix administrators have all the time ... food for some thought. Even considdering the dba work with core responsibilities one should pause at this thought. : A data base administrator is concerned with the data not the : install. By this I mean log management should be a function of the : vendor placing logs in separate dbspaces AT INSTALLATION not running : somebody through the ridiculous exersize of moving logs out of one : space into another. If you went through this you know how silly : this whole exersize is. It's almost a sick joke Informix plays : on their customers. Trying to loose an argument again... :-) : And the documentation isn't very clear what the : hell you're doing either. Please don't document any more Informix. : You've given way too much documentation to this. : :6. The ONCONFIG, while a neat idea, is really a bit rigid in what it : <CANNOT> do. There's no other way to configure the engine, this is : it. But I would think you should be able to bring the engine up, : and then phase in the shared memory on a controlled basis. The : current method usurps the system without really allowing the DBA : or anybody control over the engine. All you can do is clamp down : on the memory and hope to God it doesn't bomb. There should be : a micro-kernel start-up, and then the ability to ramp up memory. : :But hey, I could be wrong! : ::-) : :( Where's Sam Kineson when I need him oh! oh! ) : : :> However why not include checking of /etc/hosts and suggestions for :> entries in that file (should probably not be entered automatically). : :This is a good idea. However, it wouldn't be too much to ask for a :simple little example of the various types of sqlhost entries. Yes, :I've read the f***ing manuals. :-) ( correction, I continue READING :the manuals ) : : :> The tool should also check DNS, NIS or whatever the alternate systems :> are named to see that communications work and most importantly suggest :> exactly what to do. :> : :You're pushing it now. Why? If there are too many combinations than at least they should start combining. :> It's even easy to check what machines are actually out there and let :> you select servers from a list. :> The tools should of course connect to all machines where you intend to :> run Info