Product Documentation

Knowledgebase

Previous Topic

Next Topic

Converting c-tree V4.1F-V4.3C Applications

The conversion of an existing c-tree V4.3 application program involves two main aspects: file conversion and program conversion. The files from c-tree V4.3 are not compatible with the FairCom DB file format. Programs may be compatible, but many will require some modification.

In This Section

Application Conversion Details

Previous Topic

Next Topic

Application Conversion Details

  • data & index files

    Data files are converted using the utility program ctcv43 provided with FairCom DB. Index files associated with these data files should then be rebuilt using the FairCom DB function, RebuildIFile().

    Stand-alone index files are converted with the programs ctin43 and ctindx provided with FairCom DB. ctin43 must be linked with your V4.3 library. It produces a flat key file for each index. ctindx is linked with your FairCom DB library. It creates a FairCom DB index from the flat key file produced by ctin43.

  • ISAM information

    ISAM Parameter files and Incremental ISAM Structures are compatible. The tfilno field has been added to the IFIL structure. The aidxnam, altseq, and pvbyte fields have been added to the IIDX structure. See Incremental ISAM Structures in the FairCom DB Programmer's Reference Guide for more information on these structures.

    With parameter files, make sure the RTREE setting in ctoptn.h is correct.

  • header info

    FairCom DB applications cannot directly access the index file headers via the(ct_key + filno)->member reference. Instead, use the GetCtFileInfo() and GetSymbolicNames() functions, part of the FairCom DB library, to get the information.

    For example, the data record length is accessible with the following expression in c-tree V4.3: (ct_key + filno)->reclen. In FairCom DB the record length is returned by the function call GetCtFileInfo(filno,RECLEN).

    GetCtFileInfo() returns a long integer since it is also used to return header values such as the file size. All references of the form “extern CTFILE *ctnum;” must be removed. If you are using such a statement, then you must rely on the GetCtFileInfo() and GetSymbolicNames() functions instead.

  • length parms

    All length related parameters have become 4-byte values. We now provide function prototypes which should catch (and/or correct) this change. For example, in REDVREC(datno,recptr,bufsiz), bufsiz is now a 4-byte quantity.

  • Function Returns and Parameter Changes

    The following functions have undergone parameter changes between c-tree V4 and c-tree Plus V6:

 

Function Name

Function Return

Function Parameters

v4

EQLKEY

POINTER

COUNT keyno, TEXT *target

v10

EQLKEY

LONG

COUNT keyno, pVOID target

v4

GTEKEY

POINTER

COUNT keyno, TEXT *target, TEXT *idxval

v10

GTEKEY

LONG

COUNT keyno, pVOID target, pVOID idxval

v4

GTKEY

POINTER

COUNT keyno, TEXT *target, TEXT *idxval

v10

GTKEY

LONG

COUNT keyno, pVOID target, pVOID idxval

v4

NXTKEY

POINTER

COUNT keyno, TEXT *idxval

v10

NXTKEY

LONG

COUNT keyno, pVOID idxval

v4

REDREC

COUNT

COUNT datno, POINTER recbyt, TEXT *recptr

v10

REDREC

COUNT

COUNT datno, LONG recbyt, pVOID recptr

v4

frmkey

COUNT

COUNT keyno, TEXT *recptr, TEXT * txt, POINTER pntr

v10

frmkey

COUNT

COUNT keyno, pTEXT recptr, pTEXT txt, ctRECPT pntr, VRLEN datlen

v4

LOKREC

COUNT

COUNT datno, COUNT lokmod, POINTER recbyt

v10

LOKREC

COUNT

