Product Documentation

Database Administrator's Guide

Previous Topic

Next Topic

Pending File ID Overflow

The following warning message indicates that the FairCom Server internal file ID array is getting close to its upper limit:

Pending File ID Overflow

This issue is more common on older FairCom Server versions (before V9.3) because they used file ID numbers each time a c-tree data or index file was physically opened, even if it was just read, not written. Now FairCom DB uses a file ID number only when a file is physically opened and then updated.

Previous Topic

Next Topic

Understanding the "Pending File ID Overflow" Message

The “Pending File ID Overflow” message indicates the FairCom Server internal file ID numbers are getting close to the upper limit.

Each time a transaction controlled c-tree data file or index file is opened, the value of its file ID number is increased. If your system has a large number of files, this value can increase a fair amount with each day of processing.

  • The upper limit for this value is: 4,294,963,200

    If the upper limit is hit, the Server process will shut down.

  • The value at which a “Pending File ID Overflow” warning message first appears is: 4,227,858,432

    The message “Pending File ID Overflow” will be written to CTSTATUS.FCS. A new entry will be logged every time another 10,000 numbers are used.

    From the time the first warning message appears, you have at most 67,104,768 additional data file and index file opens before this value hits this limit.

When the transaction file numbers have been exhausted, error 534 and the following message will be logged in CTSTATUS.FCS:

- User# 00018 Pending File ID overflow: 534

- User# 00018 O18 M18 L58 F-1 Pfffff003x (recur #1) (uerr_cod=534)

If you get error 534, you must do a transaction log reset.

Previous Topic

Next Topic

Determining the Current File ID

To determine the current value of your system’s file ID number, you can use the ctstat transaction snapshot (ctstat -vat). The file ID number is shown as the tfil value (the sample below shows tfil of 233):

ctstat -vat -h 1 -i 1 1 -t -s FAIRCOMS

lowlog curlog lstent lstpnt lstsuc tranno tfil

46 49 3217645 3217445 0 1045589 233

See Also:

Previous Topic

Next Topic

Recommended Actions

The following actions are suggested when the file ID warning message is seen.

First, determine how much time you have before the upper limit is hit and the server shuts down:

  1. Use the ctstat -vat command (as shown in the previous section) on one of your highest number transaction logs to get the current file ID setting. Notice that this setting is only captured at the initial log creation, so it will increase during the processing of the active log.
  2. Execute the ctstat -vat command on transaction logs from the previous day, first with the earliest log for the day and then with the last log for the day.
  3. Calculate the difference in the file IDs. This will give you an idea of how many file IDs you have consumed during a given day so you can determine if you can safely wait until the next scheduled system restart.

In This Section

Transaction Log Reset

Previous Topic

Next Topic

Transaction Log Reset

Once you can safely shut down the system, be sure to shut it down cleanly. The best practice recommendation for shutting down FairCom Server is as follows:

  1. Cleanly shut down the FairCom Server.
  2. Restart the FairCom Server and prevent any users from connecting.
  3. Cleanly shut down the FairCom Server a second time.

    This second shutdown ensures that any pending transactions in the current logs are processed.

  4. Now you may safely move the existing transaction logs to a new location. Move the following files: *.FCS and *.FCT
  5. Copy the FAIRCOM.FCS file back to its original location.

    The only *.FCS to keep in your current directory is FAIRCOM.FCS.

    FAIRCOM.FCS stores user information such as user IDs, so if you don’t keep this file, you will have to recreate your users.

  6. Restart the FairCom Server and it will create new transaction logs from scratch.

    You may confirm this by looking at the file names of the transaction logs (on Unix/Linux: ls L*.FCS) and you should see the first L*.FCS has been reset to number L*00001.FCS

  7. The Old logs saved from step 4 may be discarded

If you would like to confirm that the file ID value has been reset, you can execute the ctstat -vat command again. You should see the file ID value is now a very low number.