You still do not understand.

You confuse the XM checkpoint process, which is done at the volumeset
level, with the posting to the master of the volumesets as I explained
it.  You also insist that all of main memory gets scanned at checkpoint
time.  I say it does not.

As I explained earlier and now several times, when you write stuff to XM
protected files (and the OS (directory), which is also XM protected,)
that does not go directly to the various disk drives, that stuff gets
posted, appended to the XM log files on the master of the various volume
sets.  As I explained earlier this posting/append occurs at a furious
rate, the longest interval being about 500 milliseconds.

THIS POSTING IS NOT CHECKPOINTING.

The checkpointing of a volume set occurs when half the logfile(s) are
full or some other event triggers it, and this can be at an interval of
minutes or maybe even hours.  What is important to remember is that as
stuff is posted to the XM log files on the master of the specific volume
set, the volume set is self sufficient.  By this I mean that if the
system fails before the checkpoint occurs, the volumeset does not lose
all the transactions that have occurred since the last checkpoint took
place, it has them in its logfiles.

When the system is restarted or if it's a major outage and you actually
transfer the volumeset to another system, which you can do with a SAN or
even with regular HVD or SE SCSI, when that volumeset comes online, it
will go through a checkpoint process and post all the transactions that
are contained in the XM logfiles of that volumeset.  It will be
IMPOSSIBLE for that checkpoint to scan all of main memory on the system,
because it may not even be the SAME system or at best, the system would
have restarted and main memory would have been flushed anyway.

You need to abandon your fantasy about the having the checkpoint scan
all of main memory.  It does not.  It cannot.  If it did, then by
definition it could not be a "Transaction Manager" with log files,
because it would need to access stuff in the system that is no longer
there.

Until you abandon that "scanning all of main memory" thing, you will not
be able to grasp the significance of XM on MPE.

Trust me, I have recovered hundreds of times on MPE after a crash or a
power outage and I have never lost any data because main memory could no
longer be scanned for dirty pages.  I have even moved volume sets from
one system to another and have successfully checkpointed the volume set
on this other system.

As proof of what I am saying, do this exercise:  The next time you have
an MPE system fail and you are bringing it up, watch the messages on the
system console during the boot-up.  Towards the end of the boot up
process you will see messages about the system entering the recovery of
the volume sets.  For each volume set on the system there will be a
checkpoint initiated to bring all the volumes of each volume set up to
date.  The log files are empty at that point.  When all the volume sets
are recovered, (read checkpointed,) the system will then be ready for
use.  You will note that the system's main memory is not being scanned
by the checkpoint process, it would be ludicrous to do so as the main
memory has been totally reset during the boot up process.

I do not care if Kevin Cooper or anyone else explained to you that all
main memory gets scanned during a checkpoint, it doesn't matter, you
simply got it wrong.  Period, end of story.

Denys

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