File Management

AUTO_CLNIDXX

AUTO_CLNIDXX YES

Optionally permits automatic CLNIDXX() during file open when a transaction high water mark, hghtrn, is found at file open to exceed the current transaction number.

The disadvantage of this approach is that it is necessary to traverse all the index leaf nodes, writing those to disk that have been cleaned. For a very large index, this could be time consuming. Only customers that have experienced problems with HTRN_ERR (520) are candidates to use this configuration option. Also, internal, administrative requests to open the file read only (say as part of a dynamic dump or ctFILBLK() processing) are denied if the file is in the middle of an on the fly CLNIDXX().

CTSTATUS.FCS receives messages concerning on the fly CLNIDXX(). Both success and failure are noted.

 

AUTO_MKDIR

AUTO_MKDIR  <YES | NO>

When creating a c-tree data or index file, FairCom DB can automatically create directories for the filename that do not exist.

Programmers can call the CreateFileXtd8 file create function and set the ctAUTOMKDIR bit in the splval field of the xcreblk parameter to cause directories that do not exist to be created when creating that file.

Default: No

 

BLOCKING_OPEN_RETRY_DEFER

BLOCKING_OPEN_RETRY_DEFER <# of milliseconds between retries>

Configures the delay in milliseconds between retries when retrying a failed file open.

Note Specifying a large BLOCKING_OPEN_RETRY_DEFER can slow performance, so FairCom generally recommends using the default BLOCKING_OPEN_RETRY_DEFER setting, and instead tweaking the total number of retries using BLOCKING_OPEN_RETRY_LIMIT.

 

BLOCKING_OPEN_RETRY_LIMIT

BLOCKING_OPEN_RETRY_LIMIT <maximum # of retries>

Configures the maximum number of retries allowed when retrying a failed file open. You can tweak this number to find your preferred balance between the time spent retrying and the number of opportunities for success.

A value of 0 means infinite retries.

Retries will be stopped if the server shuts down or an administrator terminates the connection.

Default: 10

See Also: You can use BLOCKING_OPEN_RETRY_DEFER to configure the time delay between retries, though this is not generally recommended.

 

CHECK_FILENAME_VALIDITY

CHECK_FILENAME_VALIDITY YES | NO

FairCom DB V12 and FairCom RTG V3 forward no longer support “Drive-Relative” Paths by default. The purpose is to ensure predictable, safe, and secure behavior. and all files must be opened using an absolute file path. For backwards compatibility, you can restore prior behavior by adding the CHECK_FILENAME_VALIDITY NO configuration option to ctsrvr.cfg.

On Microsoft Windows,® FairCom uses the concept of a "Drive-Relative Path" as an easy way to specify a relative path to where the database is installed on a drive. The path includes a drive letter without a following backslash. For example, C:mydirectory\test.dat is a drive-relative path because there is not a backslash after the drive specification (C:). On the other hand, C:\mydirectory\test.dat is not a drive-relative path; it is an absolute path. A drive-relative path is relative to whatever happens to be the current working directory of the database on that drive. A process may have a current working directory for each drive.

For example, if the working directory on C: is C:\FairCom, then the drive-relative path C:mydirectory\test.dat is equivalent to C:\FairCom\mydirectory\test.dat while the absolute path C:\mydirectory\test.dat is unaffected.

Drive-Relative Paths can cause behavior that is unpredictable, unsafe, or unsecure. Thus, the database now returns an error when a Drive-Relative Path is specified in a call to create or open a file.

Compatibility Notes: This modification breaks compatibility by disallowing certain file names that used to be allowed. The preferred solution is to use a full path. (A less preferable solution is to use the configuration option CHECK_FILENAME_VALIDITY NO in ctsrvr.cfg. This option can also be changed at runtime. In standalone mode, this behavior is controlled by a field in the CTGVAR structure, ctCheckFileNameValidity. Setting it to a non-zero value enables the check; setting it to zero disables the check.)

 

CMPREC_TYPE

CMPREC_TYPE  < TYPE >

Specifies the type of data compression type for files. Several algorithms are supported.

CMPREC_TYPE < ZLIB | RLE | USER >

The following compression types are currently supported:

  • ZLIB - General purpose compression from the zlib compression library.

Note the ZLIB compression algorithm will impact performance. A Best Practice is to consider using RLE compression. It's quick and easy to test both ZLIB and RLE, but in most cases we have found RLE to be the better combination of reduced space and minimal performance overhead.

  • RLE - A fast proprietary run length encoding optimized for data that is null character, space or zero (0) padded (sparse data files).
  • USER - A user defined compression algorithm, requiring an associated .DLL (or shared object)

With USER compression, these additional keywords must be entered in the configuration file in the order shown below, and a DLL name is required.

CMPREC_TYPE < USER >
CMPREC_VERSION < a number >= 1 >
CMPREC_DLL < name of DLL >

See Also

 

COALESCE_TRNLOG

COALESCE_TRNLOG

Attempt to combine the deleted space with adjacent deleted space that already exists in ctTRNLOG files that do not have a RECBYT index (default is OFF). Combining deleted space can reduce fragmentation.

To enable this behavior, either:

  • Add the server keyword COALESCE_TRNLOG ON

or

  • Set the global variable ctcoaltran = YES in a standalone compile.

 

COMPRESS_FILE

COMPRESS_FILE  <filename>

Forces FairCom DB to create data files whose names match the specified name with data compression enabled. The file name may include wildcard characters (see FairCom DB Standard Wildcards).

A file whose name matches the keyword is created as a variable-length data file even if the create option specifies that it is a fixed-length data file. Such a file is still restricted to containing records that have the defined fixed-record length.

The logic has been changed so that the COMPRESS_FILE keyword does not enable data compression for a data file that is created with resource support disabled. This prevents a rebuild from failing with error 484 (could not open sort work file).

See Also

  • CMPREC_TYPE in the c-tree Server Administrator’s Guide.

 

FILE_CREATE_MODE

FILE_CREATE_MODE <mode>

On Unix systems, FairCom DB defaults to a permission mode of 0660 (read/write access for owner and group; no access for world) for the files it creates.

When using FairCom DB, the permission mode assigned to files can be set with the server configuration keyword FILE_CREATE_MODE to specify the desired file permission mode.

Example

;Set read and write permission for owner
;and no permission for group and world.
FILE_CREATE_MODE 0600

Note On Unix systems, the system’s umask setting also affects the permission mode assigned to a file when it is created. If the umask setting is non-zero, the specified permissions are removed from the file’s permission mode.

 

FILE_HANDLES

FILE_HANDLES

This keyword is used on Unix system to change the number of file handles (at O/S level) that the O/S allows to be used by the FairCom Server.

No Default

 

FILE_PERMISSIONS

FILE_PERMISSIONS groupID#pmodeA#...#pmodeZ

Permits default file permissions to be assigned to one or more groups including two special groups: WORLD and OWNER. The primary need for this capability is to enforce permission flags on files that have already been created without a permission mask (i.e., the permission mask is zero at file create). A zero permission mask is equivalent to granting everyone all rights:

OPF_ALL | GPF_ALL | WPF_ALL

Note ALL does not include the special NOPASS flag that permits a file to be opened for reading without supplying the file password. To grant NOPASS permission, it must be included explicitly.

  • groupID is the name of a user group or the special groups WORLD and OWNER. The server does NOT verify that the groupIDs actually exist.
  • pmode entries are symbolic names for the possible permission flags: READ, WRITE, DEF, DELETE, ALL, NOPASS and NONE. NONE should not be used with any other permission flags. It indicates no permissions are granted. Granting a permission of WRITE, DEF or DELETE is equivalent to granting all of the lesser permissions, thus DELETE and ALL are equivalent. For example, #READ#WRITE is equivalent to #WRITE. The groupID and pmode entries are case insensitive.

The WORLD entry applies to file opens by a user whose group(s) do not match any of the specified groups for those files without an explicit permission mask. If there is no WORLD entry, then WORLD permissions default to ALL. The OWNER entry applies to file opens by the users that created the files without an explicit permission masks.

