Prev: mainframe material
Next: oracle10g SQLBEX giving 114 with Oracle Dynamic SQL Method 4 (ora9 works well)
From: bine on 24 Jan 2008 04:00
Our Application uses (in one context) Oracle Dynamic SQL Method 4
(plus 3 and 2 as well) and that fails on AIX5.3-64bit with oracle
10.2.0.1 or 10.2.0.3 (and MF-ServerExpress 4) whereas 9.2.0.4 (with
ServerExpress 2.2) worked well.
The same goes for 10.2.0.3.0 on Linux SLES9 and ServerExpress 5,
whereas the older UnitedLinux with oracle 9.2.0.4 and ServerExpress4
worked well.

We get
Execution error : file '/v3/v3f4/hubrig/Amain90/temp/114-TK/5-ALOEXMPL/
metalink/10.2.0.1.0/ALOEXMPL.gnt'
error code: 114, pc=0, call=1, seg=0
114 Attempt to access item beyond bounds of memory (Signal 11)

and after debugging (or due to the messages of DISPLAYS in that
testexample program) are sure that it is that special SQLBEX in that
context that fails with oracle10g.

Of course I will create an SR in oracle metalink today, but if anybody
has made some experiences in that context I'd appreciate the answers
here as well.

Thank you for reading,
bine
From: bine on 24 Jan 2008 07:29
correction:
that part
> The same goes for 10.2.0.3.0 on Linux SLES9 and ServerExpress 5, whereas the older UnitedLinux with oracle 9.2.0.4 and ServerExpress4 worked well.

should also read
.... oracle 9.2.0.4.0 and ServerExpress2.2
of course.

We run oracle 9 with MFSx2.2 on AIX and Linux
and oracle10 with MFSx4 (on AIX) or 5 (on SLES9)
and those ora10-versions fail

Sorry,
bine
From: bine on 24 Jan 2008 09:16
On 24 Jan., 14:53, Robert <n...(a)e.mail> wrote:
> On Thu, 24 Jan 2008 01:00:42 -0800 (PST), bine <sabine.hubrig-schaumb...(a)sungard.de>
> wrote:
>
>
>
>
>
> >Our Application uses (in one context) Oracle Dynamic SQL Method 4
> >(plus 3 and 2 as well) and that fails on AIX5.3-64bit with oracle
> >10.2.0.1 or 10.2.0.3 (and MF-ServerExpress 4) whereas 9.2.0.4 (with
> >ServerExpress 2.2) worked well.
> >The same goes for 10.2.0.3.0 on Linux SLES9 and ServerExpress 5,
> >whereas the older UnitedLinux with oracle 9.2.0.4 and ServerExpress4
> >worked well.
>
> >We get
> >Execution error : file '/v3/v3f4/hubrig/Amain90/temp/114-TK/5-ALOEXMPL/
> >metalink/10.2.0.1.0/ALOEXMPL.gnt'
> >error code: 114, pc=0, call=1, seg=0
> >114     Attempt to access item beyond bounds of memory (Signal 11)
>
> >and after debugging (or due to the messages of DISPLAYS in that
> >testexample program) are sure that it is that special SQLBEX in that
> >context that fails with oracle10g.
>
> >Of course I will create an SR in oracle metalink today, but if anybody
> >has made some experiences in that context I'd appreciate the answers
> >here as well.
>
> SQLBEX means you are using Pro*Cobol, which is buggy and poorly supported by Oracle.
> Your best solution is to abandon Pro*Cobol , switch to OpenESQL.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

thank you SO much for that suggestion, I will do that tomorrow and
report yesterday how it worked ... ;-(
I'm talking about 350 *COB and 1277 *CPY with about 1700000 lines of
code and a productive (and big) customer with a test team that wants
to evaluate every update so that won't work for the next months.
From: Sergey Kashyrin on 24 Jan 2008 16:50
Hi,

If you will provide a short test program it would be easier to tell
something.

For sure Pro*Cobol might be buggy, and it is buggy and not installed by
default on Win-64 (both ia64 and x64) and IA-64 HPUX by default.
For Win x64 I had to patch Cobol program after preprocessor this way (sed):
s/02 SQL-SQLVSN PIC S9(18)/02 SQL-SQLVSN PIC S9(9)/
/02 SQL-DUMMY/d
s/02 SQL-SQHSTL PIC S9(18)/02 SQL-SQHSTL PIC S9(9)/
s/02 SQL-SQHSTS PIC S9(18)/02 SQL-SQHSTS PIC S9(9)/
s/02 SQL-SQINDS PIC S9(18)/02 SQL-SQINDS PIC S9(9)/
s/02 SQL-SQHARM PIC S9(18)/02 SQL-SQHARM PIC S9(9)/

Seems to work after that.
On AIX 5.3 64-bit I didn't have any problems so far but I'm using OpenCobol
and not MF, so I suspect it might be MF issue as well.

Regards,
Sergey


"bine" <sabine.hubrig-schaumburg(a)sungard.de> wrote in message
news:59df0452-ccf1-42d8-8835-8eeb07b5280e(a)v4g2000hsf.googlegroups.com...
> Our Application uses (in one context) Oracle Dynamic SQL Method 4
> (plus 3 and 2 as well) and that fails on AIX5.3-64bit with oracle
> 10.2.0.1 or 10.2.0.3 (and MF-ServerExpress 4) whereas 9.2.0.4 (with
> ServerExpress 2.2) worked well.
> The same goes for 10.2.0.3.0 on Linux SLES9 and ServerExpress 5,
> whereas the older UnitedLinux with oracle 9.2.0.4 and ServerExpress4
> worked well.
>
> We get
> Execution error : file '/v3/v3f4/hubrig/Amain90/temp/114-TK/5-ALOEXMPL/
> metalink/10.2.0.1.0/ALOEXMPL.gnt'
> error code: 114, pc=0, call=1, seg=0
> 114 Attempt to access item beyond bounds of memory (Signal 11)
>
> and after debugging (or due to the messages of DISPLAYS in that
> testexample program) are sure that it is that special SQLBEX in that
> context that fails with oracle10g.
>
> Of course I will create an SR in oracle metalink today, but if anybody
> has made some experiences in that context I'd appreciate the answers
> here as well.
>
> Thank you for reading,
> bine


From: Robert on 25 Jan 2008 20:50
On Fri, 25 Jan 2008 16:54:49 -0700, "Frank Swarbrick" <Frank.Swarbrick(a)efirstbank.com>
wrote:

>>>> On 1/24/2008 at 6:53 AM, in message
><ou5hp3pv634r7l7ucevb7sllf76lr05391(a)4ax.com>, Robert<no(a)e.mail> wrote:
>>
>> SQLBEX means you are using Pro*Cobol, which is buggy and poorly
>> supported by Oracle.
>> Your best solution is to abandon Pro*Cobol , switch to OpenESQL.
>
>Is OpenESQL a Micro Focus product?

Yes, and well supported by Micro Focus. The Open in its name is a misnomer, it's not open
source.

> Does it work with non-Micro Focus COBOL compilers?

No.
 |  Next  |  Last
Pages: 1 2
Prev: mainframe material
Next: oracle10g SQLBEX giving 114 with Oracle Dynamic SQL Method 4 (ora9 works well)