Re: Batch Billing Performance.

[fkolmann@xxxxxxxxxxxxx]

Ata510@aol.com wrote:

> Using generic lists of access paths developed for someone else's system (and
> possibly release?) is not necessarily the best way to approach improving
> performance. You should look for real BMRs, to see first of all if SSA has
> found or changed anything, and then use something like DBMON or Centerfield
> Technologies tool to find and build access paths on a regular basis (such as
> after applying a cume or new set of BMRs).

If we are talking about 'just out of the box' generic SSA BPCS software then how
is
someone elses system different to your own.
At the 'base release level'  BPCS software must match across systems.

At a release level the set of lgl files required as determined by DBMON must be
consistent.

I cannot understand SSA's attitude that lgl files will be different from one
customer to the next.
I believe it is SSA's abrogation of responsibility that the lgl files are
missing.
I do not care that SSA are supporting HP and UNIX platforms and that lgl files
are not relevant
to these (so SSA say and I dont believe them), the lgls should exist in the 
first
place.

The argument that the SQL optimiser may not select the lgl suggested by DBMON is
irrelevent.
IBM may be at fault and the optimiser may not work but that is no reason for the
lgl files to not exist
and even if the optimiser decides that block arrival seq is the fastest method
for processing the SQL
that also is no excuse, you just got lucky that IBM has given you an alternate
method of processing the data
and in my experience IBMs optimiser is not much good at alternates, it should 
use
the lgl files properly in the first place.

Any internal modfications (SQL) should be controlled so that the programmer
clearly understands that along
with ANY SQL they MUST create the supporting LGLs and state this in no uncertain
terms, particularly to
hi faluting contractors that use the latest and greatest SQLs without ANY regard
to database performance.


> If it the program still doesn't work quickly enough, call it in to SSA as a
> performance problem because there are SQL constructions that can not be helped
> via an access path.

This means RIP OUT THE SQL and REPLACE with RPG code.!!!

> Also, be aware that such lists of access paths can become outdated, as BMRs 
>may
> change
> or remove the SQL that made the access path useful in the first place.

It surely again is SSA's responsibility to create or delete lgls associated with
any BMRs they implement.


> Be sure to test the paths one by one and if they do not seem to improve
> anything, or if you can not tell which statement they were built for -

This SSA should have done in the first place. Any internal mods must be
similiarly tested.
Usually it is just common sense, we are talking about a computer after all, if
you sort
or select using a particular key you should (MUST) construct the appropriate 
LGL,
there
was no other way before SQL and if you want to maintain good DB performance 
there
is
STILL no other may.

As for IBM's PTFs we can only pray.


+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---