× 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.



Joe,

There are currently 12,083 members in the biggest source file. It took close to 10 minutes for the DSPFD to run to find that out! The longest request I made through RSE and allowed to finish was around 15 minutes; I've killed several that would have taken as long or longer. Much more limited filters are the only practical solution. Our naming conventions aren't too terrible for that, fortunately.

Dave Shaw
Mohawk Industries

----- Original Message ----- From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> To: "'Websphere Development Studio Client for iSeries'" <wdsci-l@xxxxxxxxxxxx>
Sent: Friday, March 23, 2007 5:28 PM
Subject: Re: [WDSCI-L] Filters (Was: websphere udate for 6.0.0.1)


From: Dave Shaw

Greg,

I am slowly setting up a set of permanent filters that I can use.  The
issue
is our production source.  We have so many members in it, QRPGLESRC
especially, that I have to subset in order for it to be useful (and to
avoid
locking WDSC up for a long time).  I don't know the count, but it's many
thousands. Every so often I make a filter that's too all-encompassing and
kick myself while I wait for it.  The pitfalls of a large shop, I guess.
I
already have sixteen permanent filters and 5 project ones, and I've only
begun.

Dave, how long does it take for you to load your most extensive list?  And
how many members is it? I'm not questioning your request, but I'm trying to
get a feel for just what pain level you're at.

The reason I ask is that the only option in a client server environment is
to load some predetermined number of members, and then load the rest in a
background task.  The problem with background tasks is that you have to
manage them.  It can particularly tricky if the user:

A) Refreshes the list
B) Deletes the filter
C) Applies a different sort/subset

Any of those things typically mean somehow canceling the request.  In a
client/server environment, that means somehow canceling the outstanding
request, which may be a long-running one.  So now you have the infamous
hanging cancel (which typically leads to the user hitting the cancel button
over and over again).

I'd like to see if there isn't a reasonable need to create a "fast list"
object. It would NOT be an enhancement to the standard RSE, but would be a completely separate animal. It would most likely allow the basic functions of the RSE, but it would be distinct. It would be pretty limited: you could
only have one at a time, you wouldn't be able to access the list via RSE
while it was loading, that sort of thing.  But if we could figure out an
easy way to do it, it might be nice.

It may nto be doable at all; the problem is the API.  As far as I've seen,
the QGY list APIs aren't built for speed.  I'm not sure we can make the
member list API work as quickly as it does with SEU. I'd sure like to know
how the PDM folks manage to do their magic...

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.