Interfaces.Cobol (Was LRM Error?)

[Al Christians <achrist@easystreet.com>]

Richard D Riehle wrote:

>          05 Some-Number     PICTURE  S99V99 USAGE DISPLAY.
>          05 Some-String     PICTURE  9(6).
>
> We may freely MOVE  (actually MOVE means "copy") the numeric data
> to the string data without regard to the typing.  On the other hand,
> we will get a compile time error if we try to do arithmetic on the
> string. 

A field that contains 9's only is numeric and can be used for arithmetic
even if it is named Some-String.  And USAGE DISPLAY just tells how the
data is to be stored, not how it is to be used. So, you can do math on
either of the two fields above. 

> 
>  The people who worked on this package had their work cut out for them.

I agree 100%.

>  They seem to have done it well, given the huge differences between the
>  COBOL language and Ada.

Anybody know how much use this package gets?  I'd be interested to
know how well it works in practice.  How many Ada compilers other than 
GNAT come with it?  Do vendors of compilers that don't provide it get
any requests for it?

Looking at the example in the LRM, I doubt that it gets heavy use as 
illustrated there.  The example shows creating instances of the generic 
conversion routines for each field to convert.  If generics eat up 
memory, this will be quite a pig to interface to a big Cobol system (say 
100's of files, many thousands of fields) -- I think we'd find another 
way to do it. 

One alternative is to use Cobol copybooks to generate a wrapper to 
Interfaces.Cobol for each Cobol copybook, but to only create one 
instance of the generic converter for each distinct set of Cobol 
attributes.  This would be pretty good, but for a system with many 
copybooks, you would also want have to avoid duplication between 
files.  But I'd guess that the number of distinct Cobol formats 
wouldn't go too far up into the hundreds often.

I think I'm going to just write a wrapper for Interfaces.Cobol that
uses one instance of each of three generics -- for numeric, binary, 
and packed data, and machine generate the get and set functions that 
invoke the wrapper.  Anyone else already cracked this nut or otherwise 
interested?

Al