Auto Maintainance is involved in preventative maintainance and general housekeeping. It is designed to automate some of the housekeeping operations that need to be performed periodically
Operation
The design of the maintainance needs to remember:
- Very low volume retailers probably do not need this at all
- Computers are not always left on for background work overnight and we cannot just take over during the day
- Some of these tasks will be very infrequent, we need to be careful not to cause a support call when it is normal operation
- Variations in site poilicy/requirements
- In general, give users the chance to take action themselves, but set boundaries for those that continue to ignore warnings.
- Some tasks require exclusive access to database/files so cannot easily be done in the background.
AutoMaint is enabled by having the table AutoMaint in the database and the setting SettleAutoMaint defined. If SettleAutoMaint is 0/undefined it will currently disable the system, but a future release will have zero mean default mode.
Setting SettleAutoMaint definition
- "no" - disable completely
- 0 - disable completely currently, will mean same as "1" in future release
- 1 - default mode, enable but not aggresively.
- 3 - Aggressive Mode.
When a settlement close operation is performed and automaint is pending, the system will
- Display a screen saying AutoMaint is about to start
- Give user 60 seconds to stop this from happening
- Start scheduled tasks
- If enabled, power PC off when complete
Automaint will perform any tasks in the MaintList table regardless of how the commands got there. In addition, the POS has automated triggers to insert the tasks when thresholds are reached.
The list of pending Maintaince is available on fdlmgmt and also via maint(list(display))
Temp Files
With AutoMaint enabled, the check counts to see if over 9,000 files are present. The user continues to receive a warning with 2,000 files. When the 9,000 file threshold is reached, AutoMaint is scheduled (mcode=103).
The task simply deletes all .TMP files over 7 days old. This should address most sites, and if not then cleanup is best performed externally by Disk cleanup. Disk cleanup can be automatically called but has setup requirements that make it hard to automate.
Self Test
If mcode=108, the task deletes the file MaintCodeSelfTest.tmp if it exists. Users of the self test function need to create this file themselves
Database Compression
(Mcode=100) When the database exceeds the size and is first detected, the user receives a nice warning saying Maintainance has been scheduled - basically just informing them. After the initial warning, the startup warning process is the same. ie sites that never settle/close will get stronger warnings.
When the task executes, it will simply perform the equivalent of storage(compress)
Database cleanup
There is no auto detection yet- still WIP
(mcode=102) When executing the task invokes maint(archive(*)) which cleans up internal tables that are safe to clean. It also purges customer specific tables. See the code for exact list and operation.
Trading data (eg Sales) has a more restrictive logic than performed archive directly via quickcode
- The lane selects records it wishes to archive (MaintArchiveSales default 750 days). This logic has also been strengthened to avoid common date wrong situations.
- It sends the list to Head Office requesting approval
- Head office must return yes, otherwise record remains
- Head office systems will use the TBS field on sales to indicate if lane archive is permitted or not. If the field is not present, or has null/0, HO will verify the date is over MaintArchiveSales (from server) days old.
- Archived sales will be saved to a file(s) in the Pos Folder before being removed.
- Equivalent PosCommand is maint(sale(... archive(1) paranoid(1) delete))