Re: Ideas to organize informix's programs

On Sun, 11 Jan 1998, David Williams wrote: > =?iso-8859-1?q?Manel_Falc=F3?= <manel@semic.es> writes > >How do you organize yours informix's programs ? > > Varies, in my first job we had one large executable, > we have >200 small executables. I prefer one large one, this > tends to make people used library functions more often. Also the > Informix libraries only get linked in once saved disk space and > memory. Interesting. You're going to get two more or less opposite arguments. I've seen both techniques (one large program and many small programs). When I get given the option, I always use many small programs. I use libraries for the project, and each program tends to use the same library functions. Some parts, such as the start up sequence, are completely systematic and can do an awful lot of work for the application. I've seen more performance problems on systems with a few very large problems than on systems with more smaller programs. > >Do you have lots of little executables (I use RDS) or some huge ones ? I use lots of little ones. I also use the p-code linker and librarian I posted to c.d.i just before Christmas 97. One reason for lots of smaller programs is that the load time for the reports is a nuisance, especially since most people don't run most of them most of the time. With a c-code system it is probably less critical, but for a p-code system, I would definitely go with more smaller programs rather than fewer larger ones. > >Do you usually use the command "run" to call the programs ? if so, is > >it not a charge to the system (many proces, memory .. .) > > Yes and it does take more memory and disk space. I'd go with the one > large executable. I think this is in the context of a menu program. I tend to have the menu driven from the database. Ideally, the menu program sucks out of the database all the information for the user, and then disconnects entirely. It then runs the programs for each option as requested. Because it disconnects, the overhead is not serious. > >Do you have any useful tool to structure your options' programs ? > > > >I want to make an utility to structure my programs. The options would > >be organized by tables of menus. Users would be able to organize their > >own menus themselves. So I need to an informix function on execution > >time !!. > > We have menus where the menu hold the name of a program to run. See above. The systems I implement take security moderately seriously and limit the programs a user can run. That means that it doesn't usually make all that much sense to let them design their own menus. However, the actual programs also check whether the user is permitted to run the program, so if some curious-minded user designed a menu which ran programs that they are not authorized to run, then at worst they would have to wait until the program gets going to find out that they are not authorised to use it. The menu system can also do some checking. suppressing programs the user is not allowed to use, and refusing to run unregistered programs. > >Is there a way to call informix's functions by a pointer ? in C ? > > Look into shared libraryes and the dlopen(),dlsym() and dlclose() > functions. > > Basically each menu option should bave one shared library assocaited > with it. Each shared library should have one 'main' function called > FN_main() which takes no parameters and returns nothing. > > Then use dlopen() to open the shared library, dlsym(...,"FN_main") to > get a pointer to the function and dlclose() to close the shared > library when you return to the menu. In RDS, you should be looking at the fgl_call() function/macro. See fgiapi.h and the manual. You can also look at the dlopen() etc routines, but those functions have to be implemented in C. By contrast, the fgl_call() can be used to call p-code functions -- something dlopen() et al cannot help with. Yours, Jonathan Leffler (johnl@informix.com) #include <witticism.h>