Re: Dynamic 4GL

On Tue, 15 Dec 1998, Dave McNight wrote: > When ever we upgrade Online Dynamic Server, we are recommended or > required to upgrade the tools (4GL, ISQL, RDS, ID) for compatability > reasons Hmmm! That depends on what you're trying to do, and what versions you're using, and where you have the various items installed. If you solely upgrade the ODS (which must mean you're using a 6.00 or 7.1x or 7.2x engine), then you would not absolutely have to change the tools. If the ODS software is installed in one directory, and the tools are installed in another, and the tools know which sqlhosts file is necessary to communicate with the servers, then you can upgrade ODS without touching the tools. In fact, even if the ODS software is in the same directory, you could probably do the upgrade without changing anything. Your ESQL/C applications would probably benefit from the version of ESQL/C matching the ODS, and should be recompiled if you do upgrade the ESQL/C. > unless we use the relay module functionality (not recommended > normally). What versions are you using. The relay module is only relevant when you are using version 5.x or earlier applications against a 6.00 or later database server. > All of our 4GL code is recompiled. This recompile and > testing effort takes a lot of time and effort to insure that > applications still work as the user expects. It seems like we have to go > through this process yearly. With a limited staff, this results in a lot > of unproductive time as far management is concerned. So, one possibility is that you need to investigate automated methods of doing the testing. For example, you could use expect, or dejagnu (which exploits expect, which in turn exploits Tcl). Or you could investigate the various commercial equivalents... > Is Dynamic 4GL any different in this regard? A little, but not hugely. D4GL uses ESQL/. It should be reinstalled whenever you upgrade ESQL/C. Actually, that's an overstatement -- you'd need to ensure that the p-code runners are rebuilt with the new ESQL/C, and you might need to adjust the environment files to point to the new versions. If you use p-code, then you don't have to recompile the applications. If you use c-code, then you do need to relink the applications when you upgrade your ESQL/C. > It would be nice when the ODS needs upgraded that we are not forced to > go through this recompile/testing effort. If you retain your existing ESQL/C and D4GL installation, you don't have to recompile with an upgrade of ODS, any more than you would with I4GL et al. But, it requires you to keep separate things separate. If you upgrade your ESQL/C as well as ODS and remove the old version, then you have recompilation to do. The rule of thumb is to recompile -- the recompilation, even of big systems, should be automatable if not already automated. Testing is more problematic, but if you only upgrade the engine, then the only changes should be in the speed with which the results are returned from the database. > Also is it easy to port 4GL apps to D4GL when we have many C functions > included in fglgo runners currently? Porting C functions is harder than not having any C functions to port, but is not impossibly hard to deal with...unless you are using internal details of I4GL in your C functions (or undocumented I4GL functions), in which case, they probably will not work at all. The glue code (in fgiusr.c under I4GL, in fglext.c or fglExt.c for D4GL) is different. But the base functions do not have to be changed. Also, you can run into problems with variable argument lists, and with variable return lists. This means that if a function returns 3 values, your calling code had better expect 3 values; if it only uses 2, you will run into problems. > [...] Yours, Jonathan Leffler (jleffler@informix.com) #include <witticism.h> Guardian of DBD::Informix v0.60 -- http://www.perl.com/CPAN Informix IDN for D4GL & Linux -- http://www.informix.com/idn