Product Documentation

c-treeACE V10.3 Update Guide

Previous Topic

Next Topic

Rebuild Fails with Error 484 (Could Not Open Sort Work File)

When COMPRESS_FILE was specified in ctsrvr.cfg with a filename specification that matched rebuild sort work file names (for example COMPRESS_FILE *.* to match all filenames), a rebuild failed with error 484 (could not open sort work file).

NOTE: Error 401 could occur when opening any data file (not just a rebuild sort work file) that is created with resource support disabled and whose name matches the COMPRESS_FILE filename specification.

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.

Previous Topic

Next Topic

Treat fixed-length compressed data files consistently across batch record returns, inserts, and updates

Prior to c-treeACE V10.3, a fixed-length data file that had record compression turned on was implemented internally as a variable-length file with the ctAugmentedFxd file attribute. The ctAugmentedFxd attribute enforced the constraint that all the records are of the specified fixed length. After compression, the records may be of different lengths. To determine if your file is behaving in this manner, you can execute the ctinfo utility over the data file and look for the presence of the ctAugmentedFxd file mode in the c-tree extended header block.

ctBEHAV_BAT_FXDCMP changes the behavior of the batch retrieval and insertion code so that compressed, fixed-length data file records are now treated as fixed-length records, not variable-length. This new behavior is consistent with other c-tree API calls and the BAT_UPD option. ctBEHAV_BAT_FXDCMP is on by default, but COMPATIBILITY NO_BAT_FXDCMP placed in the ctsrvr.cfg file will turn off the new behavior at runtime.

The new behavior affects BAT_RET_REC and BAT_RET_BLK retrieval operations by removing the record size field that precedes each record image.

BAT_RET_FIX is mutually exclusive with BAT_RET_REC, and designed to be used with variable-length files, and not used in conjunction with BAT_RET_BLK.

Before the new behavior, BAT_RET_FIX would have resulted in compressed, fixed-length data file records being returned like variable-length records. Now they will be returned like fixed-length records.

The new behavior affects the BAT_INS option by expecting the input buffer to be in fixed-record length format for compressed fixed-length data file records.

Previous Topic

Next Topic

Unix Shared Memory Protocol Not Freeing Shared Memory Segments (different client and server user accounts)

When clients used the shared memory protocol on Unix systems and the client and server processes were run under different user accounts, shared memory segments could be left behind after the connections were closed. The ipcs -m listing showed shared memory segments with no processes attached. In V10.3 and later, the logic has been modified to correct this.

Note: These changes add a field to the client and server logon data structures to pass the user ID between the client and server processes, resulting in the following compatibility considerations:

An old client can connect to a new server and it will behave as it did before these changes.

A new client cannot connect to an old server using shared memory. It will receive error 133 if the server is configured to only use shared memory. It will connect with TCP/IP if the server is using both shared memory and TCP/IP. The old server will log the following message to CTSTATUS.FCS:

FSHAREMM: The client's shared memory version (2) is not compatible with the server's shared memory version (1)

At startup, the FairCom Server now logs messages to CTSTATUS.FCS to indicate the shared memory directory used for logon purposes and the shared memory protocol version that it is using:

FSHAREMM: SHMEM_DIRECTORY=/tmp/ctreedbs/
FSHAREMM: Protocol version=2

TOCIndex