FairCom DB Server Basic Operations

Once the FairCom DB Server is installed on the operating system, it is ready to be used. Starting and stopping the FairCom Server are basic Administrator responsibilities, therefore this chapter is required reading.

Starting FairCom DB the First Time

Before we cover the actual process of starting the FairCom Server, there are a few points to make about the Administrator’s first-time duties:

1. If the vendor has supplied an (optional) encrypted settings file, ctsrvr.set, ensure it is in the location specified in the vendor’s installation documentation. The settings file is not user-configurable. See FairCom DB Configuration Options for more information.
2. See if there is a FairCom Server configuration file, ctsrvr.cfg. If so, verify the file contents, change it if necessary, and prepare it to run when the FairCom Server starts. See Configuring the FairCom Server for details.
3. Change the Administrator’s password to protect future access to the FairCom Server and access to Administrator utilities. Use the Administrator Utility described in FairCom Server Administrator Utility.
   1. Initially, the FairCom Server recognizes only one user, who is intended to be the Administrator. This “super user” has the unchangeable User ID name of ADMIN and the initial password of ADMIN. Administrator functions can be run by anyone with knowledge of the Administrator User ID and password. The first thing to do is to change the initial password and keep the new password secure. The steps to change the password are described in FairCom DB Server Administrator Utility.
4. Set up initial User IDs so users can log on to the FairCom Server. Use the Administrator Utility, described in FairCom Server Administrator Utility.

Starting FairCom DB

The following is a general discussion of the process used to start a FairCom Server. In most environments, faircom is the name of the FairCom DB SQL Server executable (ctsrvr is the name of the ISAM-only FairCom DB Server).

1. Ensure faircom (or ctsrvr) is in the base directory for database operations. See FairCom Server Installation.
2. If reconfiguring the FairCom Server, use a text editor to create a configuration file, ctsrvr.cfg. See Configuring the FairCom Server.
3. If adding (or changing) a configuration file, make sure it is in the same directory as the FairCom Server, is optionally set with the FCSRVR_CFG environment variable, or is listed on the command line (CTSRVR_CFG <file>).

Note: If the configuration file is not found by the FairCom Server, the server will not use the customized configuration file but will begin operation using default configuration settings. Check the installation instructions for your platform in FairCom Server Installation for any exceptions.

Start the FairCom Server by entering or selecting the name of the FairCom Server executable file, faircom or ctsrvr, just as any ordinary program in the environment.

Note: The FairCom Server name may have a file extension - see the platform-specific information in FairCom Server Installation for details.

Note: By default, no password is required to start the FairCom Server, therefore an automated process, such as a batch, script, or cron process, may start the FairCom Server.

Every time the FairCom Server starts, it checks log files made when it last stopped and, if necessary, uses these files to automatically recover from problems. See Automatic Recovery for details.

In most Unix environments, FairCom recommends Administrators run the FairCom Server in background to decrease the chance of unwittingly terminating it. For example:

# faircom &

or

# ctsrvr &

The Unix “no hang up” option may also be used to keep the FairCom Server from being terminated if the user starting the FairCom Server logs off the system. For example:

# nohup faircom &

or

# nohup ctsrvr &

Start Up Errors

The FairCom Server verifies database integrity and the operation of its own components at startup. If any problems are detected, the FairCom Server places error messages in the FairCom Server Status Log, CTSTATUS.FCS, and displays them on the system console. In extreme cases, the FairCom Server halts operation. Several kinds of errors can occur at startup.

Some of these errors, and the appropriate reaction to each, are as follows:

Note: Utility error messages covered in this manual refer to messages a FairCom Server sends to a program connected to it. Although we list error numbers with brief explanations of each error, it is important to understand how errors are treated, including messages sent to users. It is the responsibility of the client application programs receiving the error messages to properly capture and display the errors.

Note: The error messages associated with specific error numbers for the FairCom DB SQL Server are found in the dherrors file which is stored in the lib sub-directory below the LOCAL_DIRECTORY (if this keyword is defined in the server configuration file), SERVER_DIRECTORY (if this deprecated keyword is defined in the server configuration file), or the directory where the server is installed.

Errors Ignored When IP Address Return for Host System Fails

FairCom Server is able to ignore some errors getting the IP addresses for the host system when it starts. Sometimes FairCom Server failed to start with error 891 (most commonly seen on Unix systems). The following message was logged to CTSTATUS.FCS:

- User# 00001  Failed to get IP address for host 'hostname': gethostbyname() returned error code 1
 

This error occurred when the system’s host name (as shown by the hostname or uname -a commands) was not present in the /etc/hosts file and could not be resolved by DNS.

FairCom Server now ignores this error except in situations that require getting the IP addresses for the host system (when using the “local connections only” and “node-based licensing” options).

Launching FairCom DB Server companion executable

The SIGNAL_READY keyword provides the ability to launch an executable when the FairCom DB Server comes up. This keyword takes as its argument the name of an executable to be launched when the FairCom DB Server is ready (i.e., automatic recovery is completed). See SIGNAL_READY in FairCom DB Configuration Options for additional information.

This option allows applications that require the Server to launch automatically. Some examples including an auditing application, subordinate controlling interfaces (bar code readers, etc.), or a client running on the same machine as the Server.

Stopping the FairCom Server

Only a user in the ADMIN group can stop the FairCom Server. The server can be stopped using the Windows Close icon or menu item, using the ctstop or ctadmn utilities, or by an application using the StopServer() function.

To stop the FairCom Server with the Close button in the upper-right corner of the application window, or with the Close item in the File menu, just click either object, as is common with any other Windows application. An ADMIN group User ID and password is required to complete the close operation.

To stop the FairCom Server with the module ctstop, a special client application:

1. Start this program like any other.
2. The stop module asks for four things:
   1. The ADMIN user ID, which must be ADMIN or a member of the ADMIN group.
   2. The user password, which is necessary for continuing with the procedure.
   3. The current name of the FairCom Server, if an alternative to the default name was given in the configuration file (see the keyword SERVER_NAME in Basic Configuration Options) to specify which FairCom Server to stop.
   4. The delay time (if any) before shutting down the FairCom Server. If a greater-than-zero delay is specified, the FairCom Server will not accept any new users or transactions. Logon attempts during the delay time specified will fail with error SHUT_ERR (150), which means, “The Server is shutting down”. New transactions cannot be started while waiting to shut down. They will return SHUT_ERR (150) or SGON_ERR (162), “Server gone”, depending on how far the shutdown process has gone.
      1. This can be given on a single line as ctstop ADMIN ADMIN FAIRCOMS

The FairCom Server may also be stopped by an application program, as long as it supplies an ADMIN group User ID and password, using StopServer() discussed in the FairCom DB Programmer’s Reference Guide, (distributed only to FairCom DB developers).

During FairCom Server shutdown, messages reflect when communications terminate and when the final system checkpoint begins. In addition, two aspects of the shutdown that involve loops with two-second delays generate output indicating their status. The first loop permits the delete node queue to be worked down. The second loop permits clients to shutdown cleanly during FairCom Server shutdown. If these loops are entered, the FairCom Server could take a measurable amount of time to shut down, depending on the amount of work to be done, and output indicates how many queue entries or clients remain. A notice indicates whether everything was cleaned-up. A clean-up notice is NOT generated if a loop was not entered.

This output permits a FairCom DB Server Administrator to monitor the shutdown, and avoid an incorrect assumption about whether the FairCom Server is making progress or has hung during shutdown. After the FairCom Server shuts down, it sends a message saying FairCom Server operations have been terminated. The output is routed to the console and CTSTATUS.FCS, although the latter does not receive the numeric information concerning the number of queue entries or active clients.

Note: If the Replication Agent is running on a server, replication should be stopped before trying to stop the server. If replication is running when you attempt to stop the server, you will see error 792 (External server shutdown disabled).

Launching Server Companion upon Shutdown

The SIGNAL_DOWN keyword provides the ability to launch a customer executable when the FairCom Server comes down. This keyword takes as its argument the name of an executable that will be launched when the FairCom Server has been successfully terminated. See SIGNAL_DOWN in FairCom DB Configuration Options for additional information.

This option could be used to launch a backup utility, to re-launch the server, or to execute a batch/shell script to perform actions that can only be performed while the server is inoperative.

Server Operational Errors

The FairCom Server performs rigorous error checking and logging during the course of everyday operation. Because of the depth of error checking that is performed, warnings and error messages are logged in even the most benign situations.

Windows Resource Error (1450) Configurable Retry Logic

When the Windows kernel has allocated all of its paged-pool memory, it will not be able to perform many tasks and instead returns a STATUS_INSUFFICIENT_RESOURCES (0xC000009A) message. This is a restriction of 32-bit addressing (only 2GB addressable within the kernel), regardless of the amount of memory available in the system.

