Disk Maintenance with Enabler

Created: 29 April 2009. Last Reviewed: 29 April 2009

Call external batch file for disk maintenance when Nibbler restarts during EOD

Enabler v4.46 introduced a new option to the Communications Setup screen to call an external batch file for disk maintenance when nibbler restarts during end of day.

Processing transactions/Comms> Communications

• Disk maintenance batch file

This field is only available when “Restart Nibbler During EOD” is turned on and allows you to enter the <path>\<filename> to an external command file that will be run when nibbler restarts during the EOD.

Eg: [\\eee-server\shared folder\batchfile.cmd]. If this field is left blank, nothing will be run, otherwise the command file will be executed and once completed, Nibbler will be restarted.

The purpose of this file being run is really so that various disk maintenance functions can be run. This largely replaces the disk maintenance as part of purge and backup - which since Windows 95/98 hasn't really done anything other than reindex anyway!

There are two disk / file system problems that occur regularly in stores (and even HO server) which are the enemy of Enabler:

1. File system corruption (which is resolved by chkdsk /f). This will occur frequently in retail stores because the machines get a hard life, staff switching them off etc.

2. File system fragmentation. The small incremental growth that occurs in Enabler database and MDX files

makes Enabler machines susceptible to extreme file fragmentation, and this severely impedes performance. This is NOT a flaw in Enabler, it is just a characteristic of the environment.

This is a very simple mechanism to assist customers in eliminating these issues. This is a simple approach, there are plenty of 3rd party tools out there that customers could use instead including sophisticated network administration tools etc. This technique makes use of features already in the O/S.

An example command file would be something like the one below. It has the ability to send email alerts to head office; it relies on the command line mailer bmail.exe which is freely downloadable to do this. http://www.beyondlogic.org/solutions/cmdlinemail/cmdlinemail.htm

--start sample

@echo off

set smtpserver=192.168.1.1

set smtpsender=diskalert@companyname.com.au

set smtprecipient=diskmonitor@companyname.com.au

chkdsk c:

if not errorlevel 3 goto DoDefrag

echo Y|chkdsk c: /f

bmail -s %smtpserver% -t %smtprecipient% -f %smtpsender% -a "File System Corruption Found" -b "Found file system corruption on %computername% C:"

goto endd

DoDefrag

defrag c:

endd

The three SET lines near the top most definitely need to be customised: the SMTP server address needs to be the customer's mail server, the sender address can be any address within the customer's domain, and the recipient address would be the person at the customer's head office who should receive the alerts.

The next step is a read-only chkdsk. If errors are found it schedules a chkdsk /f at the next reboot and sends a simple alert email. If there are no errors it performs a defrag.

The above will work on Windows XP. It probably won't work on Vista unless UAC is disabled. It should also work on Windows 2003 server. Not sure about Windows 2000, but customer's with Windows 2000 could easily customise the batch file to their requirements.

Other customisations may be required: Enabler might not be on C: - in which case chkdsk and defrag need to be changed to operate on the appropriate drive. If Enabler is NOT on the Windows system drive, then the chkdsk /f can probably run immediately rather than during a reboot. Customers might wish to chkdsk and defrag more than just 1 drive. Customers might want to include an automatic reboot after the chkdsk /f, this would be highly dependent on each environment.

Note: This batch file is a SAMPLE ONLY - customers must adjust to their needs, or seek chargeable support from Magenta Retail to assist them if required.

Note - the first night this process is run it WILL take a long time as the file system is likely to be highly fragmented. Thereafter it will run much more quickly as the defrag won't have as much work to do each night.

For many clients we would anticipate they would put the batch file on the HO or EEE server and configure Enabler to run something like \\eee-server\shared folder\batchfile.cmd (or whatever). Thus there is no manual rollout of the batch file. Stores MUST have ONLY read-only access to this share/directory/file as it would otherwise give a malicious store staff member unlimited ability to destroy all tills in all stores overnight!!!! Customer's with differing store environments can include multiple batch files in the directory at HO and use global config to configure each branch to run the appropriate version of the batch file. This batch file is an opportunity for clients to copy other files, patches, reports, you-name-it from HO to stores, run other processes in stores... the possibilities are almost unlimited.

Customers could also use this batch file to self-replicate it locally to stores - after the first night or two they could change the Enabler configuration to run the store local copy rather than download form HO every time - but the file is so small that running from HO shouldn't matter.

Customers without WAN/VPN - up to them to deploy the batch file to stores - could be achieved with tweaks to FTP scripts or ISLBatch or manually.