The FairCom transaction management logic creates special system files to record various kinds of information necessary to recover from problems. The majority of this section applies to both the FairCom Server and single-user (stand-alone) transaction processing enabled applications; therefore, the generic term application refers to both the FairCom Server and a single-user application.
The following list details the files created:
Note: To be compatible with all operating systems, the names for all these files are upper case characters. For a complete backup, be sure these files are saved when appropriate (i.e., backed up) and used for recovery if necessary. However, except for FAIRCOMS.FCS, do NOT include these files in your dynamic dump script.
Note: It is important to safeguard these files, especially the two whose names begin with ‘S’.
By default, the transaction management logic saves up to four active logs at a given time. When there are already four active log files and another is created, the lowest numbered active log is either deleted or saved as an inactive transaction log file, depending on how the FairCom Server is configured (see the term “Inactive transaction logs” below).
Every new session begins with the application checking the most recent transaction logs (i.e., the most recent 4 logs, which are always saved as “active” transaction logs) to see if any transactions need to be undone or redone. If so, these logs are used to perform automatic recovery.
An inactive log file is created from an active log file by renaming the old file, keeping the log number (e.g., L0000001) and changing the file’s extension from .FCS to .FCA. The application Administrator may then safely move, delete, or copy the inactive, archived transaction log file.
When an apparently old log file is encountered while transaction processing attempts to create the next log file (e.g., log 5 is about to be created, but a log 5 already exists), FairCom DB attempts to first rename the old log (from .FCA to .FCQ) and then attempts to create the new log. If this succeeds, then the system continues without interruption (although an entry is made in CTSTATUS.FCS and on server systems a notice of this event is routed to the console). If the renaming does not cure the problem then a NLOG_ERR (498) will be returned and the system will terminate due to a failed transaction write.
Note: The *.FCA files should be saved for use in cases when the .FCS files are needed for a backup. In the event of a system failure, be sure to save all the system files (i.e., the files ending with .FCS). CTSTATUS.FCS may contain important textual information concerning the failure.
When there is a system failure due to power outage, there are two basic possibilities for recovery: