Sometimes developers are in a situation where they need to create a COBOL file descriptor (FD) based on an existing data source table. The most important thing to understand in this situation is that there is almost nothing that you can do wrong. When the Connector opens a data source table, the only thing it checks is that the column names match the COBOL data names.
When Acu4GL reads data from the data source, it essentially does a COBOL-style MOVE from the native data type to the COBOL data type, whatever it is. And since most types have a CHAR representation (in other words, you can actually display most data types, using a standard DB2-capable tool), using PIC X(nn) for each column works perfectly well.
A better general rule is to use a COBOL type that closely matches the data source data type, but don't worry about getting an exact fit. So you can use PIC 9(9) whenever the data source has an INTEGER type.
If you have more information about the data source type, you might be able to use a different COBOL representation. For example, if you know that a particular column in an DB2 data source has values only in the range 0 to 999, you could use PIC 999 for your COBOL data. The COMP-type you use is really determined by your own preferences and should have little bearing on the COBOL data type you choose.
If you want to somehow choose your COBOL data types so that there is a best fit, you can use the following mapping:
| Acu4GL for DB2 | COBOL Data Type |
|---|---|
| date | Date (DATE XFD directive applied) |
| varchar | varchar (VAR_LENGTH XFD directive applied) |
| float | float |
| smallint | pic 9(4) |
| integer | pic 9(9) |
| decimal(10,0) | pic 9(10) |
| decimal (x + y, y) | pic 9(x)v9(y) |
| char | pic x(254) |
| pic x(255) or greater must apply VAR_LENGTH XFD directive | pic x(255) |