Skip to main content

Of Stacks, Binding and Other Ambiguous Computer Jargon

One of the strangest things about the mainframe is our jargon, sometimes shared with other parts of IT, and based, somewhat oddly, not in Latin, Greek, or even German or French, but in that messiest of common languages: English.

Yes, despite valiant efforts by other languages to inhabit computer hardware, software and programming languages (for example, Prolog, which stands for “Programmation en Logique” in French) in their own lingua, even French didn’t end up being the franca for computing. 

There are a lot of reasons why this might be the case, primary among them perhaps being the substantial role that the United States played in computing history—a country where they speak something similar to English if you don’t ask an Englishman. But another reason may be that English is unafraid of adopting and adapting words from other languages when in search of the mot juste.

But whatever the reasons, we live in a world where many of the commonly accepted terms in computing arrived via the English language. Not only that, a substantial portion of them seem to have had their origins in academia.

After all, while various philosophers (e.g. Socrates in his discussions of techne and poesis), theorists (e.g. Charles Babbage and his theoretical Analytical Engine) and technologists (e.g. Herman Hollerith and his punched-card tabulating machine) made contributions throughout history on the journey to electronic computing, the main contributors to the historical moments since the 1930’s when theory became reality had their roots in academia, military, government, and industry (including health care, finance, and insurance).

And, while the military and business and government may have been somewhat more focused on results, or at least rules, academics may be more prone to focus on data and the original primary repositories thereof: books. Lots and lots of books. Volumes. Sets. Stacks. So the analogies were bound to arise from that context.

Data Sets, Volumes and VTOCs 

Indeed, one of the most uniquely mainframe words in the world of IT is actually still in common use in its original source: academic study: data sets!

Yeah, no one else in the world of computing has an inkling about data sets—might as well be talking about DASD and VSAM—it all sounds Greek to non-mainframe-initiates. They just use “files,” a term we mainframers file away for the handle we put on the drawerful of data that we call a data set. But ”data set” originated with the still-current academic term for a group of data used for a particular purpose.

When you have a bunch of data—perhaps multiple data sets—and you keep them in a single place, you might call it a book, but academics prefer fancier terms than four letters and a single syllable provide, so the word “volume” was chosen, and it stuck, for a single disk (or spindle) or tape reel or cartridge, or similar physical container of data. And at the beginning of many books is a table of contents, so likewise these electromagnetic volumes tend to have VTOCs—i.e. Volume Table(s) of Contents.

Stacks, LIFO Queues, Piles

But if the world of computing has converged on English in some ways, it has also diverged within English in others. One of those ways is the word “stack,” which gets tossed around boardroom tables by people “in the know” who wish to fill the audible bandwidth with their terminology. Consequently, they often sow enough confusion to make you want to throw the book at them. Or maybe a whole stack of books.

Yeah—a stack of books. You know, maybe a pile of books that you put another one on top of while you go do something else, and then go back and get that book when you’re done. Also known as a last-in first-out (LIFO) queue. This is how program calling stacks work. REXX uses the concept as well, though it was not intrinsic to the original IBM System/360 architecture, nor the early implementations of COBOL (a fact I learned the hard way when trying to write a recursive PERFORM only to get an infinite loop).

Except … there are other stacks. The first of these is a network stack, or more commonly a TCP/IP stack. It’s a stack of protocols, where the bottom set of protocols talk directly to the hardware, and the next layer abstracts that into technical functions, and the next layer abstracts it further into … functional functions, and then to application functions. That’s roughly how the TCP/IP stack looks. Of course, both the OSI model and SNA have seven layers to dip your computer chips into, rather than the four that the internet runs with. Those protocols do pile up.

But the biggest pile—er—stack used by jargonizers is the application stack. No, it really is just a pile. You know: Kind of like how mainframe systems are neatly stacked in an orderly manner but distributed systems that have grown organically are more like piles. In this case, the so-called stack is just a bunch of different software and even applications that are brought together to achieve a common purpose. 


But it’s not yet time for a hard stop to this article: I’d be in a bind if I didn’t mention that other great ambiguity in the lexicon of IT.

Binding! You know—that thing that took us from the scroll to the codex. The glue and threads and cover that keep books together.

I won’t bind myself to chronological exactitude here—we’re all bound to make educated guesses sometimes—but I’m inclined to think that the original plan was to bind database accesses and programs that used them into a fixed, and therefore more efficient, approach (particularly Db2). I’m trying hard to avoid other Db2 terms here because I’m not a DBA, so perhaps we would do well to get a Db2 expert (Craig Mullins comes to mind) to write a sequel to this from a database perspective.

On the other hand, data communications could be said to predate databases from some perspectives. My favorite example is the story of a well-known mainframe database that is said to have started out as a data communications product and grown and diverged. So, when a network connection between two devices or systems is established, this is also often referred to as binding.

With today’s security concerns, however, one might suggest that such a binding is not authentic unless it involves authentication, and so we see TCP/IP-based network protocols such as LDAP,” which involve signing on with credentials—or binding.

But we still haven’t broken the spine of this word until we’ve had our CICS—or more specifically CICSPLEX. When terminal owning regions and file owning regions and application owning regions get together as one big plex, and then even talk to other plexes—either persistently or dynamically—well, they need to know they can trust each other. Ah, the binds that tie.

And with that, I think it’s time to close the book on these musings of ambiguity, or at least turn the page.