Re: Re:Thanks Genyphyr

That is an interesting idea (as long as you know which codes it is looking
for in that field - I am not familiar enough with that application to say if
the codes you listed are accurate to what the program is trying to
accomplish at that point).

If your change does cause the query to be faster, that would certainly be
good technical information to have in the BMR description so that it can be
permanently corrected. Let us know how this turns out.

Thanks,

Genyphyr Novak
SSA

-----Original Message-----
From: ANTHONY_JACKSON@dcsgroup.co.uk <ANTHONY_JACKSON@dcsgroup.co.uk>
To: BPCS-L@midrange.com <BPCS-L@midrange.com>
Date: Wednesday, February 16, 2000 4:29 AM
Subject: Re:Thanks Genyphyr


>
>Do you think this would work,we plan to test on one of our box..replace the
RRID
>substr with RRID in('RI','RP','RD','RD','TP',)..TO SEE IF THIS USES THE
>LOGICAL...
>ie KEYED ON SELECTS...AND SELECT COMP ='RI','RP','RD','RD','TP',..
>I intend to log with SSA uk helpline also...
>
>
>
>
>"Genyphyr Novak" <novakg@ssax.com> on 16022000 00:12:18
>
>Please respond to BPCS-L@midrange.com
>
>To:   BPCS-L@midrange.com
>cc:    (bcc: Anthony Jackson/North/CSI)
>
>Subject:  Re:
>
>
>
>
>Hello,
>
>The optimizer likely will not pick a simple logical you build for this due
>to the scalar function in the statement (the substring function). The
scalar
>causes the optimizer to have to build a temporary result table no matter
>what logicals you have - so, it is my guess from working on past
performance
>issues that the optimizer is deciding that it is faster for it to build
it's
>own temporary logical with the scalar results inside it at the same time,
>rather than use your logicals first and then calculate the scalar results
>later into a temporary file and combine the results together.
>
>Before starting to tune:
>1. Ensure you have the latest SQL PTFs from IBM for your release (the
latest
>Group PTF for database/SQL) before starting any of that, as the SQL
>optimizer is affected by PTFs in how it decides to choose to access your
>data.
>
>2. Check the Info APAR for BPCS on your OS/400 release (II11801) to ensure
>you have all BPCS required PTFs.
>
>Rather than relying on PRTSQLINF, instead try to find out what the
optimizer
>is building on the fly and see if you can help it out. For example, first
>try STRDBG program *NONE, UPDPROD *YES and see the SQL messages in your
>joblog by pressing F1 and then reading the 2nd level text to see what is in
>the logical file it builds. If the file has no name or keys listed, that is
>because it includes the scalar results. So, if that isn't revealing enough
>run a DBMON (the SSA Helpline can assist in analyzing this if you are
>working with a client who has OGS support, and if their final analysis
>involves requesting code changes, they can enter a BMR for you) and find
out
>more about what happens when the statement runs. The PRTSQLINF is only an
>estimated run time, not the actual. DBMON shows how long the statement
>really takes to complete, and leaves lots of clues as to why the optimizer
>chooses to do what it does do.
>
>You can try to give it an index that has everything the query needs to
>complete (every field returned, with order by and selection keys first -
the
>optimizer likes to remove as many records as possible, so put the most
>selective fields first ) except the SCALAR results of course. This would be
>an attempt to induce index-only access so that the optimizer has the choice
>of doing an index-from-index build.
>
>It may never choose to use anything you build in the end unless the
>statement is altered or program is altered. Changing the statement requires
>in depth application knowlege. If this is reducing performance
significantly
>and you suspect a BMR is in order, you should ask the customer to open a
>call to the SSA Helpline AS/400 Technical team to investigate. They can
>involve the required application consultants to assist.
>
>Another option to try (if you have source and feel like playing) is to find
>out if the program fetches the cursor in a loop that involves lots of other
>activity in between reads of the next record in the cursor. In that case,
>you could alter the SQL statement to say at the end "OPTIMIZE for n ROWS"
>where n is a low number such as 10 or 20 - this way the first 10/20 records
>might be returned more quickly, and the loop can begin processing. This may
>make the program appear to process faster to an interactive user, but that
>is dependent again upon the program logic and what else the optimizer is
>doing behind the scenes. A DBMON would give you a lot more information to
>work with.
>
>Thanks
>
>Genyphyr Novak
>SSA
>
>
>
>
>-----Original Message-----
>From: ANTHONY_JACKSON@dcsgroup.co.uk <ANTHONY_JACKSON@dcsgroup.co.uk>
>To: BPCS-L@midrange.com <BPCS-L@midrange.com>
>Date: Tuesday, February 15, 2000 1:53 PM
>
>
>>
>>Hi folks.....anybody out there...ever compiled a logical on rar..which
will
>be
>>used by
>>(see sqlinf below)...I have tried numerous qddssrc/LF specs/...and none
got
>>picked up by
>>ACR500D2....bpcs ver=6.1 full client...on AS400...its the last piece of
the
>>performance
>>improvements we have made on 'cash/memo posting'
>>     File  . . . . . :   ACR500D2                         Page/Line   2/42
>>
>> Control . . . . .   W6                               Columns     6 - 83
>> Find  . . . . . .
>>
>...1....+....2....+....3....+....4....+....5....+....6....+....7....+....8.
>.
>> A1
>>  A1
>> A1
>> DECLARE C1 CURSOR FOR SELECT * FROM RAR WHERE RCOMP = : CRCMPY AND RCURR
=
>:
>>
>> RCURR AND RCCUS = : CRCUST AND ARPTYP <> : W8PTP1 AND ARPTYP <> : W8PTP2
>AND (
>> RPTYP BETWEEN : W8FRTP AND : W8TOTP ) AND SUBSTR ( RRID , 1 , 1 ) IN
 'R'
