DSNALI Interface consuming too much CPU time

Bernd Oppolzer

DSNALI Interface consuming too much CPU time
Hello DB2 list,

we observed the DB2 interface DSNALI consuming 5 percent CPU of a
batch job involving MQ, IMS etc. (measured by Strobe).

Under similar circumstances the DB2 interface for IMS (called DFSLI000)
had a CPU usage of 0,1 percent and below.

We are quite sure that the CPU is indeed used inside the DSNALI CSECT.

Some examination showed that DSNALI dynamically LOADs the modules
DSNACAB and DSNACAF, normally only once. The information, if the
modules are already loaded or still have to be loaded, is stored at some
place
in the PSA - at least some PSA location is first read to locate this
information.

My idea is: at our installation, maybe, we do something wrong, so that
the LOAD
of these modules is executed on every call, and so this CPU comsumption
could
be explained. For example: we don't link the DSNALI interface
via alias DSNHLI to our batch programs. Instead of doing this, we link
a home grown DSNHLI, which examines the environment and then calls
a module (linked RENT, dynamically loaded once), which has DSNALI linked
to it.

I don't yet understand what may be the problem. My next steps will be:
find out, how often the LOAD is executed and if this is really the problem.

Any suggestions?

Kind regards

Bernd

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-content/index.html has THOUSANDS of free technical presentations!
DB2 LUW, DB2 z/OS, Performance, Installation, Tuning, Coding, BI, Warehouses, - among
many more categories of help waiting for you!
Whether you are an old hand or a DB2 newbie, we have presentations for every level.
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

M. Khalid Khan

Re: DSNALI Interface consuming too much CPU time
(in response to Bernd Oppolzer)
Do you get two phase commit between the resources involved (DB2, IMS, MQ)
using DSNALI ? IIRC the answer is no in which case I'd be more concerned
about data inegrity than about 4.9% extra cpu. Or this is some special
case where you don't care about proper commits/rollbacks ?

Khalid





Bernd Oppolzer <[login to unmask email]>
Sent by: IDUG DB2-L <[login to unmask email]>
02/01/2010 01:12 PM
Please respond to
IDUG DB2-L <[login to unmask email]>


To
[login to unmask email]
cc

Subject
[DB2-L] DSNALI Interface consuming too much CPU time






Hello DB2 list,

we observed the DB2 interface DSNALI consuming 5 percent CPU of a
batch job involving MQ, IMS etc. (measured by Strobe).

Under similar circumstances the DB2 interface for IMS (called DFSLI000)
had a CPU usage of 0,1 percent and below.

We are quite sure that the CPU is indeed used inside the DSNALI CSECT.

Some examination showed that DSNALI dynamically LOADs the modules
DSNACAB and DSNACAF, normally only once. The information, if the
modules are already loaded or still have to be loaded, is stored at some
place
in the PSA - at least some PSA location is first read to locate this
information.

My idea is: at our installation, maybe, we do something wrong, so that
the LOAD
of these modules is executed on every call, and so this CPU comsumption
could
be explained. For example: we don't link the DSNALI interface
via alias DSNHLI to our batch programs. Instead of doing this, we link
a home grown DSNHLI, which examines the environment and then calls
a module (linked RENT, dynamically loaded once), which has DSNALI linked
to it.

I don't yet understand what may be the problem. My next steps will be:
find out, how often the LOAD is executed and if this is really the
problem.

Any suggestions?

Kind regards

Bernd

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 *
http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-content/index.html has THOUSANDS of free technical
presentations!
DB2 LUW, DB2 z/OS, Performance, Installation, Tuning, Coding, BI,
Warehouses, - among
many more categories of help waiting for you!
Whether you are an old hand or a DB2 newbie, we have presentations for
every level.
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is
the home of IDUG's DB2-L



HCSC Company Disclaimer

The information contained in this communication is confidential, private,
proprietary, or otherwise privileged and is intended only for the use of
the addressee. Unauthorized use, disclosure, distribution or copying is
strictly prohibited and may be unlawful. If you have received this
communication in error, please notify the sender immediately at (312)
653-6000 in Illinois; (800)835-8699 in New Mexico; (918)560-3500 in
Oklahoma; or (972)766-6900 in Texas.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-content/index.html has THOUSANDS of free technical presentations!
DB2 LUW, DB2 z/OS, Performance, Installation, Tuning, Coding, BI, Warehouses, - among
many more categories of help waiting for you!
Whether you are an old hand or a DB2 newbie, we have presentations for every level.
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Bernd Oppolzer

Re: DSNALI Interface consuming too much CPU time
(in response to M. Khalid Khan)
There are indeed plans to migrate to RRS interface.
For the moment there is no problem, because this region is read-only.
The DB update regions are IMS and DB2, without MQ.

