IN FOCUSFileshare rollforward recovery trades write-time overhead for backup-based recovery
Fileshare’s Recovery Utility can restore updates after a system failure, but only when those updates were written to a recovery log. Advanced logging supports two distinct recovery strategies: rollback, which repairs the files present when Fileshare failed, and rollforward, which begins with backup copies and reapplies logged changes. Fileshare Recovery [1]
Read the full briefing
Scope: Rocket Enterprise Developer 12.0 for Eclipse on Linux/UNIX; Fileshare data-file recovery.
Fileshare’s Recovery Utility can restore updates after a system failure, but only when those updates were written to a recovery log. Advanced logging supports two distinct recovery strategies: rollback, which repairs the files present when Fileshare failed, and rollforward, which begins with backup copies and reapplies logged changes. Fileshare Recovery
To enable advanced logging for rollback alone, Rocket documents:
FS /d dbase.ref /ltf logtrans.datTo make that log compatible with both rollback and rollforward recovery, add /ltt f:
FS /d dbase.ref /ltf logtrans.dat /ltt fHere, /d identifies the database reference file and /ltf identifies the advanced recovery log. The /ltt f setting is therefore not merely a recovery-time option: Fileshare must generate a rollforward-compatible log while normal processing is running. Enabling Advanced Recovery Logging
The operational tradeoff concerns disk flushing. Rollback recovery is normally faster because it attempts to recover the files as they existed at the failure point. However, recovering from operating-system, device, or power failures—where cached data might not have reached disk—requires Fileshare to have started with write through (/lw) and flush on commit (/fc). Rocket notes that these options affect performance because an operation writes data to both cache and disk. Rollforward-only recovery does not require /lw or /fc. Advanced Rollback Recovery
Advanced rollforward recovery instead handles all documented failure types without that extra flushing requirement. Recovery consists of replacing the damaged data files with the current backup copies and running:
fs /r dbase.refFileshare then reapplies eligible logged updates. Recovery time depends on backup frequency: an older backup leaves more logged work to replay. A user exit, fsexitproc.cbl, can control which files are included. After recovery, archive the existing logs; otherwise, the next Fileshare startup can fail with FS302-S Unable to continue - A log file already exists. Advanced Rollforward Recovery
Takeaway: Decide the recovery model before failure: /ltt f plus current backups enables rollforward recovery without /lw and /fc, while rollback protection against unflushed-cache failures requires those higher-overhead options.