COUNT datno, COUNT lokmod, ctRECPT recbyt

  • frmkey

    If you use the BuildKey() function, short name frmkey, it now takes an additional parameter specifying the length, as a 4-byte quantity, of the record buffer from which the key is extracted. See the function prototype for BuildKey() in CTDECL.H.

  • current ISAM record

    cur_recno[ ] and cur_image[ ] no longer exist. Also, it is no longer necessary to use two buffers for record updates, although using two buffers will NOT cause any problem for FairCom DB. FairCom DB maintains the necessary information internally for each user.

    To determine the current ISAM record position, use GETCURP(datno) instead of cur_recno[datno]. To reset the current ISAM record after a successful rewrite, use UPDCURI(datno,SWTCURI) instead of manipulating cur_recno and cur_image. See “ResetRecord” or “CurrentFileOffset” in the FairCom DB Programmer's Reference Guide for additional capabilities.

    To set the current ISAM record to a specified byte position (and/or record image) use SETCURI(datno,recbyt,recptr,bufsiz), where recbyt is required and specifies the record position. If non-null, recptr points to a record buffer containing an image of the data record. If non-zero, bufsiz (a 4-byte value), specifies the length of the record buffer. If recptr is non-null and bufsiz is passed as 0L, then bufsiz is assumed to be the record length defined for the file at the time the file was created. For variable length files, this corresponds to the fixed length portion of the file.

  • key segment info

    If you have accessed key segment information (such as a segment length or segment mode), you can now retrieve it via a call to:

    ctgetseginfo(keyno,segment_no,mode)

    where segment_no is a zero-based segment number, and mode is one of the following:

    • ctSEGPOS - segment offset
    • ctSEGMOD - segment mode
    • ctSEGLEN - segment length
  • #includes

    Be sure to change the FairCom DB include files to the following:

    #include “ctreep.h”

    Note that ctaerr.h includes the definitions for uerr_cod, isam_err and isam_fil. It is not necessary to include ctifil.h (as specified in the manual) since it will be included automatically.

  • old key types

    Key types 1, 2 and 3 have been phased out. They supported integer and floating point keys. You can use appropriate key segments to support all of these types. Change the key type to 0, unless you desire key compression, and modify your ISAM key segment modes. If your application only uses the low level functions, you can transform the keys as required using the TransformSegment() function described in the FairCom DB Function Reference Guide.

  • Lock Table Size

    c-tree V4.X utilized an internal lock table that supported 32 concurrent locks by default, #define MAX_LOCKS 32. To alleviate this artificial lock limit, FairCom DB dynamically allocates a lock list instead of a more static lock table. The number of locks available to FairCom DB is now constrained by available system memory.

  • TRANSACTION

    The TRANSACTION() function supported in c-tree V4.3, for purposes of keeping a Server from shutting down in the middle of an application procedure, now simply returns without error. It causes no action to be taken.

    FairCom DB supports extensive transaction processing in the Server mode via the Begin(), Abort(), Commit(), SetSavePoint(), and RestoreSavePoint() functions.

  • TFRMKEY

    FairCom DB supports the automatic calling of TransformKey(), short name TFRMKEY(), to transform target key values used in ISAM level search routines. If you use the traditional FairCom DB functions to initialize FairCom DB, InitCTree(), InitISAM(), OpenISAM(), or CreateISAM(), then this automatic feature is disabled and your existing application will be unaffected. If you use the extended forms of these functions (InitCTreeXtd(), InitISAMXtd(), OpenISAMXtd(), or CreateISAMXtd()), then you must set the userprof parameter to USERPRF_NTKEY to disable the automatic calls to TransformKey(). Otherwise, your existing calls will be followed by the automatic calls, which will cause problems.

  • FPUTONLY

    There is no longer a FPUTONLY disk I/O protocol. FairCom DB now lets you select on a file-by-file basis whether or not to force updates directly to disk. OR the ctWRITETHRU constant (64) into the file mode to get the same affect as the FPUTONLY I/O protocol.

  • DOSFLUSH

    DOSFLUSH support is being phased-out. As distributed, DOSFLUSH will only become effective in the FPUTFGET, Standalone Multi-user, configuration. If necessary, add DOSFLUSH to your CTOPTN.H configuration file. CTOPT2.H contains preprocessor commands that turn DOSFLUSH off if NOTFORCE is selected.)

    Transaction processing provides a much more effective means to ensure the consistency and completeness of the data.

  • r-tree® / d-tree

    Applications using Version 1.1 of the r-tree Report Generator or Version 3.1 of the d-tree Development ToolBox require updated versions of these development tools.

TOCIndex