Subject | Re: [Firebird-Architect] Re: Gpre & Cobol |
---|---|
Author | Jim Starkey |
Post date | 2006-08-29T18:02:08Z |
Stephen Boyd wrote:
you need.
correspond to the types defined in the blr message declaration. This
needn't have anything to do with the actual declaration of the table,
however.
Worst case is that you need to write a thin (!) interface layer to
translate between the Cobol calling sequence and types and the Firebird
types. VMS was designed around "Appendix C", a single calling standard;
they level of control has about disappeared from the modern world.
--
Jim Starkey, Senior Software Architect
MySQL AB, www.mysql.com
978 526-1376
>> What we did with Pascal, where the differences between compilersA good decision. Clone the existing cobol module and whack it into what
>> was enormous, was to have different code generators for the
>> different versions of Pascal.
>>
>
> Not what I was thinking of but I can see the sense to this approach.
> This is the way I will tackle it.
>
you need.
>Actually not. It does expect/demand that the types in passed message
>> Have GPRE declare them to be a format that the compiler does
>> understand. The engine is really good about converting among
>> the data types it understands. If the chosen type is a scaled
>> binary, then you'll need to generate the call to invert bytes.
>> If you've got several compilers with different rules,
>> you may need separate code generators (and switches) for each.
>>
>>
>
> But don't isc_receive and isc_send expect the parameters in a certain
> format that is dependent on the column type?
>
correspond to the types defined in the blr message declaration. This
needn't have anything to do with the actual declaration of the table,
however.
Worst case is that you need to write a thin (!) interface layer to
translate between the Cobol calling sequence and types and the Firebird
types. VMS was designed around "Appendix C", a single calling standard;
they level of control has about disappeared from the modern world.
--
Jim Starkey, Senior Software Architect
MySQL AB, www.mysql.com
978 526-1376