When the FairCom Server configuration option IO_ERROR_BLOCK_SIZE option is specified in the FairCom Server configuration file, a read or write operation that fails with Windows system error 1450 (ERROR_NO_SYSTEM_RESOURCES) is retried in blocks of the specified size. If any one of those read or write operations fails, the FairCom Server fails the read or write operation.

The FairCom Server supports two additional configuration options that permit additional disk read/write retries and a sleep interval between retries.

IO_ERROR_BLOCK_RETRY <retries> specifies the maximum number of failed IO_ERROR_BLOCK_SIZE-sized I/O operations that must occur before the I/O operation is considered to have failed. If the IO_ERROR_BLOCK_SIZE-sized I/O operations that are being attempted for a particular I/O operation fail more than <retries> times, the FairCom Server writes a READ_ERR (36) or WRITE_ERR (37) message to CTSTATUS.FCS and considers the I/O operation to have failed.

A value of -1 signifies infinite retries. The default is 0, which means that the I/O operation is tried only once in IO_ERROR_BLOCK_SIZE-sized blocks, and if any of these I/O operations fails, the entire I/O operation is considered to have failed. As another example, if IO_ERROR_BLOCK_RETRY is set to 20 and IO_ERROR_BLOCK_SIZE is set to 65536, if a 327680-byte write is retried as 5 65536-byte write operations, then the I/O operation fails if there are 20 failures to perform those 5 write operations.

IO_ERROR_BLOCK_SLEEP <time> specifies a time in milliseconds between retry attempts. The default is zero, which means that retries are attempted immediately.

SNAPSHOT Monitoring of Failed Retires

To permit monitoring the number of I/O error 1450 retries that have occurred, a counter has been added to the system snapshot structure. The sctioblkretry field of the ctGSMS structure is defined as an unsigned long integer that stores the total number of I/O error 1450 retries that have occurred since the FairCom Server started. The snapshot log file SNAPSHOT.FCS displays the I/O error 1450 retry counter value with a description of "I/O ERR(1450) automatic retries:". The system snapshot structure version has been changed from 9 to 10 to note the presence of this new field in the structure and the statistics monitoring utility, ctstat, and ctsnpr utilities have been updated to properly handle the presence of this field in the system snapshot structure and snapshot log.

I/O Block Sizes with Windows Systems

When the IO_ERROR_BLOCK_SIZE configuration option is specified in the FairCom Server configuration file, if a disk read or write operation fails with system error 1450 (Insufficient system resources exist to complete the requested service), the server retries the I/O operation using the specified block size. If the retried I/O operation also fails with error 1450 (or if a disk I/O operation fails with error 1450 and IO_ERROR_BLOCK_SIZE is not specified in the server configuration file), FairCom DB now logs the following message to CTSTATUS.FCS:

<op_code>: loc <location> file <filename> offset <offset> iosize <iosize> syserr <errcod>

where:

• <op_code> is READ_ERR (36, indicating that a read operation failed) or WRITE_ERR (37, indicating that a write operation failed)
• <location> is the location in the code where the I/O operation failed
• <filename> is the name of the file for which the I/O operation was requested
• <offset> is the offset of the failed I/O operation
• <iosize> is the size of the failed I/O operation
• <errcod> is the system error code for the failed I/O operation

An internal write call was modified to ensure that when the IO_ERROR_BLOCK_SIZE configuration option is used, a retried I/O operation is done at the original offset for the I/O operation and that sysiocod is reset to zero before retrying the I/O operation.

Communications Errors (127/128)

When a communication error such as VDP_ERROR (127 or 128) occurs, the FairCom Server logs an entry in the Server Status Log CTSTATUS.FCS. This is not a serious situation unless the client application is also getting errors such as 127, 128, or similar errors.

The context of the communications error is that a server thread gets a notification that a message is available, but when the server performs a read, nothing is returned.

This can be caused by:

• Physical network problems
• An overworked network transport layer that is timing out and doing retries
• Clients exit without calling CloseISAM() or StopUser(), or end users that turn their machines off without properly logging out of the application. This category includes client application crashes.

To ensure the errors are not serious, try to reconcile the communications errors in the log with the client events that triggered them. Since these errors do not usually happen frequently and user names are provided, it should be easy to determine which event caused this situation.

