GRE environment variables

GREDIR

The GREDIR environment variable specifies the installation directory of the Genero Report Engine (GRE).

GREOUTPUTDIR

The GREOUTPUTDIR environment variable specifies the directory where all writing operations that would otherwise be performed in the current working directory of the Genero Report Engine (GRE) will be performed.

The value can be an absolute or a relative file path. If the value is a relative file path, then it is internally prepended with the current working directory of GRE. When set, all writing operations that would otherwise be performed in the current working directory of GRE will be performed in the specified directory.

Examples include:

relative path specification in the functions fgl_report_setOutputFileName(), fgl_report_configureImageDevice() (the filePath parameter), fgl_report_setBrowserDocumentDirectory(), and fgl_report_setBrowserFontDirectory()
The location of the GRE debug files (jdebug0.xml, jdebug1.xml, and so on.)

GRE_MAX_CONCURRENT_JOBS

The GRE_MAX_CONCURRENT_JOBS environment variable limits the number of worker threads in distributed mode.

By default, the Genero Report Engine runs 25 concurrent threads. As such, by default it can process no more than 25 concurrent jobs. Jobs that a started at a point in time when the maximum value has been reached are queued until another job completes. The limit on concurrent threads is to prevent memory exhaustion in times of critical load.

GRE_MAX_CONCURRENT_JOBS allows the modification of the number of concurrent threads. This variable takes an integer.

GREDEBUG

The GREDEBUG environment variable defines the debug level for the Genero Report Engine.

Valid values include:

0: nothing
1: fatal only
2: fatal and error
3: fatal, error, and warning
4: fatal, error, warning, and info
5: fatal, error, warning, info, and debug
6: fatal, error, warning, info, debug, and trace
6+: all debug information

With GREDEBUG enabled, additional details are written to the Output panel. This can be very useful for debugging a report design document; see Debugging your Report Design Document for more information.

In addition, debugging files are created. These debug files are the intermediary files that are created as the report is processed through various filters on its path from the DVM to the final report output. The number and names of these debug files will vary, depending on the amount of processing that is required. In general, you can look for files with names like fdebug0.xml (the initial intermediate file output by the DVM filter) or jdebug0.xml (an intermediate file created and used by a Java filter). When multiple intermediate files are created, they are numbered sequentially. Additional files will be created if needed, however the names of those files are not guaranteed. At a minimum, the names will all include the terms debug and will be .xml files.

Note: The debug files can also be explicitly created by an application using provided APIs, as documented in the topic Create non-process-level XML files. Refer to this topic for a more detailed explanation of the different types of debug files.

Tip: These files are created and can be provided to support to assist with a support case, they can be used by advanced users to identify code to include in objects such as the RichTextBox, or they can be used to simply understand what is happening between the time the data is output from the DVM to the creation of the report. There is no expectation, however, that you are expected to do much with these debug files.

These files are written to the directory specified by the GREOUTPUTDIR environment variable. If GREOUTPUTDIR is not set, they are written to the current working directory of the Genero Report Engine (GRE). See GREOUTPUTDIR for more information.

GRE_DEFAULT_IMAGE_URL

The GRE_DEFAULT_IMAGE_URL environment variable defines the URL of the fallback image for an Image Box in a report design document.

The fallback image is the image to display if the requested image for an Image Box is not found.

The URL can be an absolute or relative URL. If it is a relative URL, the URL is resolved relative to the location of the form design (4rp) document.

This environment variable is specific to Genero Report Writer.

GRESERVER

In distributed mode, the GRESERVER environment variable specifies the host name and port of the GRE that the runtime system connects to in order to display reports.

You can also configure the distributed environment using the fgl_report_configureDistributedProcessing() function. When GRESERVER is set, calling fgl_report_configureDistributedProcessing() takes higher precendence. If neither GRESERVER is set nor fgl_report_configureDistributedProcessing() is called, the GRE runs in non-distributed mode.

The values for GRESERVER must be specified with the following syntax:

{hostname|portnumber}

hostname is the name of a machine on the network.
portnumber is the value of the port.

Important: When you configure a connection to the local machine, use the string "localhost" or "127.0.0.1" for the host.

DBMONEY and DBFORMAT

The DBMONEY and DBFORMAT environment variables define the separators for input and display of numeric values.

DBMONEY can only define the currency symbol and decimal separator; an implicit thousands separator is selected. If you want to define the thousands separator, use the DBFORMAT environment variable instead.

Important:

When defined, the DBFORMAT environment variable takes precedence over DBMONEY.
DBFORMAT and DBMONEY are also used by the IBM® Informix® database client and server to make date to string conversions.
When using a graphical front-end, the decimal separator of the numeric keypad produces the character defined by the DBFORMAT or DBMONEY environment variable.

If neither DBMONEY, nor DBFORMAT are defined, the default numeric formatting depends on the type of platform where the runtime system executes:

On desktop/server platforms, the default numeric format defines the ( , ) comma as thousands separator, the ( . ) dot as decimal separator, and the ( $ ) dollar sign as front currency symbol for MONEY values. This corresponds to DBMONEY="$.", or DBFORMAT="$:,:.:".
On mobile platforms, the numeric format defaults to the regional settings defined on the device. Normally, there is no need to modify these defaults.

DBMONEY syntax

The value of a DBMONEY variable uses the following syntax:

front{.|,}back

front is a character string representing a leading currency symbol that precedes the value.
back is a character string representing a trailing currency symbol that follows the value.

The currency symbol in DBMONEY can be up to seven characters long and can contain any character except a comma or a period. It can be non-ASCII characters if the current locale supports a code set that defines the non-ASCII characters you use.

The position of the currency symbol (relative to the decimal separator) indicates whether the currency symbol appears before or after the MONEY value. When the currency symbol is positioned in DBMONEY before the decimal separator, it is displayed before the value ($1234.56). When it is positioned after the decimal separator, it is displayed after the value (1234.56F).

The runtime system recognizes the period ( . ) and the comma ( , ) as decimal separators. All other characters are considered to be part of the currency symbol. For example, ", FR" defines a MONEY format with the comma as decimal separator and the string " FR" (including the space) as the currency symbol.

Because only its position within a DBMONEY setting indicates whether a symbol is the front or back currency symbol, the decimal separator is required. If you use DBMONEY to specify a back symbol, for example, you must supply a decimal separator (a comma or period). Similarly, if you use DBMONEY to change the decimal separator from a period to a comma, you must also supply a currency symbol.

To avoid ambiguity in displayed numbers and currency values, do not use the thousands separator of DBFORMAT as the decimal separator of DBMONEY. For example, specifying comma as the DBFORMAT thousands separator dictates using the period as the DBMONEY decimal separator.

When using a graphical front-end, the decimal separator of the numeric keypad produces the character defined by this environment variable.

DBFORMAT syntax

The value of a DBFORMAT variable uses the following syntax:

front:thousands:decimal:back

front is the leading currency symbol, can be an asterisk ( * ).
thousands is a character that you specify as a valid thousands separator, can be an asterisk ( * ).
decimal is a character that you specify as a valid decimal separator.
back is the trailing currency symbol, can be an asterisk ( * ).

Enclosing the DBFORMAT specification in a pair of single quotation marks is recommended to prevent the shell from attempting to interpret (or execute) any of the DBFORMAT characters.

The asterisk ( * ) specifies that a symbol or separator is not applicable; it is the default for any front, thousands, or back term that you do not define.

If you specify more than one character for decimal or thousands, the values in the decimal or thousands list cannot be separated by spaces (nor by any other symbols). However, only the first character will be used to display numeric or currency values, when converting strings to numbers and when entering values in form fields.

Any printable character that your locale supports is valid for the thousands separator or for the decimal separator, except 0-9 digits, <, >,, |, ?, !, =, [ and ].

The same character cannot be both the thousands and decimal separator. A blank space (ASCII 32) can be the thousands separator (and is conventionally used for this purpose in some locales). The asterisk ( * ) symbol is valid as the decimal separator, but is not valid as the thousands separator.

Enclosing the DBFORMAT specification in a pair of single quotation marks is recommended to prevent the shell from attempting to interpret (or execute) any of the DBFORMAT characters.

This table illustrates the results of different combinations of DBFORMAT setting and format string on the same value.

Table 1. Results of combinations of DBFORMAT setting and format string on the same value
Value	Format String	DBFORMAT	Result
`1234.56`	`$#,###.##`	`$:,:.:`	`$1,234.56`
`1234.56`	`$#,###.##`	`:.:,:DM`	`1.234,56`
`1234.56`	`#,###.##@`	`$:,:.:`	`1,234.56`
`1234.56`	`#,###.##@`	`:.:,:DM`	`1.234,56DM`

When the user enters numeric or currency values in fields, the runtime system behaves as follows:

If a symbol is entered that was defined as a decimal separator in DBFORMAT, it is interpreted as the decimal separator.
For MONEY fields, it disregards any front (leading) or back (trailing) currency symbol and any thousands separators that the user enters.
For DECIMAL fields, the user must enter values without currency symbols.

When the runtime system displays or prints values:

The DBFORMAT-defined leading or trailing currency symbol is displayed for MONEY values.
If a leading or trailing currency symbol is specified by the FORMAT attribute for non-MONEY data types, the symbol is displayed.
The thousands separator is not displayed unless it is included in a formatting mask of the FORMAT attribute or of the USING operator.

When MONEY values are converted to character strings by the LET statement, both automatic data type conversion and explicit conversion with a USING clause insert the DBFORMAT-defined separators and currency symbol into the converted strings.

For example, suppose DBFORMAT is set as follows:

*:.:,:SFr

The value 1234.56 will print or display as follows:

1234,56SFr

Here SFr stands for the Swiss Franc currency symbol. Values input by the user into a screen form are expected to contain commas, not periods, as their decimal separator because DBFORMAT has *:.:,:SFr as its setting in this example.