johnmoloney@gmail.com wrote:
> I have recently come across a very useful feature in the g95 compiler
> called the Corefile Resume Feature. It allows a program to create an
> executable called 'dump' which allows the user to restart a job if you
> kill it or (if setup correctly) to restart from the last dump point
> created by the environmental variable G95_CHECKPOINT.

The CHECKPOINT/RESTART feature of OS/360 was designed for this.
That was when hardware was slower and less reliable, and restarting
was needed more often.

> Unfortunately I generally use the Intel fortran compiler (for its
> speed). I would like to know if there is a way to write say a g95 main
> program wrapper which does nothing but handle this restart facility? Is
> this possible as I would like to use the speed of the Intel compiler
> while utilising the g95 resume functionality so that a stopped job
> could be simply restarted at the position it was stopped. If this
> feature exists in the intel compiler accept my apologies as I have not
> yet found it.

It is hard to say. It sounds mostly dependent on the OS and the
library, so it might work. There could be problems with some
optimizations, such that programs might not restart right.

Traditionally this could be done with unformatted I/O, writing
out all the important data at convenient points, and having the
ability to start up and read in such data. That seems also
to be popular for video game consoles.

TeX has used a feature like that, where available, to generate
executables with macro packages preloaded. At load time, it
checks for an initialized static variable which indicates that
many other variables have already been initialized. For OS without
that ability, there were programs that could find variables in
the executable file and initialize them.

> I see this as a very nice safety feature (for example in the case of a
> machine hardware failure, power cut etc.) and I would appreciate any
> help with this (or criticism relating to this possibly crazy idea).

It is a little complicated in some cases to get right, especially
with I/O devices. Consider the windows XP hibernate feature,
and TCP network connections. (Even without that, it doesn't seem
to restart perfectly 100% of the time.)

-- glen