To avoid these errors, ensure the FairCom Server’s host machine is not burdened beyond its capacity. Using a more powerful machine or limiting the number and types of applications on a machine can improve performance and limit errors at the communication level. Also, ensure no specific application is over-using resources on the host machine. If appropriate in the server's operating environment, increasing the priority of the FairCom Server can eliminate or reduce communications errors. This should be done cautiously as it will affect other applications running on the same machine.

The error messages in the Server Status Log can be turned off, but unless they are an inconvenience, this is NOT recommended. The messages serve as a good health check on the state of your network and may be an early warning of more serious network and system problems. To disable the messages, add

CTSTATUS_MASK  VDP_ERROR

to the ctsrvr.cfg file and restart the FairCom Server.

8770

The 8770 error occurs when the server attempts to remove an internal unique file ID from a list as a file is closed, but that file ID is not on the list. This might be caused by an application opening different files with the same internal file ID. This would typically be the case when a file is copied and both files are then opened; therefore they both have the same file ID. To avoid these errors do not copy server-controlled files. If the 8770 error occurred after another more serious error, the 8770 error can be safely ignored. If it recurs, contact your application developer for assistance.

Server Memory Calculations

This document provides information about the memory that the FairCom Server uses, including formulas to calculate the server's expected memory use based on the configuration options and usage patterns.

Note: The FairCom Knowledgebase has a memory use calculator spreadsheet that can help you evaluate the best memory usage.

Baseline server memory use

The FairCom Server startup memory requirementsare calculated using the following equation:

Baseline Memory =
   Server binary size +
   Data cache size +
   Index cache size +
   System file control blocks +
   Lock wait-for graph +
   Global array sizes

Server binary size:

Calculate the server binary size by adding the size of the executable on disk and the sizes of all the shared libraries that the server process loads.

Data cache size:

The data cache size is set using the DAT_MEMORY configuration option. It defaults to 100 MB.

Index cache size:

The data cache size is set using the IDX_MEMORY configuration option. It defaults to 100 MB.

System file control blocks:

At startup, the server allocates an array of pointers to hold the system file control blocks. The number of entries in the array is set to the FILES configuration option. Each time a file uses a previously unused system file number, the server allocates a system file control block for that system file number and memory use increases by the size of the system file control block structure (CTFILE).

Initial allocation size:

FILES * sizeof(CTFILE *)

Size when fully used:

FILES * sizeof(CTFILE *) + FILES * (sizeof(CTFILE) + alignment)

Example structure size for 64-bit Windows server:

sizeof(CTFILE) + alignment = 4720

Lock wait-for graph:

The server allocates a two-dimensional array that it uses to detect that a blocking lock request would cause a deadlock. The array uses two bits per entry and uses the maximum number of connections set by the CONNECTIONS configuration option for both dimensions of the array.

Allocation size in bytes:

CONNECTIONS * CONNECTIONS / 4

Global array sizes:

The server allocates a number of global arrays. Many of these arrays are sized based on the maximum number of supported connections that is set in the server binary at compile time. This value, MXU2, is currently set to 10287 for a 64-bit server and to 4143 for a 32-bit server.

Some of the sizes of the global arrays depend on the CACHE_LINE configuration option, since this option causes those array elements to be aligned on a multiple of the specified cache line size. Supported CACHE_LINE values are: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, and 1024. If an invalid CACHE_LINE option is specified in the configuration file, the server logs a warning message to CTSTATUS.FCS and uses the default value.

The total global array size for a 64-bit server is approximately 74 MB when using the default CACHE_LINE size of 128.

Memory use for each ISAM connection

Base memory use for each ISAM connection is approximated as follows. <fils> is the fils parameter value specified by the client when connecting to the server.

    Thread stack size +
    Communication buffer size +
    Record compression buffer size +
    Schema conversion buffer size +
    Connection level state information +
    ISAM level state information +
    Block encryption buffer +
    User file control blocks +
    Transaction mark list buffer +
    Preimage space hash bins +
    ISAM context hash bins +
    ISAM context state +
    User level lock hash bins+
    Preimage space entries +
    Lock table entries

Thread stack size:

Each thread allocates a stack. The thread stack size is set as follows:

On Windows systems:

• For ISAM threads, the stack size is set to 64 KB and cannot be changed.
• For SQL threads, the stack size defaults to 1 MB for servers that don't support Unicode and to 1.5 MB for servers that support Unicode.
• The stack size for SQL threads can be changed by using the server configuration option SETENV DH_THREAD_STACK_SZ_KB=<stack_size_in_kilobytes>

