Justin
I believe that 'Find String' uses the same command (on the i) as does
'iSeries Search' - FNDSTRPDM. Both resolve your specifications to the
members they search in. FNDSTRPDM does just one member at a time, no
wild cards.
'Find String' is an option you get when you right-click on something in
the Remote Systems Explorer. I've never used it - I might start,
although I'm quite satisfied with 'iSeries Search' from the 'Search'
item on the menu bar.
I suspect, without actually trying things, that the time to do a search
depends on a number of things. If you specify something like a library
filter that is *LIBL or *ALLUSR, it might take a long time to find all
the members in that filter. If you have a member filter in one library,
it should not take it long to resolve to those members (this being the
use of 'Find String' on a member filter). I would expect it to take
longer to use 'iSeries Search' over that same library, specifying
similar file and member settings. But that's an assumption that the
filter has already done the resolution AND is used by the operation.
So I'll say it depends - there is such an extensive variety of
possibilities. I still find 'iSeries Search' to be fine. If I specify a
very general set of values like SRC* for library, Q* for file, and * for
member - hey, it's going to take a while. We have several 10's of SRC*
libraries. And this would go through every source member with the
FNDSTRPDM command over each. Sometimes I just need to do it. And WHEN I
do this, I multitask and do something else.
One thing about testing performance - you need to do your best to have
things set up the same - especially as regards what is in memory. If you
run 2 processes over similar data sets, the second will almost always
run faster, other things being equal. That is because the first process
has brought data into memory, which data is possibly still there, hence
faster to work with.
BTW, I did see that text strings I had specified to search for in
'iSeries Search' were listed in the history drop-down in 'Find String'.
I did see that when I used what amounts to the same spec, the time taken
was the same, approximately. I ran 'Find String' over a library filter.
One reason to use filters might be the greater flexibility over
libraries, files, members.
Now don't talk to me about cross-reference products!!!
Vern
On 9/7/2010 8:08 AM, Justin Taylor wrote:
Is "Find String", the same as "iSeries Search"? I'm not familiar with Find String but iSeries Search is horribly slow, and would love to run it in the background.
----------------------------------------------------------------------
message: 1
date: Mon, 6 Sep 2010 07:08:39 +0200
from: "Colpaert, Peter"<Peter.Colpaert@xxxxxxxxxxx>
subject: Re: [WDSCI-L] Why can I not run a "Find String" in the
background?
Stuart,
Apparently, 'Find string' is only slow when searching a member filter.
I found that running it on a source file filter is much quicker.
I don't know if creating a file filter is an option for you, but it might help.
For the record, I'm (still) on WDSCi 7.0.
Best regards,
Peter Colpaert
Software Engineer - PLM Development Team
Philips Consumer Luminaires
Tel: (+32) 3/459 13 17
Fax: (+32) 3/450 74 33
Address: Industrieterrein Satenrozen 11, 2550 Kontich, Belgium
Email: Peter.Colpaert@xxxxxxxxxxx
**********
midrange.com