Consider the following entries, and assume all the files in use did not have explicit permission masks at creation. Files with explicit permission masks (except for OPF_ALL | GPF_ALL | WPF_ALL) at creation are not affected by these FILE_PERMISSIONS entries.

FILE_PERMISSIONS OWNER#DEF
FILE_PERMISSIONS inventory#WRITE
FILE_PERMISSIONS ACCOUNTING#write#nopass
FILE_PERMISSIONS WORLD#NONE

In this example, the owner of a file will have READ, WRITE and DEF permissions. The owner of the file cannot delete the file. Members of the INVENTORY group have READ and WRITE permissions. Members of the ACCOUNTING group have READ and WRITE permissions and may open a file without its password (and receive READ permission only). A user who is not the owner of a file and not a member of the ACCOUNTING or INVENTORY groups will be assigned WORLD permissions, which in this case is NONE. NONE means the file cannot be opened.

If a user belongs to multiple groups, and two or more of its groups are specified with the FILE_PERMISSIONS keyword, the permissions granted to the user will be the union of the individual group permissions. However, if the user is the OWNER of the file, it receives OWNER permissions that default to ALL.

 

FILESYS_COMPRESS_FILE

FILESYS_COMPRESS_FILE <filename>

The FairCom Server configuration option FILESYS_COMPRESS_FILE can be used to enable file system compression on files whose names match the specified filename, which can include wildcard characters. The compression is enabled at the time that the file is created. This option only affects data and index files, not transaction logs or CTSTATUS.FCS.

Limitations

Currently, support for file system level compression is implemented only on Windows systems, using the built-in compression feature of the NTFS file system.

https://docs.microsoft.com/en-us/windows/win32/fileio/file-compression-and-decompression

Example

FILESYS_COMPRESS_FILE custmast.dat
FILESYS_COMPRESS_FILE custordr.dat
FILESYS_COMPRESS_FILE ordritem.dat
FILESYS_COMPRESS_FILE itemmast.dat

 

HUGE_TO_SEG_MB

