Operating Systems 101

… and a good way to think of this is that this is the equivalent of typing at the command line …

export ENVIRONMENT
cd PATH
DVM MODULE PARAMETERS

… if you do a ps e.g. (ps -ef | grep ‘fglrun’) you should find the running process.  You should also be able to find the proxy and dispatcher processes as per the Genero Application Server architecture.  If you look in these proxy and dispatcher logs, you will find that the value of the environment can be output in the logs when the process starts, see this tip here about making sure CATEGORIES_FILTER includes CONFIGURATION.

There are two common misconceptions I see with programs launched via GAS.

• Who is the process owner? Those coming from command line are used to the process owner being who they are logged into the server as.  When using GDC with Direct Connection short-cuts this is also logging into the server as the passed in user. (in both cases typically the name of the person between the keyboard and chair) When using Genero Application Server either with GDC or via GBC, it is not logging into the server, the Web Server launches the dispatcher which in turn launches the proxy which in turn launches the fglrun process, all as the same system user as opposed to the name of the user between keyboard and chair.  This in turn has a flow on effect in terms of permissions, database connections (value of USER in SQL operations), and values of environment variables USER, HOME and other variables typically set in login shells etc.  There is a note to this effect that you need to consider when moving from GDC – Direct Connection to GDC via HTTP and GBC.  Typically you need to introduce the concept of an application user that a lot of the logic that was tied to the process owner should be tied too.  If someone has trouble with this point, I will either point them at the database processes and ask what system user are they owned by? or I might say if you had terminal access to a Facebook server, could you logon to that server with your Facebook login and password?
• Launching programs via GAS or GST also requires a different way to think about setting of environment variables.  At your terminal, and with GDC Direct Connection, environment variables are typically set via login shells.  With Genero Application Server, environment variables are set by the ENVIRONMENT settings in the .xcf.  However you also need to consider the inheritance of environment variables from their parent.  This actually comes handy into passing environment variables from the Web Server as documented here with the FGL_WEBSERVER family of environment variables and how these values are then available in your 4gl program.  But when testing with httpdispatch, you also need to consider how httpdispatch is launched and what was in its environment when it was launched.  A common trap I have seen is environment variables such as LD_LIBRARY_PATH have been set via login shells for the developer who runs httpdispatch, these are then inherited in the fglrun program if in the .xcf they have been set with entries that are equivalent of LD_LIBRARY_PATH=some-path:$LD_LIBRARY_PATH.  That is the value is inherited from, or includes the value from  the parent process of httpdispatch.  When the .xcf is run from a Web Server, this value is not in the parent process and hence LD_LIBRARY_PATH is not set as expected or as it was when testing using httpdispatch.  The rule of thumb here is to set the complete environment you need in the .xcf.

You can also find the environment dumped into the log files as mentioned above and in Genero Studio you can right-click on the application node to get a dump of the environment.

A tip I also give is to add logic similar to  …

IF some-condition THEN
   RUN "env | sort > /tmp/yourname.env"
END IF

… as close as possible after MAIN to look at the actual environment the process has when it runs.  A number of support calls have been solved doing that and the developer realising that when their program executed it did not have the environment variable value they were expecting.

I mentioned that the process operating is set by the EXECUTION node in the .xcf when using GAS.  With Genero Studio a similar process occurs so that when you build, execute, package, deploy etc, a command is built-up and executed with a particular environment in a particular directory.  The places where it is set are more varied.   The Genero Configuration Management dialog has details of the runtime, environment sets and what user interface client to use.  There is a little more to it than just what appears on that dialog but if you right-click on an Application node and investigate the entries Display Environment, Edit Build Rules, Edit Package Rules, Advanced Properties you can either see where the command was derived or check its value. The Build Rules being a good one to see the steps being executed when a compile is taking place.  The key point to takeaway is that Studio like GAS is building up a command and executing it.

This concept of environment variable inheritance also applies to the RUN command.  The environment will be the same as per the fglrun command, if you need a different environment variable value then you need to set it as part of the RUN command.  It is not a bug in Genero if the value of LD_LIBRARY_PATH needed for fglrun and its communication with a database breaks a command launched in the RUN.  As part of the RUN command you need to set your environment to what is required.

One question I get after asking developers to try and have an understanding about what processes are running, is what is gsproxy?  You won’t find a mention of it in the Genero Studio documentation.  Where you will see it is in the .xcf files created by Genero Studio when you run a program using the Genero Application Server.  If you find them in FGLASDIR/appdata/app you will see two .xcf files are created with your appname_yourname_studio.xcf and appname_yourname.xcf.  If you study these two .xcf files you will see different entries in the EXECUTION node …