LOCK
A procedural database language recorded as appearing in 1977 and now dormant - and a case study in a language whose only surviving trace is its catalog entry, hidden behind one of the most overloaded words in computing
Created by Not publicly documented - no paper, manual, vendor announcement, or roster entry naming the language's author or sponsoring organization has been located
LOCK is recorded as a procedural database language that first appeared around 1977 and is now dormant. That sentence contains nearly everything that can be stated about it with confidence, and this page is honest about why: the language has left almost no trace in the public record. No specification, no implementation, no manual, no paper, no vendor announcement, and no named creator could be located in the web searches, encyclopedia and catalog lookups, and academic-index queries conducted for this article.
LOCK’s case is made harder by its name. “Lock” is one of the most overloaded words in computing - the term for a concurrency-control primitive, for a database transaction mechanism, for a record-level file operation, and for at least two unrelated systems that are also called LOCK. Any search for the language is buried under tens of thousands of results about locking in databases rather than a database language named LOCK. Most entries in this encyclopedia reconstruct a language from its surviving artifacts. This one documents the rarer situation of a language known only from its catalog record, and treats the gap itself as the subject: what the record says, what the name and classification suggest, what was happening in database languages in 1977, which other LOCKs it must not be confused with, and what its disappearance says about how software history gets lost.
What the record says
The catalog entry that preserves the language records five facts:
| Field | Recorded value |
|---|---|
| Name | LOCK |
| Year | 1977 |
| Paradigm | Procedural |
| Category | Database |
| Status | Dormant |
That is the entire documented corpus. Each of those values should be read with the caveat that none of them has been independently confirmed against a primary source, because no primary source could be found in any archive searched. The year in particular should be treated as approximate: catalog compilers of obscure languages frequently take a date from a single manual, roster, or bibliography citation, and a citation year is not necessarily a release year.
What the classification suggests
Two things can be inferred from the record, and both are labelled here as inference rather than fact.
“Procedural” plus “Database” describes a specific 1970s genre. Before the relational query languages took over, the dominant way to program against a database was procedurally, one record at a time. The CODASYL Data Base Task Group’s 1971 report - the foundation of network-model systems such as IDMS, IDS/II, and DMS 1100 - defined a data manipulation language whose verbs (FIND, GET, STORE, MODIFY, ERASE) were embedded in a host language, usually COBOL, and navigated the database by following set relationships from one record to the next. Hierarchical systems such as IBM’s IMS worked the same way through DL/I calls. A “procedural database language” of 1977 is far more likely to belong to this navigational tradition than to the declarative, set-at-a-time style of SQL and QUEL that was still largely confined to research prototypes. If LOCK was such a language, it would have been a record-at-a-time DML, a database-oriented extension of a general-purpose language, or a proprietary vendor language for a particular DBMS.
The name is probably meaningful, and probably an acronym. “Lock” was the technical word of the moment in database research: the mid-1970s papers by Jim Gray and his colleagues at IBM San Jose on lock granularity and predicate locks, and by Ries and Stonebraker at Berkeley on the performance cost of locking, established transaction locking as the core problem of multi-user database systems. A 1977 database language called LOCK could plausibly have taken its name from that concern - or, in the fashion of the era, could be an acronym whose expansion has not survived. Which of these is true, or whether the name means something else entirely, the record does not say.
Not to be confused with
Because the name is so heavily reused, it is worth being explicit about what this language is not. Both of the following are documented, and both are unrelated to a 1977 database language:
| Name | What it is | Why it is not this language |
|---|---|---|
| LOCK - LOgical Coprocessing Kernel | A multilevel-secure operating-system project at Honeywell’s Secure Computing Technology Center in Minneapolis (formed in 1984). It grew out of the Secure Ada Target (SAT) effort begun in 1982 and took the LOCK name in its third phase, around 1986-87, targeting the A1 level of the TCSEC and notable for its full implementation of type enforcement. The group was later spun off from Honeywell (reportedly around 1989) as Secure Computing, whose Sidewinder firewall reused LOCK’s ideas. | It is a security kernel, not a language; it dates from the mid-to-late 1980s, not 1977; and its “database” connection is limited to the classified data it was built to protect |
| LOCK (esoteric language) | An esoteric programming language on the Esolang wiki, created by the contributor MagiMaster in 2006 and loosely based on MechaniQue. Program blocks are “locks” that execute only when the running program holds the matching “key,” making locks and keys the sole flow-control structure. | It is a 21st-century thought experiment about control flow, with no database features and no connection to the 1970s |
Alongside these, the generic database concept - lock modes, lock managers, two-phase locking, the LOCK TABLE statement in SQL dialects - accounts for the overwhelming majority of search results for the word, none of which concern a language of that name.
The world LOCK appeared into: database languages in 1977
While nothing further can be said about LOCK itself, its recorded context is unusually well documented, and it makes the existence of a procedural database language in that year entirely plausible - 1977 sits at the exact hinge between the navigational and relational eras.
On the commercial side, the CODASYL network model was at its peak. Cullinane’s IDMS, Honeywell’s IDS/II, Univac’s DMS 1100, and Digital’s DBMS-10 and DBMS-20 all implemented procedural DMLs embedded in COBOL, and the CODASYL committees were preparing the revised 1978 specification. IBM’s hierarchical IMS dominated the mainframe world with its own call-level interface. Vendors and large users routinely built their own query and update languages on top of these systems, most of which never escaped the organization that wrote them.
On the research side, the relational approach was moving from theory toward products. At Berkeley, the Ingres project’s QUEL had been in use since about 1976; at IBM San Jose, the System R prototype’s SEQUEL language was being renamed SQL around 1977 after a trademark conflict; and Moshe Zloof’s Query-by-Example, a visual query language, was described in the IBM Systems Journal that year. In June 1977, Larry Ellison, Bob Miner, and Ed Oates founded Software Development Laboratories, the company that would become Oracle, to build a commercial relational system. The same year, ANSI published the first standard for MUMPS, the hierarchical-database language from Massachusetts General Hospital, giving the minicomputer world a standardized database-programming language of its own.
Between these poles sat a large and mostly forgotten population of vendor-specific, site-specific, and academic database languages - the languages Jean Sammet’s periodic rosters tried to count and the languages later catalogers inherited from those rosters. LOCK’s recorded profile - procedural, database, 1977, dormant - matches that population precisely. It establishes an obvious ecological niche for the language to have occupied, without establishing anything about which part of that niche it filled.
What could not be verified
In the interest of transparency - and so that a future editor with better sources can pick up where this page leaves off - here is what was searched without result:
- General web search, under “LOCK” combined with programming language, database, query language, 1977, data base, acronym, roster, and the names of the major computer vendors of the period, with results about locking mechanisms and physical locks filtered out
- Wikipedia (including its category of programming languages created in 1977 and its full-text search API) and Wikidata, which has no item for a language of this name
- The Esolang wiki, FOLDOC, and programminglanguages.info, none of which record a 1977 database language called LOCK
- dblp and the Internet Archive’s catalog, which return no paper, report, or scanned manual in which LOCK is the proper name of a database system or language
- Jean Sammet’s Roster of Programming Languages for 1976-77 (ACM SIGPLAN Notices 13(11), 1978), the most likely primary source for a language dated 1977 - its full text was not accessible for this article, so LOCK’s presence or absence in it remains unchecked
- The online HOPL encyclopedia and PLDB, two large community catalogs of obscure languages, which were not reachable at the time of research
No match was found in any source that could be reached. Accordingly, this page asserts no creator, no institution, no host DBMS, no feature list, no syntax, no implementation status, and no influence relationships. If the language survives anywhere, it is most likely in a vendor manual that was never digitized, in the printed Sammet roster, or under an expanded acronym that a search for the bare word “LOCK” cannot find.
Why it matters
It may seem odd for an encyclopedia to keep an entry it cannot substantiate. There are two reasons this one stays, and both are the point of the site.
A catalog entry can be a tombstone, and tombstones are data. LOCK is a documented instance of a real phenomenon: the 1970s database language that was real enough to be counted and not durable enough to be preserved. The commercial database world of that decade produced hundreds of proprietary query, report, and update languages, each tied to one vendor’s DBMS and one generation of hardware. When the machines were retired, the manuals went with them, and languages that had run payrolls and inventories for years vanished more completely than many hobbyist languages of the 2000s, which at least left a wiki page. An honest empty entry records that loss more accurately than a confabulated full one would.
It shows how a name can erase a history. Julie4Chapel, another entry on this site known only from its catalog record, is at least searchable; its name is rare. LOCK is the opposite case. A language named after the most common technical noun in its own field is nearly unrecoverable by search alone, because every query returns the concept instead of the language. Preservation is not only about keeping the artifacts - it is also about keeping the metadata that lets someone find them, and a bare four-letter name with no expansion, no author, and no vendor attached is metadata that has already failed.
If you have primary information about this language - a manual, a roster entry, an acronym expansion, a memory of a 1970s database installation - it would be genuinely welcome; a single surviving artifact would let this page be rewritten into a real history.