> I turned the DSQL parser into a class in Vulcan. It's not going to get
> you anywhere. Yacc is yacc and doesn't subclass.
>
> GPRE and QLI are both instances of GDML.
>
> It shouldn't make any difference that GDML keywords overlap COBOL
> keywords. The GDML is long gone before it hits the compiler. That's
> why it's called a preprocessor.

It matters because the GDML preprocessor sees a Cobol reserved word in
the middle of a Cobol statement, grabs it and tries to parse it as a
GDML command. This causes the precompiler to fail or to emit bogus
Cobol code. Even simple things like a statement label like
0080-COMMIT causes the GDML parser to think that it has seen a COMMIT
command. Thankfully the embedded SQL parser doesn't trigger until it
sees EXEC SQL so it doesn't have the same problem.

> > it easier to keep GPRE and DSQL in sync? To say that parts of the
> > code in GPRE are a bit opaque is putting it mildly.
> >
> Hey, it was my first C program. Be nice.

I wasn't meaning to throw stones, just pointing out that GPRE can be a
bit of a challenge to modify. Seemingly simple changes are sometimes
full of unintended consequences. And regression is a bitch!

> Sorry, if I were smarter then, I would have used an OO API. The only
> problem was that OO hadn't quite been invented then.
>
> Add One to Cobol, anyone?
>

A pun on C++. Cute! :)

OO Cobol is not the answer. I can't remember having seen a nastier
hack than the way the OO Cobol committee twisted Cobol syntax to make
it appear object oriented. We looked at OO Cobol for .Net and decided
we would be just as well off to convert to C# or Delphi or something
similar rather than wrestle with the OO aspects of Cobol.

If I were to try to use Cobol to code to the Firebird API I would
probably create some sort of Activex control that would hide the worst
of the complexity from the Cobol program. Even that would be ugly.