FairCom ISAM for C

Transaction Processing Logs

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.

1. System Status Log - When the application starts up, and while it is running, the transaction management logic keeps track of critical information concerning the status of the application (e.g., when it started, whether any error conditions have been detected, and whether it shuts down properly). This information is saved in chronological order in a system status log, named CTSTATUS.FCS.
2. Administrative Information Tables - FairCom Server ONLY. The FairCom Server creates and uses FAIRCOM.FCS to record administrative information concerning users and user groups.
3. Transaction Management Files - The transaction management logic creates the following four files for managing transaction processing:

   I0000000.FCS

   D0000000.FCS

   S0000000.FCS

   S0000001.FCS

   Note: It is important to safeguard these files, especially the two whose names begin with ‘S’.

4. Active Transaction Logs - Information concerning ongoing transactions is saved on a continual basis, in a transaction log file. A chronological series of transaction logs is maintained during the operation of the application. Transaction logs containing the actual transaction information are saved as standard files. They are given names in sequential order, starting with L0000001.FCS (which can be thought of as active transaction log, number 0000001) and counting up sequentially (i.e., the next log file is L0000002.FCS, etc.).

   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.

5. Inactive transaction logs - Transaction logs that are no longer active (i.e., they are not among the four most recent log files) are either deleted or saved as inactive transaction log files when new active log files are created. The choice of deleting old log files or saving them as inactive log files is made when configuring the Server (see the KEEP_LOGS configuration option). The number of active single user transaction logs is discussed in Single-User Transaction Processing.

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:

1. When the power goes back on, the system will use the existing information to recover automatically, or
2. The Administrator will need to use information saved in previous backups to recover (to the point of the backup) and restart operations.

In This Section Automatic Log Adjustments Automatic Log Size Adjustment Automatic Increase of Active Transaction Logs SystemConfiguration Log Space Reporting SystemConfiguration Log Reporting Enhancements Flush Directory Metadata to Disk for Transaction-Dependent File Creates, Deletes and Renames