Re: Using VARCHAR2 with Pro*COBOL

Michael Ho wrote:
>
> Brian M. Biggs wrote:
>
> > What is the best (or at least better) approach for using VARCHAR2
> > columns in Pro*COBOL programs? We currently have a database with many
> > tables in CHAR format. In doing some preliminary testing with
> > converting those tables to VARCHAR2, we have found that there is about a
> > 25% performance hit with using VARCHAR2 columns. This hit was seen in a
> > read-only program.
>
> 01 ABC.
> 05 ABC-LEN S9(4) COMP
> 05 ABC-TEXT X(40)
>
> EXEC SQL
> SELECT <varchar2> into :ABC....
> ...
>
> Simple isn't it.

Sure. Can you also declare variables of type VARYING within your EXEC SQL DECLARE section? I think if you do that, the precompiler will automatically make that variable a group-level variable and append -ARR and -LEN onto the name. Oracle will set the length appropriately when you read from the database, but you have to keep track of the string length within COBOL and set that -LEN variable every time you write back to the database. Is that correct? I don't know COBOL, and I'm going on what our primary COBOL programmer is telling me.

Is what I have said above accurate? Is there an easy way to track string lengths in COBOL? Is it worth it? As I said in my first message, when we changed the datatypes to VARCHAR2, and kept our fixed-length COBOL variables, we had to put RTRIMs on the variables before writing to the database. As a result, we took about a 20-25% performance hit. This doesn't seem right to me, but the numbers don't seem to lie.

> However, the bad new is for NULL
> If the value is nullable (every column), to check null you need :
>
> 01 ABC-IND S9(4) COMP.
> 01 ABC.
> 05 ABC-LEN S9(4) COMP
> 05 ABC-TEXT X(40)
>
> EXEC SQL
> SELECT <varchar2> into :ABC:ABC-IND ....
> ...
>
> IF ABC-IND = -1 THEN.....
> ...
>
> And also, many bugs involved in this part.

Bugs, or just more room for programming errors?

> Personally, I think Pro*COBOL is not a good product. But, it still have
> its use.

I'm not particularly a fan of Pro*COBOL either, or regular COBOL for that matter, but we don't really have a choice but to use it right now. We have too much invested in the code to rewrite it, convert it or just throw it away.

Brian

-- 
Brian M. Biggs				mailto:bbiggs_at_cincom.com
Cincom Systems, Inc.			voice: (513) 677-7661
http://www.cincom.com/