RE: ODBC problem??? -- MIDRANGE-L

Can you isolate the OS/400 job and run a SQL trace on that through OpsNav?
That would tell you the SQL statements being executed by OS/400. Comparing
those statements against the Monk SQL scripts would be a start.

A question: what data type is this field? If it's float, that could be more
problematic than packed or zoned. Do other fields of the same data type
exhibit the problem?

Sorry I can't help further, we don't have SeeBeyond.

Loyd Goodbar
Senior programmer/analyst
BorgWarner
E/TS Water Valley
662-473-5713
-----Original Message-----
From: Steve Landess [mailto:sjl_abc@xxxxxxxxxxx] 
Sent: Wednesday, March 02, 2005 10:37
To: midrange-l@xxxxxxxxxxxx
Subject: ODBC problem???

I know that this is a long shot, but I need help in solving a problem in
very complex environment.

My client uses SeeBeyond EAI software (version 4.5.2)  to move data
between various systems.

The SeeBeyond server (running Windows 2003 server) uses scripts written in a
language called Monk, which uses IBM's V5R3 ODBC (v 10.00.02.00) driver
to fetch and update data from the i5 520, which is running i5/OS V5R3.

It is a very odd coincidence indeed that the problem I am writing about
appears to have begun occuring on the day that this brand new system began
operating in a production work environment after having been relocated from 
the
client's data center in Austin, Texas to an IBM Global Services facility in 
Chicago.

The Environment:
What happens is the the EAI script sends an SQL statement for execution by
the ODBC driver.  I'm fairly certain that there is some SeeBeyond middleware
in play here, and SeeBeyond is basically non-responsive in helping us solve
the many problems we have had with their software, not to mention the
company politics here!.

SeeBeyond is like the big pink elephant over in the corner -
everyone knows it is there, but nobody wants to acknowledge or
talk about it...

However, I digress.

The problem:
The result set that gets returned from a simple SQL select statement in the 
SeeBeyond
Monk script has a strange value in _one_ of the numeric fields - it is 
changed by
an order of magnitude!  I _know_ that this sounds really strange,
but I verified the raw data in the result set from the SeeBeyond log file
and confirmed that it was wrong.

It doesn't happen every time, and we haven't been able to replicate the 
problem
in our FAT testing environment - it only occurs on the production server, so

far.
This field is randomly being changed, and the value is always off by a 
factor of
10.

On numerous occasions a quantity of 1 became 10.
On several occasions, a quantity of 2 became 20.
On several occasions, a quantity of 3 became 30.

On one highly visible occasion, a quantity of 5 became 50, and it caught
notice because it would have been a $ 225,000.00 sales error!  If it hadn't
been caught and fixed by someone, we would have shipped 50 Dell servers
to the customer instead of 5...

It could very well be that a SeeBeyond component that is handling the ODBC
stuff is modifying the result set before it gets handed off to the script,
but at the present time, without some very technical assistance from 
SeeBeyond,
I'm at a loss to explain the cause of the problem.

(Did I say that SeeBeyond has been very difficult to deal with in solving 
our
technical problems???).

Any thoughts on a methodology to resolve this problem?
Are there any known issues with IBM's ODBC driver?
Anybody else out there using SeeBeyond?

I tried playing around with ODBC trace and logging, and have found
that this can bring the client PC to its knees when turned on.
(Not to mention that it also crashed on me...)
I'm fairly certain that I wouldn't be allowed to do any ODBC tracing
on the production SeeBeyond server...

Regards,
Steve Landess
Austin, Texas
(512) 423-0935