GRE environment variables
These environment variables are relevant for the Genero Report Engine (GRE).
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.
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.
- 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
- Standard error, in non-distributed mode.
- The gre.log file in the home directory of the user invoking the GRE daemon, in distributed mode.
You can redirect the log messages to a different file.
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 running report application 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 running report application 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.
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 running report application 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.
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.
- 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.
- 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 toDBMONEY="$."
, orDBFORMAT="$:,:.:"
. - 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.
Value | Format String | DBFORMAT | Result |
---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
*:.:,:SFr
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
as its setting in this example.*:.:,:SFr