Re: Cache option of compile?

[coulthar@xxxxxxxxxx]

Jon, the cache algorithm is very simple. If refresh is turned on, then
for every bit of information required from the host of a given action,
such as verify, that information is saved to disk locally, in the cache
directory. So, it will only cache what that particular verify action
requires.

Regarding how we can improve the algorithm, the speed, and the
ability to work with that cached objects, let me level set you. There
is no improvement coming in this area in the next release, sorry
to say. However, it is a high-priority item after that. We appreciate
all input and ideas on the subject, and will endeavour to do what
we can to implement them. We also reserve the right to say you are
wrong. Not for all users on this distribution list, just for you Jon :-)

If we can get nicely netted-out ideas for the caching support we would
be appreciative. I know many think we should be able to point at a
database and use a "do cache" action, such that suddenly verifies
would work if they only used that database. However, keep in mind
that a verify does more than just access database and workstn files.
It also requires job information and sometime user-defined edit code
information, among other things. There is also copy members of course.
So, I am not sure that this nervana is possible. However, a right click
action on an RPG source member to cache all the required information
for that particular member is indeed doable. Sharing the database cache
between components, for the same database, is also doable. A work
with cache UI is also doable. Faster retrieval and caching is also
theoretically possible, and desirable. We will certainly focus on
performance,
but we can't guarantee we will find any unnecessary loops. However, in
general performance is a key consideration in the new communication
layer we are building for the new generation of tools. So is openness, so
the Java APIs we are writing to retrieve the information will be documented
and available for those interested in using them. Indeed, there will be
JavaDoc for every bit of our code ultimately (for the first release this
will
be made available on demand, so we can harden the APIs a bit). So,
we expect to see lots of great additions and alternatives to our supplied
tooling! For example, "Jon's caching tools" would be a nice plugin to
look forward to (seriously). Brush up on those Java skills, and you'll
have a wide open world at your finger tips soon.... way and well beyond
just writing editor macros. The whole thing will be open and extensible.

Phil Coulthard, iSeries Software Architect,  IBM Canada Ltd.