Re: Ideas to organize informix's programs

I have mixed feelings about this one. My personal preference goes for one huge app, rather than many small ones, but I agree that for RDS the performance hit is a major one, at least when starting the app. My experience with RDS dates back to 1990 on a NCR Tower650, so take it with a grain of salt: in those days a 450k RDS module (corresponding roughly, I think, to a 1.6M compiled app on SCO) would load in more or less 30 secs vs roughly one for a compiled app (1.3M, it was) with exactly the same functionality... I think the correct approach depends really on what your users requirements are. For instance, mine requested (a long time ago..) to be able to fire *any* of the tasks which they are allowed to carry out from *any* of the data browsers they are allowed to use, and quickly go back to data browsing as soon as they complete the task, with the data browser reopening the cursor and redisplaying the data if the task involved manipulating the data being displayed, or just restoring the screen otherwise. With more than 300 tasks involved, and 70+ data browsers (and that's not counting the reports) I don't see any possible route other than the huge app. However, I tried to mediate between the two approaches by embedding in my huge apps data driven menu routines, a simple report interpreter (with a preview capability), and resorting to stored procedures whenever practical. Security issues are handled via views that let the users access only those menu entries they are allowed to use, and of course, by granting appropriate rights on all the tables in the database :-). My Lit.36, Marco. _______________________________________________________________________________ Marco Greco, Catania, Italy marcog@linux.ctonline.it rem radioterapia +39 95 447828 fax 446558 Informix faq http://www.iiug.org/techinfo/faq/informix.htm 4glworks http://www.ctonline.it/~marcog Informix on Linux http://www.ctonline.it/~marcog/ifmxlinux.htm Jonathan Leffler wrote: } } 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>