Re: Invoice Billing Process

All of this sounds facinating if you've got time to anlayze every job in
the BPCS system or if you want to hire BPCS consultants on a full time
basis.  It's pretty sad that every time you apply a PTF on you system you
have to be overly concerned about creating performance issues within the
system..  Whatever happened to the days when a job ran the most efficient
it could without worrying about all of the outside factors.  I guess those
where the days when AS400 jobs were written in RPG or Cobol and not ASSET.
In the case of the billing process, I can't see how companies can run
billing that differently thus there should not be that many factors that
would impact the performance of the billing process.   I would think there
would be a base group of logicals or performance recommendations for this
job as with some others in the system.   I'm running about 800-1000
invoices in about 50 minutes.  Maybe that's good, maybe not.  I do remember
when this process ran in about 20-30 minutes but frankly I can't remember
the number of invoices that were being generated then.   My point to this
email, is none, other than I get tired of seeing all the '  if this or
maybe that, or this could be.... or whatever.  No one really knows how to
make this system perform all the time, its a constant effort to keep the
wheels on especially if you like to stay current with IBM updates, etc.



                    "Genyphyr
                    Novak"                To:     <bpcs-l@midrange.com>
                    <novakg@ssax.co       cc:
                    m>                    Subject:     Re: Invoice Billing 
Process
                    Sent by:
                    bpcs-l-admin@mi
                    drange.com


                    04/30/2002
                    06:01 PM
                    Please respond
                    to bpcs-l






Hello FWSoftware,

My point in the last posting I made was to mention that even in these cases
of using the DEBUG joblog messages, or analyzing the DBMON file to find out
what the optimizer recommends as logical files, there are going to be
certain SQL constructions for which the SQL optimizer cannot make a
recommendation to you or for which it won't make the most beneficial
recommendation. It makes recommendations out of need for something, rather
than to tell you the 'most optimal of all possible ways' to run a query.

In such cases, you need to use your (or someone you hire) knowledge of the
way the optimizer works to try to build a logical which it will use, and in
other cases you need to understand when it is necessary to re-write the SQL
(or to call SSA GT Support and make sure a BMR is entered so that SSA GT
corrects the SQL).

One simple example is that if a query would run faster with Index-Only
access (eliminates one extra read to the database, because the position-to
and read can be done from the same path) you will need to put all the
fields
retrieved by the SQL statement into the logical file yourself - the
optimizer won't tell you this.

You will have to realize when this might help performance in a particular
case and build for yourself a 'test' logical containing the extra fields
required in the SELECT on the query, and which do not assist whatsoever in
positioning to the records (loops with lots of FETCH statements are very
good places to try for index-only access). Then test the new logical, and
see if the query uses it and if it causes index only access to happen, and
of course, decide if it helps performance or not.

There are several other cases where the optimizer won't tell you every
single thing that could make the query run better/faster, and therefore you
need to understand many things in combination: the query, the system, the
QAQQINI file settings available, the types of processors you have on your
system and the way the SQL optimizer is working at your OS/400 release to
get the most performance out of your box. Or alternatively, hire a
consultant who does understand such things to come out and assist you in
tuning your system; such as SSA GT professional services (this consulting
is
recommended for overall performance tuning, rather than for performance BMR
support of a specific slow program in BPCS, where SSA GT Support can be
called).

Thanks,

Genyphyr Novak
SSA GT

----- Original Message -----
From: <FWSoftware@aol.com>
To: <bpcs-l@midrange.com>
Sent: Saturday, April 27, 2002 12:23 AM
Subject: Re: Invoice Billing Process


> --
> [ Picked text/plain from multipart/alternative ]
> Use STRDBG *YES (update production files). Should give you Index
> recommendations in the joblog. Also, DBMON works perfect but you need to
know
> Query's that use the DBMON file to it's fullest.
>
>
> _______________________________________________

_______________________________________________
This is the SSA's BPCS ERP System (BPCS-L) mailing list
To post a message email: BPCS-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/bpcs-l
or email: BPCS-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/bpcs-l.