Re: Rapid Development system

In <34BBD91F.5210@bloomberg.com>, "Art S. Kagel" <kagel@bloomberg.com> writes: > > 72274.115@compuserve.com wrote: > > > > I'm looking for opinions on the Rapid Development system. Is the > > resulting object any faster, better, or worse, than the c4gl output? > > The resulting RDS executable is generally slower than compiled 4GL > (C4GL) except for database operations which do not suffer appreciably. > The penalty depends on how much of the program is devoted to calculation > and how much to database operations and screen operations. For heavy > duty screen functions the delays are not noticeable as long as major > calculations are not required in AFTER FIELD type clauses. The normal > penalty for batch programs is about 15% but can be as much as 25% for > heavy compute bound programs. This can be reduced significantly by > writing calculation modules in "C" and linking them into the pcode > runner for RDS. This is a good technique to reduce the overhead in > C4GL programs also which can be as much as 15% slower than the > equivalent "C" function if compute bound. So if you make a discipline > of writing compute modules in "C" and linking a custom runner for your > RDS applications these same functions can be placed into a library or > shared library for C4GL compiled programs and migrating from RDS to > C4GL still gains you noticeable improvement. > > The memory footprint for C4Gl is less than for RDS executables if more > than a few applications are running on the same machine and even less > still if more than a few users are running the same executable on one > machine, especially if you put common code in shared libraries. For a > single copy of a single executable RDS uses less memory. > > BTW, little known fact, C4GL compiled 4GL functions which are commonly > shared can also be linked into an RDS runner! > > Art S. Kagel > Linking compiled 4GL functions (and even some ESQL/C functions) into a custom runner can be harder than it sounds, as I am in the process of discovering. Difficulties arise when the compiled functions use 4GL global variables to communicate with their application programs, or when a compiled 4GL function uses the DISPLAY statement, the INPUT statement, or any of a variety of form- handling commands. We have a standard set of 4GL and ESQL/C subroutines used in application development, organized into several libraries of related functions. When compiled into a custom runner using cfglgo or cfgldb, these functions can no longer communicate with the 4gl application running as a .4go or .4gi. The appears to because the global definitions used by the .4go have nothing in common with the memory areas reserved for the same globals in the compiled functions. I can write a RDS function to copy values to and from the real global variables in the compiled functions, but this requires establishing different calling procedures in the application programs if the program is running under RDS vs. the same program running under c4gl. The form-handling problems only occur when trying to debug a .4go or .4gi that is calling a compiled 4gl function that attempts to interact with the screen. The debugger's source and command windows get overwritten by the output of the program and input to the debugger's command window is lost, apparently intercepted by the application itself. This occurs after linking the libnforms.a library from $INFORMIXDIR/lib/tools to the custom runner via cfgldb. Attempting to use the shared version of the 4gl runtime code in lib4gsh604.a overwrites the debugger's command interpreter when loaded, causing -16311 errors with any debugger commands issued. The libnforms.a library is required by cfgldb and cfglgo to resolve the internal 4gl functions used by the compiled 4gl subroutines. We are attempting to provide an environment where a c4gl-based application can be recompiled under RDS to facilitate debugging. I'm now breaking out the 4gl portions of our standard libraries into a new source code library just for debugging purposes, but I don't have any good solution for dealing with the ESQL/C code that manipulates 4gl global variables directly. I'm appealing, therefore, to the combined wisdom of this group (hi, John!) for any insight into the problems listed above. Our environment includes AIX version 4.2 for the RS/6000 series computers, Online DSA 7.22.UC2 engine and fglgo/fgldb version 6.04.UC3 with pcode version 602. The compiled functions (4gl and esql/c) were compiled via c4gl version 6.04.UC2. Thanks for any assistance. -- Dave Adams //dna// adams@well.sf.ca.us ---------------------------------------------------------------------------- "It's not the things we don't know that get us into trouble; it's the things we do know that ain't so." -- Will Rogers DISCLAIMER: Software is not returnable.