[Info-vax] VMS Cobol - GnuCOBOL

[bill]

On 3/1/2023 8:21 AM, Johnny Billquist wrote:
> On 2023-02-28 18:53, bill wrote:
>> 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.
> 
> All very true. But that does not change the fact that when you point a 
> debugger at it, it will trace the binary back to C, not Cobol, unless 
> you extend the debugger to do the reversing of the C to the original 
> Cobol code. And unless you do some tricks to the C compiler, a debugger 
> don't even have a way to know that it wasn't originally C code.
> 
> But it is the same kind of problems all those other languages also have, 
> and in fact even native compiled languages. After all, the debugger only 
> sees the machine code, and hopefully a bunch of symbols and other 
> meta-data the compiler left behind.

Looks like COBOL is still stuck with
      SOURCE-COMPUTER. source-computer-entry [WITH DEBUGGING MODE].

:-)

bill