Re: [open-cobol-list] Internal compiler error

[Charles Anthony]

> I trust you will keep us advised as to who wins this bet? :)

Alas I ran out time, but I finished it anyway.

Background: There is a programming competition

            http://omg2.thedailywtf.com/

The idea is to solve a simple problem in the most convoluted,
improbable, wrong way possible.

I completed two entries that can be seen at:

             https://github.com/charlesUnixPro/OMGWTF2

     and

             https://github.com/charlesUnixPro/OMGWTF2A

I was then stuck with the inspiration to resubmit the first entry
rewritten in COBOL (from C). I didn't finish
in time, but you can find it at:

             https://github.com/charlesUnixPro/OMGWTF2B

I must warn you that looking at the source code may make your eyes bleed.

The problem is to write a business application that randomly says Yes or No.

My solution was to find a 1987 program written for the Atari 800 that
is an "Executive Decision Maker", which is kinda close to the problem
spec. The program is actually a glorified "Magic 8-ball" toy that
randomly says things like "Signs point to Yes!".

The program is on an encapsulated floppy disk image.

My program reads the image, extracts the floppy image, parses the
Atari DOS directory, located the
program, and extracts it into memory. The program is a tokenized Atari
BASIC program. My program
uses YACC to parse the tokenized program and drive a BASIC interpreter
which runs the Executive
Decision Maker.

To do this in COBOL required invoking the C code generated by YACC,
and allowing the generated C code to call into the COBOL. The
interpreted BASIC uses mostly "double" floating point and counted
strings, neither of which are COBOL forte.

As I mentioned, I learned a little COBOL back in 1980-mumble when
helping my girl-friend with her homework. I have used a *lot* of
languages over the years, so picking up COBOL wasn't a big issue, but
I am sure that I am doing many things in the Wrong Way, but that was
part of the competition.

I started with the OpenCOBOL from fedora (labeled 0.20090209.fc17.2),
but it was giving me a lot of grief and I was unsure which issues were
my errors and which the compilers. I pulled the latest release from
SourceForge, and built it 32-bit as I was concerned that the 64 bit
build I had been using was correctly handling C/COBOL calls back and
forth.

I am pretty sure that the issues that I couldn't solve in COBOL were
related to passing doubles around. C wants to pass doubles by value
pushing 64-bits on the stack, and allow 64-bit return values. I was
unable to convince OpenCOBOL to push 64-bit values on the stack or
deal with 65-bit return-codes.

Also, I note that OpenCOBOL always does decimal math, even when the
operands are comp-2. I don't know if this is a COBOL thing, or just
something not handled because if you want to do that kind of math, go
do some FORTRAN.

Anyway, I had fun.

-- Charles