Cobol - Pro*COBOL and CLOB Columns

Author

Pro*COBOL and CLOB Columns

Chris

2004-12-22, 8:55 am

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

LX-i

2004-12-30, 3:55 am

Chris wrote:
> 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.

I'm not quite sure what you think is incorrect. I saw your previous
post, that only 9999 would fit into the length field. Check your
compiler's manual and see how "COMP" fields are allocated. My guess is
that you've got a signed half-word or word-length field there, that will
hold a number greater than the picture clause, at first blush, would
allow. (At least I know my compiler allows more - a pic 9(02) comp can
hold a value up to 511...)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi0007@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

rjones0@hotmail.com

2004-12-30, 8:55 am

Bottom posting

Chris wrote:
> 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

Hello Chris,

I agree you have a problem and it seems to me the best solution is to
report
it to Oracle to fix the pre-compiler.

But in the meantime you might check whether the reported generated
source code
definition is actually correct, e.g. looking at the object code might
reveal
that the definitions are OK.

As someone else mentioned, you should look at the compiler
documentation to
find out how such a COMP field is handled, I am not personally familiar
with
these compilers so can't comment in detail.

As a last resort, you may have to manually manipulate the precompiler
output.

It may be that there is a size limit on data items that can be
declared. At
one time, I think that some compilers (and perhaps precompilers) had
size
limits of 32K (32768 or thereabouts), which correlated with the maximum
value
that could be stored in an IBM defined binary halfword, irrespective of
whatever the actual picture specified.

Whether or not the contents of binary halfwords are checked for
conformity to
size limitation of the PICTURE clause is governed by the compiler and
various
compiler options that may be in force. I would regard it as bad
practice to
rely on values being allowed to exceed the PICTURE definition, but
circumstances can (used to) necessitate cases where it is desired,
ideally
such cases should be documented by comments to warn the unwary.
Good luck and let us know how you get on.

Rober

Robert Wagner

2004-12-30, 3:55 pm

On 17 Dec 2004 06:46:05 -0800, "Chris" <ctaliercio@yahoo.com> wrote:

>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

The syntax you're using is appropriate to VARCHAR2, so named because
its length is 2 bytes long. You want a LONG VARCHAR, which you have to
define yourself like this:

01 LogBuffer.
02 LogBuffer-LEN PIC S9(9) COMP.
02 LogBuffer-ARR PIC X(262146).
EXEC SQL VAR LogBuffer-ARR is LONG VARCHAR END-EXEC.

EXEC SQL INSERT INTO MyTable VALUES (:MyKey, :LogBuffer) END-EXEC.

If you want to define it internally as a CLOB, rather than LONG
VARCHAR, the syntax is something like this (I didn't try it, so you
may have to tinker):

01 MyCLOB-pointer SQL-CLOB. *> contains pointer not contents.

EXEC SQL ALLOCATE :MyCLOB-pointer END-EXEC.

EXEC SQL INSERT INTO MyTable VALUES (:MyKey, :MyCLOB-pointer)
END-EXEC.

EXEC SQL LOB ENABLE BUFFERING :MyCLOB-pointer END-EXEC.
*> Buffering is probably not necessary.

Read your data into LogBuffer

EXEC SQL LOB WRITE :Bytes-Written FROM :LogBuffer-ARR WITH LENGTH
:LogBuffer-LEN INTO :MyCLOB-pointer END-EXEC.

EXEC SQL LOB FLUSH BUFFER :MyCLOB-pointer END-EXEC.

EXEC SQL FREE :MyCLOB-pointer END-EXEC.

Alternatively, you could define your log as a BFILE and
1. Just store the pointer to it (path/file) in the database, using
LOB FILE SET. This is called an External LOB.
2. Use EXEC SQL LOB LOAD to copy contents into the CLOB
Both have the advantage of not requiring a Cobol program; you could do
it entirely in SQL, perhaps as a stored procedure.

Howard Brazee

2004-12-30, 3:55 pm

On 29-Dec-2004, LX-i <lxi0007@netscape.net> wrote:

> I'm not quite sure what you think is incorrect. I saw your previous
> post, that only 9999 would fit into the length field. Check your
> compiler's manual and see how "COMP" fields are allocated. My guess is
> that you've got a signed half-word or word-length field there, that will
> hold a number greater than the picture clause, at first blush, would
> allow. (At least I know my compiler allows more - a pic 9(02) comp can
> hold a value up to 511...)

I have a called program that has to be compiled with TRUNC(BIN). We had to
create an Endevor type just for this program, as our migration procedure
includes compiler options. That option tells the compiler to ignore CoBOL
pictures in deciding the maximum value that is in a field.

In this case, IDMS database keys are stored in:
03 DBKEY PIC S9(8) COMP SYNC.

But can contain values greater than 99999999. This program accepts either
this key or a formatted display version of this and returns the other.

Robert Wagner

2004-12-30, 3:55 pm

