Pro*COBOL and CLOB Columns

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 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++++                                            ~
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

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

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.

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.

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 t
o
>create an Endevor type just for this program, as our migration procedure
>includes compiler options.    That option tells the compiler to ignore CoBO
L
>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 eithe
r
>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.

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 se
tup
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.

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 s
etup
>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)

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 ws 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/


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.