RE: Accessing program variables across 4gl files in the same executable

>---------- From: Manish Hemrajani[SMTP:channels@worldnet.att.net] >Sent: Saturday, March 14, 1998 8:45 PM >>JL: No. They're file static variables in terms of C code. >>>don't confuse these with globals) >>JL: I'm not confused, but it appears you are; what you want are global variables. >No I'm not confused I want to avoid using globals cause' of the overheads. >Do u understand? Which overheads are you referring to? I've seen Marco Greco's response and it covers indirectly the points I'm about to make - see below. >>>across 2 or more 4gl programs within the same executable (.4ge file). >>JL: I4GL GLOBALS are precisely variables which can be accessed across 2 or >>more I4GL source files within the same executable, which is apparently what >>you want. >>>Say for example I have one 4gl program containing the "main" and "end >>>main" which in turn calls functions which are declared in another 4gl >>>program. Can these 2 programs access a common set of variables (similiar >>>to "extern" variables in "C") >>JL: Yes, but only if they are GLOBALS. Why did you think that GLOBALS are >>not what you want? >I have an application which has 89 executable files. So, that's 89 source files, or 89 separate executables with even more source files? It doesn't matter much; it is a moderately big system either way. Mind you, I'd not want to run a single executable built from 89 source files - that would be too large. > If I start declaring variables which are gonna be used in just a couple of programs in the >globals file how big do u think my globals file It depends on how you write your globals files (note the plural!) I take it that each program (meaning separate executable) does have it's own set of globals? If not, why not? And there is no compulsion that all the source files in a single executable have to use the same globals files, any more than there is a compulsion that every source file has a non-procedural DATABASE statement at the top. Most usually, code is written like that, but it is not necessary to write it like that, and I don't write code like that all the time. >(which as u might already know is declared in every program) Only in projects which I'm not in charge of. :-( :-) >All I wanted to know was whether one can declare variables accessible to 2 >programs like C. If the answer is NO I'm fine with that The answer is Yes. Subject, as Marco said, to having a moderately recent version of I4GL (4.14/6.02 or more recent). And, in fact, the answer is yes for any version of I4GL, but subject to rather more in the way of provisos. Let's take it nice and easy... With 4.14/6.02 and later versions of I4GL, you can write a file source1.4gl: DATABASE somename GLOBALS "file1.4gl" GLOBALS "file2.4gl" GLOBALS DEFINE g1 DATETIME YEAR TO SECOND, ... END GLOBALS DEFINE m1 DATETIME YEAR TO SECOND, ... GLOBALS "file3.4gl" ...possibly MAIN, followed by functions and reports... This will include precisely those globals files you specify, thereby declaring the variables listed in those files (and I'm using C terminology for declare, and as distinct from defining those variables). It will also define the global variable g1. It will also define the module variable m1. Normally, you will compile the files file1.4gl, file2.4gl and file3.4gl as free-standing modules too; that ensures that the variables are defined, and you link those files in with your executable to satisfy the references made from the source files which use them. Now, you could also write a new file, file4.4gl, which contained: GLOBALS DEFINE g1 DATETIME YEAR TO SECOND, ... END GLOBALS And you could then write another program file, source2.4gl, which uses it: DATABASE somename GLOBALS "file4.4gl" ... This source code can now access the variable g1. However, there would be no need to compile and link file4.4gl into the program because source1.4gl defines the variable. If you are using 6.0x I4GL, then trying to link file4.o into the program will lead to problems because the variable is doubly defined; in 4.1x I4GL or if the type was something like INTEGER, most systems would not object to the double definition because there was no explicit initializer in the generated C code (there is an explicit initializer generated by the 6.0x ESQL/C compiler, which is why it fails under 6.0x I4GL). Indeed, on some systems, you could write GLOBALS DEFINE g1 INTEGER END GLOBALS in both source1.4gl and source2.4gl and have the resulting program link. But this is extremely dubious coding practice and is not guaranteed to work on all systems (eg AIX) - ANSI C does not require it to work! In practice, of course, you would never use this technique because there are multiple definitions of the variables; it is much simpler to have source1.4gl and source2.4gl both use file4.4gl and to compile and link with file4.o and source1.o and source2.o; nevertheless, you could do it if you really wanted to. Also, there is not, and never has been, any reason why two source files cannot share a single globals file which only they know about and use. As long as all three object files (two source files, one globals file) are all linked into the executable, the other parts of the executable can share and use one or more other globals files. This has always worked in all versions of I4GL. What was not possible prior to 4.14/6.02 was to have the two source files share both their own private globals file and also one or more public ones. This is now perfectly feasible, and good programming practice. Indeed, that is the main reason why I put the multiple globals files feature into I4GL! :-) On this subject, I do know what I am talking about. I haven't mentioned various gruesome hidden features that I know of because they're bugs that should not, ever, be exploited. Yours overly-defensively, Jonathan Leffler (jleffler@visa.com) #include <bother.ms-exchange.h>