× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Billing Invoice Process
  • From: Ata510@xxxxxxx
  • Date: Sat, 27 Feb 1999 01:59:39 EST

In a message dated 2/19/99 2:37:38 AM Central Standard Time,
andrew_murphy@uk.xyratex.com writes:

> We have also had problems with the length of time BIL500 takes to run. We 
> have
>  been informed by SSA that NO users can be on the system while this job runs
> so
>  users like ourselves which run world-wide operations on a single
environment
>  must remove all access to BPCS (including client/server applications) while
> it
>  runs. We also use consolidated invoicing which increases run time even
more!
>  
>  I will certainly try creating the logicals suggested but should these be 
> created
>  as logical files (i.e. DDS) or as SQL indexes (CREATE INDEX .....)? Most
>  documentation I have seen has recommended that indexes are created but 
> surely
>  this then loses any select/omit criteria that the logical files being 
> replaced
>  had?
>  
>  I would be interested to hear if anyone has tried either method.

I have tried both, and if no select/omit criteria are required, then the
behavior of each as regards speed increases is very similar. In this case, you
are not replacing logicals, you are adding more over the same files. The
advantage of the logicals is that you have the source around as clear
documentation of what was done, and as an easy way to create the same exact
thing in many environments. If Select/Omit is required, you will have to use a
logical -- but the DBMON tool never recommends Select/Omit -- you have to use
DBMON with a knowlege of the code and what it is trying to do, as well as what
the Query Optimizer is trying to do and why (and out-think the DBMON
recommendations in some cases) to come up with what will ultimately be the
best solution. 

In short -- in this case, you could use either method. CREATE INDEX is a quick
and dirty way to test and see if it makes a difference in performance.  Mostly
because I am AS/400-centric and indexes were imported from Unix they just
don't seem as 'normal' to me -- but they can get the job done. You could ask
on one of the AS/400 Forums about what the technical differences are in the
DB2 database when one versus the other is used, because I really don't know. 
Also when you name the new ones, consider starting at very high numbers (like
ECHL99) so that you can easily recognize what parts of the database are your
customizations when it is time to upgrade to another release.
You don't necessarily want to bring them all with you, as they may not be
needed at the next release...and too many logicals over a file can cause
performance degradation for interactive users.

Also, I would take a look at the BMRs listed on OGS, because there are new
performance BMRs written against that program that also recommend logical
files (some of the same mentioned by Walt Schaff at Abbott, in fact). If the
BMRs are ever completed, you might want to just get the official fix instead.
Sometimes they alter the SQL in the code so new logicals are not needed.
+---
| 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.