[Info-vax] VMS Cobol - GnuCOBOL

[bill]

On 2/28/2023 12:04 PM, Denys Beauchemin wrote:
> On Monday, February 27, 2023 at 7:11:36 PM UTC-6, Robert A. Brooks wrote:
>> On 2/27/2023 6:35 PM, Arne Vajhøj wrote:
>>
>>> But isn't that the case for all VMS compilers? I know
>>> I use /DEB/NOOP for both Fortran, Pascal and C when I want
>>> to debug.
>> Reagan may weigh in here, but I'm pretty sure that DEC suggested using
>> /DEBUG/NOOP when using the debugger for any language with an optimizer back in
>> the 80's; if so, then that's been a pretty consistent message.
>>
>> -- 
>>
>> --- Rob
> Speaking of debuggers.
> 
> I'm not clear on how you can actually debug a gnucobol program, since it's C in reality.

To be honest, there probably isn't really a debugger for GnuCOBOL.
We really need to put this one misconception to rest.  You are not
supposed to do anything with the C code generated by the GnuCOBOL
compiler.  It's an intermediate language not intended for human
consumption.  Every compiler I have worked with so far takes the
original source and converts it into some intermediate language.
Some use RTL.  Some use assembler.  GnuCOBOL uses C.  RATFOR uses
Fortran.  :-)  We even have the Chung/Yuen Tiny Pascal which converted
to a P-code that could be further processed into 8080 Assembler and
then further processed into an executable for the Northstar.
None of these intended humans to read, understand or manipulate
the intermediate forms.  So lets just ignore the fact that GnuCOBOL
converts COBOL into C.  It really converts COBOL into an executable
program on the host computer just like every other compiler.

bill