Re: Globals in 4gl - feature or bug?

Before reply to Nils, I would like to clarify that my was a "pleasant" discovery, and that my usage of globals is so scarce that we're only discussing here accademically. Having said that, here we go: --- On 27 Mar 1996 05:16:08 EDT Nils.Myklebust@ccmail.telemax.no wrote: >: marcog@ctonline.it (marco greco) writes: >: Quoted from the 4gl reference manual, volume 2: >: >: 1. You may have at most one GLOBALS statement where global variables are defined. >: This statement may be in a separate file or in the file containing the main >: program block. >: >[snip] > >The manual only states that you can have only one globals in one source module. >Nowhere is it stated as far as I can remember, that these can't be different >in different source modules even if they are compiled into one program. Your >quote sertainly doesn't say this is illegal. I tend to disagree: the above, read litterally, as a minimum means that you cannot define globals where you only have functions. And having read Jonathan's articles "Do you cheat with globals" (BTW Jonathan, it was in April), besides his illuminating answer to my post, I begin to see why: such globals would not be globals, since to access them you should cheat and *redefine* them in other modules (c only! but then 4gl started as a c precompiler). And since someone's decided that you can only have one globals reference (probably to avoid problems with different database directives), if you use global variables from two different sets of logically tied modules, you'll end up having only one globals file anyway. >In our programs the source module with the main function doesn't even have any >globals. > >[snip] So do mine, as well as all the other modules that do not reference any global variables. I note however that in April 1994 someone replied to Jonathan stating exactly my erroneous belief. This brings us to two morals: 1) Before hurring to your mailer, go take a look at iiug! the excellent full context search is there just for this reason. I did after writing and I made a mistake. This is particularly true for those, like me, have been around for a year or less and therefore have no idea of what has heppened before their arrival. 2) As I said before, the manuals are not always clear. The following is an example that has always driven me mad (I've quoted it on this forum before, so excuse the repetition) Informix 4gl Reference Manual, volume two: 1. only one lock can apply to a table at any given time. That is if a user locks a table (in either share or exclusive mode), no other user can lock that table in either mode until the first user unlocks it Informix Guide to SQL, Reference: ...The Lock table statement fails if the table is already locked by another process. ... *SE* The INFORMIX-SE database engine does not permit more than one user to lock a table in share mode. (???? it was stated that only one lock can exist at a given moment in time!!!!) This is very different than saying: *SE*: only one lock can apply to a table at any given time. That is, if a user locks a table (in either share or exclusive mode), no other user can lock that table in either mode until the first user unlocks it *OL*: only one kind of lock can apply to a table at any given time. Many shared locks are allowed concurently, while only one exclusive lock can exist at any givem time. And note that lock behaviour has serious implications in application design... saluti. marco. ____________________________________________________________________________ rem radioterapia, which I immeritately manage, seldom agrees with what I say marco greco (Catania, Italy) Work: marcog@ctonline.it rem radioterapia 39 95 447828 fax 446558 (was mar.greco@agora.stm.it) Achea 39 95 503117