Executing programs
There are different ways to execute compiled programs, depending on the configuration and the development or production context.
Prerequisites before executing a program
Make sure that all required environment variables are properly defined, such as: FGLPROFILE FGLGUI, FGLSERVER, FGLLDPATH, LC_ALL (or LANG).
To display program forms in graphical mode, the GUI front-end must run on the computer defined by FGLSERVER, and all network security components (such as firewalls) must allow TCP connections on the port defined by this environment variable.
Verify the database client environment settings, and check that the database server is running and can be accessed, for example by using a database vendor specific tool to execute SQL commands.
Starting a program from the command line on the server
A program can be executed with the fglrun tool from the server command line:
fglrun myprogram
This method is typically used in development context. After compiling the programs and forms, for example with the make utility, execute the programs with fglrun.
The program name passed as parameter must be a .42m module implementing a
MAIN
block, or a .42r program file. The file extension
(.42m or .42r) can be omitted: If no file extension is
specified, fglrun will try to load
progname.42r, then
progname.42m.
The progname argument can be a simple base name of the program file, or an absolute or relative filename (including the path) to the program file. The FGLLDPATH environment variable is not used to find the program file: This variable is used to find modules used by the program.
For more details about the fglrun options and how the program file is found, see fglrun command reference.
Executing sub-programs from a parent program with RUN
Sub-programs can be executed from a parent program with the RUN
instruction.
There can be limitations, depending on the platform where the parent program executes.
The RUN
instruction provides IN LINE/FORM MODE
and
WITHOUT WAITING
options, to be used depending on the purpose of the child program
or command, and if the parent program runs in TUI or GUI mode.
For more details, see the reference page of the RUN
instruction.
Starting a program from the front-end
It is also possible to start programs on the application server from the platform where the front-end resides.
- For a desktop front-end (GDC) application, define application shortcuts and use rlogin/ssh network protocols to start programs on the server or by using HTTP through a web server (GAS).
- For a web-browser application (GBC), configure the application server (GAS) to run applications from a URL.
- For a mobile device application (GMI/GMA), in a configuration where the programs
run on a GAS application server, use the "
runOnServer
" front call, to start a program from the GAS.
Starting programs on a mobile device
- For a GMA (Androidâ„¢) application, program files and GMA must be bundled together in an .apk Android package to be deployed. For more details, see Deploying mobile apps on Android devices.
- For a GMI (iOS) application, program files and GMI must be bundled together in an .ipa package to be deployed. For more details, see Deploying mobile apps on iOS devices.
- To start programs on an application server from a small embedded mobile
application (starter), use the
runOnServer
front call. For more details, see Running mobile apps on an application server.
Mobile app foreground and background modes
On mobile devices, apps can switch between the foreground and background mode.
The app state can be detected and managed in your Genero program code.
For more details, Background/foreground modes.
Common app directories on mobile platforms
base.Application.getProgramDir
returns the directory path where the main .42m is located. Consider this location read-only and safe (no other app can access it). See also the FGLAPPDIR environment variable.os.Path.pwd
returns the path to the current working directory. When a mobile application is started, the GMA and the GMI set the working directory to the default application directory. Consider this location read-write and safe (no other app can access it).- The front call
standard.feInfo/dataDirectory
returns the front-end side temporary directory. Storage on this directory may be erased by the OS. On an embedded mobile application, as the runtime and the front-end run on the same system, the program can use this front call to retrieve a temporary directory and use the path to store temporary files. Consider this location read-write and unsafe. Applications executed remotely through arunOnServer
front call, can use the sandboxRunOnServer directory under the directory returned by thefeInfo/dataDirectory
front call, to exchange files with the embedded application.