It may facilitate RLX application testing to set the following options with respect to RLX error handling and the display of diagnostic panels:
RLX CONTROL ERRORS RETURN RLX CONTROL EPANEL DISPLAY
The CONTROL ERRORS RETURN setting allows your RLX application to continue execution even if it encounters severe errors. This allows you to detect several errors -- be they syntactical, contextual, SQL related, or data related -- in a single trial.
When testing is complete, you can change the RLX error handling and error reporting options to settings more appropriate for production use. For example,
CONTROL ERRORS FILTER CONTROL EPANEL DISPLAY
6.4 Datatype conversion and output formatting
This section describes how RLX processes host variables that contain numeric values, date values and time values with respect to input editing and output formatting. Several RLX CONTROL services enable you to specify how RLX formats the values it returns to your application. In addition, you can specify such parameters as the format of date and time values that your application will present to RLX and DB2.
6.4.1 Output Formatting of Numeric Datatypes
NOTE: This section applies primarily to RLX applications that issue SQL requests from application components written in the TSO CLIST language. The restrictions described in this section do not apply to REXX. Rather, RLX applications written in REXX can leave the setting that controls output formatting of numeric datatypes to the default value of 'edited'. This setting is suitable for both display and arithmetic.
The TSO CLIST language provides rather limited support for numeric datatypes and for calculations. This is because the CLIST language allows only integer values for numeric datatypes. Therefore, in order to perform arithmetic with a numeric variable, the variable must have an integer value.
This is a serious limitation with respect to packed decimal and floating point datatypes.
For these datatypes, you must choose between formatting the result either in a form suitable for display (e.g. edited-decimal value of 12345.67) or as an integer value suitable for arithmetic.
The CONTROL NUMERIC service lets you switch between integer and edited decimal output formats. Its syntax is:
RLX CONTROL NUMERIC numeric_option
This service has two options -- EDITED and INTEGER -- and it globally affects all variables whose internal datatype is packed decimal or floating point (single or double precision). Specifically:
• RLX CONTROL NUMERIC EDITED - causes RLX to format the variable as an edited decimal value on output. For example, 123.45 -- i.e., there are result digits to the right of a decimal point.
• Conversely, RLX CONTROL NUMERIC INTEGER causes RLX to format the variable as an integer value on output -- e.g., 12345
6.4.2 Input editing and output formatting of DATE datatypes
The RLX CONTROL DATE service specifies which date format should be used during input and output processing of DATE datatypes. On input, your choice of date format governs which edit validations will be conducted to determine whether a string representation of a date value is valid.
NOTE: RLX validates date string values before passing them to DB2.
If an RLX procedure invoked through the RLXS frontend detects an invalid date string value, it displays a Data Error panel rather than globally rejecting the entire SQL statement. This allows the user to readily identify the error and rekey the value rather than terminate the application.
On output, your choice of date format governs how RLX presents string representations of date values for display.
The CONTROL DATE service, through its support for the various date formats described in the DB2 SQL reference, allows you to switch among the various date formats. Its syntax is:
RLX CONTROL DATE date_option
where date_option is one of the date format name abbreviations described below and in the DB2 SQL reference.
RLX CONTROL DATE ISO - causes RLX to edit and format date values consistent with the International Standards Organization (ISO) format
i.e., - yyyy-mm-dd, as in 1990-12-25.
RLX CONTROL DATE USA - causes RLX to edit and format date values consistent with IBM USA standard (USA) format
i.e., - mm/dd/yyyy, as in 12/25/1990.
RLX CONTROL DATE EUR - causes RLX to edit and format date values consistent with IBM European standard (EUR) format
i.e., - dd.mm.yyyy, as in 25.12.1990.
RLX CONTROL DATE JIS - causes RLX to edit and format date values consistent with the Japanese Industrial Standard JapaJ(JIS) format
i.e., - yyyy-mm-dd, as in 1990-12-25.
RLX also supports date strings defined as LOCAL, the format for which is site defined.
6.4.3 Input editing and output formatting of TIME datatype
The RLX CONTROL TIME service specifies which time format should be used during input and output processing of TIME datatypes. On input, your choice of time format governs which edit validations will be conducted to determine whether a string representation of a time value is valid.
NOTE: RLX validates time string values before passing them to DB2.
If an RLX procedure invoked through the RLXS frontend detects an invalid time string value, it displays a Data Error panel rather than globally rejecting the entire SQL statement. This allows the user to readily identify the error and rekey the value rather than terminate the command procedure.
On output, your choice of time format governs how RLX formats string representations of time values for display.
The CONTROL TIME service, through its support for the various time formats described in the DB2 SQL reference, allows you to switch among the various time formats. Its syntax is:
RLX CONTROL TIME time_option
where time_option is one of the time format name abbreviations described below and in the DB2 SQL reference.
RLX CONTROL TIME ISO - causes RLX to edit and format time values consistent with the International Standards Organization (ISO) format.
i.e., - hh.mm.ss, as in 13.30.15
RLX CONTROL TIME USA - causes RLX to edit and format time values consistent with IBM USA standard (USA) format
i.e., - hh:mm PM, 12:15 PM
RLX CONTROL TIME EUR - causes RLX to edit and format time values consistent with IBM European standard (EUR) format
i.e., - hh.mm.ss, 13.30.15
RLX CONTROL TIME JIS - causes RLX to edit and format time values consistent with the Japanese Industrial Standard (JIS) format,
i.e., - hh:mm:ss, 13:30:15
RLX also supports date strings defined as LOCAL, the format for which is site defined.
6.5 VDEFINE - explicitly define host variable datatypes
The RLX CONTROL VDEFINE service lets you explicitly define the datatype characteristics of one or more host variables. The RLX VDEFINE service is documented in Chapter 14.3 which includes support for the syntax ‘RLX CONTROL VDEFINE’.
6.6 Scope Control
6.6.1 Scope of cursor name recognition
By default, a cursor name DECLAREd in an outer EXEC will not be recognized within an inner exec or TSO CLIST. This is intended to maximize the independence of separately written procedures should the same name be used inadvertently in more than one procedure. On the other hand, developers may deliberately intend to reference the same cursor in both an outer and inner command procedure. RLX provides the CONTROL SCOPE CURSOR service for this purpose. Its syntax is:
RLX CONTROL SCOPE CURSOR scope_option
where 'scope_option' is either LOCAL or GLOBAL.
The LOCAL option instructs RLX to consider only DECLARE CURSOR statements within the current command procedure as it tries to identify a cursor name referenced in SQL OPEN, FETCH, and CLOSE statements. Thus, two cursors DECLAREd with the same name in two different procedures are treated as separate entities.
In contrast, the GLOBAL option instructs RLX to consider all DECLARE CURSOR statements executed so far within a nested hierarchy of REXX execs and/or TSO CLISTs in its attempt to identify a cursor name. Thus, a cursor can be DECLAREd in one command procedure, OPENed in another, and FETCHed and CLOSEd within yet another exec or TSO CLIST. When CONTROL SCOPE CURSOR GLOBAL is in effect, each of these statements make reference to the same CURSOR entity.
6.6.2 Scope of recognition for Host variable VDEFINEs
By default, a host variable name VDEFINEd in an outer command procedure will not be recognized within an inner command procedure. This is intended to maximize the independence of separately written procedures should the same name be used inadvertently in more than one procedure. On the other hand, developers may deliberately intend to reference the same host variable in both an outer and inner exec or TSO CLIST and make use of the same explicit variable definition. RLX provides the CONTROL SCOPE HOSTVAR service in support of this requirement. The syntax for requesting this service is:
RLX CONTROL SCOPE HOSTVAR scope_option
where 'scope_option' is either LOCAL or GLOBAL.
The LOCAL option instructs RLX to place subsequent VDEFINE entries within a local pool associated with the current exec or TSO CLIST. Thus, two VDEFINEs for variables of the same name that appear in two different procedures are treated as separate variable definitions.
In contrast, the GLOBAL option instructs RLX to add new VDEFINE entries to the global pool associated with the entire RLX application. Thus, a host variable can be VDEFINEd in one command procedure and referenced in others.
By searching the global VDEFINEs pool, every host variable of the same name makes reference to the same VDEFINEs entity.
6.6.3 Scope of RLX statement recognition
By default, an RLX statement string coded in an outer exec or CLIST will not be recognized within an inner procedure. This is intended to maximize the independence of separately written procedures should the same statement string be used inadvertently in more than one procedure. On the other hand, developers may deliberately intend to use the same RLX statement in more than one procedure within a nested procedure hierarchy.
RLX provides the CONTROL SCOPE STATEMENT service for this purpose. Its syntax is:
RLX CONTROL SCOPE STATEMENT scope_option
where 'scope_option' is either LOCAL or GLOBAL.
The LOCAL option instructs RLX to consider only RLX statements within the current procedure as it tries to identify statement strings it has already encountered and processed. Thus, two identical statement strings coded in two different procedures are treated as separate entities.
In contrast, the GLOBAL option instructs RLX to consider all RLX statements executed so far within a nested hierarchy of REXX execs and/or TSO CLISTs as RLX tries to match a statement string. When CONTROL SCOPE STATEMENT GLOBAL is in effect, each of these statements makes reference to the first statement encountered.