Sometimes developers are in a situation where they need to create a COBOL File Description 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 interface opens a data source table, the only thing it checks is that the column names match the COBOL data names.
When the interface 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 ODBC-capable tool), using PIC X(nn) for each column will work 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 ODBC data source has values only in the range 0-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:
SQL_CHAR PIC X(nn) nn = size of item
SQL_VARCHAR PIC X(nn) nn = maximum size of item
SQL_DECIMAL PIC 9(n)v9(m)
SQL_NUMERIC PIC 9(n)v9(m)
SQL_SMALLINT PIC 9(5) COMP-5
SQL_INTEGER PIC 9(9) COMP-5
SQL_REAL USAGE FLOAT
SQL_FLOAT USAGE FLOAT
SQL_DOUBLE USAGE DOUBLE
SQL_TINYINT PIC 9(3) COMP-5
SQL_BIGINT PIC 9(9) COMP-5
SQL_BINARY PIC X(nn)
SQL_VARBINARY PIC X(nn)
SQL_LONGVARBINARY PIC X(nn)
SQL_DATE PIC 9(6) or PIC 9(8)
SQL_TIMESTAMP USAGE DISPLAY
NOTE
The BINARY data types are usually of a form that COBOL can't understand anyway. You will usually just read these columns, and rewrite them unchanged. If you have more information about the data in the columns, you might be able to do something else, but this requires more knowledge about the columns.
The DECIMAL, NUMERIC, DATE, and TIMESTAMP types usually have special representations in a data source, which really doesn't match any COBOL data type exactly. When the interface binds the data (a technical term), it asks the data source to return it in character form, so the most efficient COBOL data type would probably be USAGE DISPLAY.