"Evidently PDM manages to do something under the covers that
allows it to get at a list of members much more quickly than DSPFD."
i would "assume" they are using QDBRTVFD (and friends) APIs. since the
returned info isn't in a user space and is received as a memory allocation
(data string) it would be blazingly fast compared to a DSPFD command. not
sure if WDSC taps into those APIs or how they are getting the info. but
as Joe states i really haven't had any issues like the one you're
mentioning. but I'd definitely suggest opening a PMR. if it's not really
a problem but a DCR needed they should be able to tell you and help you
get one set up (or point you to documentation on creating a DCR.
Thanks,
Tommy Holden
Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>
Sent by: wdsci-l-bounces@xxxxxxxxxxxx
02/04/2008 09:16 AM
Please respond to
Websphere Development Studio Client for iSeries <wdsci-l@xxxxxxxxxxxx>
To
Websphere Development Studio Client for iSeries <wdsci-l@xxxxxxxxxxxx>
cc
Subject
Re: [WDSCI-L] RSE performance against very large source files
Dave Shaw wrote:
This is one of the issues that's killing acceptance of the product in
this shop. It would be very hard to justify NOT having a copy of PDM for
everyone with this kind of issue, and if the company has to buy everyone a
copy of ADTS, why should they also buy RDi? Yes, I know why, but it
hasn't been an easy sell getting people to use WDSCi for the price of a
decent PC and some learning time; now I have to justify buying it, too.
Have you raised this with IBM, either as a PMR or a DCR? You seem to
have a legitimate issue, and it's an underlying system issue. Two
things are immediately apparent, at least to me. First, there is
something ridiculously wrong if it takes 39 minutes to do a DSPFD on a
file with a few thousand members (or even 20,000 members).
In my unofficial test I just ran, it took less than 15 minutes to add
15000 members to a file. Next, I did a DSPFD on it, and the list came
up in about 30 seconds. I then went into WDSC and open a connection to
my machine. I added the library to my library list, and then expanded
the library. Two seconds. I then expanded the source file. 12
seconds. Now granted, these were empty members. There may be other
issues that come into play when there are lots of records in the source
(DSPFD definitely displays number of records and deleted records; if it
calculates those dynamically at display time, that could explain some of
the overhead).
Even so, 39 minutes to display a member list seems excessive. Is there
something else at play here? An exit program, perhaps? Some sort of
bizarre auditing issues? Have you asked IBM about it?
But there's a second issue, which is probably more to your specific
point. Evidently PDM manages to do something under the covers that
allows it to get at a list of members much more quickly than DSPFD. If
that's indeed the case, then maybe there's a call for some sort of
"paged widget" in RDi that can directly access the same functions that
PDM uses. There would be limits, such as not being able to filter
without a performance hit (because as you know, filtering in PDM takes a
healthy chunk of time as well). But if enough people were to tell
George Farr that this is a deal-breaker, then he might be willing to
devote some resources to it.
Joe
midrange.com
