Re: 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