SQLBEX CALL in a COBOL program with imbedded sql

[nagojohn]

Hey all,
I have a batch cobol program with embedded sql that blows on the call to
SQLBEX, the last subroutine call of Oracle code brought in by the
precompiler to execute embedded sql calls/procs.

SQLBEX is a subroutine that is linked in by the Oracle precompiler.

I get the following error
"114 Attempt to access item beyond bounds of memory"

Anyone have and idea what could be the problem

Oracle 8.1.7
Microfocus 4.1
Unixware 7.1.1

This started happening as soon as I upgraded to Oracle 8i from
Oracle 7.3.

I have recreated my RTS with the new Oracle 8i make files and pretty
sure it worked correctly. (well an RTS was made :) )

My opinion is either the libclntsh.so file (been told this is the entry
point for SQLBEX subroutine) in the $ORACLE_HOME/lib directory is
corrupt or not linked in correctly.

Any help would be much appreciated, this is a show stopper for our
upgrade to Oracle 8i.

Any ideas???

--
Posted via http://dbforums.com

[Robert Wagner]

Which program is causing the 114, yours or SQLBEX? It tells you on line before
the error message.

If the answer is SQLBEX, are you SURE libclntsh.so is coming from the correct
directory? Do a 'which' to find out.

You said "linked in by the Oracle precompiler." You didn't statically link it,
did you? Shared objects are called dynamically.

---- history below ---------------

[Simon Tobias]

Hi.

There are known problems with Oracle on Intel-order platforms, in that the
byte ordering of the data items generated by Pro*COBOL don't necessarily
match what's expected by Oracle, which can lead to RTS114s. I strongly
suspect that this is the cause of your issue.

If you have Oracle maintenance, then check out articles 478.1 and 70245.1
under the Oracle Metalink site (http://metalink.oracle.com), which provides
the history behind these issues.

Basically, they provide a comp5 option to procob, which forces the
data-items to be generated as USAGE COMP-5, rather than USAGE COMP. See the
Oracle docs for more information on this option. If you've specified this
option, you must ensure that all parameters passed to Oracle APIs -- e.g.
SQLBEX -- are defined as USAGE COMP-5.

If you're compiling with the Micro Focus cobsql directive -- which will
precompile and compile in a single step -- then you need to ensure that the
cobsql directive MAKESYN -- which can translate host variables into
COMP/COMP-5 items -- is set to an option which will work alongside the
Pro*COBOL comp5 directive. Apologies for the formatting of this :

Oracle comp5 Cobsql makesyn Result

Comp5=no NOMAKESYN will not work

Comp5=yes NOMAKESYN will work

Comp5=no MAKESYN will work

Comp5=yes MAKESYN will work

Comp5=no not specified will work

Comp5=yes not specified will work

Comp5=no Not Used will not work (1)

Comp5=yes Not Used will work

Notes
Not Used : cobsql not used ; procob then separate compile
1: must use compiler directive (MAKESYN "COMP-5" = "COMP") to make this
work.

Simon.

[Richard]

rob...@wagner.net (Robert Wagner) wrote

> are you SURE libclntsh.so is coming from the correct
> directory? Do a 'which' to find out.

'which' only looks down the PATH while .so files are found on
LD_LIBRARY_PATH (or other), so it is unlikely that a 'which' will find
the library, and if it does or not this will not indicate anything
useful.

[nagojohn]

Simon,

Thanks for you help we figured it out with all of the articles you told
us to lookup. In nutshell we need to add the following lines to the
pcccob.cfg (which was empty) file in $ORACLE_HOME/precomp/admin.

comp5=yes
define=comp5

That got rid of the error I was getting.

Thanks again for your help!

John