It has been a little while since I last investigated the XM aspects of
the MPE/iX, but I believe your understanding may be faulty.  This is the
reason why I wanted to hear your reasoning first.

The Transaction Manager, XM for short, does not work quite the way you
explained.  I am doing this from memory, mind you and I am quite happy
to be corrected.

There are many parts to the XM.  During the life of MPE, there is an
area in memory reserved for a queue to the master of the volume sets.
This queue gets emptied according to various parameters, one of them
being activity and another one being time.  IIRC the maximum time
between buffer flushing to the masters is about 500ms or half a second.
I believe this is called the serial write queue.  IMAGE/SQL and KSAM/XL
are attached to the XM and can force the SWQ to flush to disk.  I
believe most files on MPE are not attached to the XM.  I think it's only
system tasks (directory and stuff,) IMAGE/SQL and KSAM/XL that are.  You
can attach another file if you want to, but you have to program for
that.

The dirty pages are continuously being flushed to disk, in this case,
the XM logfiles of each volume set.  These logfiles are on the master
volumes of each volume set.  If you only have one volume set,
"MPEXL_SYSTEM_VOLUME_SET," then Ldev 1 is the only drive with the XM
logfile.

Now, at checkpoint time, which is reached when half the XM logfile is
filled on the master of any volume set, the logfile is used to update
all the volumes of the volume set being checkpointed.  In the olden
days, this was a high priority task and would take over the system for
the duration of the checkpoint.  The disk drives would go nuts for a
little while.  In time, MPE was enhanced to reduce the impact of this
massive "flush to disk" activity.  Please note that it is not main
memory dirty pages that are being flushed to disk, rather it is the XM
logfile contained in the master of the volume that is being flushed.

Whilst this checkpointing is going on, the other half of the XM logfile
is used to record any new activity going on for that volume set.  When
that half is full, it will then be checkpointed.  The size of main
memory has NOTHING to do with the ckeckpointing process.

The neat feature of XM is that if the system crashes, you can disconnect
the volume set from the failed system, reconnect it to another MPE/iX
system and when the drives are brought on-line, the XM logfile on the
master will be flushed to the volumes of that volume set and the volume
set will be ready for use.

I know, because I have done this many times.

Bottom line, dirty pages of files or objects attached to the XM are
flushed to disk virtually continuously.  The size of RAM is irrelevant.

Denys

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
Behalf Of Craig Lalley
Sent: Tuesday, February 03, 2004 8:55 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] 997 and memory

Denys,

During the checkpoint the XM will scan memory for dirty pages to post.
This is
the notorious pin 11 or 12 that people see periodically on the system
(pin 17
for N-class boxes).

Scanning memory creates a lot of system overhead and there is a patch to
reduce
the effect of semaphore locking (MPEMX34A probably superseeded).

The real problem is when the second Checkpoint hits, before the first
has time
to finish, i.e. they collide.  To compensate for this, it is possible to
increase the size of the XM logfile and reduce the time between
checkpoints.

The good news is that the XM checkpoint is a serially threaded process,
hence
it will only use up one processor (better have a few if you have 16GB of
memory).

The problems I am discussing are for very heavy, data entry systems.
The XM
(transaction manager) is a write cache.

Generally more memory will help batch reporting, it does not always help
on-line response times.

Hope that makes sense, it took me awhile to understand it.

-Craig


--- Denys Beauchemin <[log in to unmask]> wrote:
> Ok, explain how that would be painful.
>
> Denys
>
> -----Original Message-----
> From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
> Behalf Of Craig Lalley
> Sent: Tuesday, February 03, 2004 8:28 AM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] 997 and memory
>
> Chuck, Dane, Joe and all,
>
> I humbly beg to differ, a 997 supports 16 GB of memory with standard
HP
> memory.
>
> Although I do not recommend it.  The problem is the 180Mhz 997
> processor.  At
> 180 Mhz, it takes about 80 seconds to scan 16GB of memory.  That could
> make the
> XM checkpoints quite painful.
>
> -Craig
>
>
> --- Chuck Ciesinski <[log in to unmask]> wrote:
> > Dane, Joe, and all,
> >
> > I humbly beg to differ with Joe,  with third party arrays, you can
get
> 16
> > GB in a 997.
> >
> >
> > Chuck Ciesinski
> > Hughes Network Systems
> > 11717 Exploration Lane
> > Germantown, MD  20876
> > p  301 601 2608
> > f   301 601 6303
> > email  [log in to unmask]
> > "The joy of life is living it..."  unknown
> >
> > * To join/leave the list, search archives, change list settings, *
> > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free web site building tool. Try it!
> http://webhosting.yahoo.com/ps/sb/
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *