Breuners
During those years I actually moved from BofA to John Breuner Company otherwisBe known as Bruener’s Furniture Stores. (John Breuner was a furniture builder who made his fortune during the California Gold Rush in the 1850’s . It was really merchants like Breuner (and Leland Stanford) who made their fortunes from the Gold Rush. The minors who actually found the gold had to pay such exorbitant prices for goods like groceries and furniture that they really weren’t able to keep their own wealth. I often see an analogy in late 20th Century Silicon Valley: The programmers are the miners, a few of whom get rich, but most don’t; the entrepreneurs are the merchants: it is they for the most part who have gotten wealthy on the computer “gold rush”.)
To see an example of John Breuner’s handiwork, one has only to visit the California state capitol building in Sacramento. All of the desks used by the Senate and Assembly were made by John Breuner.
When I worked for Breuner’s, it was still owned by the Breuner family: William Breuner was the president, and Rich Breuner was my third-level manager.
At Breuners I was again using DOS, but this time it was the virtual-storage version of DOS—DOS/VS on a System/370.
Eventually we decided to convert from DOS to OS, in particular OS/VS1. In order to facilitate that we first installed VM/370. VM was always my favorite of the IBM operating systems, because—thanks to CMS—it was interactive rather than batch.
I left Breuner’s and went back to BofA, then back to Breuner’s.
It was at Breuners that I saw my first diskette drive. In those days most processing was “batch” processing, meaning that input was prepared offline as punched cards and the data was loaded in a batch into the computer.
At Breuners we got key-diskette machines that would load data onto diskettes. The diskettes were then read into the computer. The diskettes were eight inches in diameter. I still have one. My kids think it looks enormous compared to the five inch and 3.5 inch drives used today. Actually, I do too.
I once told a computer operator at Breuners that working there was like being at Disneyland: On one side of the street was Frontierland, and on the other side was Tomorrowland. Our “Frontierland” was a set of programs that were originally written for the IBM 1401 (the 2nd generation computer I had learned in the army programming school). Our “Tomorrowland” was a system called “BOLTS”: the “Breuners OnLine Terminal System”. This was the first non-batch system I had worked on. We had IBM 3270 terminals in our headquarters as well as in each of the Breuners Furniture Stores. These latter terminals were connected to our computer facility via dedicated lines we leased from the telephone company. We also began using terminals to submit our compile and test jobs. Yet, our development environment was still batch oriented. We could use the terminal to enter and edit our source program and control statements, but then they were submitted to the batch queue as if they had been read in from cards.
BOLTS used an IBM product called “CICS” (the Customer Information Control System). The name was somewhat of a misnomer: CICS had nothing to do with controlling customer information. Rather, it was what was then known as a “teleprocessing monitor” or what would be known today as an “application server”. The batch operating system was not optimized for handling the numerous simultaneous tasks from remote terminals, and so CICS acted almost like an OS within an OS that would control resources for the online environment. IBM shipped the source code for CICS and I learned a lot about operating-system and other computer-science concepts from studying CICS.
It was through studying CICS, for example, that I learned about linked lists. Because CICS was not really an operating system, it could not utilize such hardware features as memory protection or interrupts. Thus, it was possible for one CICS application program to damage the memory of another; they all ran in the same “partition”. Likewise, CICS could not supply true pre-emptive multitasking. Instead it used co-operative multitasking where a task voluntarily gave up control either directly or by calling some CICS service (such as File Control) that would recognize that the task was blocked and give control to another task.
CICS was very table driven. For every major component there was a table. For the File Control Program there was a File Control Table; for the Terminal Control Program there was the Terminal Control Table, etc. These tables were actually built using assembler macro instructions. IBM provided the definitions of these macros and we would code the table by coding instances of these macros. We would then turn them into the run-time tables by running the assembler. The macros generated data, not code, but the result was nevertheless an object file that was loaded into the CICS storage.
It was at Breuners that I ran into what might be considered my first hacker. The word “hacker” has multiple meanings. One meaning is someone who loves programming and even programs for personal enjoyment, not just as a job. By that definition, I am definitely a hacker. It can also, therefore, imply an amateur, or one who is not well trained. Although I don’t have a computer-science degree, I do consider myself a professional, and I consider myself knowledgeable and experienced in computer programming.
Another meaning of “hacker,” which is more common in the popular press, and thus in use in the general population, is someone who breaks into computers or uses them for dishonest or illegal purposes. Some hackers by the previous definition refer to these disreputable hackers as “crackers” because they like to crack system security.
It is this latter type of hacker we ran into at Breuners. He was not actually a programmer, but he was a Breuners employee. (There was no Internet in those days, so Breuners had a private network, only accessible to employees.) He worked in the credit-authorization department as a terminal operator. He would answer the phone from store employees to approve credit purchases. When the phone wasn’t ringing he found other things to do.
We first ran into him when another systems programmer and I went to the credit-authorization department to investigate some problem. We made use of a CICS transaction that we had written called DEBG which was essentially a machine-language debugger. It could access and change any memory within the CICS partition. We found it handy for examining system state in memory. After we fixed the problem and returned to our office, we began to notice that the DEBG transaction was still being used from credit authorization. This guy had seen us use it and had started to play with it. We password protected it to block him.
Several months later, the credit-authorization clerks were given a tour of the computer room. This guy was among those on the tour. While he was there he stole a CICS Reference Card, a small card showing CICS system commands. He somehow also determined the operators’ password, necessary to execute these commands.
I guess Sundays are slow days, because the following Sunday he spent his time trying out these commands. The system was always scheduled to shut down at a specific time on Sundays (when the stores closed). At precisely that time, he shut down the system. The operator called me at home to see if I had done it, but in fact that would not have been possible because of the private nature of the Breuners network.
The next day we analyzed a log tape to determine what had happened. This tape included every transaction that was entered. There was actually a sequence of commands necessary to shut the system down properly, and the perpetrator hadn’t known that sequence. So the log tape had not been closed properly and we lost the last few minutes of activity, including the shutdown command. But what we did see on the tape were numerous occurrences of CICS system commands coming from this guy’s terminal.
My boss pondered whether to fire the guy or transfer him to our department; he was obviously clever and interested in computers. In the end he decided on neither; the guy was given a tongue-lashing by his own supervisor.
The third encounter with this guy I heard about only indirectly from my boss. It seems this guy had become romantically involved with a woman working at one of our store warehouses. They cooked up a scheme to steal furniture and cover their tracks using the computer. They were both fired, and possibly arrested.
In retrospect, it seems like we should have taken one of the actions my boss had considered, but which one? If we had taken the guy into the data-processing department he might have been better occupied and stayed out of trouble. Or his increased knowledge might have gotten him into bigger trouble—possibly undetected.