COBOL does not have a concept that corresponds directly to SQL's NULL. The closest candidates in COBOL are data items that contain either SPACES or LOW-VALUES. In SQL, NULL is often used to indicate that the data is missing or not applicable.
To maintain the integrity of the source data and to ensure that any data written from your application back to the COBOL source is accurate, you must provide a representational mapping between COBOL's SPACES and LOW-VALUES and the corresponding SQL column values.
Use the NULL_NUMERIC_READ variable to indicate which COBOL numeric data should be represented as NULL. For data coming into your application (READs), if a field contains either SPACES or LOW-VALUES in numeric data in the COBOL files, instruct the application to represent it as either NULL or a zero. Valid values are:
NULL_NUMERIC_READ null NULL_NUMERIC_READ 0
With numeric fields, LOW-VALUES and SPACES are valid values for many numeric types, as shown in the following examples:
| If the numeric type is ... | LOW-VALUES is equal to ... | SPACES is equal to ... |
|---|---|---|
| PIC 9(4) COMP-3 | 0 | 202 |
| PIC 9(2) COMP-5 | 0 | 8224 |
| PIC 9(4) COMP-2 | 0 | INVALID |
Therefore, AcuXDBC follows these rules for numeric data coming in to the ODBC-enabled application:
| Field | Rule |
|---|---|
| All LOW-VALUES | If LOW-VALUES is an invalid value for the numeric type, the field comes into the application based on the setting for numeric variables for the data source |
| Any other values | If the value is invalid for the numeric type, undefined data may come in to the application |
By default, numeric data is interpreted as zero on input to your ODBC-enabled application.
See NULL_NUMERIC_WRITE configuration variable for additional restrictions on writing data to your COBOL data file from your ODBC-enabled application.