>>Even with gentle shutdown, data entry is sensitive to being interrupted, and it's important to let the operator know that either a transaction in process was committed as far as it had been entered (not my preference) or backed out entirely and to always be consistent in this treatment of data in flux. It's important to let the data entry operator know not to throw away the first 5 pages of an order if they walk away for a quick (read 3-4 hour) lunch break in the middle of entering a PO that arrived in the mail.
>
>I like the cattle prod idea < s > Yes, occasionally a forcible shutdown needs to be done, and there is a little occasional data loss. But this happens from other network problems, anyway, so it's not like it's a new event in a user's life. And they do learn, sometimes easily, sometimes the hard way, to adhere to downtime schedules...we always have backups from late the night before, just in case, anyway, so not much will be lost from early morning maintenance...

I see we attended the same classes on managing end users... < g >

Just tell me that you make sure that the backup ran successfully the night before prior to starting your early morning madness (if not, lie to me and start doing it.) I don't feel very secure about doing global nastiness without a solid backup in hand, and I'll often copy the app directory over to another volume or server before doing things if I can, to ensure that i can recover quickly from my own mistakes.

The same logic goes into any of our batch processing - we shoot a pre-close tape before closing order processing, the accounting system, royalties and the like, and make a second backup after succesful completion so that we have a known abilioty to restore to the starting position for the month. I also checkpoint the close process at several points, backing up the data to another disk at each checkpoint, and don't proceed until we've checked some intermediate result reports.