>,
>> T' ) AND ARWSID IN ( : W8WSID , : ZZSWS ) AND RSEQ = 0 AND RREM <> 0
ORDER
>BY
>> DDTE , RCUST , ARODPX , RINVC FOR FETCH ONLY
>> 4021  Access plan last saved on 18/05/99 at 08:15:58.
>> 4020  Estimated query run time is 12 seconds.
>> 4017  Host variables implemented as reusable ODP.
>> 4006  All access paths considered for file 1.
>> 4009  Access path created for file 1.
>> S1 V4R3M0 980729     Print SQL information          Program
*LIBL/ACR500D2
>>**************************************************************************
*
>*****
>>
>>BPCS Support
>>DCS Industry Solutions
>>Caledonia House                         office    0113 2043300
>>Lawnswood Business Park                 fax       0113 2043333
>>Redvers Close
>>leeds LS16 6QY
>>The information contained in this electronic mail message is confidential.
>It is
>>intended  solely for the use of the individual or entity to whom it is
>addressed
>>and  others  authorised  to receive it. If the reader of this message is
>not the
>>intended recipient, you are hereby notified that any use, copying,
>dissemination
>>or disclosure of this information is strictly prohibited.
>>
>>
>>
>>
>>
>>+---
>>| 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
>>+---
>>
>
>+---
>| 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
>+---
>
>Tony Jackson
>DCS Industry Solutions
>Caledonia   House,                  Office   :       +44   (0)   113   204
3300
>Email :   ANTHONY_JACKSON@dcsgroup.co.uk
>Lawnswood  Business Park,   Facsimile :  +44 (0) 113 204 3333           Web
Site
>:www.dcsgroup.co.uk
>Redvers Close,                 Mobile:        +44 (0) 7711 734 479
>Leeds, LS16 6QY
>United Kingdom.
>The information contained in this electronic mail message is confidential.
It is
>intended  solely for the use of the individual or entity to whom it is
addressed
>and  others  authorised  to receive it. If the reader of this message is
not the
>intended recipient, you are hereby notified that any use, copying,
dissemination
>or disclosure of this information is strictly prohibited.
>
>
>
>
>
>
>
>+---
>| 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
>+---
>

+---
| 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
+---