For Programmers: Free Programming Magazines  


Home > Archive > Cobol > December 2004 > Pro*COBOL and CLOB Columns









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Pro*COBOL and CLOB Columns
Chris

2004-12-17, 3:55 pm

All:

I have another interesting scenario.

I have a data item in a COBOL program that is declared as follows:

EXEC SQL BEGIN DECLARE SECTION END-EXEC.

01 LogBuffer PIC X(262146) VARYING.

EXEC SQL END DECLARE SECTION.


The Pro*COBOL pre-compiler expands this to:

01 LogBuffer.
02 LogBuffer-LEN PIC S9(4) COMP.
02 LogBuffer-ARR PIC X(262146).


As you can see - the exploded definition produced by Pro*COBOL is not
correct. I cannot seem to find a decent way around this - does anyone
have a good suggestion.

Standard Info:

COBOL: MF Server Express 4.0 SP1
Oracle: 9i
Pro*COBOL: 1.8 (don't ask why ...)
OS: HP-UX 11i


Thanks in advance,
Chris

Thomas A. Li

2004-12-17, 3:55 pm

That is right, because the length info of string is needed for
intercommunication between COBOL and SQL modules.

There are directions when using them:
From COBOL to SQL, writing both ,
From SQL to COBOL, reading LogBuffer-ARR,

Good luck,

Thomas Li
Corporola Inc.


"Chris" <ctaliercio@yahoo.com> wrote in message
news:1103294765.387986.37710@z14g2000cwz.googlegroups.com...
> All:
>
> I have another interesting scenario.
>
> I have a data item in a COBOL program that is declared as follows:
>
> EXEC SQL BEGIN DECLARE SECTION END-EXEC.
>
> 01 LogBuffer PIC X(262146) VARYING.
>
> EXEC SQL END DECLARE SECTION.
>
>
> The Pro*COBOL pre-compiler expands this to:
>
> 01 LogBuffer.
> 02 LogBuffer-LEN PIC S9(4) COMP.
> 02 LogBuffer-ARR PIC X(262146).
>
>
> As you can see - the exploded definition produced by Pro*COBOL is not
> correct. I cannot seem to find a decent way around this - does anyone
> have a good suggestion.
>
> Standard Info:
>
> COBOL: MF Server Express 4.0 SP1
> Oracle: 9i
> Pro*COBOL: 1.8 (don't ask why ...)
> OS: HP-UX 11i
>
>
> Thanks in advance,
> Chris
>



Chris

2004-12-18, 12:46 pm

Thomas,

Thanks for the feedback, but the reson I am saying that the Pro*COBOL
exploded definition is wron is this: it only allows for a length of
9999. Clearly in this situation that maximum is insufficient.

The LogBuffer field is being inserted into a CLOB column, so there is
no reason to restrict the length of the string field here.
Thanks,
Chris

Thomas A. Li

2004-12-20, 8:55 pm

That is right, because the length info of string is needed for
intercommunication between COBOL and SQL modules.

There are directions when using them:
From COBOL to SQL, writing both ,
From SQL to COBOL, reading LogBuffer-ARR,

Good luck,

Thomas Li
Corporola Inc.


"Chris" <ctaliercio@yahoo.com> wrote in message
news:1103294765.387986.37710@z14g2000cwz.googlegroups.com...
> All:
>
> I have another interesting scenario.
>
> I have a data item in a COBOL program that is declared as follows:
>
> EXEC SQL BEGIN DECLARE SECTION END-EXEC.
>
> 01 LogBuffer PIC X(262146) VARYING.
>
> EXEC SQL END DECLARE SECTION.
>
>
> The Pro*COBOL pre-compiler expands this to:
>
> 01 LogBuffer.
> 02 LogBuffer-LEN PIC S9(4) COMP.
> 02 LogBuffer-ARR PIC X(262146).
>
>
> As you can see - the exploded definition produced by Pro*COBOL is not
> correct. I cannot seem to find a decent way around this - does anyone
> have a good suggestion.
>
> Standard Info:
>
> COBOL: MF Server Express 4.0 SP1
> Oracle: 9i
> Pro*COBOL: 1.8 (don't ask why ...)
> OS: HP-UX 11i
>
>
> Thanks in advance,
> Chris
>



Chris

2004-12-20, 8:55 pm

Thomas,

Thanks for the feedback, but the reson I am saying that the Pro*COBOL
exploded definition is wron is this: it only allows for a length of
9999. Clearly in this situation that maximum is insufficient.

The LogBuffer field is being inserted into a CLOB column, so there is
no reason to restrict the length of the string field here.
Thanks,
Chris

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com