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



Maybe I misunderstand the caching mechanism or the purpose for it. Is it
stored on a per-member basis? When I open one member, it takes a long time
to get an outline. When I open another member that uses the same resources
(a bunch of includes), THAT member takes a long time as it updates all the
very same cache items, and so on as I open other members, even though all
those cached items were updated by opening the prior members, like they
have no idea that the cached item was just updated.

When I open multiple members while one or more outlines have not been built
fully yet, the cache updates collide in their efforts to update the same
cached items and each of the members will have random /includes marked
"unavailable" with a yellow triangle. The unavailable items are different
each time.

None of the includes being used have any external references to record
formats (externally-described data structures). They're just data
definitions and prototypes. They are all fairly static and do not change
often (some have not changed for 3 years or more).

When I open an older member that has very few includes, and a database or
workstation file, it loads quickly (4-6 seconds) regardless of the size of
the member.

Stu




On Fri, Dec 19, 2014 at 6:08 AM, Stuart Rowe <rowestu@xxxxxxxxx> wrote:

CHANGE.

You might consider letting us condition that behaviour (like a checkbox or
something).

It's annoying that it takes so long -- I can open a member, make some
changes, compile a couple times, more changes, more compiles, and be done
before the outline ever shows up.

The code I work with most often has no files declared, just code with LOTS
of nested includes (definitions only, no code). I've never counted them
before, but there might typically be a hundred or more /includes included.
Seems like it is fetching all those source members from the iSeries
regardless of the state of the cache. Is it possible that some mistake was
made that expanded the scope to encompass all /includes as well as "PF
files etc"?

The cache has an expiration feature on it (number of hours). This leads
me to believe that if the member on my PC has not "expired" that it would
not be read from the iSeries again, regardless of whether I am initially
loading the outline or pressing "refresh" (unless I force it to be
reloaded). I don't think "initial load of the source" and "first load of
the day when the cache is out of date" are the same thing. I can
understand that first thing in the morning all my cache is expired and
would be re-loaded from the iSeries, but I do not understand the rationale
behind forcing them to be re-loaded when the same member is opened again 5
minutes later. "PF files etc" have change dates and times on them; if the
cached information agrees with those, there's really no reason to load them
all up again.

Stu







On Thu, Dec 18, 2014 at 4:57 PM, Edmund Reinhardt <
edmund.reinhardt@xxxxxxxxxx> wrote:


When I fixed APAR SE56000 which was delivered in 9.0.0.1, I had to address
the complaint that the outline view was not reflect changes made to PF
files etc, once the source was loaded.
The behaviour of the outline view is:

to extract file info from the host if
a) the file is not in the cache
b) this is an initial load or the refresh button was pressed

One might argue that this is erring on the side of accuracy instead of
speed and that we should instead extract the file info if
a) the file is not in the cache
b) the refresh button is pressed

but on initial load it should try to get things from the cache if it can.

For those who care, reply and tell me if you think the outline view should
use cached (potentially) stale data on the initial load and only get from
the host if the cache doesn't have it, or the refresh button is pressed.
Email and say "CHANGE"

If you prefer to keep it the way it is say: "KEEP THE WAY IT IS"




Regards,

Edmund (E.H.) Reinhardt
Technical Architect for Rational Developer for i



Phone: 1-905-413-3125 | Home: 1-905-854-6195
E-mail: edmund.reinhardt@xxxxxxxxxx
RDi YouTube: 8200
Warden Ave
www.youtube.com/user/IBMRational#g/c/62DF24D5BCD43501 Markham, ON
L6G 1C7
Find me on:
Canada






From: Stuart Rowe <rowestu@xxxxxxxxx>
To: "Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries" <wdsci-l@xxxxxxxxxxxx>
Date: 17/12/2014 12:37 PM
Subject: Re: [WDSCI-L] Outline is not using cached source?
Sent by: "WDSCI-L" <wdsci-l-bounces@xxxxxxxxxxxx>



By "hard" I mean the remote command server job runs upward of 50% of my
CPU
for 2 or 3 minutes until the parsing is done (wrapping the job message
queue several times in the process).

I'll try clearing the cache and starting over.




On Wed, Dec 17, 2014 at 11:30 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 12/17/2014 9:58 AM, Stuart Rowe wrote:
Anyone else experiencing this after applying the 9.1.1 update?

The outline view seems to not be using cached content. It hits the
server
hard every time I open a member, even though I just opened it 2
minutes
ago.

Not sure I understand 'hard' - I have a grim 3500 line interactive
monstrosity that goes back to the 90s. It's ugly. Lots and lots of
variables, work variables, copies of work variables and indicators.
Cleared my caches, opened the beast and it took 6 seconds to populate
the outline view. This is about what it takes to do a Verify on this
beast of a program. I have a direct connexion to IBM i 7.2; no VPN or
remote site. I have the latest PTFs as of last Saturday.

Having said that, it takes the same 6 seconds every time I open it,
whether it's in the cache or not.

--
--buck

'I had nothing to offer anybody except my own confusion' - Jack Kerouac
--
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.

--
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.

--
This is the Rational Developer for IBM i / Websphere Development Studio
Client for System i & iSeries (WDSCI-L) mailing list
To post a message email: WDSCI-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/wdsci-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.