Re: EGL vs. Java

Joe,

For what it's worth, a DSPFD *MBRLIST against that source file takes about as long. Total members in the file are well over 10,000; it's just my group's portion of them that's smaller.

QCLSRC and QDDSSRC are also huge.

The subsystem has the jobs running in *BASE, which has about half a gig out of a total of 2.75 gigs allocated to it. It's a model 890 with the 7424 processor feature. This is our development system; the production box is faster at nearly everything, but it doesn't have the source on it and they don't like us doing anything intensive on it.

Dave Shaw

----- Original Message ----- From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
To: "Websphere Development Studio Client for iSeries" <wdsci-l@xxxxxxxxxxxx>
Sent: Friday, February 01, 2008 3:14 PM
Subject: Re: [WDSCI-L] EGL vs. Java

Dave Shaw wrote:

Joe,

The particular programming group I'm in is responsible for something on the
order of a thousand source members, a small portion of our total system. A
single filter with all of them takes 5 to 10 minutes to refresh with our
box, and even without refreshing takes about 15 seconds to expand on my 2
GHz Core 2 Duo - I built the filter once to try it, and decided it was more
trouble than it's worth, since I didn't know a way to position within the
filter (in table view) that was as quick as the positioning dialog in PDM.
Since there are often several possibilities for member name prefixes for a
given function, I often have to try 2 or 3 times to find what I'm looking
for. (Yeah, the naming conventions are old and terrible - can't do much
about that at the moment.) PDM is very quick for that; I can't say the same
for my multiple attempts at making filters that will get me to what I want.

Have you used RSE against a very large system? Are there tricks I'm not
seeing for how to make the access faster? An unfiltered drill-down into our
production source library, just to see the 20 or so objects in it, takes
between 15 minutes and half an hour. Drilling into the QRPGLESRC in that
library takes longer than that. WRKOBJPDM on that library and WRKMBRPDM on
that file take a second or two.

This is something that really needs to be taken up with IBM. If they
want people to move to the tool, then they need to fix this particular
issue. It's a one-time fix; they need to write the appropriate APIs to
do it. It may require PTFs, but it's pretty important. But honestly,
I've NEVER seen a drill down take a half an hour. You may be the
endpoint condition, but that's still crazy. Is it possible your
QZRCSRVS jobs are running in a limited memory pool?

How often do I need to do it? Sometimes I go a week without needing it,
other times I use it repeatedly in the same day - often with my boss or some
other programmer standing over me. How do I justify to them taking 20
seconds to 20 minutes using RSE to do something that they know they can do
in 2 seconds using PDM? It isn't so bad looking it up in PDM, Alt-Tabbing
to WDSCi, and doing a Ctrl-Shift-A to open it - they can see the advantages
of the color coding, outline view, and search functions. It's also easy to
show the advantages of RSE filters over the development libraries - it's
just during the research and analysis phase when we have to look at the
production stuff that I get frustrated.

So, suggestions?

I'm going to do some of this myself. I'm going to create a source file
with 1000 members and do some testing here just to see what happens.
I'll get back to you.

Joe