Re: GLOBALS statement everywhere

dennisp@informix.com wrote: > At the risk of Jonathan L correcting me (which he does only when I'm > WRONG), No (major) corrections needed -- but I am going to add a few comments. > You need the GLOBALS statement in any module that makes > reference to any of the variables defined in the GLOBALS function. Technically, the GLOBALS ... END GLOBALS statement isn't a function (it has no name of its own, for example), but it is a bit similar to a function. Regardless of what you call it, you should only include the globals file in a source file which uses at least one of the variables in the GLOBALS ... END GLOBALS statement. > Otherwise it's not needed. > > The DATABASE statement is used at compile time if you have any > DEFINE statements (in the GLOBALS function or otherwise) that use > LIKE syntax ("DEFINE r_table RECORD LIKE table.*"). Or "DEFINE variable LIKE Table.Column" > It is used at run time to open the database (in this context, > it can be within a function as well as at the top of a module). The non-procedural DATABASE statement always precedes any functions. The procedural DATABASE statement may appear almost anywhere any other executable statement can appear (but there are some places where you should not use it, such as in any code called while a 2-pass report is being run!). > So use the DATABASE statement in the module with the MAIN for > both reasons, and elsewhere for the first. > > So (here's where johnl might get me; I haven't done this in awhile) > if your globals module (a module containing only the GLOBALS > function and no others) has a DATABASE statement in it, Since the majority of such files use LIKE notation, this condition is usually met. > and your GLOBALS statement is at the top of the module, This condition is always met -- you cannot put a GLOBALS statement (of either GLOBALS "file" or GLOBALS ... END GLOBALS type) after any function (MAIN, FUNCTION, REPORT). > there's no need for another DATABASE statement. This is true. It does no harm to repeat the DATABASE statement (once in the file containing GLOBALS "globals.4gl" and once in globals.4gl itself), but it isn't necessary. > Note there's a difference between the GLOBALS function: (GLOBALS > DEFINE ... END GLOBALS) and the GLOBALS statement: (GLOBALS > "/full/path/name.4gl") Anybody who ever includes a full path name needs to be shot. It is invariably unportable. Admittedly, there isn't a decent way to locate the files (no analogue of the C compiler -I option), but using an absolute path name is the worst way of fixing that problem. Normally, either a hard link or a symlink is the best way of dealing with. But there is also a big difference between the two. The first defines the variables (in the C sense of allocates the memory for them). The second declares them (again, in the C sense of makes the compiler aware that they exist but are defined elsewhere). That's why you have to have some file, somewhere, which actually defines each of the variables. The most convenient way of doing that is to actually compile the file containing the GLOBALS ... END GLOBALS definition of the global variables -- but there are other ways of doing it for the perverse. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.59 -- see http://www.perl.com/CPAN #include <disclaimer.h> > In article <35c1946b.689599964@news.globalnet.co.uk>, > xxx@xxx.xxx wrote: > > I'm in the processing of revamping some code and have spotted what I > > think is superflous use of the GLOBALS statement. > > > > A typical example would be as follows: > > > > a.4gl would look like this: > > --------------------------------------- > > DATABASE dbname > > GLOBALS "/pathname/global.4gl" > > DEFINE variable1 CHAR(20) > > END DEFINE > > MAIN > > blah > > END MAIN > > FUNCTION func() > > END FUNCTION > > > > b.4gl would look like this: > > --------------------------------------- > > DATABASE dbname > > GLOBALS "/pathname/global.4gl" > > FUNCTION func2() > > END FUNCTION > > > > c.4gl would have the same structure as b.4gl > > > > As we are running RDS we compile the programs like this: > > > > fglpc a.4gl > > fglpc b.4gl > > fglpc c.4gl > > > > And finish off with: cat a.4go b.4go c.4go > newprog.4gi > > > > The question is: are the GLOBALS statements in b.4gl and c.4gl > > unnecessary? > > > > Also, is the DATABASE statement in b.4gl and c.4gl unnecessary too?