• 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.

    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.

• 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.