This is the first part of a three-part look at the software I worked with at the start of my career.
I started looking for work as a programmer in 1999, in the shadow of the dot-com crash. There weren’t many programming jobs to go around in the Chicago suburbs. And if you wanted to know what work was out there, you looked in the newspaper, not online. I faxed…yes, faxed…my resume to a bunch of companies with ads, but there was a huge pool of experienced developers forced out of work recently, and little incentive to hire a youngster without any “real-world” experience.
One of the few companies to bring me in for an interview was a bit of a mystery. They were looking for entry-level programmers, but the ad didn’t say much more. I don’t remember their website, if they even had one, giving up any details of their technology stack. So, I walked into the interview with ten pages of sample code from school, object-oriented C++ code calling out to OpenGL through GLUT. The technical interviewer rolled his eyes at it. “I’ll be honest. Someone like you is probably going to be pretty bored working here. Are you sure you really want the job?” Of course I did. How bad could it be?
Famous last words
To be fair, the job was never boring. In fact, I learned a lot about analysis, project management, professionalism, and dealing with customers there. But what I regret, maybe even resent, was taking a job based around Pick.
The last time I came across Pick was in a display at the Computer History Museum in Mountain View, California. I waited until a group of schoolchildren filtered out of the minicomputer room, then flipped the bird to a photo of its creator. I doubt I was the first. The software that bears his name defined the first seven years of my career and cost me about $1,000 to escape. Much of my time is spent blissfully reminiscing about technologies I’ve used in my life. There’s no such affection for Pick.
The Pick Operating System
Richard “Dick” Pick is a cult icon ripe for caricature, a serial monogamist who named his first database system after his favorite pastime: Generalized Information Retrieval Language System (GIRLS). He wrote GIRLS in 1965 for the IBM System/360 mainframe, itself released in 1964, and the software was as cutting-edge as the hardware it ran on.
The controversial name was dropped for the system’s 1973 commercial release, when it became the Pick Operating System (often shortened to “Pick”). Pick was written to run on mainframes and minicomputers. Later versions run as an application on modern Windows and Unix computers, like a machine within a machine, but more akin to an emulator than a VM. The original OS supported multiple users and time sharing (an early form of multitasking). I don’t know if it supported it in the beginning, but by the time I worked with it, Pick supported virtual memory and could see up to a gigabyte of RAM on its host system.
What’s a “multivalue”?
Database tables in Pick are…wait, I need to rewind here. The Pick operating system is also a database. A post-relational database, as their marketing department proclaimed in the early 2000s. That’s right, MongoDB users. Pick was post-relational before it was cool.
The native Pick file system is built around hash-table based “files”, with primary keys and data. And that data could be any kind of text, as there’s no set schema in Pick. Instead of having a proper schema like a relational database, the data part of a record is essentially a text file. Individual columns, or attributes, in the record are delimited by an attribute mark, ASCII 254. So a person’s first name and last name might be stored as Dana[254]Ross.
Literally every record on a Pick system can look completely different from every other record, even ones in the same table…I mean file…I mean table.
So now you might be thinking “great, but what if I wanted to store two first names in a single record’s first name field?” No, you’re not thinking that? Well good, because that’s insane. Also, Pick has you covered. Every attribute can be divided into one or more multivalues, split by a “value mark”, ASCII 253. So, if you wanted, you could have a record that looks like Dana [253] George [254] Ross [253] Washington. Now you’ve essentially got a way to create records inside of records, if that’s your thing. When you have two attributes whose multivalues line up like that, they’re said to be associated multivalues.
Ok, pick your jaw up off the floor, because we’re not done. We haven’t talked about subvalues yet. What’s a subvalue? Why, it’s how you divide your database columns up even further. I can’t even think of a good example here, because we’re talking about records inside records inside records at this point. The delimiter for this is the “subvalue mark”, ASCII 252.
You’ll be happy to know that’s as far as you can divide one “column”. Oh, except for one variant of Pick with an ASCII 251 delimiter. I’m not making this up. And that’s enough about delimiters because we really need to move on to dictionaries.
As a “post-relational” database, Pick doesn’t have any sort of rules for what a record looks like. Literally every record on a Pick system can look completely different from every other record, even ones in the same table…I mean file…I mean table. So to try and impose some order on top of this, every file has a dictionary, a secondary file attached to the original one. And through its own attributes, values, and subvalues, the dictionary describes data in the main file. None of the data types or other details are enforced, and indeed you can even assign two names to the same attribute. But it’s a dictionary, and it’s essential for writing queries, which we’ll talk about in Part 2.