HUGE_TO_SEG_MB  <segment size in MBs> [#<maximum number of segments>]

Note Segmented Tables have been deprecated.

Force any huge file to be created as a segmented file.

On systems that do not support files greater than 2 GB or 4 GB, FairCom DB can still support huge files by creating tables as segmented files. The size of each segment stays below the OS maximum file size limit, but the aggregate size exceeds the limit.

The maximum number of segments is optional and defaults to sixteen (16). For example, to specify a segment size of 1 GB, and a maximum of 8 segments for a total file size of up to 8 GB, an entry would look like

HUGE_TO_SEG_MB  1024#8

If the file has been created with a maximum size in the XCREblk structure (see parameters for the extended create file function), then the number of segments will be computed to accommodate the maximum size.

Note If dynamic dumps are used, then it would be appropriate to use the !EXT_SIZE script option so that the dump stream file would also be broken into automatic segments.

 

INHERIT_FILE_PERMISSIONS

INHERIT_FILE_PERMISSIONS YES | NO

By default, FairCom DB file permissions are inherited from world to group to owner. For example, if the SECURITY() function is called with a mode of SEC_FILEMASK and a permission mask of WPF_READ, GPF_READ and OPF_READ permissions are turned on. However, note that if GPF_NONE is specified, the permissions are not passed on to the group (and to the owner).

Note Changing this option does not affect inheritance of permissions on files whose permissions have already been set. It only affects the inheritance of permissions when they are set at file create time or by calling the SECURITY() function with a mode of SEC_FILEMASK.

Default: YES

 

KEEPOPEN_CLOSE_RETRY_LIMIT

KEEPOPEN_CLOSE_RETRY_LIMIT  <limit>

Determines the number of times to retry the close operation before failing.

KEEPOPEN_LIST logic has internal checks to determine if the file open or create function returned an insufficient file control block error. If so, it checks if a KEEPOPEN file is available to close, closes it, and retries the open or create operation. The FairCom Server configuration option KEEPOPEN_CLOSE_RETRY_LIMIT determines the number of times these functions retry the operation before failing.

Default: 3

The default value for KEEPOPEN_CLOSE_RETRY_LIMIT is appropriate for most situations. You may want to consider increasing it if you experience errors 165.

See Also

 

KEEPOPEN_FLUSH

KEEPOPEN_FLUSH  YES | NO

When a data or index file is closed, the c-tree server will flush updated cache pages and set the update flag of the file to zero under the following conditions:

  • The file does not use the full transaction logging (ctTRNLOG) filemode.
  • No other users have the file opened.
  • The KEEPOPEN_LIST option is set to keep the file open.
  • The configuration option KEEPOPEN_FLUSH YES in ctsrvr.cfg is set..

Default: NO

 

KEEPOPEN_LIST

KEEPOPEN_LIST  <file spec>

<file spec> can be a file name or a partial name including wildcard characters. See FairCom DB Standard Wildcards. Upon file creation or physical open, (1) if the file name matches a <file spec> and (2) if the file is a data file and (3) if the data file creation/open is part of an ISAM creation or open, then the KEEPOPEN attribute is attached to the data file and its indexes.

KEEPOPEN_LIST logic has internal checks to determine if the file open or create function returned an insufficient file control block error. If so, it checks if a KEEPOPEN file is available to close, closes it, and retries the open or create operation. The FairCom Server configuration option KEEPOPEN_CLOSE_RETRY_LIMIT determines the number of times these functions retry the operation before failing. It defaults to 3. The default value for KEEPOPEN_CLOSE_RETRY_LIMIT is appropriate for most situations. You may want to consider increasing it if you experience errors 165.

To specify multiple files, repeat the KEEPOPEN_LIST keyword for each file. You can specify KEEPOPEN_LIST as many times as you need. The only limitation is only one file per entry. For example:

KEEPOPEN_LIST custmast.dat
KEEPOPEN_LIST itemmast.dat
KEEPOPEN_LIST ordritem.dat
KEEPOPEN_LIST tell*.dat

Memory files have the option of staying open after all users have closed the file. The motivation for keeping memory files open is to avoid losing the contents of the file so that subsequent users can open the file and read and/or update the contents.

When a non-memory file is physically closed, c-tree removes the data cache and/or index buffer entries associated with the file. A file is physically closed when all users that have the file open close the file. For a non-memory file, keeping the file open even after all users have closed the file permits the associated cache/buffer entries to stay in memory. Then subsequent opens have the benefit of the cache contents.

ISAM data files and their associated indexes can also be designated as KEEPOPEN files. The motivation is to keep the files in the data cache and index buffers. It also eliminates a physical open when the next user opens the file. If all users have closed a KEEPOPEN file, then ctCLSNAM() can be called to close the data file and associated indexes.

Files to be treated in this manner are specified in the server configuration file with one or more entries of the form shown above.

Note If a file is kept open by KEEPOPEN_LIST, a call to ctFILBLK does not block access to it. Calling CloseCtFileByName will close the file and it will remain closed until unblocked by a subsequent ctFILBLK call. (The FairCom DB Developer Guide explains the ctFILBLK and CloseCtFileByName functions.)

Behavior Change for V10.3.1 and Later

For a data or index file that does not use full transaction logging (ctTRNLOG), FairCom Server now flushes updated cache pages and sets the update flag to zero for the file when the last user closes the file and the KEEPOPEN_LIST option keeps the file open.

The configuration option KEEPOPEN_FLUSH NO can be used in ctsrvr.cfg to disable this flushing behavior and revert to the behavior prior to V10.3.1, although this is not recommended.

This is a change from previous behavior: When FairCom Server's KEEPOPEN_LIST configuration option was in effect for a c‑tree data or index file that was not under transaction control, FairCom Server kept that file open after the last user closed the file. Updated data and index cache pages remained and were not written to disk before the call to close the file returned to the caller. This caused unnecessary data integrity risk should the FairCom Server abnormally terminate while the file remained open. The file is likely to fail to open with an FCRP_ERR error, 14, under such scenarios.

See Also

 

LEAF_NODE_READ_LOCK

 

MATCHING_SEGMENT

MATCHING_SEGMENT <RENAME | DELETE | OVERWRITE | ERROR>

The segmented file logic behaved as follows when an attempt to create a new file segment encountered an existing segment with the same name:

  • If the existing segment matched the host file’s file ID and other attributes, then the existing segment was simply overwritten.
  • If the file ID did not match, then an error was returned and no more records could be added to the file.

Overwriting a matching segment could cause a problem because the existing data is simply left in place until new records overwrite the data.

In addition to different defaults, the behavior for a matching segment (i.e., segment’s file ID matches the host file’s unique ID), is quite different than for a non-matching segment. For a matching segment, if RENAME is in effect and the rename fails, then a delete is attempted. If a delete fails, then the segment is overwritten. The error option must be explicitly requested. For a non-matching segment, if either rename or delete are in effect and they fail, then an error occurs (and overwrite is not an option).

CTSTATUS.FCS entries are made when one of these unexpected segments are encountered. When a rename occurs, the segment’s name is modified by adding the hexadecimal representation of the system’s time in seconds to the end of the file name. For example,

mydata.s04

might become

mydata.s04.4465f728

where 0x4465f728 is the system time in seconds from some arbitrary starting point.

Default: RENAME

See Also

 NONMATCHING_SEGMENT

 

MAX_FILES_PER_USER

Client file information, on both client and server side, is automatically resized when:

  • A file open or create uses a file number beyond the existing client file range.
  • A new file number is assigned with automatic file number assignment (for example, OpenFileWithResource() with a -1 filno).

A configurable limit on files per user is enforced when this auto resizing comes into effect. An open/create which returns a FINC_ERR (604) implies that the create succeeded on the FairCom Server, but the client could not allocate memory for the local file info, and the newly created file has been closed.

Stand-alone applications support automatic resizing of file control information up to the limit imposed by ctMAXFIL, which defaults in ctoptn.h to 110. If ctMAXFIL is not defined, the limit defaults to 1024 files/FCBs.

Note If a filno beyond the existing file range causes a resizing, the new number of files supported goes from 0 to filno + MAXMEMB + 1, with FCBs allocated for all potential file numbers in the range. Use automatic file number assignment for maximum memory efficiency.

For example, if InitISAM() requests 100 files and OpenCtFile() uses file number 1000, resizing changes the number of files supported to 1000 + MAXMEMB + 1, or 1032. All the files between 100 and 1000 are now available. By contrast, if an automatic file number assignment causes resizing, the file number range is only extended by MAXMEMB + 1. If InitISAM() requests 100 files and OpenFileWithResource(-1,...) causes resizing, the number of files supported would increase to 132.

Default: The default value of MAX_FILES_PER_USER is the same as the server's maximum supported FILES value (which is update 1 million open files). You can use the MAX_FILES_PER_USER option to set a connection's maximum number of open files to a smaller value.

See Also

FILES

MAXMEMB

 

Maximum Index Members per File (MAXMEMB)

The default for the MAXMEMB (the number of index members per single index file) has been updated to 127 allowing a larger number of segments per index.

We now define ctMAXMEMB in ctopt1.h instead of in ctopt2.h, because ctport.h references ctMAXMEMB and it is included before ctopt2.h.

We also define MAXMEMB to ctMAXMEMB in ctopt1.h.

 

MAX_KEEPOPEN_FILES

MAX_KEEPOPEN_FILES <maximum # of KEEPOPEN files>

Sets a limit on the number of files that can be kept in the KEEPOPEN state (meaning the file has been closed by all connections, but the server is keeping the file open for reuse).

This prevents potential negative performance impacts from keeping too many files in the KEEPOPEN state.

Default: 1000

 

MAX_REBUILD_QUEUE

MAX_REBUILD_QUEUE <max_queue_size>

FairCom Server supports an option to use a worker thread to sort the keys read from the data file. The rebuild thread reads records from the data file and constructs key values, which it passes to the sort thread using an inter-thread queue. After all the key values have been passed to the sort thread, the sort thread sorts the key values and passes them back to the rebuild thread in a second queue.

This option is enabled by specifying MAX_REBUILD_QUEUE <max_queue_size> in ctsrvr.cfg with a positive value. The value is a number in bytes indicating the maximum size of the queue used to pass the keys to the worker thread. MAX_REBUILD_QUEUE defaults to 100 MB. A 64-bit server has a limit of 4 TB - 1 for this setting, and a 32-bit server has a limit of 4 GB - 1 for this setting.

For example, in one test comparing V10 rebuild performance with its defaults (16,000 bytes of SORT_MEMORY and no MAX_REBUILD_QUEUE support) to this optimized rebuild available in V11, rebuilding a 17 GB data file completed in an average of 1,816 seconds, and the optimized rebuild completed in an average of 623 seconds, which is 66% faster (about 1/3 the time of the original rebuild).

<maximum_queue_size> is interpreted as bytes by default, or it can be specified with a suffix of KB, MB, or GB (e.g., 10 MB).

See Also:

 

MAX_VIRTUAL_FILES

MAX_VIRTUAL_FILES  <Maximum files>

An integer argument specifying the maximum number of virtual files that may be opened at one time.

A <Maximum files> value of -1 forces all files as ctPERMANENT.

Default: 500

 

MEMFILE_MAX_BINS

MEMFILE_MAX_BINS <bins>

The maximum size of a memory file determines the number of hash bins that FairCom DB allocates for the memory file. However, there is a hard limit on the number of hash bins for a memory file. Previously, this limit was set at compile time to 65536. This configuration option is used to set the maximum number of hash bins allowed for a memory file at run time. This may be necessary for efficient access to very large memory files.

Default: 65537

 

MEMORY_FILE

The FairCom Server supports creating memory files using a server configuration keyword. This feature allows developers to create memory files using their existing application code, provided that the file is created using an Xtd8 create function such as CreateIFileXtd8(). To create a memory file using the server configuration keyword, specify one or more entries of the form:

MEMORY_FILE <file name>#<max size>

where the file name may include wildcard characters (see FairCom DB Standard Wildcards) and the maximum size is optional. If no maximum size is specified, then 4GB is used. If a file is being created and matches one of the MEMORY_FILE file name entries, then it will be created as a memory file unless it is a superfile host, superfile member, mirrored, segmented or partitioned file.

To cause all possible files to be created as memory files, add the following configuration entry:

MEMORY_FILE *

The MEMORY_FILE keyword is useful to quickly test how a file or set of files will behave as memory files.

 

NONMATCHING_SEGMENT

NONMATCHING_SEGMENT  <RENAME | DELETE | ERROR>

The segmented file logic behaved as follows when an attempt to create a new file segment encountered an existing segment with the same name:

  • If the existing segment matched the host file’s file ID and other attributes, then the existing segment was simply overwritten.
  • If the file ID did not match, then an error was returned and no more records could be added to the file.

Overwriting a matching segment could cause a problem because the existing data is simply left in place until new records overwrite the data.

In addition to different defaults, the behavior for a matching segment (i.e., segment’s file ID matches the host file’s unique ID), is quite different than for a non matching segment. For a matching segment, if RENAME is in effect and the rename fails, then a delete is attempted. If a delete fails, then the segment is overwritten. The error option must be explicitly requested. For a non matching segment, if either rename or delete are in effect and they fail, then an error occurs (and overwrite is not an option).

CTSTATUS.FCS entries are made when one of these unexpected segments are encountered. When a rename occurs, the segment’s name is modified by adding the hexadecimal representation of the system’s time in seconds to the end of the file name. For example,

mydata.s04

might become

mydata.s04.4465f728

where 0x4465f728 is the system time in seconds from some arbitrary starting point.

Default: ERROR

See Also

MATCHING_SEGMENT

 

RECYCLE_BIN

The recycle bin is configured with SUBSYSTEM  CTFILE RECYCLE_BIN . This subsystem configuration option supports the following options:

  • recycle_folder_name: directory name where the recycle bin is stored and can be absolute or relative. If relative, the directory is relative to the server's LOCAL_DIRECTORY configured directory or current working directory if LOCAL_DIRECTORY is not used.
  • purge_frequency_minutes: time in minutes between checks for files that should be purged from the recycle bin.
  • max_file_age_days: maximum number of days a file is kept in the recycle bin.
  • max_folder_storage_size: maximum total byte size of the files in the recycle bin. If deleting a file causes the recycle bin to go over the limit, files are deleted until the size is below the limit.

Example

subsystem ctfile recycle_bin {
    recycle_folder_name        deleted_files
    purge_frequency_minutes    60
    max_file_age_days          30
    max_folder_storage_size    1 gb
}

MONITORING

The statistic utility, ctstat supports a deleted_files option listing the total size and detail list of files currently in the recycle bin.

Example

ctstat  -deleted_files -u ADMIN -p ADMIN -s FAIRCOMS -i 1 -h 1 -t

Thu Dec  9 15:01:48 2021
Total file size: 917500 for 4 file(s)
Deleted file of size 131071 deleted\1639081086.20211209\qatranrepl097.sup.992
Deleted file of size 131071 deleted\1639081086.20211209\qatranrepl097.sup.998
Deleted file of size 327679 deleted\1639081086.20211209\qatranrepl097.sup.1017
Deleted file of size 327679 deleted\1639081086.20211209\qatranrepl097.sup.1026

NEW SERVER FILES

Two new files are required for tracking inactive files in the recycle bin. RECBINDT.FCS and RECBINIX.FCS are transaction-controlled data and index files retaining data about the current recycle bin state. The data file contains a state record for each deleted file, and a state record that holds the total space in use by deleted files. The index enables the background thread to find files that were deleted from the oldest to newest timestamp.

REPLICATION AGENT CHANGES

The replication agent supports a configuration option to enable whether the agent uses the recycle bin any time it deletes a file on the target server. The ctreplagent.cfg option is delete_to_recycle_bin  yes | no and is on by default.

 

SPLIT_NBR_OF_FILES

SPLIT_NBR_OF_FILES  <# of files>

When using the partitioning file rule:

<file_part_ind> = ( <int_unique_key> % <nbr_of_files> ) + 1

<nbr_of_files> is configured by the SPLIT_NBR_OF_FILES configuration entry.

Note Partitioning is currently only supported with a custom build containing the partition rule. Please contact your nearest FairCom office for availability.

 

TMPNAME_PATH

TMPNAME_PATH <path>

The TMPNAME_PATH location becomes the default directory for temporary files. On startup, if a TMPNAME_PATH entry is encountered in ctsrvr.cfg, the FairCom Server tests the validity of the path. If there is an error, the FairCom Server terminates. Whether or not successful, the FairCom Server enters the path name in the CTSTATUS.FCS file.

This configuration option can include an environment variable name that will be substituted with its value when the configuration file is read.

Default: Current server directory

 

DIAGNOSTICS PTADMIN

DIAGNOSTICS PTADMIN

When a partition member purge fails with error 718, this enables the filename and list of open instances of that file to be logged to CTSTATUS.FCS. Below is an example. For each connection we list the task ID, user name, node name, and user file number.

Mon Dec 12 12:40:33 2011
 - User# 00012  PT_ADMIN: purge failed, partition .\ctreesql.dbs\admin_pt.20111129.015307.dat is open (2 open instances):
Mon Dec 12 12:40:39 2011
 - User# 00012  PT_ADMIN: Connection 16: ADMIN(SQL:CTREESQL) 64
Mon Dec 12 12:40:44 2011
 - User# 00012  PT_ADMIN: Connection 17: ADMIN(SQL:CTREESQL) 45

A process stack is also created when this occurs. This option can also be enabled via SETCONFIG() and through the ctadmn utility.

storage organization

Was this article helpful?

Give feedback about this article

Related Articles