DB2 modules DSNHLI and DSNHADDR
Stewart S Smith GBSLAC ISD DevDBA 51216
batch jobs. It seems to revolve around the exessive loading of DB2 modules as
detailed below by our Performance Manager Sys Prog.
We are running OS/390 2.5 and DB2 v4.1. The job is running using the TSO
terminal monitor program IKJEFT1B. Anything to do with the Language
Environment, possibly.
Stewart S Smith
Date: 6 May 1999
To: Stewart S Smith GBSLAC ISD DevDBA 51216
From: Bruce Morgan GBSLAC ISSD Performance Mgt
Subject: MLINDP50 - Strobe results
I Strobed PSTEP030 of the above job last night.
The job is very CPU bound, 50% of the time is spent using CPU resource. Of the
50% the break down is as follows;
SVC 8 - Program Load 42%
SVC 18 - BLDL 19%
SVC 83 - SMF 13%
Everything else 26%
74% of the CPU of this job is spent looking for modules, loading them and
telling SMF all about it.
An analysis of PDS Man records shows the following for this job;
DSNHADDR and DSNHLI loaded 482,963 times EACH!
The job has a steplib (CIB1.CNPR4ZBX.LOADLIB). A Steplib must be searched
before any other library including the linklist. So this library was searched
about 1 MILLION times for these modules. (Actually, it was only searched once
because we have Dynamic BLDL switched on for this library which basically says
"This module is not here - go away" - but there is still an overhead).
Someone needs to look at why these modules are being continually (re)loaded,
any idea who?
Bruce Morgan
Performance Analyst
CC: Terry Weston GBSLAC Bank. Serv. x20756
Alan Wright GBSLAC IS Appl Maint 54561
Derek J Ireland GBSLAC IS Banking x20760
The Standard Life Assurance Company* is a mutual company registered in
Scotland (no SZ4) Head Office:Standard Life House, 30 Lothian Road,
Edinburgh EH1 2DH. Tel (0131) 225 2552.
Standard Life may record and monitor telephone calls to help improve
customer service.
The Standard Life group includes Standard Life Pensions Funds Limited*#
Standard Life Trust Management Limited*# Standard Life Investments
(Mutual Funds) Limited*#
This e-mail is confidential, may be covered by legal professional
privilege and is intended for the addressee(s) only. If you are not the
intended recipient you are not authorised to and must not disclose,
copy, distribute or retain all or part of this e-mail without our
authority.
The Standard Life Assurance Company* will not be liable for direct,
indirect or consequential damages arising from alteration of content of
this message by a third party.
*Regulated by the Personal Investment Authority #Regulated by IMRO
Xuan...@gap.com
05/06/99 10:24 AM
If memory served, DSNHADDR is only generated by DB2/COBOL pre-compiler. It keeps
track of all SQL parameter lists. Even if you compiled and linked dynamically,
MVS should only search and load these modules once unless one specifically
release these modules. A possibility is if someone put cobol CANCEL statements
in their sub-routines.
--Xuan
Please respond to DB2 Data Base Discussion List <DB...@AMERICAN.EDU>
To: DB...@AMERICAN.EDU
cc: (bcc: Xuan Tran/SB/GAPINC)
Subject: Re: DB2 modules DSNHLI and DSNHADDR
This is all from memory, so it may be a bit vague....
DSNHLI is the routine that is called (first) when your program issues an
SQL statement. So EXEC SQL ....... END EXEC turns into CALL DSNHLI. So, I'm
thinking that maybe the program has been compiled/link-edited to resolve
the DSNHLI call dynamically. So, for EVERY SQL call, there is a load of the
DSNHLI module (from wherever). DSNHLI should really be statically linked
into your program and NOT loaded dynamically.
Check the load module to see whether it contains DSNHLI and try recompiling
it NODYNAM.
Phil Grainger
Director of DB2 Operations, Europe
PLATINUM technology
Stewart S Smith GBSLAC ISD DevDBA 51216 <GBSL...@IBMMAIL.COM> on 06/05/99
12:37:49
Please respond to DB2 Data Base Discussion List <DB...@AMERICAN.EDU>
To: DB...@AMERICAN.EDU
cc: (bcc: Phil J Grainger/Pti)
Subject: [DB2-L] DB2 modules DSNHLI and DSNHADDR
Gary Blair
Could your main program be ATTACHing a subtask repeatedly that executes SQL
and DETACHing? This may very well be the case if this is an ISPF
application. This would cause repeated loading of DB2 modules. Otherwise,
the DB2 modules are for the most part are rentrant and reuseable, so they
should only be loaded once per module.
Gary Blair
Softbase Systems