ZIFFPAGE TITLEA Hex in ComputingBy Tom Steinert-Threlkeld | Posted 2005-07-08 Email Print
WEBINAR: On-demand webcast
Next-Generation Applications Require the Power and Performance of Next-Generation Workstations REGISTER >
Decades before the idea took hold in the dot-com era, Reader's Digest kept a "360-degree view" of each of its customerstracking every contact it ever had with a subscriber to its magazine or a purchaser of any of its condensed books or o
A Hex in Computing
The practical reality, in the early days, was much more prosaic.
There wasn't much discussion of "data warehousing" or "data mining" or anything you might want to call "business intelligence.''
In fact, before the Univac II came along, Reader's Digest's data warehouse consisted of 18 million stencils, little metal plates with subscribers' names, addresses and expiration dates on the front. They were used to create mailing labels, by pressing ink on them. Their edges were notched, to add marketing information to stencils selected for marketing campaigns.
Several rooms in the company's headquarters were devoted to this "prehistoric" system, as Otten terms it. About 100 women and men would toil in a stencil room, making sure each stencil was in the right sequence in the right tray for the right postal code. And, once removed, returned to its right place.
What they couldn't do was easily put customers in buckets they could do something with, like sell customers a new book or record. Or just simply put names in alphabetical order without shuffling cards by hand.
With the new file system and the battery of IBM 360s, they finally had a way of putting order into the universe.
"It was wonderfully awesome to do a sort of 10 million names,'' Burns says.
Being able to sort millions of records by name, state or street address was not the point. Figuring out what prompted each customer to buy more products was the mystery worth solving.
For Burns and 29 other programmers, that meant devising a schema that would compact a record of any offer made to any customer in an "atomic record" of four bytes per event. One byte would record the name of the product; a second the action that resulted (promoted, paid bill, canceled, etc.); a third the type of marketing effort (direct mail piece, house ad, etc.) that spurred the action; and another the month and year of the mailing or other marketing campaign.
Each byte mattered in an era of expensive hardware and expensive memory. IBM had spent $5 billion in 1964 ($28 billion in today's dollars) just to launch the 360.
In fact, Reader's Digest programmers had to figure out how to squeeze lots of information into fields that might only be one byte long. That meant writing in hexadecimal code, an approach taken to maximize use of the limited memory of the IBM machines. "That was the nature of the beast,'' Otten says.
Everyday math is based on decimal code: the numbers 0 through 9. The base is 10: the characters you know as numbers.
Hexadecimal code takes those 10 numbers and adds six letters. Readers' Digest chose A through F.
With decimal code, you can store only 100 different values in two digits: 10 times 10. With hexadecimal code, you can store 256 different values: 16 times 16.
Which happens to be the maximum amount of information that can be stored in a byte. IBM, with the 360, established the standard in the computing industry that a byte would be the equivalent of eight bits of information fed to a machine at a time. Those bits were ones or zeroes. Two different values, eight digits, multiplied into all their possible permutations equals256.
So, November 1987 would become 1C. November 1994 would be 70 and November 2004 was E8. More than two decades of months and years could be captured in 256 two-character combinations.
How could you tell what E8 meant? By looking it up in a table, kept on paper. Or in one's head.
Kahrs and Ritchie, the two lead developers, would define much of the foundation of the system, such as what values to put in the compacted fields. Did you need hex codes for active customers? Expired? Deadbeat? Temporary? Gift recipient?
But everyday "users" of the system wouldn't have to know hex code, project manager Otten decided. Key Reader's Digest policies, such as when to stop shipping products to a particular customer, subscription rates and who was entitled to which rate, would be kept in tables that could be pulled up on screen, altered and fed back into the system.
That separation of business purposeand putting it on screen in a form an everyday worker could see and deal withwas "unique" in a period when only gods working in air-conditioned rooms with raised floors could be experts in computing, according to Burns.
"To think of the system user was quite advanced,'' he says. Until then, dabbling in hex code or putting it to any kind of use "was strictly up the Mr. Wizards and the Mrs. Wizards."