cancel
Showing results for 
Search instead for 
Did you mean: 

DBINT contains different result going from CentOS6 vs CentOS7

vmimmsiv
Discoverer
0 Kudos

I am using ASE_16. EBF22544_linux-x86-64bit.tar is what I have.

My C code is compiled with gcc compiler: gcc-4.4.7-18.el6.x86_64

[ Yes, I know they are old. Can't be helped just now. ]

In my database, I have a table (type_tbl) defined as follows:

type_a int

a_str varchar(15)

type_b int

b_str varchar(15)

Data in the type_tbl:

1 AA 1 X

2 BB 2 Y

3 CC 3 Z

I pull the this data via a stored procedure: dbcmd(dbproc, "exec get_type_data);

Then bind it:

DBINT type_a;

DBCHAR a_str;

DBINT type_b;

DBCHAR b_str;

while (dbresults(dbproc) != NO_MORE_RESULTS) {

dbbind(dbproc, 1, INTBIND, 0, (BYTE DBFAR *) & type_a);

dbbind(dbproc, 2, STRINGBIND, 0, (BYTE DBFAR *) a_str);

dbbind(dbproc, 3, INTBIND, 0, (BYTE DBFAR *) & type_b);

dbbind(dbproc, 4, STRINGBIND, 0, (BYTE DBFAR *) b_str);

This has all worked fine for many, many years until we moved the code from CentOS6 to CentOS7.

To print the data: printf("type_a: %ld a_str: %s type_b: %ld b_str: %s\n", type_a, a_str, type_b, b_str);

When I printf the data in CentOS6 I get:

type_a: 1 a_str: AA type_b: 1 b_str: X

type_a: 2 a_str: BB type_b: 2 b_str: Y

type_a: 3 a_str: CC type_b: 3 b_str: Z

Exactly as it should be and I expect! This is what I want.

But after compiling the same code and running it on CentOS7, my results are as follows:

type_a: 140733193388033 a_str: AA type_b: 1 b_str: X

type_a: 140733193388034 a_str: BB type_b: 2 b_str: Y

type_a: 140733193388035 a_str: CC type_b: 3 b_str: Z

I have figured out 140733193388033 in HEX is 7FFF00000001 and I'm getting 7FFF more than I should be. The question is why and what to do about it. Upgrade everything is the obvious first answer but if that was possible for me at this time I would have but it is not for the foreseeable future.

I have also figured out if I first set type_a = 0 I get the correct answer. And if I use "int" instead of DBINT that also gives the right result set. Not sure what side-effects this change could cause so I am trying to see if the root issue can be uncovered. Very thankful for any and all comments/suggestions.

V/R, vmimmsiv

Accepted Solutions (0)

Answers (2)

Answers (2)

c_baker
Employee
Employee

Did you change from 32-bit to 64-bit when you upgraded your Linux?

Yes, your ASE is old (released in 2014) but what is the version of SDK that you are using (isql -v)?

Chris.

vmimmsiv
Discoverer
0 Kudos

Hi Chris,

No - everything here is 64bit. I verified this - assuming 'uname -a' is sufficient to verify.

And isql -v returns the same for both:

SAP CTISQL Utility/16.0 PL02/P-EBF22570/DRV.16.0.00.02/Linux x86_64/Linux 2.6.18-128.e15 x86_64/BUILD1600-002/64bit/OPT/Fri Apr 11 17:19:50 2014