[open-cobol-list] AW: Open Cobol and SQL / new version 0.2.1

[Frank Polscheit]

Hi Mike,
thank you very much for your feedback below. I have put all 4 aspects
into the new version 0.2.1 (see attachment).

If you set the following environment variable within a unix shell like

    export PGSQL_CONTROL="AUTO-OPEN"

the generated cobol program will now use the auto-open call to establish
a database connection using the content of the 3 environment variables
PGSQL_DB, PGSQL_USER and PGSQL_PASSWORD, which have to be set within the
shell as well. If PGSQL_CONTROL is not set or contains another value
than "AUTO-OPEN", you have to open the database connection within your
COBOL code as shown within the example code as comment (initialize PGSQL
vars. first, then call the open routine).

Cheers, Frank

-----Ursprüngliche Nachricht-----
Von: Polscheit, Frank [mailto:address@hidden 
Gesendet: Montag, 1. März 2004 08:51
An: address@hidden
Betreff: WG: Open Cobol and SQL

-----Ursprüngliche Nachricht-----
Von: mike boggs [mailto:address@hidden 
Gesendet: 27.02.2004 21:37
An: Polscheit, Frank
Betreff: Re: Open Cobol and SQL



Hi Frank, 

  Thanks for posting cobsql to the open cobol list .. I have been
playing arround with it, and it works prety good for an early Alpha. I
have found the following small problems with it:

1) When generating SQL in the Cobol program you put out -BEGIN and -END
   labels which require a . after them, this interferes with scope
   terminated statements like PERFORM and IF, when there is embeded SQL
in
   them. I like the -BEGIN and -END delimiters but I changed them to
just be
   COBOL comments instead of real labels to get arround this problem.

2) As above I notice you put a . at the end of your generated CALL, MOVE
   etc. statements, this also interferes with PERFORM, IF, etc. From
what I
   understand of COBOL there is no real need for . in the PROCEDURE
   DIVISION anymore, except for on labels. ( you could use END-CALL to
   terminate the CALL statement instead of a . )

3) I encountered a bus error ( on MAC OS X 10.2 ), in your generated C
   SQL statement program when a FETCH returned no rows but had an
SQLCODE of
   100. I think it was because you move results without checking the SQL
   return code first. I changed COBSQL.RB to generate
   if (sqlca.sqlcode == 0) {
   before doing the strcpy etc. and this fixed my problem.

4)  How can I use the SQL-OPEN routine and not have the SQL-AUTO-OPEN
    routine used by default, is there a switch I missed ?

Hope this helps, and again thanks for putting this ruby routine
together!

   Mike

cobsql
Description: Binary data

testen.cob
Description: Binary data

cobsql.rb
Description: Binary data