RE: UPS ODBC Gone Wild!

["Mackie, Roger L. (Precision Press)" <RLMackie@xxxxxxxxxxxxx>]

David,

We also have 3 UPS WorldShip stations. We saw something like this is when we
put the file we were trying to download in the same library as the rest of
the production data. We theorized that while starting editing/using an
import/export map, the software mapped every _field_ in the library on the
fly. When we gave the export file it's own library and specified it in the
DSN, the excruciating delays went away.

>From that experience, I suspect a library list problem. You might want to
check and see if the default library list differs between the people who
have problems and those who don't. It's simple I know, and you probably have
checked already, but it's the only thing I can think of.

HTH,
Roger Mackie

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of David Wright
Sent: Thursday, February 19, 2004 11:38
To: MIDRANGE-L@xxxxxxxxxxxx
Subject: UPS ODBC Gone Wild!

Hey All,

 

We use ODBC connections from the WorldShip program to our iSeries to
download addresses and upload tracking details.  It has been working fine
for a few years.

 

Yesterday, all three of our UPS systems were unable to download.  When we
attempt to edit the maps, it kicks off QZDASOINIT jobs on the iSeries that
run for 10-15 minutes...it appears they are calling a number of SQL
procedures, and they chew up huge amounts of memory.

 

Oddly enough, this only happens when connecting with certain user
names...others do absolutely nothing...no map, no error, no QZDASOINIT jobs.

 

Connections with same DSN are instantaneous through apps like Excel or
Access.

 

Anyone else seeing (ever seen) something like this?

 

Thanks!

David