DHES

Dale,

I was thinking that it would be a good idea to setup a timed backup feature within POS.EXE. It would be configured via POSCONFG of course.

Example:

* Users sets time interval (2 hours, etc.) and destination for the timed backup via POSCONFG. Simple enough. Short time intervals (ie. < 1.5 - 2 hours) could get rather annoying, so a setting of at least 2 hours is recommended.

* POS.EXE monitors for time interval and executes backup accordingly (ie. close files, copy, re-open) A pop-up box indicating it's happening should be shown.

Exception handling:

Obviously, this shouldn't happen in the middle of a sale. In the event the timer is up and a sale in being made, a boolean flag is set so that upon the sale's completion, the backup will take place before the next sale can be executed. This would have to be checked in accordance with the Post-Sale option (ie. Sale->Next Sale or Sale -> Main Menu)

Just a thought!

Of course, this would compliment the usual backup procedures at the end of the day. I believe this feature will be helpful as it will save an admin/manager the extra time needed to re-enter the day's transactions incase of a crash during the course of the day.

Comments/suggestions welcome!

//Rickpos

Rickpos>

I dont think this is a possible code within QB (what pos is codeded in)

ibmsystems:

With all due respect, I beg to differ. Qbasic is more than capable of performing this operation.

Basically, there are two ways (possibly more) to go about it.

1. Reset data file position to the beginning, read through it and route data to the backup destination. In essense, an internal copy procedure.

or

2. Close data files and then run a copy operation via shell command.


//Rickpos

you might be right i'm just a QB dummy

I don't see why it couldn't do a backup. Afterall, there is the option of creating a stock table backup...and it does just fine doing so on it's own. I guess we shal just wait to see what Dale's responce is.

Well the deal is that the POS.EXE program has gotten so pig-like that it is now way too large to allow the SHELL command to be used. However what would be possible is to have the POS.EXE program call another program and then have that program do a SHELL.

The other question is what files do you want to back up? If you wish to back up all of the data files that would be super because I only have to use the copy command with wildcards, i.e.

SHELL "COPY " + FL$ + ".* " + PATH$

and all of the data files for a particular register would be backed up. The problem lies in the fact that this could be 50 megabytes of data which will 1. Not fit on a floppy, not even close, and 2. Take a while, during which time, "You ain't gonna be ringing up no sales, honey."

The "no floppy" deal is not a serious problem considering that you could be backing up to a CD, RAM drive, ZIP drive, or over the network and if you only have a floppy, well then, you're screwed.

The time consideration is more serious and will probably limit backups to when you close the register.

Comments?

Hello Dale,
I am writing an F4.exe Program to be used with your F4 feature. Basically it calls on other shells to work. Ive added a backup feature to my menu, but I have a question about something else. Is it better to use Shell to return back into POS or is it better to use End??

So Far My menu looks basically like this:

1. RUN DHPOS SALES APPLICATION
2. Configure Sales Application
3. Review Electronic Journals
4. Reserved For Future Use
5. Reserved For Future Use
6. Backup All POS Files
7. Start Price Station
8. Terminal Monitor
9. Sign-Off



1 shells to pos.exe
2 shells to posconfg.exe
3 shells to menu2.exe which has a list of journals to select from
4 & 5 nothing yet
6 shells to BU batch file
7 shells to lookup
8 shells to remote
9 shells to logon.exe, a screen that signs you out where you have to enter a password to get back into the f4.exe i created


When I am through perhaps someone can test it out.


Tina

Dale,

It wouldn't take long at all to create an external program to reference for the copy. I do agree with you regarding the amount of time it would take transferring several large files.

However, I was thinking about how to best implement this method when another idea came to mind.

Instead of a timed backup function, how about a MIRROR function??

The process would go as such:

* User executes POSCONFG (directly and not from within POS.EXE - for memory conservation sake) and selects "Data Mirroring" option (for example)

* User enters destination path, which can be verified by having POSCONFG create and delete a temp file