On Thu, 30 Dec 2004 15:16:28 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>
>On 29-Dec-2004, LX-i <lxi0007@netscape.net> wrote:
>
>
>I have a called program that has to be compiled with TRUNC(BIN). We had to
>create an Endevor type just for this program, as our migration procedure
>includes compiler options. That option tells the compiler to ignore CoBOL
>pictures in deciding the maximum value that is in a field.
>
>In this case, IDMS database keys are stored in:
>03 DBKEY PIC S9(8) COMP SYNC.
>
>But can contain values greater than 99999999. This program accepts either
>this key or a formatted display version of this and returns the other.

I wouldn't create an Endevor type for one program; I'd put the option
on the first line of the program, with a prominent comment. Or I'd do
it with redefines, like this:

linkage section.
01 binary-parm pic x(04).
01 display-parm pic 9(10).

working-storage section.
01 binary-64 comp pic 9(10) value zero.
01 redefines binary-64.
05 filler pic x(04).
05 binary-32 pic x(04).

procedure division.
if binary-parm not equal to low-values
move binary-parm to binary-32
move binary-64 to display-parm
else
move display-parm to binary-64
move binary-32 to binary-parm
end-if
goback.

But no amount of programming will make a number larger than 64K fit
into 16 bits, which was the original question.

Howard Brazee

2004-12-30, 3:55 pm

On 30-Dec-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:

> I wouldn't create an Endevor type for one program; I'd put the option
> on the first line of the program, with a prominent comment. Or I'd do
> it with redefines, like this:

Tried it. Our Endevor ignores it. I don't know whether that is a shop setup
or not.

The program uses redefines:
01 PASSED-DBCONV-RECORD.
02 PASSED-DBCONV-DISPLAY-DBKEY.
03 PASSED-DBCONV-PAGE PIC X(08).
03 PASSED-DBCONV-PAGE-N REDEFINES PASSED-DBCONV-PAGE

PIC 9(08).
03 PASSED-DBCONV-DASH PIC X(01).
03 PASSED-DBCONV-POS PIC X(03).
03 PASSED-DBCONV-POS-N REDEFINES PASSED-DBCONV-POS

PIC 9(03).
02 PASSED-DBCONV-X.
03 FILLER PIC X(4).
03 PASSED-DBCONV-DBKEY PIC S9(08) COMP.

Robert Wagner

2004-12-30, 3:55 pm

On Thu, 30 Dec 2004 18:07:35 GMT, "Howard Brazee" <howard@brazee.net>
wrote:

>
>On 30-Dec-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:
>
>
>Tried it. Our Endevor ignores it. I don't know whether that is a shop setup
>or not.
>
>The program uses redefines:

You still need the compiler option because the redefines don't
accomplish what you're trying to do. The following would eliminate the
need for a compiler option:

01 PASSED-DBCONV-RECORD.
02 PASSED-DBCONV-DISPLAY-DBKEY.
03 PASSED-DBCONV-PAGE.
04 PASSED-DBCONV-PAGE-N PIC 9(08).
* Shouldn't the above be 9(10)?
03 PASSED-DBCONV-DASH PIC X(01).
03 PASSED-DBCONV-POS.
04 PASSED-DBCONV-POS-N PIC 9(03).
02 PASSED-DBCONV-X.
03 FILLER PIC X(4).
03 PASSED-DBCONV-DBKEY PIC S9(08) COMP.
02 PASSED-DBCONV-BIG REDEFINES PASSED-DBCONV-X
COMP PIC 9(10).
* The last two lines eliminate the need for TRUNC(BIN)

Arnold Trembley

2005-01-01, 8:55 am

Howard Brazee wrote:
> On 30-Dec-2004, Robert Wagner <spamblocker-robert@wagner.net> wrote:
>
>
>
>
> Tried it. Our Endevor ignores it. I don't know whether that is a shop setup
> or not.
> (snip)

I think this is the way your shop has Endevor configured. All our
source and object code is managed by Endevor and I am able to use
PROCESS and CBL directives in my source code. I can store compile
options in the source program.

Our Endevor processors for COBOL specify the version of COBOL to use
(although we are removing Endevor processors for OS/VS COBOL and VS
COBOL II, since they are no longer supported), then whether the
program is batch or CICS, then whether the program uses DB2, then some
specialized codes for copybook search paths.

We used to have specialized COBOL processors for products that
required statically linked Vendor code, such as H&W SYSB-II,
CA-Interlink TCP/IP support, and IBM Crypto, but the Endevor
administrators seem to have solved that problem.

So we have a very specialized naming convention for our Endevor COBOL
processors:

CO3B Compile Enterprise COBOL, batch
CO3C Compile Enterprise COBOL, CICS
CO3BD Compile Enterprise COBOL, batch with DB2
CO3CD Compile Enterprise COBOL, CICS with DB2
CO3CNNNP Compile Enterprise COBOL, CICS, with only production level
copybooks
CO2B Compile COBOL II, batch (obsolete now)

My biggest gripe with Endevor is that now we use parallel development,
so that a single program may be in several different stages of
development for multiple releases. It's a nightmare to intervene for
a production fix, jump over all the in-flight versions to install into
PROD, and then retrofit the fixes to the release level projects. It's
complicated enough that sometimes we avoid applying production fixes
because the source code is locked down for a release implementation
that is several w

