GLOBALS DEFINE p_username CHAR(8) END GLOBALS ... LET p_username = FGL_GETENV("LOGNAME") DISPLAY p_username
… then you should in a separate .4gl define these variables with PUBLIC scope, and then reference this .4gl via IMPORT FGL statement. This will give you something like …
#! global.4gl PUBLIC DEFINE username CHAR(8) #! file.4gl IMPORT FGL global ... LET global.username = FGL_GETENV("LOGNAME") DISPLAY global.username
This will allow you to make a more modular approach with several smaller .4gl files imported where necessary, rather than having one big monolithic globals file.
This approach also facilitates the use of PUBLIC CONSTANTS and TYPES that you can also reference via IMPORT FGL, something you could not historically do with GLOBALS.
You should end up with a “global” variable only requiring definition in one file, not being defined in multiple places with many definitions. Also if you have “global” variables that are not really “global”, but perhaps being applicable to a certain range of programs, then you can have an imported module that is only imported by that certain range of programs.
So if you do have GLOBALS, at your next big upgrade, evaluate the option of removing the use of GLOBALS from your code-base, and make your code easier to maintain.