RE: ole db/400 performance large file

The OLE operations are handled by a QZDASOINIT job in QUSRWRK. Make sure
your OLE developers aren't opening and closing the connection for each
record. There's lots of overhead in establishing the connection. Once
established, the records should go in very quickly, probably faster than
FTP. Rochester engineers spent a lot of resources making QZDASOINIT jobs
work very efficiently.

The QZDASOINIT job will be running under QUSER, but one of the first few
entries in the job log will tell you the user profile the OLE
programmers have used. I'll often look for locks on that profile object
and work back to the job from there.

Make sure you have the latest PTF's and are using the latest version of
the iSeries Access ODBC drivers and OLE classes.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Franz
Sent: Wednesday, January 13, 2010 7:49 PM
To: Midrange Systems Technical Discussion
Subject: Re: ole db/400 performance large file

No journalling needed. The file is processed, then cleared for the next
load.
The file on the System i is a regular dds created PF.
btw- there were a few older posts about this issue, one described as a
"bulk load", but no solution that I could see.
I can't seem to capture which server job is handling this request to see
if anything else going on.
jim franz

----- Original Message -----
From: "Dan Kimmel" <dkimmel@xxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Wednesday, January 13, 2010 6:44 PM
Subject: RE: ole db/400 performance large file

This should run very quickly if you have no index and no key

(uniqueness

constraint). Just make sure you have plenty of room on the box, both
memory and disk. How are you creating the file? An SQL create will
probably allocate more room, but it also will journal the file by
default. For this kind of operation, I'll usually create with SQL and
then delete the journal. If I need journaling, I'll start it after the
load.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Franz
Sent: Wednesday, January 13, 2010 4:29 PM
To: MIDRANGE-L@xxxxxxxxxxxx
Subject: ole db/400 performance large file

I've search the archives for this & not found a good answer.
One of the network programmers is using the iSeries Access V5R4 OLE DB
connection to move 500,000 records from a network server to the System

i

(v5r4). The native file has no logicals, and no key.
It is taking many minutes to load the first 10,000 and hours to load
500,000.
Local lan connection. Cannot see why so slow.
File not in use on either end. Not a huge record layout.
How can we speed this up. It needs to run on a regular basis (weekly

or

even daily).
We have considered ftp, but that server is off on the production

server.

Same OLE connection used for many applications, but those are

generally

random access, and no problems. Only the large file is a problem.
Verified the network side is accumulating the records very fast.
Jim Franz
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take

a

moment to review the archives at

http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.