In the meantime I found the reason for the high CPU consumption.

The interface DSNALI chases the CDE chain to find out, if the modules
DSNACAB and DSNACAF are already loaded. This is done on every call
to DSNHLI (that is, DSNALI). This may be ok, if there is one batch program
and a very short CDE list. But our CDE list has thousands of modules.
This is
the problem.

Do you think that we will get IBM to fix this and give us an improved
version
of DSNALI, or will I have to tune it myself? I guess, little hope for a
global
solution. I'll try to fix it without changing DSNALI, but I'm still
looking for
a clever idea.

BTW: 4 percent CPU means hundreds of thousands of Euros per year for us.

Kind regards

Bernd



M. Khalid Khan schrieb:
>
> Do you get two phase commit between the resources involved (DB2, IMS,
> MQ) using DSNALI ? IIRC the answer is no in which case I'd be more
> concerned about data inegrity than about 4.9% extra cpu. Or this is
> some special case where you don't care about proper commits/rollbacks ?
>
> Khalid

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/db2-content/index.html has THOUSANDS of free technical presentations!
DB2 LUW, DB2 z/OS, Performance, Installation, Tuning, Coding, BI, Warehouses, - among
many more categories of help waiting for you!
Whether you are an old hand or a DB2 newbie, we have presentations for every level.
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

M. Khalid Khan

Re: DSNALI Interface consuming too much CPU time
(in response to Bernd Oppolzer)
I won't hold my breath for IBM providing a fix. They will probably
catagorize it as Working As Designed. How about doing a static link rather
than dynamic one and side stepping the problem ?

Khalid





Bernd Oppolzer <[login to unmask email]>
Sent by: IDUG DB2-L <[login to unmask email]>
02/01/2010 03:22 PM
Please respond to
IDUG DB2-L <[login to unmask email]>


To
[login to unmask email]
cc

Subject
Re: [DB2-L] DSNALI Interface consuming too much CPU time






There are indeed plans to migrate to RRS interface.
For the moment there is no problem, because this region is read-only.
The DB update regions are IMS and DB2, without MQ.

In the meantime I found the reason for the high CPU consumption.

The interface DSNALI chases the CDE chain to find out, if the modules
DSNACAB and DSNACAF are already loaded. This is done on every call
to DSNHLI (that is, DSNALI). This may be ok, if there is one batch program
and a very short CDE list. But our CDE list has thousands of modules.
This is
the problem.

Do you think that we will get IBM to fix this and give us an improved
version
of DSNALI, or will I have to tune it myself? I guess, little hope for a
global
solution. I'll try to fix it without changing DSNALI, but I'm still
looking for
a clever idea.

BTW: 4 percent CPU means hundreds of thousands of Euros per year for us.

Kind regards

Bernd



HCSC Company Disclaimer

The information contained in this communication is confidential, private,
proprietary, or otherwise privileged and is intended only for the use of
the addressee. Unauthorized use, disclosure, distribution or copying is
strictly prohibited and may be unlawful. If you have received this
communication in error, please notify the sender immediately at (312)
653-6000 in Illinois; (800)835-8699 in New Mexico; (918)560-3500 in
Oklahoma; or (972)766-6900 in Texas.

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/solutions-journal.html - home of the IDUG Solutions Journal
Technical atricles from world famous authors in DB2's most prestigious, peer reviewed
magazine now on-line!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L

Bernd Oppolzer

Re: DSNALI Interface consuming too much CPU time
(in response to M. Khalid Khan)
yes, but this is done inside DSNALI, and to fix it,
I would have to change DSNALI, and I don't (yet) believe that management
will
allow me to do so.

In fact, once changed, DSNALI should not be subject of
future changes during new DB2 releases, because it is supposed to be linked
to every batch program, and normally batch programs are not required to be
relinked on DB2 release changes.

This said, I only have the possibiliy to change DSNALI, because my clever
colleagues in 1990 decided NOT to link DSNALI to the batch programs
but to link a little stub called DSNHLI instead which determines the
environment
and calls the appropriate interface dynamically. If this was not the
case, we
would have to relink all our programs, if we decided to change DSNALI.

Kind regards

Bernd



M. Khalid Khan schrieb:
>
> I won't hold my breath for IBM providing a fix. They will probably
> catagorize it as Working As Designed. How about doing a static link
> rather than dynamic one and side stepping the problem ?
>
> Khalid
>

_____________________________________________________________________

* IDUG North America * Tampa, Florida, * May 10-14 2010 * http://IDUG.ORG/NA *
_____________________________________________________________________

http://www.idug.org/solutions-journal.html - home of the IDUG Solutions Journal
Technical atricles from world famous authors in DB2's most prestigious, peer reviewed
magazine now on-line!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's DB2-L