On Unix systems:

• For ISAM threads, the stack size defaults to 64 KB.
• For SQL threads, the stack size defaults to 1.5 MB for servers that don't support Unicode and to 3.5 MB for servers that support Unicode.
• The stack size for ISAM and SQL threads can be changed by using the server configuration option SETENV DH_THREAD_STACK_SZ_KB=<stacksize_in_kilobytes>

Communication buffer size:

The communication buffer is initially 4 KB. When the client reads or writes a record that exceeds the current communication buffer size, the server allocates a sufficiently-sized communication buffer to hold the record. The communication buffer remains allocated at that larger size until the client disconnects.

Note: The server configuration option TRIM_USER_MEMORY YES can be used to cause the server to periodically check if the communication buffer exceeds 1 MB, and if so it reduces the communication buffer to its default size of 4 KB.

Record compression buffer size:

A connection that reads or writes records that use data record compression allocates a buffer to hold the uncompressed record image. This buffer remains allocated until the client disconnects.

Note: The server configuration option TRIM_USER_MEMORY YES can be used to cause the server to periodically check if the communication buffer exceeds 1 MB, and if so it reduces the communication buffer to its default size of 4 KB.

Schema conversion buffer size:

A connection that reads records from a table that has had a hot alter operation performed on it might need to convert records from an older version of the record schema to the current schema version. As a performance enhancement, the server allocates a schema conversion buffer to hold the converted record image. This buffer remains allocated until the client disconnects.

Note: The server configuration option TRIM_USER_MEMORY YES can be used to cause the server to periodically check if the communication buffer exceeds 1 MB, and if so it reduces the communication buffer to its default size of 4 KB.

Connection level state information:

The server allocates memory to hold connection level state information in the format of a CTGV structure.

Example CTGV structure size for 64-bit Windows: 14736 bytes

ISAM level state information:

The server allocates memory to hold ISAM state information. The amount of memory depends on the sizes of the CTIS, CTIS1, and CTIS2 structures, the size of the FILNO data type, and the maximum number of files requested by the client when it connects to the server. The server automatically increases the file number limit as needed when the client requests using a file number that exceeds the current file number limit, up to the MAX_FILES_PER_USER server configuration option.

The formula for calculating ISAM memory use is as follows, where <fils> is the maximum number of files requested by the client:

sizeof(CTIS) +
<fils> * sizeof(CTIS1) +
<fils> * sizeof(CTIS2 *) +
2 * <fils> * sizeof(FILNO *) +
<fils> * MAX_KEY_SEG * sizeof(CTIS2) +
2 * <fils> * MAX_DAT_KEY * sizeof(FILNO)

Typical values for 64-bit Windows are:

sizeof(CTIS) = 3160
sizeof(CTIS1) = 80
sizeof(CTIS2 *) = 8
sizeof(FILNO) = 4
sizeof(CTIS2) = 12
MAX_KEY_SEG = 16
MAX_DAT_KEY = 64

Block encryption buffer:

For each connection the server allocates a buffer for encrypting data in blocks of size 32768 rounded up to a multiple of the LOG_PAGE_SIZE server configuration option (which defaults to 8192).

User file control blocks:

The server allocates memory to hold connection level state information about each file that a connection has opened. The amount of memory depends on the size of the FUSR structure and the maximum number of files requested by the client when it connects to the server. The server automatically increases the file number limit as needed when the client requests using a file number that exceeds the current file number limit, up to the MAX_FILES_PER_USER server configuration option, which defaults to 32767.

The formula for calculating user file control block memory use is as follows, where <fils> is the maximum number of files requested by the client:

<fils> * sizeof(FUSR)

A typical value for 64-bit Windows is:

sizeof(FUSR) = 504

Transaction mark list buffer:

The server allocates a buffer to manage transaction marks in index nodes. The buffer size is given by the following formula:

PAGE_SIZE / 128 * 16 * 6

PAGE_SIZE defaults to 32768.

Preimage space hash bins:

The server allocates hash bins for efficiently searching preimage space. The memory use is given by the following formula:

PREIMAGE_HASH * sizeof(SHADLST *)

PREIMAGE_HASH defaults to 128.

sizeof(SHALST *) is 8 for 64-bit systems and 4 for 32-bit systems.

ISAM context hash bins:

