BTW:
when we installed the tool in the mid 90s, IIRC,
and when we defined the first rule set for our DB2 programs
(I was in charge then to define the rules together with the DB2 admins,
because I started in 1992 to do the DB2 classes for our DB2 developers),
we then did a first check on all the present DB2 code base.
We observed that ca. 50 % of the DB2 programs had violations
regarding our (new) coding standards, and we then spent some time
to repair that.
Over time, when this Q/A tool was in effect, things got much better.
I believe, this was a great success and helped us much to improve
the overall quality of DB2 coding and the skills of our application people
(together with the DB2 classes, of course).
Kind regards
Bernd
Am 10.01.2015 um 14:40 schrieb Bernd Oppolzer:
Am 10.01.2015 um 13:58 schrieb Scott Chapman:
On Sat, 10 Jan 2015 01:44:35 +0100, Bernd Oppolzer
<bernd.oppol...@t-online.de> wrote:
It is normal practice at the shops I work to do EXPLAIN regularly on
all
programs that go into production and to store the PLAN TABLE results
for later trouble shooting ... if there is trouble. The developers at
our sites
Probably 20 years ago one of our DBAs added a step to the migration
process that checked the plan table in the QA environment, looking
for certain obvious problems. For example a tablespace scan on a
table larger than x. Such packages were flagged and migration to
production halted, IIRC. It didn't catch everything, but it was helpful.
Scott
This is what is done at our site(s), too,
but we have a vendor tool for this, written in COBOL.
There is one problem from that what you describe ...
I think there was a discussion related to that some days
ago on this forum:
for batch programs, a table space scan on large tables may well be
the best access strategy, if the related SQL is the overall cursor
controlling
the batch program, and if large portions of the table is used. So you
have to
do at least two things, IMO:
a) the programmer has to tell if the program that goes into production is
a dialog program or a batch program, so that when doing the performance
checks or controls, the appropriate rule set can be used, and
b) you have to build an exception table, where you can speficy critical
programs or modules that are allowed to pass the checks and controls,
although they violate the site specific performance rules.
Furthermore:
we decided from some experiences, not to stop the transfer to
production (maybe it is an emergency program fix, done in the night
etc.),
but to send an email to the programmer, the manager and the DBAs
and transfer to program, anyway. This worked much better for us.
HTH,
kind regards
Bernd
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