s away.

But we also manage the compile listings with Endevor and SAR, and we
no longer retain hardcopies because we can reprint them anytime.

Our Endevor is also configured with several different environments,
and we only compile into the earliest environment and stage, and then
migrate the executable to each following stage. It is possible to
configure Endevor so that the program will be automatically recompiled
as it is migrated to each successive stage, development,
certification, PROD. Of course, the Endevor MOVE processors must
correctly handle DB2 binds for each environment, but that setup seems
to work fairly well.

YMMV, IANAL, and all sorts of other disclaimers may apply.

With kindest regards,

--
http://arnold.trembley.home.att.net/

Robert Wagner

2005-01-01, 3:55 pm

On Sat, 01 Jan 2005 08:50:57 GMT, Arnold Trembley
<arnold.trembley@worldnet.att.net> wrote:

>

>Our Endevor is also configured with several different environments,
>and we only compile into the earliest environment and stage, and then
>migrate the executable to each following stage. It is possible to
>configure Endevor so that the program will be automatically recompiled
> as it is migrated to each successive stage, development,
>certification, PROD.

I was assigned to write a one-time program that absolutely HAD to run
that night. I compiled it in Test (with no special options) and tested
it there. I even snuck into production, copied the executable and ran
it against production data to make sure it would work.

That night they promoted it to Prod with Endevor and recompiled it
with different options. When executed, it abended. I was the bad guy.

It escapes me why shops recompile tested code.

Binyamin Dissen

2005-01-01, 3:55 pm

On Sat, 01 Jan 2005 16:39:03 GMT Robert Wagner <spamblocker-robert@wagner.net>
wrote:

:>On Sat, 01 Jan 2005 08:50:57 GMT, Arnold Trembley
:><arnold.trembley@worldnet.att.net> wrote:

:>>Our Endevor is also configured with several different environments,
:>>and we only compile into the earliest environment and stage, and then
:>>migrate the executable to each following stage. It is possible to
:>>configure Endevor so that the program will be automatically recompiled
:>> as it is migrated to each successive stage, development,
:>>certification, PROD.

:>I was assigned to write a one-time program that absolutely HAD to run
:>that night. I compiled it in Test (with no special options) and tested
:>it there. I even snuck into production, copied the executable and ran
:>it against production data to make sure it would work.

:>That night they promoted it to Prod with Endevor and recompiled it
:>with different options. When executed, it abended. I was the bad guy.

:>It escapes me why shops recompile tested code.

To verify that all parts of the module were promoted.

To verify all source pieces exist.

Also, you should be aware that test mode might mask some errors, since more
storage is used.

--
Binyamin Dissen <bdissen@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

rjones0@hotmail.com

2005-01-01, 3:55 pm

Howard Brazee

2005-01-03, 3:55 pm

Wiggy

2005-01-03, 8:55 pm

Chris,

Are you running at the latest patch level from Oracle? You can search
for, and download, patches, via http://metalink.oracle.com (access
requires a valid maintenance contract, I believe).

SimonT.

Howard Brazee

2005-01-04, 3:55 pm

On 1-Jan-2005, Robert Wagner <spamblocker-robert@wagner.net> wrote:

>
> I was assigned to write a one-time program that absolutely HAD to run
> that night. I compiled it in Test (with no special options) and tested
> it there. I even snuck into production, copied the executable and ran
> it against production data to make sure it would work.
>
> That night they promoted it to Prod with Endevor and recompiled it
> with different options. When executed, it abended. I was the bad guy.
>
> It escapes me why shops recompile tested code.

Theory is: They want it to work even when some maintenance programmer has to
make some little change in the middle of the night. So it's an excellent idea
to compile into STG1TEST using Endevor (I hate brand names that misspell words),
guaranteeing that your last test uses the same options as some future
maintenance programmer will have.

Howard Brazee

2005-01-06, 8:55 am

Chris

2005-01-06, 3:55 pm

All:

Many thanks for the replies to this post. I too was under the
impression that a PIC S9(4) COMP would be able to hold a value larger
than 9999, but that is not the case (at least not on our system). If I
try to move anything larger than 9999 to the -LEN variable, it
truncates to the last four digits of the number being moved (i.e. 10000
becomes 0, 10001 becomes 1 ).

The solution Mr. Wagner proposed has given me the ability to resolve my
issue. I did have to make two minor changes though. This variable, can
be used to insert values into a CLOB column successfully. Of course, as
the size of the field becomes larger and larger, it may be more prudent
to use Mr. Wagner's alternative SQL-CLOB variable type and its
associated commands, but for now - this works nicely.

01 LogBuffer.
02 LogBuffer-LEN PIC S9(9) COMP.
02 LogBuffer-ARR PIC X(262146).
EXEC SQL VAR LogBuffer is LONG VARCHAR (242146) END-EXEC.
Again - thanks to all.

Chris

Wiggy

2005-01-06, 8:55 pm

Binyamin Dissen

2005-01-07, 3:55 pm

Sponsored Links