IBPhoenix Development

High-level Description of the InterBase 6.0 Source Code

By Ann Harrison

Now the InterBase sources are released, as developers you will find yourself facing a significant amount of code, varying widely in sophistication and relevance.

Engine

The engine directory is "jrd" - "Jim's Relational Database" - not one to hide his light under a barrel is our Jim. The external entry points are in isc.c.

They generally call a matching set of internal routines in JRD.C. JRD calls off to CMP.C to compile requires, MET.C to find metadata, and EXE.C to execute a compiled request. When EXE.C wants data, it calls RSE.C (record source expression, I think).

It uses BTR.C (b-tree) for index lookups, VIO (virtual I/O) to get records by record id, SORT.C for sorting (surprise!). VIO gets its records from CCH.C, the cache handler. CCH is the lowest level that has any concept of page types or structured data. It calls PIO.C to do the actual reading from disk.

MET.C is a preprocessed file. The actual file is "MET.E". Other preprocessed modules are DPM (data page manager - it works with VIO, getting records and cleaning up stuff), DFW (deferred work. It creates indexes and actually makes metadata changes when a transaction commits.)

EVL.C evaluates expressions. CMP.C performs comparisons. FLU.C is the function look up module. GDS.C has service routines, visible outside the server.

CODES.H is an interesting problem. It's created by CODES.E (precompiled to CODES.C) from the message database. You need codes.h before you can build the engine and the engine before you can run CODES.C.

Another module worth looking at is ALL.C, the block allocation (and deallocation routine). The old utilities also have an ALL.C module.

Coding conventions
Externally visible routines are XXX_<name>
where XXX is the three (or four) letter module name. Routines in a module start with the external routines in alphabetical order, followed by the internal routines in alphabetical order.

Guardian

The Guardian is in the ISCGUARD directory. It's a windows thing.

Server-side Client Interface

See below.

Client-side Client Interface

Both these bits are in the directory REMOTE. It's a cute architecture, which requires more explanation that I can provide here. As far as I know, it can't be explained without a whiteboard.

IBX

See below.

InterClient and InterServer

See below.

IBConsole

They'll show up, but they're a mystery to me at the moment.

ISQL and WISQL

ISQL and WISQL ISQL directory. qli

QLI Directory

Query Language Interpreter. It's a command line interactive query language with "procedures" which are stored sections of QLI code that are invoked like macros (without arguments, worse luck).

Starts at DTR.C (Datatrieve, its paternal ancestor). Commands and statements (they're different) go through LEX.C (which breaks them into lexemes) PAR.C (which parses them), COMPILE.C (which compiles them). GENER.C generates BLR.

QLI, like all the old utilities, uses the BLR interface rather than DSQL. PICSTR interprets data formatting instructions - lots of them. Jim objects strongly to pronouncing it "pick stir".

Gbak

BURP directory. (Back Up Restore Program). The main modules are backup.e and restore.e. The entrypoint is in BURP.C.

Gfix

ALICE directory. (All Else).

Marion

Source code management system.

TCS

Test control system for regression testing. TCS will be provided with a small set of tests, orgainized in series and metaseries.

Fred

Forms editor for a very creaky VT100 style forms package.

Pixis

The aforementioned forms package.

Pictor

An unsuccessful graphical query language. These three gems seem to have disappeared. If I can find the code and if I can convince Borland to release it, I'll expose them to the light of day.

Dudley

DDL utility. Interpreted commands in the old data definition language (declare relation, declare field - square brackets where you want to put parentheses). Generates BLR for views and triggers, GDML (non-SQL relational language) for metadata updates.

Gpre

Preprocessor for static SQL and GDML. Internally much like QLI, except that it understands COBOL. Probably the best BLR generator of the bunch.

Dsql

dsql The dynamic sql processing. Originally, DSQL was compiled into BLR on the client side, requiring that the client have a copy of the relevant metadata. Now, DSQL strings are passed and interpreted on the server side and parsed into BLR there. extlib The predefined "user" defined functions.

Internationalization

In the INTL directory. This will make a great deal more sense when you've read Dave Schnepper's paper.

Lock Manager

In the lock directory. Used for classic architecture versions to coordinate page access (and such things). Based on the VMS distributed lock manager.

Msgs

Subsystem for creating, checking, and changing message text.

Utilities

Server manager appears to be here, and gsec.

WAL

Write ahead log. Dead, to the best of my knowledge.