Smarts Broadcast Systems wrote:

>
> 1). I take it that's the origin of the 'g' prefix to commands such as
> ``gbak'', ``gstat'' and so on. Correct?

Right. The original utilities had more basic names like "burp"
for "backup and restore program", "dudley" for ddl interpretation,
and "alice" which did "all else". We were urged to "dress them
for success" by choosing less idiosyncratic names. The database
was called "gds/galaxy" at that point. Our lawyer told us that
"galaxy" would lead to trademark problems.

>
> 2). What's the derivation of the equally-ubiquitous ``isc''?

Interbase Software Corporation, the final name of the company.

>
> 3). There's a static archive library file file in Interbase,
> ``libgds_pyxis.a''. What's this for?

Wow. Ancient history. It was a drawing package for dumb terminals
that supported graphing from data tables. At the time we were using
constellation names to go with galaxy. There's a constellation called
pyxis that somehow reminded me of an easel.

>
> 4). In the native C API, what was the design rationale for using raw
> memory blocks for such things as the ``database parameter block'' and
> the various ``isc_info_*'' functions? These are essentially free-form
> regions of memory as opposed to fixed structures.

Because they are free-form things. All the parameters in a dpb, tpb,
and info blocks are optional. The entries are tagged and length
encoded, so that an older engine (or foreign) engine could skip
entries it didn't understand. The C-API was designed to allow
different implementations and, in fact, had three different databases
built to it - Rdb/ELN, Rdb/VMS, and InterBase.

>
> 4). The ISC_STATUS_ARRAY type allocates an array of 20 longs. Is there
> really any function call that can yield up to 19 error results?

No, but the intention was to make it big enough so we wouldn't have
to make it bigger. In the case or remote access ... or hop-scotch
remote access, each layer may need to put its own codes and arguments
into the status vector.

>
> 5). What's the background for lengthy error strings such as
> ``Unsuccessful execution caused by a system error that precludes
> successful execution of subsequent statements''. Was this a DEC-ism?
> (I contrast this with the terse error strings in a *nix culture).

Message strings seemed like a better idea than 10054 or 103. The
internal name for that is BUGCHECK, which was a clean-up of the
original RDB$OH_SHIT.

Cheers,


Ann