RSE performance against very large source files

I didn't think the title 'EGL vs. Java' applied anymore. ;-)

A case in point on my specific performance issues:

This morning I created a new member filter. The library is our production source library, the file name is QDDSSRC, and the member name filter is PRF*. I expanded the filter. After 2 minutes, I got the message asking if I wanted to cancel the request. I answered No, and finally got the results after 3 1/2 minutes, getting back 13 member names. I did a DSPFD on this source file just to check the total number of members. It took 39 minutes to tell me it has 19,892 members. Note that our QRPGLESRC has a LOT more.

I can, of course, do a WRKMBRPDM on this file, and then a position to using PRF, and get to what I'm looking for in a couple of seconds. I will stipulate that doing an F17 and putting PRF* in the name filter produces a very slow response as well, but I don't need to do that with PDM since it has the position to function.

All I wanted to do was open a particular member in CODE Designer so I could look at the screens. Even though in this case I knew the member name, Ctrl-Shift-A was useless because it doesn't open CODE Designer. I could have found the member and used the PDM user option to open it in CODE and had the thing up in less than 30 seconds (by the time I set my screen groups up in Designer), vs. 4 minutes for the RSE to CODE process. My co-workers would just use PDM/SDA, and be happy with the more limited function because of the up-front time savings.

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.

Dave Shaw
Mohawk Industries