Since I am not a member of the developers list and my posts to that
list bounce, I am going to try posting this here to see if I get any
response.

I am looking at Cobol support in GPRE. Specifically support for
RM/Cobol, although much of this would apply to most ANSI-85 Cobol
compilers.

ANSI-85 Cobol support in GPRE is seriously broken. So far I have
uncovered the following:

1) Using USAGE COMP data items as though they were 16 or 32 bit
integers. The content of USAGE COMP data items is defined by the
compiler manufacturer and cannot be depended on the be any particular
format. These need to be changed to USAGE BINARY(n) data items with
the # of bytes of storage specifed as n.

2) Using PIC S9(9) to define a 32 bit integer field or PIC S9(4) to
define a 16 bit integer field. This will cause very large integers to
be truncated since you need 10 digits to fully contain a 32 bit
integer. We need to use USAGE BINARY(4) to force PIC S9(10) data
items to 4 bytes. The same applies for 16 bit integers.

3) In some places integer (USAGE BINARY) fields are assumed to be in
native byte order. This is not the case for RM/Cobol and I would be
surprised to find if it were the case for other Cobols since native
byte order on Intel processors would tend to break some legacy
mainframe code.

4) Use of USAGE COMP-1 and COMP-2 to hold floating point values. As
far as I know these are extensions to the ANSI-85 standard and are not
supported by all Cobol compilers. Certainly not by RM/Cobol in any case.

5) Use of USAGE COMP-X in some places to hold binary character data.
I'm not sure of the status of this in ANSI-85 but it is not supported
by RM/Cobol.

6) Some relatively minor bugs regarding column alignment.

I could use some feedback on this stuff.

First and most important. Is anyone actually using Cobol with GPRE?
That is to say, if I rework this to actually match ANSI-85 Cobol is
that going to break anyone else's code? Or should I introduce the
concept of a Cobol dialect that could be set via the command line to
generate legacy (-ansi) code vs RM/Cobol or any other Cobol that might
come along?

In order to support RM/Cobol (and possibly other Cobols) we have to
re-jigger the byte order from Cobol order to native order and vice
versa. I am thinking that we will need to create an entirely new DLL
a la gds32.dll with Cobol specific entry points that flip the bytes
and call the existing isc_* routines. Anyone have any problems with
this? Or a better idea?

I'm uncertain what to do about floating point data items for Cobol
compilers that don't support them. We would probably need to create
new subroutines that would be called to convert from floating point to
some sort of Cobol numeric data type rather than using the Cobol MOVE
verb. For RM/Cobol this is relatively easy because the subroutine
activation record gives the type and size of all arguments. I suspect
that we will need a more generic approach for other compilers but that
could get fairly ugly given the large number of Cobol data types.

Any and all comments and suggestions are welcome.

If I don't here anything at all, I will have to assume that no one
cares and that I can do my own thing.