On Fri, Mar 13, 2009 at 4:26 AM, David FOXWELL <David.FOXWELL@xxxxxxxxx> wrote:
On a general note :
Alan, how do you get to learn this kind of thing? I'd like to know more about how the system functions, for example, how a program is activated or shared.
The Fortress Rochester and the older Inside the AS/400 books by Dr.
Soltis are a good place for i specific info. ILE Concepts, work
management, and performance manuals are also useful.
As for the example above, I thought that the unique storage address meant that you never knew if main or secondary storage was
being used. How would you know for sure that a job got swapped out to disk? Is this information recorded somewhere? How can you > manage it? I'm thinking of a program that we have that uses an SQL request that functions normally then suddenly takes a long time > to execute.
Computers 101 (ok maybe 301), CPU's can only work with data in memory,
not directly on disk.
The difference between the single level store the i uses and the swap
file system used by other systems, is that when the i swaps data out
of memory, it only exists in one place on disk. Whereas with other
systems, data is swapped out of memory into a specific swap file on
disk plus the original copy of the data still resides on the file
system. In other words, with the i, a particular piece of data exists
at a given time either on disk, or in memory. With other systems, a
particular piece of data may exist in three places at the same time,
the file system, memory, and the swap file.
You don't manage it, virtual memory is a function of the OS. The
books mentioned above go into detail about how i OS does it. You can
find books that discuss Windows or Unix/Linux.
With your SQL you'd break out the various performance tools to dig
into what's going on. Thrashing is the term used when a job doesn't
have enough memory and spends to much time swapping data in and out of
memory. You'd identity that has the problem by looking at the number
of faults.
As mentioned in my other post to Alan, the "correct" way on the i to
ensure that a job isn't swapped to disk is to run it in its own
subsystem with a private memory pool. In addition, there's the
SETOBJACC command that lets you move an object into memory. Assuming
you move it into a private memory pool, the system won't swap it out.
Any job the uses the object will benefit from the fact that it's
already in memory.
HTH,
Charles Wilt
midrange.com
