Re: Q: shared libraries

I recognise and agree with your reasons for using shared libraries. I didn't mention these issues because they aren't very important to us when it relates to 4GL programs only wich are from the "last decade". The one all overriding issue for us is management and any increase in this has to be offset by very significant other advantages to the end user or ourselves. The only reason for mentioning this issue at all where that I have seen several posts from people having problems with shared libraries, and would mention that they might think through the *possible* dissadvantage as well as the obvious advantages. As shared libraries still isn't available for 4GL programs compiled on SCO Unix the issue haven't materialised yet for us. Remember "last decade" :-) guest wrote: :In <580mpu$tcj@nntp.idgonline.no> <Nils.Myklebust@idg.no> (Nils Myklebust) :wrote: :: The only tiny problem I have with shared libraries is the small added :: management of making sure the shared libraries are available at :: runtime. I have no experience on this, and it may be insignificant. :: However so is the space we would save using shared libraries. Our :: executables take up about 80 MB althogether, but that's insignificant :: in itself with todays cheap disks, and particularly when you compare :: to the typical database size we have. :: : I read this ten days after its posting. However, it seems you were : speaking from last decade. If you didn't point out, I would almost : forget shared libraries might have been partly used for saving disk : space in stone age of this industry. : : Nowadays, have nothing to do with your reason of using shared libraries, : most unix and database engine/server vendors and users supply and use : shared library mainly for following reasons(far away from a complete : list and likely to be wrong and bad as you may point out): : : 1. reducing duplicated job on loading identical program text/data/.. : segments and thus speeding up the program startup. Please, think : about if csh, ksh, bsh are built without using shared library. Our 4GL programs typically starts in less than a second. : 2. reduce process size(not only program size). This will reduce the job : (and speed up) of memory paging(or swapping on old system) as well as : reduce the page consumption. Think about if informix server was built : without using shared libraries and 100 process instances were spawned : from it(typical db server text/data/.. segment size without using : shared library will be 2 to 10 Mb). Again 4GL programs only, and yes we could save memory. If this becomes an issue we might use shared libraries when they become available. : 3. upgrading/patching (PIC)libraries without affecting applications(i.e. : without relink the applications). This haven't been a significant issue with our 4GL programs yet. : 4. extending application by users(such as loadable extending C-code SQL : functions in Informix Univerisal Server and Postgres95, etc.). In our 4GL programs we haven't made this possible, and don't forsee doing it. : Of cause, with next century's cheap high speed cpu and ram, people will : possibly not bother to use shared library for above reasons. : : -g Nils.Myklebust@idg.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company The Informix FAQ is at http://www.iiug.org