saving and reloading app to/from hdd

[Danny Blankenbyl]

I want to be able to save my running application and ALL variables and arrays to the hard drive when a power cut hits. A UPS will enable me to keep the PC running durning the shut down period.
When the power comes back on I want to reload the app and all the variables and keep on running just as if nothing ever happened.
Can some one give me some pointers like which blocks of memory I should save etc.
Thanks Danny Blankenbyl NZ

[Lance Edmonds]

Well, what do you know... another Kiwi appears on board! Welcome!

Danny, saving variables and arrays is relatively easy to accomplish (remember, memory is dynamic and variables may not be positioned in memory at the same address each time the program is run), but you may want to consider a few aspects before you implement your design:

First, it is not really feasible to write raw memory blocks/segments to disk, and when the program restarts, memory *may* be arranged differently. This is especially true for dynamic strings which move with each assignment statement.

So, assuming that the power does not fail *during* the save operation, you need to be able to restore the "state" of the program exactly.

1. Your program must be able to restart itself and determine whether it has to reload it's data from disk, or start from scratch. If it has to reload, it should verify the data before trusting it to be ok.

2. You'll probably want to optimize the way you write the data to disk. Are you using UDT's? UDT's offer the simplest way for loading and saving data to disk. Arrays are more complex, but the simplest way is simply to write each subscript into a (probably sequential) disk file. If you use VIRTUAL arrays, you'll _have_ to write them subscript by subscript.

Unfortunately, more specific suggestions are not really possible without knowing more about your particular program, and what sort of variables are in use, etc.

In general, programs that work like this are constructed so that the save/restore operation is integrated:

Start:
  ' Load data from HD, if necessary.  Verify FLAG value.
  DO
    ' Process data
    ' Write data to HD, and finally set a FLAG to 
    '   indicate data successfully written to HD
  LOOP
END

With this design, when the data is reloaded, it is processed normally, and the app continues... I;d use some sort of CRC on the data, as you would not like to be reading the FLAG from save *before last* and incorrectly assuming the data is Ok in the *last* save. (clear as mud?)

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Mel Bishop]

The only reason that I am mentioning this is that maybe someone
can remember what I can't.
Years ago, I remember seeing an ad in a computer magazine about
a self contained device that, when the power fails, dumps the
contents of the computers entire memory to a hard drive file and
automatically shuts off the computer.
Then, when the power comes back on, the device reads the file,
re-loads memory and keep's on keeping on.
Can SOMEONE remember the name and/or manufacturer of that
device?????


------------------

[Michael Mattias]

The problem of "what if a power failure occurs during operation xxxx" is one which has challenged designers for a long time. I've a couple of these applications, and the way I did it was to look at the problem the same way a datbase system handles updates, by marking a "begin transaction", saving what I needed there, doing the file updates, then when the updates had completed, marking an "end transaction."

This approach does not save the "exact state" of the program; rather, it saves the state of the program "up to a known point" and allows a restart after the "last known good transaction" and re-processes the interrupted transaction.

As Lance said, you will need to have your program look for something which tells it, "I was interrupted while processing transaction number 567" and have your application start with transaction number 567.

I am personally skeptical of any "hardware solution" other than a UPS.

MCM

[Anton Lasich]

Hi

Mattias is 100% right. BEGIN TRANSACTION , END TRANSACTION and
of course rollover are database related and were used and still
are in complex computing environs where online status is:
online/offline/online/offline/online all the time...

I have found its best (I can only talk from PC angles) to make
sure that your writing is kept minimal and files are closed at
all times open only for a short period. This has kept database
damage down to only 2 major crashes in one system in 3
years...whereas other programmes that leave datafiles open all
the time have damage all the time. I usually build in trapping
routines to determine where I am in a programme when an error
occurs. With some adpation I am sure you could adjust this so
that you are constantly aware so that you could easily write
some kind of ini file to pickup where you were within say 90% of total,
when a terminal/pc goes out...

If you have a UPS, then perhaps you need to look at a TSR that
will inform your programme or your programme can poll to
determine its status and upon finding it is in a powerdown
cycle simply copy all existing memory data has a binary image
and reload it? I remember one of the first things I liked about
a laptop I had was that I could switch off the machine and
startup exactly where I left off. So this idea of yours has
been done before...

Keep us updated on what happens. I would like to know how you
solved it

Anton


------------------