Oppolzer - Informatik / Blog

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 S.C.:
>> On Sat, 10 Jan 2015 01:44:35 +0100, Bernd Oppolzer
>> <bernd.oppolzer@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.
>>
>> S.
>
> 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 listserv@listserv.ua.edu with the message: INFO IBM-MAIN