# Sign of numeric fields

Numeric fields defined with decimal places (even if zero) are generated with a signed COBOL picture. Numeric fields defined with no decimal places are generated with an unsigned COBOL picture.

`FIELD-A W 5 N 2`

is generated as:
`02 FIELD-A PIC S9(03)V99 VALUE ZEROS.`

and
`FIELD-A W 5 N`

is generated as:
`02 FIELD-A PIC 9(05) VALUE ZEROS.`

Some COBOL instructions force a positive sign in unsigned numeric fields, even if the source field is negative. This can lead to differences at run time due to logic taking on a different path when unsigned fields are tested for positive or negative values. Make sure that arithmetic comparisons for negative values operate on signed fields.

Easytrieve forces an F

sign in positive zoned decimal numeric fields.
This is true for signed (fields defined with decimal places, such as quantity),
and for unsigned fields (fields defined without decimal places).

COBOL forces a C

sign in positive zoned decimal numeric fields that
are defined with a sign. Refer to the `FSIGN=`

option in
Migration Utility translation options for
overriding options.

```
Definition Hex Value
Easytrieve O-BALANCE 1 5 N 0 F2F2F2F2F2
COBOL O-BALANCE PIC S9(05) F2F2F2F2C2
```

`F2`

instead of `C2`

, This
is numerically equal, but it is not equal if compared as an alphanumeric value.
Altering the Easytrieve definition to a numeric unsigned field yields the same
in COBOL:
```
Definition Hex Value
Easytrieve O-BALANCE 1 5 N F2F2F2F2F2
COBOL O-BALANCE PIC 9(05) F2F2F2F2F2
```

Make sure that your Easytrieve fields are properly defined. All quantitative fields should be defined with decimal places (even if zero) and all non-quantitative values should be defined without decimal places.

In general, the intermediate calculations are not a problem. The problem is visible on the output display numeric fields that are defined as quantity (with a sign) but they are truly not a quantity, such as account numbers, serial numbers, and item numbers.