The server allocates hash bins for efficiently searching ISAM contexts. The memory use is given by the following formula:

CONTEXT_HASH * sizeof(ctICON *)

CONTEXT_HASH defaults to 6.

sizeof(ctICON *) is 8 for 64-bit systems and 4 for 32-bit systems.

ISAM context state:

Each ISAM context allocates memory for each index whose state is stored in the ISAM context. The formula to calculate the memory use is as follows:

(sizeof(ctCONBUF) + key length) rounded up to multiple of sizeof(ctCONBUF)

sizeof(ctCONBUF) is 24 for 64-bit systems and 16 for 32-bit systems.

User level lock hash bins:

The server allocates hash bins for efficiently searching the user lock table. The memory use is given by the following formula:

LOCK_HASH * sizeof(ULOKHSH)

LOCK_HASH defaults to 16.

sizeof(ULOKHSH) is 16 for 64-bit systems and 8 for 32-bit systems.

Preimage space entries:

Each operation on a transaction controlled file creates a preimage space entry, which contains information about the operation. This information can include a data record image or a key value.

Memory used for each preimage space entry:

sizeof(SHADLST) + data length

data length is the size of the record image or a key value

Example structure size for 64-bit Windows server:

sizeof(SHADLST) = 128

Lock table entries:

Each record that is locked has a system lock table entry (RECLOK). Each record lock request creates a user lock table entry (LOKS). Because more than one read lock can be held on a particular record, when using read locks more than one user level lock entry can exist for a system lock table entry.

Table read locks and table write locks can be used to reduce memory use by locking the entire table rather than locking a large number of individual records.

Memory used for each record that is locked:

sizeof(RECLOK) + alignment

Memory used for each record lock that a connection has acquired:

sizeof(LOKS) + alignment

Example sizes for 64-bit Windows server:

sizeof(RECLOK) + alignment = 88

sizeof(LOKS) + alignment = 40

Stack Traces in Case of Critical Error

A diagnostic feature is available that provides a stack trace showing calls for all threads. This is performed automatically when a fatal error occurs.

This feature redirects output to the file pstack<server_pid>_<sernum>.log, where <server_pid> is the process ID of the FairCom Server process and <sernum> is a serial number maintained by the server to ensure unique log names. The server also writes a message to its status log, CTSTATUS.FCS, indicating that a process stack trace was dumped. For example, the following message in CTSTATUS.FCS refers to the file pstack_454_01.log:

Dumped stack for server process 454, log=1, loc=73, rc=0

Please contact your vendor immediately if you encounter a FairCom DB crash and be prepared to supply these stack dumps. This enables FairCom engineers to quickly pinpoint critical errors and enable fast response times for corrected servers.

Note: To receive function times, you will need shared libraries (Unix/Linux) or DLL (Windows) with symbols. Be sure to run the pstack command from the local directory where the FairCom Server library resides. If it is not run from that directory, the symbol-enabled library will not be loaded and the system function calls will appear as question marks in the call stack.

Unix Operating Systems

For servers running on Unix operating systems, the implementation invokes the pstack utility.

Note: If pstack does not exist on your system, no trace will be created.

If your system's process stack trace creation utility is named something other than pstack, you can create a shell script named pstack to run your utility. For example, if the utility on your system is named dumpstack, create a shell script named pstack with the following two lines:

#!/bin/csh

dumpstack $1

Remember to give your shell script execute permission (for example, chmod +x pstack) and put it in a directory that is in the path.

IBM AIX Operating Systems

The server uses the AIX procstack utility to log the stack trace.

Microsoft Windows Operating Systems

This feature requires an external DLL, dbghelp.dll, which is part of the Windows installation, and is dynamically loaded at stack dump time. It also requires that this DLL exports the function MiniDumpWriteDump() which may not be the case with older versions of this DLL. In the case where the DLL cannot be found or it does not contain the function, the stack dump fails and a message is logged in CTSTATUS.FCS without any other consequence.

It is suggested to enable Dr. Watson on the Windows system of interest when attempting to generate a dump file with information needed to trace a continuing server stack dump. Visual Studio 7.0 or greater is required to inspect the file for Windows stack dumps.

Security Note: In-flight data will be captured at the time these core files are generated. Consider the case of data and indexes residing in the memory caches of the server process space. This will be unencrypted data even if it was encrypted on disk. Please consult with your local risk assessment organization concerning any privacy or security issues before forwarding this information to FairCom.