From: credondo on
Hi Guys,
I'm working on a .net project (C#) and my database is a DB2 iSeries
Server. Basically, we have a set of Stored Procedures that are
consumed from the Data Layer using .Net DB2 Provider (V5R4). DBA is
reporting a unusual high CPU utilization from a job signed with my DB2
user (same user I use within the dB2 connection string), but nobody in
the system is reporting performance issues neither frozen app. I
worked with the DBA and we noticed that at the beginning of the day
the server reports some jobs created with my app db user, but all jobs
are in TimeWait status with 0% of CPU usage (which is normal and
expected). Do you know how .Net Provider should behave with jobs on
DB2? Could a job on DB2 server attend more than one request at the
same time?

Thanks.
From: Karl Hanson on
credondo wrote:
> Hi Guys,
> I'm working on a .net project (C#) and my database is a DB2 iSeries
> Server. Basically, we have a set of Stored Procedures that are
> consumed from the Data Layer using .Net DB2 Provider (V5R4). DBA is
> reporting a unusual high CPU utilization from a job signed with my DB2
> user (same user I use within the dB2 connection string), but nobody in
> the system is reporting performance issues neither frozen app. I
> worked with the DBA and we noticed that at the beginning of the day
> the server reports some jobs created with my app db user, but all jobs
> are in TimeWait status with 0% of CPU usage (which is normal and
> expected). Do you know how .Net Provider should behave with jobs on
> DB2? Could a job on DB2 server attend more than one request at the
> same time?
>
> Thanks.

The following is some info from a System i .NET expert (not me) that may
be helpful:

When you use the Access for Windows .NET Provider to connect to your IBM
i, the .NET provider connects to server jobs called QZDASOINIT (or
QZDASSINIT if using SSL encryption). Those jobs run under your user id.
Depending on how you are using your .NET provider connections, you may
have one or more of these server jobs running. By default, .NET
provider connections are 'pooled', meaning that when you .Close() a
connection, the server job stays active, the connection gets placed into
a pool, and the next .Open request that uses the exact same
ConnectionString will pick up the connection out of the pool.

If you have many server jobs running, it's possible one of the following
may be happening:
- You never call Close() on the connection object, so each new call to
Open() causes a new server job to be created.
- You are using the MinimumPoolSize property in your ConnectionString.
This causes a 'minimum' number of pooled connections to be created at
the time the first connection is opened, and they will sit idle until a
new connection Open request comes in.

Without knowing more information about your scenario, it is hard to say
for sure what's going on. For future questions about this .NET
provider, please use the "DB2 for i" forum located here:
http://www.ibm.com/developerworks/forums/forum.jspa?forumID=292

--
Karl Hanson