This month represents Database Programming & Design’s final appearance before it becomes Intelligent Enterprise (although the magazine will continue on the Web as Database Programming & Design Online). The magazine has served the database community well ever since its premier issue in 1987, and I’m pleased and proud to say that I still have a complete set of issues in my own professional library. I’m proud too to have been a regular contributor to the magazine for more than six years, and I will continue those contributions when it appears as Database Programming & Design Online.
To mark the occasion and close out my own regular column (at least in its current incarnation), I’ve decided to take a little bit of a break from my usual “theory is practical!” theme. (Or have I?) Instead, I want to share with you a sad little story that illustrates the importance of being given good, correct, and relevant instruction and advice (because I take the provision of such instruction and advice to be one of the prime aims of a magazine like this one). The story that follows is true in all major particulars; only the names have been changed—slightly—to protect the parties concerned. I hope you enjoy it.
Several years ago, it was my misfortune to encounter one of the most incompetent pieces of professional computer instruction I have ever seen. I was attending a class on IBM System/360 Assembler Language, which tells you how long ago it was. I should say immediately that I was attending the class not to learn the material as such—I already knew Assembler Language and had written Assembler Language programs. Rather, I was there to observe how the material was taught, because part of my job at that time involved designing and then teaching a basic programmer training course on the same subject.
I need to introduce you to the cast of characters in my tale. There are two of them. Billy (not his real name) was the course instructor. He was close to retiring age and not—so far as I could tell—a software person at all; his background seemed to be in hardware instead. Lee (also not his real name) was a student in the course, a genuine beginner, with no background in computers whatsoever. Lee and I sat next to each other in the front row of the class. As a consequence, Lee quickly discovered that I was already familiar with the subject matter and took to consulting me on technical questions from time to time, and naturally, I helped him out whenever I could. Oh, and I should tell you that Billy the instructor was also aware that I already knew Assembler Language and that I was there primarily to study his methods of instruction.
So much for the mise en scene. Now to my story. On the day in question, we were engaged in one of the class exercises, writing some little toy programs that were going to be run on the computer that night. (Yes, these were the days of punch cards! Batch jobs! Overnight runs! It really was a long time ago.) Anyway, Lee turned to me with a question. Basically, what he wanted to do was define a character string constant, with value the character string AB, but for some reason he wanted that constant to be aligned on a halfword boundary instead of just on a byte boundary.
In case you’ve forgotten (or perhaps never knew), let me show you the correct solution to Lee’s problem. The Assembler Language instruction for defining a constant is DC; thus, the normal way of defining a character string constant with value AB would be as follows:
CCON DC C’AB’
(The name CCON is arbitrary, of course, and in fact optional.) The problem is, however, that character string constants, type C, are in general merely byte aligned, not halfword aligned. So what Lee needed to do was precede the DC instruction just shown with a kind of dummy “define storage” (DS) instruction that would force the necessary alignment, like this:
DS 0H —force halfword alignment
CCON DC C’AB’
However, I wasn’t able to explain this solution to Lee right away, because Billy overheard Lee asking my advice. The following conversation ensued:
Billy: What’s your problem, Lee?
Lee: (Explains.)
Billy: Ah yes, so you do have a real problem, don’t you, Lee? Because you need a type C constant, and type C constants are just byte aligned, not halfword aligned. Right, Lee?
Lee: That’s right, Billy.
Billy: So you can’t use a type C constant—you’ll have to use a type H constant instead, right Lee? Type H constants are halfword aligned. OK? But the trouble is, type H constants are numbers, not character strings, aren’t they? So what we have to do is convert your character string to a number! How do we do that, Lee?
Lee: I’m not sure, Billy.
Billy: OK Lee, get out your handy-dandy green card. [What Billy called the “handy-dandy green card” was a reference card that listed IBM System/360 machine instructions, instruction formats, condition codes, EBCDIC character codes, and the like.] Now look up the list of eb-see-dick character codes on your handy-dandy green card. You found that, Lee?
Lee: Yes, Billy.
Billy: OK Lee, so what’s the eb-see-dick character code for an A?
Lee: Er, I guess it’s charley one, Billy.
Billy: Charley one. [Writes C1 on the blackboard.] OK, and what’s the eb-see-dick character code for a B?
Lee: Charley two.
Billy: Charley two. [Writes C2 on the blackboard, next to the C1, like this: C1C2.] Good. So now we have a number, charley one charley two. But the trouble is, Lee, that type H constant wants a decimal number—and that charley one charley two isn’t a decimal number, is it? It’s a hexadecimal number, right? You know what a hexadecimal number is, Lee?
Lee: Yes Billy, I think so.
Billy: OK, so what we have to do now is convert that hex number to a decimal number. You know how to do that?
Lee: Well, I guess I’m not really sure, Billy.
Billy: All right. Get out your handy-dandy green card again, Lee. You got that? All right, find the section on hexadecimal numbers. Can you find that?
Lee: Yeah, I’ve got it.
Billy: All right then, Lee, what’s a hex charley in binary?
Lee: Er…it’s one one zero zero, Billy.
Billy: Thank you, Lee. [Writes 1100 on the blackboard.] OK, and what’s a hex one in binary?
Lee: Zero zero zero one.
Billy: Three zeros and a one. [Writes 0001 on the blackboard, next to the 1100, like this: 11000001.] Then we have another hex charley. [Adds 1100 to the binary string on the blackboard, like this: 110000011100.] And then a hex two. What’s hex two in binary, Lee?
Lee: Zero zero one zero.
Billy: Uh huh. [Adds 0010 to the binary string on the blackboard, like this: 1100000111000010.] So now we have the whole hex number in binary, Lee. That’s a binary number, Lee. You understand that, Lee?
Lee: Er, yes, I think so, Billy.
(Meanwhile, I’m watching this procedure in total disbelief. What does Billy think he’s doing? But to continue:)
Billy: So our next step is to convert that binary number to decimal, because our type H constant is going to want a decimal number, isn’t it, Lee?
Lee: I suppose so, Billy.
Billy: All right, here’s how we do that. [He writes out the entire binary string again, with plenty of space between pairs of adjacent digits, like this:
1 1 0 0
0 0 0 1
1 1 0 0
0 0 1 0
Then:] Look at your handy-dandy green card again, Lee, and read me off the powers of two.
Lee: One, two, four, eight, 16…[And so on. As he reads off the numbers, Billy writes them down right to left beneath the string of binary digits, like this:
| 1 | 1 | 0 | 0 |
| 32768 | 16384 | 8192 | 4096 |
| 0 | 0 | 0 | 1 |
| 2048 | 1024 | 512 | 256 |
| 1 | 1 | 0 | 0 |
| 128 | 64 | 32 | 16 |
| 0 | 0 | 1 | 0 |
| 8 | 4 | 2 | 1 |
Then:]
Billy: So we have 32,768…and 16,385…and 256…and 128…and 64…and two. So now what we have to do, Lee, we have to add all of these numbers up. [As he reads off the powers of two, he writes them out as an addition sum, thus:
32768
16384
256
128
64
2
_____
_____
_____
At this point he notices my expression as I continue to watch the procedure, jaw agape.] Did I get that right, Chris?
Me: Oh yes, please go on, Billy. You’re doing just great. [Agog to know what’s going to happen next.]
Billy: [Does the addition by hand, very laboriously, taking several minutes, and getting the answer wrong.] So that makes…48,582. So all right Lee, what you need to do is define your halfword constant like this. [Writes:
HCON DC H’48582’
on the blackboard.] Do you understand that, Lee?
Lee: (Looking thoroughly puzzled and confused.) Er…well…um…
Billy: Well, yeah, as a matter of fact, Lee, now you do have a real problem. You know what your real problem is, Lee?
Lee: ???
Billy: (With a flourish.) Yeah, your real problem is, that number [pointing to the 48582 in the DC instruction on the blackboard]—that number—that number might be too big to fit into a halfword!
Lee: ?????
Me: !!!!!
Billy: So what do you think will happen if the number’s too big, Lee?
Lee: ???????
Billy: Well, if the number’s too big…if the number’s too big…Well, if the number’s too big, I guess that old assembler will just trunc-ate it, Lee!
Envoi
If you didn’t understand the tale of Lee and Billy, then maybe I should congratulate you (or envy you) for being too young ever to have had to deal with horrible things like Assembler Language. But that’s not the real point, of course. Sadly enough, I could have easily—though a trifle dishonestly—updated the story to turn it into a fable of relations, domains, and other matters much more directly related to databases, without changing the essential moral one bit.
I guess that’s enough of that. Goodbye for now. I will be talking to you again soon when Database Programming & Design reappears in its online form, as well as in Intelligent Enterprise with a special series analyzing and evaluating E.F. Codd’s original work on the relational model.
C. J. Date is an independent author, lecturer, researcher, and consultant, specializing in relational database systems. His most recent book, coauthored with Hugh Darwen, is Foundation for Object/Relational Databases: The Third Manifesto (Addison-Wesley, 1998). Correspondence may be sent to him in care of Intelligent Enterprise, 411 Borel Ave., Ste. 100, San Mateo, CA 94402.