Go to Source Code Developers' Register

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

2. Guardian
   The Guardian is in the ISCGUARD directory. It's a windows thing.
3. Server-side client interface See below.
4. 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.
5. IBX See below.
6. InterClient See below.
7. InterServer See below.
8. IBConsole They'll show up, but they're a mystery to me at the moment.
9. ISQL and
10. WISQL ISQL directory.
11. 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".
12. gbak
    BURP directory. (Back Up Restore Program). The main modules are backup.e and restore.e. The entrypoint is in BURP.C.
13. gfix
    ALICE directory. (All Else).
14. marion
    Source code management system.
15. tcs
    Test control system for regression testing.
    TCS will be provided with a small set of tests, orgainized in series and metaseries.
16. fred
    Forms editor for a very creaky VT100 style forms package.
17. pixis
    The aforementioned forms package.
18. 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.
19. 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.
20. gpre
    Preprocessor for static SQL and GDML. Internally much like QLI, except that it understands COBOL. Probably the best BLR generator of the bunch.
21. 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.
22. extlib
    The predefined "user" defined functions.
23. Internationalization
    In the INTL directory. This will make a great deal more sense when you've read Dave Schnepper's paper.
24. 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.
25. Msgs
    Subsystem for creating, checking, and changing message text.
26. Utilities
    Server manager appears to be here, and gsec.
27. WAL
    Write ahead log. Dead, to the best of my knowledge.

    Top of this page
    Go to Source Code Developers' Register