(replying on midrange-L as the question as nothing to do with RPG)
Given that you're using the IBMDA400 provider....you're not using
ODBC...you're using OLEDB :)
I usually use the IBMDASQL provider, but can't say that it offers
performance advantages over IBMDA400. Assuming that you don't need RLA or
access to data queues, programs or commands, you could switch providers and
see if that makes a difference.
However, you're real issue is probably work management and/or index
related...
- By default, QZDASOINIT runs at a priority of 20 just like interactive
green screens. Which is fine if your OLEDB apps are green
screen equivalents like order entry or CRUD. Not so good, if your OLEDB
apps are BI, data extracting, or other data heavy (aka batch) apps.
- By default, QZDASOINIT jobs all run in the QUSRWRK subsystem. Fine if
you've just got a couple, but the lack of control is a problem when you get
lots of different apps.
You can move QZDASOINIT jobs to user defined subsystem(s)...and adjust the
run-time attributes of those jobs appropriately. I'd suggest at least two
subsystems, one "interactive" and one "batch". From that point you can
work with memory allocation, max active, and every other piece of IBM i
work management functionality. Here's a good article about how to set up
a separate subsystem...
http://www.centerfieldtechnology.com/PDFs/August-2005-Newsletter.PDF
Now you can start digging into SQL performance tuning...lots of tools and
articles for that. Here's a place to start (though a bit dated):
http://www.redbooks.ibm.com/abstracts/sg247326.html
Have fun!
Charles
On Mon, Dec 17, 2012 at 3:08 PM, Brian Piotrowski <
bpiotrowski@xxxxxxxxxxxxxxx> wrote:
adoCon.Open "Provider=IBMDA400.DataSource
midrange.com