* Once destination is verified, the user can press an action key (TAB, etc.) that would begin the operation. A pop-up lets the user know that the initial mirror copy is taking place. POSCONFG shells to a tiny program to execute a "copy *.* x:\destination" and then returns to present an "Operation Completed!" pop-up. ** The user would be responsible for ensuring that would be adequate space on the destination drive. ** This would save some extra check functions.

* User exits POSCONFG and executes POS.EXE

* When POS.EXE opens the files, it would check for the MIRROR boolean flag (for example.) If true, it would also open the data files on the destination drive. After that, the program basically mirrors the transactions, keeping a backup "in real time."

Granted, this is all dependent on memory constraints!! If that won't be an issue, and the feature can be implemented, minor code adjustments would be needed to accommodate the MIRROR function (ie. If mirror feature is on duplicate current transaction.)

To add that extra layer of quality, a small I/O check would catch errors when writing to the files. If an error is detected during a read/write operation, a pop-up would inform the user which set failed.

For example:

(Pop-up)
The main data set failed a read/write operation.
Program will continue with remaining set.
Please address issue ASAP!
[Press TAB to continue]
(Pop-up)

Sample pseudo-code:
------------------------
Write operation to main set -> Check result
If error in result mainerror = true

Write operation to mirror set -> Check result
(Error as well? User is out of luck as both data sets have a problem!
It would be very rare to encounter this, but needs an exception process
to handle it in any event)

If mainerror = true then open pop-up for mainset
else if mirrorerror = true then open pop-up mirrorset

-- end --

If such a feature could be done with the remaining memory space, it would usher in the age of "Advanced DHPOS" as no POS program out there I've heard of has such a feature.

What do you think Dale?

Which suggestion sounds more feasable?

//Rickpos

Tina,

And if the test goes well you may want to consider putting it up on the "3rd Party Software" page.

Assuming that you start the POS.EXE program first and get to your program by pressing [F4] the best way to return to the POS.EXE program is to (in your program) use RUN, i.e.

RUN "POS"

This will not only terminate your program and start the POS program but it will also return you directly to the main menu of the POS.EXE program.

Try it. How does it work? Magic.

No matter how you do the backup thing I would have to add a feature in the POSCONFG.EXE program so folks could enter the PATH to the backup device.

I am assuming by "mirroring" that you mean that the POS program would always open a main data file and a backup file on another device and then write the new data to both files. It would do this so that if one of the files were lost the other file could then be used to restore the lost file.

Let me think, NO.

Unbeknownst to just about everyone, there are a whole pile of data files used for different things and the POS program spends a great deal of time and code to open, write to, and close all those files when they are needed. Different parts of the program will open different parts of the same file to store or retrieve different kinds of data. (The ??????.POS file kind of amazes me sometimes with all the totally different stuff that is jammed in there.)

So to "mirror" the program would have to open all those files twice, write the data twice, and then close each file twice, of course using not quite twice the code. And to make sure this happened I would have to track down every instance in the code of a file being opened, written, and closed.

Then we have the issue of the program sometimes being on stand-alone computers and sometimes on networked computers in which case the program is already writing data to two different places.

So I think I am going to pass on this one and just work on a backup scheme, maybe, someday, eventually.

Yep, I knew it this idea was only going to maybe posibly........ not going to make it and by what i read this feature would do exactly what someone could do with a few mouse clicks

Dale:

As always, Thanks for taking the time to respond.

The idea was rather simple, but I do agree that the code and time needed to get it done properly would not be worth it.

Anyway, it's good to hear from you!

Take care...

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

ibmsystems:

After my initial post, you wrote:

"I dont think this is a possible code within QB (what pos is codeded in)"

Regardless of the outcome, the code IS possible. However, it boiled down to memory availability, moderate code complexity and an inclination to keep DHPOS as simple as possible.

Also, you fail to realize that DHPOS is a DOS based program and backup is not just a few clicks away for some users. That not withstanding, a simple batch file being run after exiting DHPOS for the day would serve the purpose just fine.

//Rickpos