Hi,

We are investigating the use of the 64 bits 12.5 ct-library.
During our tests, we ran into the following error (which did not occur
in our 32 bit applications):

Number: 21. State: 1. Severity: 20.
'WARNING - Fatal Error 4020 occurred at Sep 3 2003 1:58PM. Please
note the error and time, and contact a user with System Administrator
(SA) authorization.'

The conditions under which this occurred were a bit uncertain: stepping
in a debugger helped in some applications but not always, specifying
only tcp in the interfaces file (and not tli) got rid of some
irreproducible instances of the error, leaving still reproducible cases.

According to sybase docs error 4020 occurs when the receiving buffer of
the server is too small. As possible reasons they list:
1 application errors
2 corrupt packets being transmitted
3 incorrect network configuration

Since the aplications haven't changed (except for being compiled 64
bits) and the server is on the same machine as the client, all causes
don't seem applicable (apps run already without problems on OSF 64 bits).

Some data:
Server version 12.0.0.4 (32 bits) (two engines)
Ct library version 12.5 (64 bits)
Solaris 8

Thanks in advance for any help, insights, experiences and opinions.

Hans van Eck
Henk van der Wal

Henk van der Wal <none@noware.nl> wrote in
news:3F55F146.5020209@noware.nl:

> According to sybase docs error 4020 occurs when the receiving
> buffer of the server is too small. As possible reasons they list:
> 1 application errors
> 2 corrupt packets being transmitted
> 3 incorrect network configuration
>
> Since the aplications haven't changed (except for being compiled
> 64 bits) and the server is on the same machine as the client, all
> causes don't seem applicable (apps run already without problems on
> OSF 64 bits).

Hi Henk,

Since you're using 64-bits, the memory model is different than
32-bits. This means that your application has changed and it's very
possible that any bad pointers that weren't showing in 32-bit mode
are
now being uncovered.

I've had a situation similar to yours but it wasn't 32-bit to 64-bit
but instead using a DB Vendor's new API. It changed dramatically and
the headaches it caused were tremendous!

The port was relatively simple but the bugs in the existing code line
I hadn't counted on. They were tickled by moving to a different
memory model.
--
Pablo Sanchez, Blueoak Database Engineering
http://www.blueoakdb.com

Pablo Sanchez wrote:
> Henk van der Wal <none@noware.nl> wrote in
> news:3F55F146.5020209@noware.nl:
>
>
>>According to sybase docs error 4020 occurs when the receiving
>>buffer of the server is too small. As possible reasons they list:
>>1 application errors
>>2 corrupt packets being transmitted
>>3 incorrect network configuration
>>
>>Since the aplications haven't changed (except for being compiled
>>64 bits) and the server is on the same machine as the client, all
>>causes don't seem applicable (apps run already without problems on
>>OSF 64 bits).
> Since you're using 64-bits, the memory model is different than
> 32-bits. This means that your application has changed and it's very
> possible that any bad pointers that weren't showing in 32-bit mode
> are
> now being uncovered.

The applications already run on 64 bits Alpha so pointer problems are
not likely.
Furthermore, we use lint and Purify to check our sources.
What maybe of significance is that the problem occurs on the second call
of a stored procedure that returns an image field. After the first call,
ct_cancel is called (something we can see in a truss of the application).

Hans van Eck/Henk van der Wal

Try these:

1. Can you execute an insert using isql interface from your 64 bit client?
2. Do you have difference in charactersets or encodings on client that was
not on other 64 bit machine (Sybase 12.5 is more sensitive to i18n stuff
than 12.0).
3. Though this may not apply but if the connection has some pending result
set you will get errors (not this one though).

Can you share a small snippet of code where you think the problem occurs?
Maybe you are specifying the size of data based on 64 bit units instead of
32bit units. Unlikely but possible.

HTH,
-----------------------------------------------------------------
Amit Jindal, Development Engineer

Want ease of development or performance? Why not get both!
http://www.roguewave.com/products/sourcepro/db/

[Disclaimer: All views expressed here are my personal views and they can be
incorrect at times]
-----------------------------------------------------------------



"Henk van der Wal" <none@noware.nl> wrote in message
news:3F57441F.9010901@noware.nl...
> Pablo Sanchez wrote:
> > Henk van der Wal <none@noware.nl> wrote in
> > news:3F55F146.5020209@noware.nl:
> >
> >
> >>According to sybase docs error 4020 occurs when the receiving
> >>buffer of the server is too small. As possible reasons they list:
> >>1 application errors
> >>2 corrupt packets being transmitted
> >>3 incorrect network configuration
> >>
> >>Since the aplications haven't changed (except for being compiled
> >>64 bits) and the server is on the same machine as the client, all
> >>causes don't seem applicable (apps run already without problems on
> >>OSF 64 bits).
> > Since you're using 64-bits, the memory model is different than
> > 32-bits. This means that your application has changed and it's very
> > possible that any bad pointers that weren't showing in 32-bit mode
> > are
> > now being uncovered.
>
> The applications already run on 64 bits Alpha so pointer problems are
> not likely.
> Furthermore, we use lint and Purify to check our sources.
> What maybe of significance is that the problem occurs on the second call
> of a stored procedure that returns an image field. After the first call,
> ct_cancel is called (something we can see in a truss of the application).
>
> Hans van Eck/Henk van der Wal
>