I remember seeing, in the 1970’s, computer tape drives in store front windows. Operators would have to go into the window display area to change tapes, making the entire thing a show (and they were wearing white shirts and ties, which is not a particularly good idea when working with equipment that has rapidly spinning parts). That’s what most people thought of when they thought of computers in those days. In fact, a drawing of an old-fashioned tape drive is still used to represent computers in cartoons today. Eventually IBM figured out that sunlight is very hard on plastic tape—in fact, leave it in the sun long enough and it will disintegrate—and so they moved the tape drives into air conditioned computer rooms where they belonged.
But those computer rooms, though nominally clean, were not the best place for disk drives and other highly sensitive equipment. The main problem with the old computer rooms is that they contained people—and people are, and were, the dirtiest things in such rooms. In the early days it took fairly large teams of people to keep computer systems functioning. Contrary to popular belief, most of the people in the computer rooms were not scientists or mathematicians; they were more likely to be high school grads with no particular skills other than a willingness to follow instructions and work through the night and on weekends. Being out of public view they dressed pretty much as they pleased under the lab coats that they wore (in order to protect them from ink in the printers and plotters, not because they were scientists).
When I began there were employees in the computer room who had been there for several years. They were full-fledged government employees protected by unions and a hierarchical system that rated seniority above ability. But, new employees did not receive that benefit; instead, they were hired as “term” employees, meaning they were not protected by the unions and their term of employment was limited (usually to six months, though such terms were regularly renewed.) It took me about a year to win full-time permanent status, but, most employees continued as terms for many years. I once remarked to my boss that I thought the reason that new employees were permanently on term (a slight contradiction in terms) was to prepare for the day when computers would not need so many humans attending on them. He agreed.
I was one of the ones working on the process to get people out of the noisy air-conditioned rooms, to leave the computers to look after themselves. I wrote a series of programs that did some of the routine monitoring that people used to do. Where the huge CDC Cybers and the midrange IBM system required dozens of people in constant attendance, my VAX VMS machines required only an operator to change tapes now and then. Everything else I set up as automated self-regulating systems. My purpose was never to put people out of work, but to free them from boring repetitive tasks that computers could handle on their own at far greater accuracy. People, I figured, would get more interesting jobs; for one, there was a shortage of programmers and software engineers.
Contracting-out expanded rapidly throughout the Mulroney years. Permanent employees are expensive. Besides medical benefits, long term disability, employer taxes, most employers then paid for pension plans. Unionized employees were even more expensive because you had to give them a severance package far better than what the law required—and you had to lay people off in order of seniority leaving you with a skeleton crew of the highest paid group of employees. By contracting-out services you avoid all that overhead. Companies bid to supply the services and you pay a predictable amount for the contract. Who the people are who are doing the actual work and what they are paid does not matter to you as long as they don’t screw up.
Another benefit was that the government could claim it had slashed so many jobs from the public service (always a popular move in the rest of the country). The fact that often those very same people would be back at the same jobs under a contracting arrangement was not mentioned. That accounts for the contradiction of fewer public employees but higher government expenditures. Every political party claims it intends to, or has, let thousands of people go, but, the numbers actually working in the public service keep growing. It’s just that most of them are not “employees;” they are “contractors”—and we don’t count those.
When the axe fell and almost two hundred people employed at the centre and in its support systems were let go, I moved on to a consulting firm. Because the firm I joined had won the contract to supply personnel to keep the computer-room going, I was asked for recommendations by my new private-business employers. For each of the former employees at the centre who I recommended they hire, I was paid $1,000. Not a bad deal from my point of view. (I think that my total was $7,000 in such “bonuses.”)
Because privately-owned companies are in the business of making money, the fewer people they have to pay to meet the terms of a contract the better. And so the squeeze began in earnest. Where once you needed two people: one monitoring the system and the other standing by waiting for a computer to ask for a tape to be mounted, now you could ask the person monitoring the system to do that. In fact, I was once asked to design a system so that the monitoring equipment and tape drives could be kept at the contractor’s site, just leaving the computer and main communications gear at the client site. That way many systems could be monitored and attended to by a much smaller crew. Remote communication simply was not fast enough and reliable enough at the time to set up such a system though it is certainly feasible today. The point is that people were becoming redundant.
“Lights out” technology became a buzz-word for a while, especially as the huge old people-dependant machines were phased out. The advantages of having no humans at all in computer rooms were obvious. At the time, people still had to enter the rooms to change tapes, but, otherwise, all monitoring and software support tasks could be done from outside the room. As communications improved, those monitoring and otherwise supporting did not have to be in the same building that the systems were located. They could be anywhere in the country (or the world, as it is today). In fact, I did a lot of remote support of systems from one coast to the other, often from my office at home. I could nurse a sick server in Kamloops, BC, oversee a disk-drive replacement in Halifax, NS, and talk to someone in New York about a software licence, and then “attend” a conference call with my country-wide clients in the morning, all without leaving the house. So, instead of one of me in every city across the country, there was just one living in a remote forest. And all those computers were running smoothly in cool darkened and people-free rooms.
Tuesday, 11 October 2011
Monday, 3 October 2011
Data and Disaster
In my first year or two in the computing world I saw a lot of card decks. No, not the playing kind—the computer kind. Hollerith cards were originally created by Herman Hollerith (1860-1929) as tools to be used in analyzing statistics. By punching holes in standard-size cards at predetermined locations, one could use mechanical methods to sort data quickly. His technique was used to tabulate the 1890 American census results. Eventually his company, through mergers, became one of the foundations of IBM (founded in 1924).
The standard cards in use in the computing industry throughout the later part of the 20ieth century had 80 columns of 12 rows each. The rows were numbered 0 through 9, with two more rows reserved, originally for plus and minus signs, but later used to expand the vocabulary of a card to allow for upper and lower case letters and other special marks. Sometimes the holes were used to represent binary numbers (which, you will recall, are symbolized by digits of only 0 and 1). As computing spread through the business world in the 1970’s and early 1980’s key-punch operators were in demand. Financial records, medical records, inventory-tracking systems, scientific data were all being recorded on punch cards.
I often handled card decks in my early years. In fact, my first programs were written on punch cards. I would write the program out by hand, then sit at a huge card punch machine to enter the code that would be punched onto cards. The cards were then taken to the computer room where they were fed through another huge machine to be read and executed by the computer. Output was printed onto fan-fold paper. Cards in-paper out was the way we operated then. In my role as operator at the computer centre where I first worked, users would bring me boxes of cards that I would accept through a submission window. I’d put the cards through the card reader when I had time. The job wouldn’t actually execute until a senior operator gave it the go-ahead—and that might not be until 2:00 am the following day, depending on how busy the system was. After it did run, I’d fetch the paper output from the printer that was about the size of a small car then wrap the paper around the original card box and secure it with an elastic band. The package was kept in pigeon holes to await the return of the user.
I’ve gone into some detail here in order to stress the fact that “data” was something tangible that users could hold in their hands. I sometimes tried to convince users that their data was safe if stored on disk—and much more convenient to access. Some wouldn’t buy it. They had spent a career gathering the data vital to their research and didn’t trust it being turned into electronic signals. Cards they could keep secure in their offices—and if the computer centre burned to the ground, their data was safe and could be processed on another computer. Eventually, of course, card decks disappeared except as curiosity items.
But, what about the data they represented? First, while 12 rows of 80 columns can hold a tremendous amount of data, sometimes that simply wasn’t enough space. Many simple computer code instructions, for example, could not be fit into 80 character spaces—to give a mundane example. One of the science groups I worked with recorded data that had to be precise to 29 decimal places. That doesn’t leave much room for anything else. You might recall, if your name was longer than, say, 12 characters, receiving mail with your name truncated. That’s because a programmer was trying to fit your name and full address, along with other relevant information into 80 spaces. So, cards were already unreliable because of the limitations on how much data each card could contain. It is one thing to truncate a name, but quite another to truncate medical information.
Secondly, cards were not as physically secure as many users believed. They were made of very light cardboard and so could get caught in card readers and torn to shreds. They could get dropped and slide unnoticed under a file cabinet. They burned readily—and sometimes they showered out of a university’s computer room to the streets below. Computer disks, which at that time were the size of a standard home dryer, didn’t suffer from those limitations—though a particle of cigarette smoke could get between the disk surface and the read-write head, dislodging the head causing it to crash onto the disk’s surface. Hence: a head-crash. Usually unrecoverable because, even with a new head assembly, the disk surface, where the data was stored, was scratched and computers could no longer make sense of the signals they were reading.
Because of the limitations of physical devices computer rooms everywhere established procedures to protect the data in the event of a head crash. The standard method was to copy the data, in a compressed format, onto tapes. At first the tapes were stored in the computer room but eventually it occurred to someone that this, perhaps, wasn’t the best idea. The tapes should be stored at some other location so that, even if the computer room did burn down, the vital information was secure. At the same time, the data needed to be readily accessible, so compromises were made, like one copy on-site, one off-site.
But that’s not the end of the story. Tapes, made of ferrous oxide on a plastic strip, had limited lifetimes. If the tape was left unused for long enough, eventually data would “bleed” from one location on the tape to an adjacent strip pressed firmly against it. Oxide eventually disintegrated and fell off the surface. Plastic would get brittle given enough time and break when it was stretched by a tape drive. The half-life (the time at which 50% of the tapes became unusable) was usually about ten years. Not good enough. Businesses, government offices, research facilities, medical centres, etc. could not afford to lose half of their data every ten years.
To preserve the data on tapes for as long as possible, tape librarians—if they knew what they were doing—would “exercise” the tapes at regular intervals by mounting, unreeling them, then rewinding. Tape formats changed over the years in order to get more data into physically smaller space, but, the basic limitations of tape never changed. Still, large computer centres relied on tape, sometimes in robotic-controlled “silos” capable of storing thousands of tapes, usually in cartridge format.
In the mid 1980’s to early 1990’s a new approach was developed. Disk drives were now fast enough that data could be written to two disks simultaneously—thus providing a real-time very accessible backup. RAID sets, as groups of linked disks were called, came in different configurations depending on how vital immediate access to backed up data was (and the pocket book of the owner). A popular configuration was a three-disk unit where the data was written to three disks, and could be reconstructed, based on the parity information on the surviving two disks, in the event that one of them crashed. This doesn’t get around the limitation of storing data in one place, so it was often combined with off-site tape storage. An even better solution, when immediate access to data no matter what disaster occurred, was the development of remote clusters.
A system cluster was a group of computers linked together in such a way that they could perform, as far as the user was concerned, as one system much larger than any individual one. Not only was performance, as a whole, enhanced, but immediate access to redundant data was possible. Once it became possible to have a cluster that functioned as a unit even though components were at different locations, live off-site backup was a reality. Such setups are expensive, but absolutely necessary in some situations (like banking information). In these setups usually both sites are accessed as if they were one unit, but the data is kept at both locations. If one site goes down, the other can continue to function, though at a reduced performance rate. Users could possibly notice no more than a temporary glitch in their sessions.
Not every company can afford such a setup. Depending on the urgency of access to data (and the amount of money available) there are different strategies in place to enable a business to recover from the disaster of a computer-room fire. There are companies that specialize in disaster recovery who offer different levels of service. One method that I worked on with two different clients involved a contract commitment to a 24-hour recovery. This meant that the recovery company guaranteed that the business could be functional within 24 hours of a disaster. It involved having equipment available that could mirror the setup of the target system quickly and provide the delivery of off-site backup tapes. As well, rented equipment, such as personal computers, servers, desks, telephones, could be delivered to a pre-arranged location. The tapes would restore the data to the mirror system while the new “office” was being set up.
You might think, on reading this, that every business is now protected by data redundancy. Such, however, is not the case. After I left the field and worked for non-computer companies I was surprised to find no backup strategies in place at all. At one small company, I started a system of backing-up the key data every night to a writable CD and then doing a full backup once a week. The full backup I would hand to the company owner and tell him, “This is your business. Keep it at home in a safe place.”
At another company, we experienced a disk crash. No one at the company seemed to have a clue what was going on as the disk failed over the course of a few hours. A general feeling panic developed as people with no background or experience guessed at what was happening and how long recovery would take. When the disk finally failed completely and a new disk installed by a technician, I was stunned to find out that the company had no backups of the data. When I asked why not, I was told that they had never experienced a problem with that software package before. No one understood when I tried to explain that the failure had absolutely nothing to do with the software application. It was a hardware failure, pure and simple, and, eventually, all hardware will fail.
Fortunately, I was able to rebuild the lost data using information stored on another disk and in the paper files. It took several weeks at 4-8 hours a day—and the only reason I could do it was because I was intimately familiar with the two software packages involved, as well as general computing basics. No one else at that office could have accomplished what I did. They now backup their data nightly.
The standard cards in use in the computing industry throughout the later part of the 20ieth century had 80 columns of 12 rows each. The rows were numbered 0 through 9, with two more rows reserved, originally for plus and minus signs, but later used to expand the vocabulary of a card to allow for upper and lower case letters and other special marks. Sometimes the holes were used to represent binary numbers (which, you will recall, are symbolized by digits of only 0 and 1). As computing spread through the business world in the 1970’s and early 1980’s key-punch operators were in demand. Financial records, medical records, inventory-tracking systems, scientific data were all being recorded on punch cards.
I often handled card decks in my early years. In fact, my first programs were written on punch cards. I would write the program out by hand, then sit at a huge card punch machine to enter the code that would be punched onto cards. The cards were then taken to the computer room where they were fed through another huge machine to be read and executed by the computer. Output was printed onto fan-fold paper. Cards in-paper out was the way we operated then. In my role as operator at the computer centre where I first worked, users would bring me boxes of cards that I would accept through a submission window. I’d put the cards through the card reader when I had time. The job wouldn’t actually execute until a senior operator gave it the go-ahead—and that might not be until 2:00 am the following day, depending on how busy the system was. After it did run, I’d fetch the paper output from the printer that was about the size of a small car then wrap the paper around the original card box and secure it with an elastic band. The package was kept in pigeon holes to await the return of the user.
I’ve gone into some detail here in order to stress the fact that “data” was something tangible that users could hold in their hands. I sometimes tried to convince users that their data was safe if stored on disk—and much more convenient to access. Some wouldn’t buy it. They had spent a career gathering the data vital to their research and didn’t trust it being turned into electronic signals. Cards they could keep secure in their offices—and if the computer centre burned to the ground, their data was safe and could be processed on another computer. Eventually, of course, card decks disappeared except as curiosity items.
But, what about the data they represented? First, while 12 rows of 80 columns can hold a tremendous amount of data, sometimes that simply wasn’t enough space. Many simple computer code instructions, for example, could not be fit into 80 character spaces—to give a mundane example. One of the science groups I worked with recorded data that had to be precise to 29 decimal places. That doesn’t leave much room for anything else. You might recall, if your name was longer than, say, 12 characters, receiving mail with your name truncated. That’s because a programmer was trying to fit your name and full address, along with other relevant information into 80 spaces. So, cards were already unreliable because of the limitations on how much data each card could contain. It is one thing to truncate a name, but quite another to truncate medical information.
Secondly, cards were not as physically secure as many users believed. They were made of very light cardboard and so could get caught in card readers and torn to shreds. They could get dropped and slide unnoticed under a file cabinet. They burned readily—and sometimes they showered out of a university’s computer room to the streets below. Computer disks, which at that time were the size of a standard home dryer, didn’t suffer from those limitations—though a particle of cigarette smoke could get between the disk surface and the read-write head, dislodging the head causing it to crash onto the disk’s surface. Hence: a head-crash. Usually unrecoverable because, even with a new head assembly, the disk surface, where the data was stored, was scratched and computers could no longer make sense of the signals they were reading.
Because of the limitations of physical devices computer rooms everywhere established procedures to protect the data in the event of a head crash. The standard method was to copy the data, in a compressed format, onto tapes. At first the tapes were stored in the computer room but eventually it occurred to someone that this, perhaps, wasn’t the best idea. The tapes should be stored at some other location so that, even if the computer room did burn down, the vital information was secure. At the same time, the data needed to be readily accessible, so compromises were made, like one copy on-site, one off-site.
But that’s not the end of the story. Tapes, made of ferrous oxide on a plastic strip, had limited lifetimes. If the tape was left unused for long enough, eventually data would “bleed” from one location on the tape to an adjacent strip pressed firmly against it. Oxide eventually disintegrated and fell off the surface. Plastic would get brittle given enough time and break when it was stretched by a tape drive. The half-life (the time at which 50% of the tapes became unusable) was usually about ten years. Not good enough. Businesses, government offices, research facilities, medical centres, etc. could not afford to lose half of their data every ten years.
To preserve the data on tapes for as long as possible, tape librarians—if they knew what they were doing—would “exercise” the tapes at regular intervals by mounting, unreeling them, then rewinding. Tape formats changed over the years in order to get more data into physically smaller space, but, the basic limitations of tape never changed. Still, large computer centres relied on tape, sometimes in robotic-controlled “silos” capable of storing thousands of tapes, usually in cartridge format.
In the mid 1980’s to early 1990’s a new approach was developed. Disk drives were now fast enough that data could be written to two disks simultaneously—thus providing a real-time very accessible backup. RAID sets, as groups of linked disks were called, came in different configurations depending on how vital immediate access to backed up data was (and the pocket book of the owner). A popular configuration was a three-disk unit where the data was written to three disks, and could be reconstructed, based on the parity information on the surviving two disks, in the event that one of them crashed. This doesn’t get around the limitation of storing data in one place, so it was often combined with off-site tape storage. An even better solution, when immediate access to data no matter what disaster occurred, was the development of remote clusters.
A system cluster was a group of computers linked together in such a way that they could perform, as far as the user was concerned, as one system much larger than any individual one. Not only was performance, as a whole, enhanced, but immediate access to redundant data was possible. Once it became possible to have a cluster that functioned as a unit even though components were at different locations, live off-site backup was a reality. Such setups are expensive, but absolutely necessary in some situations (like banking information). In these setups usually both sites are accessed as if they were one unit, but the data is kept at both locations. If one site goes down, the other can continue to function, though at a reduced performance rate. Users could possibly notice no more than a temporary glitch in their sessions.
Not every company can afford such a setup. Depending on the urgency of access to data (and the amount of money available) there are different strategies in place to enable a business to recover from the disaster of a computer-room fire. There are companies that specialize in disaster recovery who offer different levels of service. One method that I worked on with two different clients involved a contract commitment to a 24-hour recovery. This meant that the recovery company guaranteed that the business could be functional within 24 hours of a disaster. It involved having equipment available that could mirror the setup of the target system quickly and provide the delivery of off-site backup tapes. As well, rented equipment, such as personal computers, servers, desks, telephones, could be delivered to a pre-arranged location. The tapes would restore the data to the mirror system while the new “office” was being set up.
You might think, on reading this, that every business is now protected by data redundancy. Such, however, is not the case. After I left the field and worked for non-computer companies I was surprised to find no backup strategies in place at all. At one small company, I started a system of backing-up the key data every night to a writable CD and then doing a full backup once a week. The full backup I would hand to the company owner and tell him, “This is your business. Keep it at home in a safe place.”
At another company, we experienced a disk crash. No one at the company seemed to have a clue what was going on as the disk failed over the course of a few hours. A general feeling panic developed as people with no background or experience guessed at what was happening and how long recovery would take. When the disk finally failed completely and a new disk installed by a technician, I was stunned to find out that the company had no backups of the data. When I asked why not, I was told that they had never experienced a problem with that software package before. No one understood when I tried to explain that the failure had absolutely nothing to do with the software application. It was a hardware failure, pure and simple, and, eventually, all hardware will fail.
Fortunately, I was able to rebuild the lost data using information stored on another disk and in the paper files. It took several weeks at 4-8 hours a day—and the only reason I could do it was because I was intimately familiar with the two software packages involved, as well as general computing basics. No one else at that office could have accomplished what I did. They now backup their data nightly.
Saturday, 17 September 2011
Working at the PMO
Most government departments appear to be housed in office towers if they are not in the Tunney’s Pasture Complex of buildings. A notable exception is the Prime Minister’s Office which is located in a group of connected buildings between Wellington and Sparks, running from Elgin to Melcalfe Streets. The buildings themselves date back to the 1920’s or so when architecture still included gargoyles and carved friezes depicting historic or fanciful themes.
The employee entrance to the PMO is through an otherwise nondescript door on Sparks Street. One enters a dark narrow hallway with a commissionaire seated at a simple wooden desk. After he checks your ID you can pass to the small elevator lobby. The elevators are old and start and stop with abrupt jerks. Often they contain CSIS agents. You can always tell who they are by their size. There must be a minimum height requirement of six and a half feet to join that service.
The building is aged. Hardwood floors are worn and many offices are encased in glass while others have heavy wooden doors. The computer room is enclosed a box made of three-inch thick steel. No, that’s not to make it bomb-proof; it is supposed to be spy-proof. Apparently the Russians had sophisticated equipment that could reconstruct the monitor of a computer or a computer keyboard just from the electronic signals it generated. The prime minister’s computer were the most “secure” I had ever seen in my government career—though I am sure they must be others even more highly protected that I would never have gotten near.
The “secrets” that the PMO’s computers housed were the day’s daily wire-service reports. Most of the world’s wire services fed into the machines that used elaborate search-engine techniques to sort out what might be of interest to the leader of the country. Humans, located at another location, sifted through the selected reports, further refining the search, cutting and editing. All this to produce briefing notes on whatever the Prime Minister might be called upon to respond to.
The operators in the computer room were the same as you will find in any other computer room. High school grads with no particular skills except for the ability to sit up all night staring at computer screens and being able to follow directions if an event occurred. Jeans and casual shirts were the standard uniform. Some wild hair was tolerated. The standard vocabulary and speech patterns were working-class Ottawa valley. I was told that Trudeau used to sometimes drop by the computer room late at night and chat with the guys, asking what they were up to. He had a genuine curiosity about what people around him did for a living and about their lives. I was there during the Mulroney era and was told that “King Brian,” as the staff referred to him, never deigned to slum.
The offices were generally very large, as befitting those close to the PM. Many had large television sets and VCR machines housed in cabinets—and their desks were cluttered with computer equipment. The rooms weren’t designed for modern electronics and so cables tended to snake everywhere, clashing with the general décor. On one brief contract I upgraded the computers, replacing the 4 Gb RAM chips with 8 Gb RAM, and the amber monitors with colour ones. At the same time I upgraded the operating systems. No one was ever in an office when I entered with my screw driver and bag of computer chips. I studiously ignored the files and booklets stamped “Secret” that lay on many of the desks. I paranoid-ly assumed that I was being watched and, in any case, the “secret” stuff was probably boring and meaningless to me.
I was required to return the machines to the same start-up state they were in before I made my modifications. I was somewhat surprised to find some booted directly into “The Search for Red October,” a popular game at the time. One time I took a wrong turn and wound up in the Wellington Street lobby of the Prime Minister’s office. It was a huge open space like the lobby of an expensive hotel. The deep blue carpet was being vacuumed by a uniformed maid. Another time I wound up in the basement of the building—a long room, almost the length of the entire complex, filled with traveling trunks and cases. I was told this was what traveled with the PM whenever he left Ottawa. It must have taken a fleet of tractor trailers to get all that stuff just to the airport.
When President Clinton was visiting Ottawa a fellow employee took me up to the top floor overlooking Wellington Street and Parliament Hill. I was surprised, though I probably shouldn’t have been, to see sharp-shooters and spotters in positions on the roofs and terraces on our building and the buildings around us. I would guess that it’s about a kilometer from where we were to the main front doors of parliament—and these guys never missed.
One evening when Clinton was visiting a police officer stepped out in front of our car, holding us up for over an hour while we waited for Clinton’s motorcade to appear and race past. Such is life in a capital city.
The employee entrance to the PMO is through an otherwise nondescript door on Sparks Street. One enters a dark narrow hallway with a commissionaire seated at a simple wooden desk. After he checks your ID you can pass to the small elevator lobby. The elevators are old and start and stop with abrupt jerks. Often they contain CSIS agents. You can always tell who they are by their size. There must be a minimum height requirement of six and a half feet to join that service.
The building is aged. Hardwood floors are worn and many offices are encased in glass while others have heavy wooden doors. The computer room is enclosed a box made of three-inch thick steel. No, that’s not to make it bomb-proof; it is supposed to be spy-proof. Apparently the Russians had sophisticated equipment that could reconstruct the monitor of a computer or a computer keyboard just from the electronic signals it generated. The prime minister’s computer were the most “secure” I had ever seen in my government career—though I am sure they must be others even more highly protected that I would never have gotten near.
The “secrets” that the PMO’s computers housed were the day’s daily wire-service reports. Most of the world’s wire services fed into the machines that used elaborate search-engine techniques to sort out what might be of interest to the leader of the country. Humans, located at another location, sifted through the selected reports, further refining the search, cutting and editing. All this to produce briefing notes on whatever the Prime Minister might be called upon to respond to.
The operators in the computer room were the same as you will find in any other computer room. High school grads with no particular skills except for the ability to sit up all night staring at computer screens and being able to follow directions if an event occurred. Jeans and casual shirts were the standard uniform. Some wild hair was tolerated. The standard vocabulary and speech patterns were working-class Ottawa valley. I was told that Trudeau used to sometimes drop by the computer room late at night and chat with the guys, asking what they were up to. He had a genuine curiosity about what people around him did for a living and about their lives. I was there during the Mulroney era and was told that “King Brian,” as the staff referred to him, never deigned to slum.
The offices were generally very large, as befitting those close to the PM. Many had large television sets and VCR machines housed in cabinets—and their desks were cluttered with computer equipment. The rooms weren’t designed for modern electronics and so cables tended to snake everywhere, clashing with the general décor. On one brief contract I upgraded the computers, replacing the 4 Gb RAM chips with 8 Gb RAM, and the amber monitors with colour ones. At the same time I upgraded the operating systems. No one was ever in an office when I entered with my screw driver and bag of computer chips. I studiously ignored the files and booklets stamped “Secret” that lay on many of the desks. I paranoid-ly assumed that I was being watched and, in any case, the “secret” stuff was probably boring and meaningless to me.
I was required to return the machines to the same start-up state they were in before I made my modifications. I was somewhat surprised to find some booted directly into “The Search for Red October,” a popular game at the time. One time I took a wrong turn and wound up in the Wellington Street lobby of the Prime Minister’s office. It was a huge open space like the lobby of an expensive hotel. The deep blue carpet was being vacuumed by a uniformed maid. Another time I wound up in the basement of the building—a long room, almost the length of the entire complex, filled with traveling trunks and cases. I was told this was what traveled with the PM whenever he left Ottawa. It must have taken a fleet of tractor trailers to get all that stuff just to the airport.
When President Clinton was visiting Ottawa a fellow employee took me up to the top floor overlooking Wellington Street and Parliament Hill. I was surprised, though I probably shouldn’t have been, to see sharp-shooters and spotters in positions on the roofs and terraces on our building and the buildings around us. I would guess that it’s about a kilometer from where we were to the main front doors of parliament—and these guys never missed.
One evening when Clinton was visiting a police officer stepped out in front of our car, holding us up for over an hour while we waited for Clinton’s motorcade to appear and race past. Such is life in a capital city.
Monday, 12 September 2011
Sex and the workplace? What do we really know?
This story is a bit difficult to tell because when it comes to the private relationships between sales representatives and clients obviously no one else was there to witness what went on in intimate moments. People in the workplace make statements like: “She’s fucking him,” or “He’s doing her regularly” in an authoritative insider-knowledge tone, but, how do they know? Really? We do observe other people’s interactions and draw inferences, but how accurate are our interpretations? Everything we experience is filtered through the sieve of our prior experiences and expectations so can we trust anything we think we see?
At the same time, when I was a student I knew a young woman who went to work for a large corporation. I had a drink with her one evening after work and my jaw nearly hit the floor when she told me that her intention was to fuck her way to the top. Other than uttering that one sentence she presented herself as a nice young woman from the suburbs. Of course I was young and still somewhat naïve, not realizing at that time that nice girls do and that women can be just as cold-blooded and manipulative as men when it comes to sex. More so, in some cases, as the male usually is satisfied with the act while females can use the act in order to achieve some other end. Still I was thunderstruck by the rawness of her statement.
During my career I have worked with about a half-dozen women who made no secret of the fact that they were using their sexuality as a tool in the workplace. A few admitted it openly to me. I can think of four different women, in different jobs at different times, whose standard daily work outfit included a micro-skirt that rode up to their hips, when viewed from the side, when they sat down. I am fully aware that one of the reasons for wearing so little covering that one’s underwear is exposed as a matter of course is to assert a woman’s right to wear whatever she wishes without being subject to harassment or unwanted attention. That’s what they say, anyhow.
I met one such woman when I was working on a contract where she was the sales representative for Digital Equipment (DEC). She was, by any standard, a stunningly beautiful woman in her early 30’s, and she dressed the part. Every male eye was on her when she entered a room and she exuded an attitude of secure and infallible sexuality, apparently aware that she could turn any man in the room into a gibbering idiot. Of course, she was not interested in gibbering idiots. She was attracted to the men apparently immune to her charms, the men with power to control others and to face her with serene equanimity.
She was supposed to teach me how to use a new product that Digital was promoting. She did so disdainfully and unwillingly. I worked for a competitive company and she was not keen to share any advantage. I let her go through her condescending dismissive demonstration without comment, then, afterwards, set about teaching myself how to use the product.
I then moved on to the Prime Minister’s Office. I was there for about three months as a consultant to the operations group, helping them to get their procedures developed and documented. As a matter of course I installed the system monitoring tools I had developed over the years. These tools kept track of performance and usage metrics and automatically produced reports on the system’s workloads. When I finished that contract, I went to another computer site for three or four months, but then returned to the Prime Minister’s Office in order to study and make recommendations for facilities management. In other words, produce a report indicated what kind of hardware upgrades they could expect to make during the next two or three years.
I already had my tools running, so, by this point, I had about six months’ worth of data to work with. I would have preferred data spanning a year or more, but, I had to work with what I had. I painstakingly analyzed the data, identifying trend-lines and projecting them, accounting for the interactions between different hardware. For example, if disk space requirements expanded by 50%, are their sufficient tape drives to back up this data within the constraints of the backup windows? That sort of thing. Being the Prime Minister’s Office I had all the latest toys to work with, including a four-color plotter. This was long before color printers and color photocopiers. A plotter consisted of four computer-controlled pens that could be used to draw charts and graphs. I made full use of it.
My report was a masterpiece. Beautiful four-color charts gave immediate visual confirmation of what my words communicated. I had solid lines where there was solid data and dashed lines where it was projected data. Relationships were all clearly identified and illustrated. I had projected the future of the Prime Minister’s computing centre for two years out with indications of what was to come beyond that. I handed in my report.
I was at home nursing the flu a few days later when I got a call that I had a meeting scheduled with the ADM that afternoon. An ADM (Assistant Deputy Minister) is the highest position in the civil service. The Minister of a department is the front-line political appointee and his deputy ministers are his staff, each responsible for a certain aspect or operation of the department. An ADM is as close to god as any human can get without entering the rarefied atmosphere of the political top dogs. You do not say no to an ADM. I showered, hoping that the sweat and sickness would wash away, and dressed in my suit (I did have one suit reserved for just such occasions), which was too hot considering my fever, and drove to the centre of downtown Ottawa.
I was escorted by security to the ADM’s office where a group of half a dozen were seated around a table. They were mainly elderly men with one stunning exception: the Digital Sales Rep who was sitting next to the ADM himself. The ADM was a friendly older man obviously used to wielding power. He congratulated me on my skilful use of colour in my report, then ruefully lamented that it didn’t survive photocopying. (There was no such thing as a colour copier then.) He asked me to summarize the report for the assembled.
I did my best. When I finished the ADM turned to the DEC Sales Rep and asked her for comments. She began by saying, “As we discussed previously…” and then she went on to present her analysis of what hardware would be required, completely ignoring my data and what I had said. It was as if I didn’t exist. The ADM then smiled at me and said, “Do you think you can revise your report before five o’clock today? We’d like to get the RFP out as soon as possible.” (The RFP is the procedure the government follows when seeking tenders for goods and services.)
What choice did I have? I stood at my desk for a long time considering what had just occurred. My report had been honest. I did not agree with the sales rep’s analysis, yet it was clear that the ADM and his team had already bought it. What would I gain by refusing the ADM’s orders? Nothing. I’d probably never work in a government department again. But, if I followed them my integrity would be compromised. We like to think of ourselves as heroes standing for what is right no matter what the cost, but, there are times when you have to weight the consequences. I sighed, and sat down to revise my charts to support the decisions that had already been made.
Later, when telling this story to a colleague he said without hesitation, “Everyone knows she was fucking him.” It made sense. I had picked up a hint of intimacy between them during the meeting. One thing was very clear: they knew each other fairly well before that meeting. But I don’t know the truth and neither did my colleague. “Everyone knows” is proof of nothing. One thing was clear to me: I did not exist in her world; she saw only power—and I had none. I’m okay with that. I am comfortable with the fact that I don’t exist for many people. There is one advantage I have: I can observe them.
At the same time, when I was a student I knew a young woman who went to work for a large corporation. I had a drink with her one evening after work and my jaw nearly hit the floor when she told me that her intention was to fuck her way to the top. Other than uttering that one sentence she presented herself as a nice young woman from the suburbs. Of course I was young and still somewhat naïve, not realizing at that time that nice girls do and that women can be just as cold-blooded and manipulative as men when it comes to sex. More so, in some cases, as the male usually is satisfied with the act while females can use the act in order to achieve some other end. Still I was thunderstruck by the rawness of her statement.
During my career I have worked with about a half-dozen women who made no secret of the fact that they were using their sexuality as a tool in the workplace. A few admitted it openly to me. I can think of four different women, in different jobs at different times, whose standard daily work outfit included a micro-skirt that rode up to their hips, when viewed from the side, when they sat down. I am fully aware that one of the reasons for wearing so little covering that one’s underwear is exposed as a matter of course is to assert a woman’s right to wear whatever she wishes without being subject to harassment or unwanted attention. That’s what they say, anyhow.
I met one such woman when I was working on a contract where she was the sales representative for Digital Equipment (DEC). She was, by any standard, a stunningly beautiful woman in her early 30’s, and she dressed the part. Every male eye was on her when she entered a room and she exuded an attitude of secure and infallible sexuality, apparently aware that she could turn any man in the room into a gibbering idiot. Of course, she was not interested in gibbering idiots. She was attracted to the men apparently immune to her charms, the men with power to control others and to face her with serene equanimity.
She was supposed to teach me how to use a new product that Digital was promoting. She did so disdainfully and unwillingly. I worked for a competitive company and she was not keen to share any advantage. I let her go through her condescending dismissive demonstration without comment, then, afterwards, set about teaching myself how to use the product.
I then moved on to the Prime Minister’s Office. I was there for about three months as a consultant to the operations group, helping them to get their procedures developed and documented. As a matter of course I installed the system monitoring tools I had developed over the years. These tools kept track of performance and usage metrics and automatically produced reports on the system’s workloads. When I finished that contract, I went to another computer site for three or four months, but then returned to the Prime Minister’s Office in order to study and make recommendations for facilities management. In other words, produce a report indicated what kind of hardware upgrades they could expect to make during the next two or three years.
I already had my tools running, so, by this point, I had about six months’ worth of data to work with. I would have preferred data spanning a year or more, but, I had to work with what I had. I painstakingly analyzed the data, identifying trend-lines and projecting them, accounting for the interactions between different hardware. For example, if disk space requirements expanded by 50%, are their sufficient tape drives to back up this data within the constraints of the backup windows? That sort of thing. Being the Prime Minister’s Office I had all the latest toys to work with, including a four-color plotter. This was long before color printers and color photocopiers. A plotter consisted of four computer-controlled pens that could be used to draw charts and graphs. I made full use of it.
My report was a masterpiece. Beautiful four-color charts gave immediate visual confirmation of what my words communicated. I had solid lines where there was solid data and dashed lines where it was projected data. Relationships were all clearly identified and illustrated. I had projected the future of the Prime Minister’s computing centre for two years out with indications of what was to come beyond that. I handed in my report.
I was at home nursing the flu a few days later when I got a call that I had a meeting scheduled with the ADM that afternoon. An ADM (Assistant Deputy Minister) is the highest position in the civil service. The Minister of a department is the front-line political appointee and his deputy ministers are his staff, each responsible for a certain aspect or operation of the department. An ADM is as close to god as any human can get without entering the rarefied atmosphere of the political top dogs. You do not say no to an ADM. I showered, hoping that the sweat and sickness would wash away, and dressed in my suit (I did have one suit reserved for just such occasions), which was too hot considering my fever, and drove to the centre of downtown Ottawa.
I was escorted by security to the ADM’s office where a group of half a dozen were seated around a table. They were mainly elderly men with one stunning exception: the Digital Sales Rep who was sitting next to the ADM himself. The ADM was a friendly older man obviously used to wielding power. He congratulated me on my skilful use of colour in my report, then ruefully lamented that it didn’t survive photocopying. (There was no such thing as a colour copier then.) He asked me to summarize the report for the assembled.
I did my best. When I finished the ADM turned to the DEC Sales Rep and asked her for comments. She began by saying, “As we discussed previously…” and then she went on to present her analysis of what hardware would be required, completely ignoring my data and what I had said. It was as if I didn’t exist. The ADM then smiled at me and said, “Do you think you can revise your report before five o’clock today? We’d like to get the RFP out as soon as possible.” (The RFP is the procedure the government follows when seeking tenders for goods and services.)
What choice did I have? I stood at my desk for a long time considering what had just occurred. My report had been honest. I did not agree with the sales rep’s analysis, yet it was clear that the ADM and his team had already bought it. What would I gain by refusing the ADM’s orders? Nothing. I’d probably never work in a government department again. But, if I followed them my integrity would be compromised. We like to think of ourselves as heroes standing for what is right no matter what the cost, but, there are times when you have to weight the consequences. I sighed, and sat down to revise my charts to support the decisions that had already been made.
Later, when telling this story to a colleague he said without hesitation, “Everyone knows she was fucking him.” It made sense. I had picked up a hint of intimacy between them during the meeting. One thing was very clear: they knew each other fairly well before that meeting. But I don’t know the truth and neither did my colleague. “Everyone knows” is proof of nothing. One thing was clear to me: I did not exist in her world; she saw only power—and I had none. I’m okay with that. I am comfortable with the fact that I don’t exist for many people. There is one advantage I have: I can observe them.
Saturday, 10 September 2011
Something to think about on 9/11.
I was going to write on what I was working on September 11, 2001, but that seems somewhat trivial compared to the events of that day. However, like many folks, I was confused and my initial thought was that I must have done something wrong. When I dialed the number of a software manufacturer in Islandia, New York I received a busy signal before I got past the area code. After a few more tries my next thought was that my long distance privileges had been disallowed, though I had nothing to base that on and it would have been extremely unreasonable of my client. Still, to confirm, I called home, which was long distance at the time.
Ann answered, so that wasn’t it. “I can’t get through to New York,” I told her. “The whole area code is busy.”
A few minutes later she phoned me back and said that a plane had hit the World Trade Center, probably a Cessna or other small privately-owned plane. At about the same time people on my floor starting muttering about New York, the Trade Center, and a plane. Many of us headed to the operations room where there was a small TV set for use on the midnight shift. We watched in stunned silence as the events unfolded.
What can I say? I am sure many people felt the way I did: slightly nauseous and disorientated, as though coming down with the flu. My brain could hardly take it all in. I left early that day, wanting to be home with my family. The images of people falling from 90 floors or more, the roiling cloud of white dust boiling down streets, an airliner disappearing into a building are all still clear in my mind.
Being in the high tech industry, that’s where my thoughts turned over the next few days. With distributed computing, clustering, hot backup sites, the requirement to house hundreds or thousands of employees in one place was disappearing. Companies would realize this and wake up to the new reality that insanity makes everyone a target; the bigger the target the more likely it will be attacked. I envisioned large companies spread out into small computer-connected offices located far apart in small towns and rural areas. That hasn’t happened as far as I know, but it is entirely feasible. It no longer makes sense to me to herd people into congested inner-cities where they become, not only targets, but contributors to the stresses on our selves and on our planet.
But, I also considered other things. Few realize what the name “Al-Queda” means and where it comes from. It is an Arabic translation of the name of the science fiction seven-volume series of novels called The Foundation by Isaac Asimov. The books encompass the story, covering several thousand years, of the predictions and timely interventions in history by Hari Seldon, a psychohistorian. This one person triggers the collapse of the current corrupt empire and then guides humanity’s creation of a new galactic empire built upon the ruins of the old. The series was published between 1951 and 1986, with the original trilogy produced between 1951 and 1953. There have been several articles published that claim a link between Asimov’s books and the basic premises and modus operandi of the terrorist group. If you Google “al-queda Asimov” a number of the articles and speculative pieces are listed. But, whether you buy the premise that bin Laden read the series and that some of the ideas presented shaped his thinking or not, there are striking similarities. Bin Laden and Hari Seldon had a lot in common. Without a doubt, bin Laden was the hero of his own story.
The idea that society, or the world as a whole, is corrupt and beyond redemption is not new. The idea that a single individual, or a small group of individuals, can bring down the corrupt and build a new utopia based upon whatever bias they have, is not new. We have seen this played out repeatedly in movies like the James Bond series, the classic western, or any of the fantasy-driven franchises that dominate. None of this is new. The Crusades, for example, were based upon the premise that an evil empire had control of the Holy Land which had to be liberated by Christian heroes. Beowulf fought and killed the monstrous Grendel. Moses confronted the Pharaoh and led his people out of slavery. This idea is in Gilgamesh’s battles with the monsters Humbaba and the Bull of Heaven. The story of the hero standing up to evil, destroying it, thus making possible the new utopia goes back into prehistory. In that regard there was nothing original about bin Laden.
…and everyone is the hero of his own story. It’s the others who are the bad guys. Some have difficulty imagining that they are the bad guys in someone else’s story. The certainty that we are right and they are wrong never really leaves us. We simply cannot be the bad guys in someone else’s view because we know, beyond a doubt, that it is they who are the bad guys, so whatever they believe must be wrong. We can write up lists as long as required about their shortcomings and failures, about how they betrayed us and let us down. We can write even longer lists about all the wonderful things we offered and gave them, that they ungraciously threw back at us.
I was sixteen in the fall of 1962 when the world stood on the brink of disaster. For several hours we did not know if this was the end of humans and most of all life on this planet. I recall the distain I felt when the Toronto Board of Education ordered all of its students to assemble in school basements to crouch and cover their heads. How on earth was that going to protect us from an atomic blast? The math and the reality didn’t add up. There really are powers bigger than we are; bigger even than our heroes. Nuclear explosions are one of them.
And it occurred to me as I walked back to the boarding house that day that there was probably someone in Russia, my age, who realized the same thing as I did, and was wondering what do they get out of killing me and everyone else? What’s in it for the Russians? And he was wondering what was in it for the Americans. The image of the average Russian, a farmer or factory worker with no greater aim than to nurture and protect his family, flashed into my mind. What do we have against him? And I have asked myself that question during every conflict since. What did we gain by destroying villages in Vietnam and killing the rice farmers and tradesmen? What good does it do any of us to fire missiles at the homes of accountants and teachers and day laborers? What does it benefit anyone to hijack an airliner and fly it into an office building?
The power of myth is a force difficult to see past. Not only does it blind us, but it directs our actions along paths we would never otherwise consider taking. Nietzsche’s “superman” was not amoral as some believe, but he simply has risen above the divisive power of the myth of good and evil, of us versus them. And that is a genuinely noble pursuit.
But as long as we don’t know the answers and are locked into this mythic struggle, we are in a state of high anxiety. Watch a zoo animal in a cage: it paces back and forth, back and forth because it doesn’t know the answers about where it is; something is wrong but the animal doesn’t know what. I’ve seen confused and frightened people do the same thing. The same movements. The same expressions. Which are you? Which are all of us? Do we control our visions or do they control us?
Ann answered, so that wasn’t it. “I can’t get through to New York,” I told her. “The whole area code is busy.”
A few minutes later she phoned me back and said that a plane had hit the World Trade Center, probably a Cessna or other small privately-owned plane. At about the same time people on my floor starting muttering about New York, the Trade Center, and a plane. Many of us headed to the operations room where there was a small TV set for use on the midnight shift. We watched in stunned silence as the events unfolded.
What can I say? I am sure many people felt the way I did: slightly nauseous and disorientated, as though coming down with the flu. My brain could hardly take it all in. I left early that day, wanting to be home with my family. The images of people falling from 90 floors or more, the roiling cloud of white dust boiling down streets, an airliner disappearing into a building are all still clear in my mind.
Being in the high tech industry, that’s where my thoughts turned over the next few days. With distributed computing, clustering, hot backup sites, the requirement to house hundreds or thousands of employees in one place was disappearing. Companies would realize this and wake up to the new reality that insanity makes everyone a target; the bigger the target the more likely it will be attacked. I envisioned large companies spread out into small computer-connected offices located far apart in small towns and rural areas. That hasn’t happened as far as I know, but it is entirely feasible. It no longer makes sense to me to herd people into congested inner-cities where they become, not only targets, but contributors to the stresses on our selves and on our planet.
But, I also considered other things. Few realize what the name “Al-Queda” means and where it comes from. It is an Arabic translation of the name of the science fiction seven-volume series of novels called The Foundation by Isaac Asimov. The books encompass the story, covering several thousand years, of the predictions and timely interventions in history by Hari Seldon, a psychohistorian. This one person triggers the collapse of the current corrupt empire and then guides humanity’s creation of a new galactic empire built upon the ruins of the old. The series was published between 1951 and 1986, with the original trilogy produced between 1951 and 1953. There have been several articles published that claim a link between Asimov’s books and the basic premises and modus operandi of the terrorist group. If you Google “al-queda Asimov” a number of the articles and speculative pieces are listed. But, whether you buy the premise that bin Laden read the series and that some of the ideas presented shaped his thinking or not, there are striking similarities. Bin Laden and Hari Seldon had a lot in common. Without a doubt, bin Laden was the hero of his own story.
The idea that society, or the world as a whole, is corrupt and beyond redemption is not new. The idea that a single individual, or a small group of individuals, can bring down the corrupt and build a new utopia based upon whatever bias they have, is not new. We have seen this played out repeatedly in movies like the James Bond series, the classic western, or any of the fantasy-driven franchises that dominate. None of this is new. The Crusades, for example, were based upon the premise that an evil empire had control of the Holy Land which had to be liberated by Christian heroes. Beowulf fought and killed the monstrous Grendel. Moses confronted the Pharaoh and led his people out of slavery. This idea is in Gilgamesh’s battles with the monsters Humbaba and the Bull of Heaven. The story of the hero standing up to evil, destroying it, thus making possible the new utopia goes back into prehistory. In that regard there was nothing original about bin Laden.
…and everyone is the hero of his own story. It’s the others who are the bad guys. Some have difficulty imagining that they are the bad guys in someone else’s story. The certainty that we are right and they are wrong never really leaves us. We simply cannot be the bad guys in someone else’s view because we know, beyond a doubt, that it is they who are the bad guys, so whatever they believe must be wrong. We can write up lists as long as required about their shortcomings and failures, about how they betrayed us and let us down. We can write even longer lists about all the wonderful things we offered and gave them, that they ungraciously threw back at us.
I was sixteen in the fall of 1962 when the world stood on the brink of disaster. For several hours we did not know if this was the end of humans and most of all life on this planet. I recall the distain I felt when the Toronto Board of Education ordered all of its students to assemble in school basements to crouch and cover their heads. How on earth was that going to protect us from an atomic blast? The math and the reality didn’t add up. There really are powers bigger than we are; bigger even than our heroes. Nuclear explosions are one of them.
And it occurred to me as I walked back to the boarding house that day that there was probably someone in Russia, my age, who realized the same thing as I did, and was wondering what do they get out of killing me and everyone else? What’s in it for the Russians? And he was wondering what was in it for the Americans. The image of the average Russian, a farmer or factory worker with no greater aim than to nurture and protect his family, flashed into my mind. What do we have against him? And I have asked myself that question during every conflict since. What did we gain by destroying villages in Vietnam and killing the rice farmers and tradesmen? What good does it do any of us to fire missiles at the homes of accountants and teachers and day laborers? What does it benefit anyone to hijack an airliner and fly it into an office building?
The power of myth is a force difficult to see past. Not only does it blind us, but it directs our actions along paths we would never otherwise consider taking. Nietzsche’s “superman” was not amoral as some believe, but he simply has risen above the divisive power of the myth of good and evil, of us versus them. And that is a genuinely noble pursuit.
But as long as we don’t know the answers and are locked into this mythic struggle, we are in a state of high anxiety. Watch a zoo animal in a cage: it paces back and forth, back and forth because it doesn’t know the answers about where it is; something is wrong but the animal doesn’t know what. I’ve seen confused and frightened people do the same thing. The same movements. The same expressions. Which are you? Which are all of us? Do we control our visions or do they control us?
Monday, 5 September 2011
Common Sense and Security
In the early 1990’s I was sent to a military research station to see if I could help out with a performance issue they were having. The site consisted of several buildings surrounded by a very high steel-link fence (fifteen feet?) and you entered by stopping at a barrier; a commissionair (the government’s standard security; actually retired members of the military) in a glassed-in cage would ask to see your identity card. After my first few days I just held my ID card up to the car window and the guard waved me through. I quickly learned that the base was off-limits to all non-security personnel between the hours of 6:00 pm and 6:00 am. No overtime there.
After I settled in I took a look at the system—which was running very slowly indeed. It didn’t take long to spot a batch job running at an elevated priority; high enough that it was blocking interactive users from accessing the system. The batch job was the daily backup procedure. Two questions: 1) why was the backup running during prime time? and 2) why was its priority raised?
The operator responsible told me it took two 9-track reel-to-reel tapes to perform a complete backup. He arrived at work at 6:00 am to start it, but, as each tape took about two hours, backup time ran into work time. He raised the priority of the job so that it would execute faster.
My first response: it should not take a 9-track tape two hours to fill with backed-up files. Raising the priority of that job was counter-productive because a job cannot run faster than the device it is writing to. Tape drives are slow, but not that slow. Lowering the priority of the job to a more reasonable level and increasing the buffer size, so that it wrote more data at a single time, cut the execution time down closer to an hour per tape.
My second response: why are you waiting until 6:00 am to start the backup? Why not mount a tape before leaving the previous day and have the job start executing at, say, 4:00 am. That way, by the time humans were allowed on-site, at 6:00 am, the job would be waiting for its second tape mount—and that should take less than an hour, thus finishing the daily backups by 7:00 am well before any scientists arrived to start their daily shift.
Both steps were simple common-sense solutions. I sometimes irritated people I worked with by asking: “why are you doing it that way? Why not…” It didn’t matter where I worked or in what field, I usually saw a more efficient way of doing something and ran into defensiveness and resentment when I pointed it out. The only way I was ever truly happy at work was when I was either the “expert” who they had to listen to, or the boss (who they also had to listen to). That way I could implement what, to me, looked like obvious improvements that apparently weren’t so obvious to others. The times when I was in the kind of position where I could make improvements in the work-flow without running into snarling and snapping mother wolves protecting the old ways, I always received praise and complements from higher ups, the reason being that my improvements were genuine improvements: just like resetting job parameters to speed up writing to tape and starting the job before humans arrived to mount the second tape.
They kept me around at the research facility for a while; first, writing documentation, then, when that was done, writing a program that would automatically take the data stored on old 9-track tapes and write it to cassette tapes. Three 9-tracks could fit onto one cassette and cassettes required a lot less storage space. That was fun. I got to explore the actual physical and logical structures that controlled tapes because I had to over-ride them to write three tapes onto one. Of course the program kept track of everything and printed out labels to put on the cassette covers listing the contents.
While I was working on that the system suddenly slowed down one afternoon. What the? I identified an interactive session that was running at an elevated priority. Even though I could do anything I wanted to on a system, having full access to everything, I would never consider raising the priority of my session except in a few exceptional emergency situations. I knocked the priority of the run-away session back to where it was supposed to be. Ten minutes later, there it was, running at a high priority again. Time for a closer look. The account in question was assigned all system privileges. Impossible: I was the only one who was supposed to have such access. Even operators were restricted in what they could do. I fixed the account by stripping away all the privileges that a common user had no right to. End of problem.
Until a few days later. There was that same account running at an elevated priority, locking everyone else out of the system. And, the account once again had full system access. There were only two ways this could have happened: either my—or the system account that was reserved for upgrades—had been broken into; or, someone had unauthorized access to the computer room. It was the latter. In those primitive days of computing we did not have monitors and keyboards connected directly to the computer in the computer room, we had teletype machines. In other words, every command and response was printed on fan-fold paper. That system solved a few mysteries during my career.
Because the console was wired directly into the machine it had access to everything. That was intentional so that a technician could work on a failed machine. Someone, presumably the owner of the account, had entered the computer room and typed the commands necessary to give his account full system access. Now most computer rooms were locked with a card-scanner or a cipher lock so that only those who needed to be there could actually enter the room. You would think that at a secure military research site that this basic security feature would be in place. It was not. The computer room door was left wide-open at all hours.
I reported the incident to the security team who immediately had the computer room locked. The employee was given a stern dressing-down and warned. I heard from the people working at the site a few months after I had moved on that the culprit had been caught trying his old trick again and had been fired on the spot. So, what had he gained at the expense of his career? a few minutes of uninterrupted access to a CPU. It wasn’t as if he was doing important work at the time; he had been playing a computer game.
After I settled in I took a look at the system—which was running very slowly indeed. It didn’t take long to spot a batch job running at an elevated priority; high enough that it was blocking interactive users from accessing the system. The batch job was the daily backup procedure. Two questions: 1) why was the backup running during prime time? and 2) why was its priority raised?
The operator responsible told me it took two 9-track reel-to-reel tapes to perform a complete backup. He arrived at work at 6:00 am to start it, but, as each tape took about two hours, backup time ran into work time. He raised the priority of the job so that it would execute faster.
My first response: it should not take a 9-track tape two hours to fill with backed-up files. Raising the priority of that job was counter-productive because a job cannot run faster than the device it is writing to. Tape drives are slow, but not that slow. Lowering the priority of the job to a more reasonable level and increasing the buffer size, so that it wrote more data at a single time, cut the execution time down closer to an hour per tape.
My second response: why are you waiting until 6:00 am to start the backup? Why not mount a tape before leaving the previous day and have the job start executing at, say, 4:00 am. That way, by the time humans were allowed on-site, at 6:00 am, the job would be waiting for its second tape mount—and that should take less than an hour, thus finishing the daily backups by 7:00 am well before any scientists arrived to start their daily shift.
Both steps were simple common-sense solutions. I sometimes irritated people I worked with by asking: “why are you doing it that way? Why not…” It didn’t matter where I worked or in what field, I usually saw a more efficient way of doing something and ran into defensiveness and resentment when I pointed it out. The only way I was ever truly happy at work was when I was either the “expert” who they had to listen to, or the boss (who they also had to listen to). That way I could implement what, to me, looked like obvious improvements that apparently weren’t so obvious to others. The times when I was in the kind of position where I could make improvements in the work-flow without running into snarling and snapping mother wolves protecting the old ways, I always received praise and complements from higher ups, the reason being that my improvements were genuine improvements: just like resetting job parameters to speed up writing to tape and starting the job before humans arrived to mount the second tape.
They kept me around at the research facility for a while; first, writing documentation, then, when that was done, writing a program that would automatically take the data stored on old 9-track tapes and write it to cassette tapes. Three 9-tracks could fit onto one cassette and cassettes required a lot less storage space. That was fun. I got to explore the actual physical and logical structures that controlled tapes because I had to over-ride them to write three tapes onto one. Of course the program kept track of everything and printed out labels to put on the cassette covers listing the contents.
While I was working on that the system suddenly slowed down one afternoon. What the? I identified an interactive session that was running at an elevated priority. Even though I could do anything I wanted to on a system, having full access to everything, I would never consider raising the priority of my session except in a few exceptional emergency situations. I knocked the priority of the run-away session back to where it was supposed to be. Ten minutes later, there it was, running at a high priority again. Time for a closer look. The account in question was assigned all system privileges. Impossible: I was the only one who was supposed to have such access. Even operators were restricted in what they could do. I fixed the account by stripping away all the privileges that a common user had no right to. End of problem.
Until a few days later. There was that same account running at an elevated priority, locking everyone else out of the system. And, the account once again had full system access. There were only two ways this could have happened: either my—or the system account that was reserved for upgrades—had been broken into; or, someone had unauthorized access to the computer room. It was the latter. In those primitive days of computing we did not have monitors and keyboards connected directly to the computer in the computer room, we had teletype machines. In other words, every command and response was printed on fan-fold paper. That system solved a few mysteries during my career.
Because the console was wired directly into the machine it had access to everything. That was intentional so that a technician could work on a failed machine. Someone, presumably the owner of the account, had entered the computer room and typed the commands necessary to give his account full system access. Now most computer rooms were locked with a card-scanner or a cipher lock so that only those who needed to be there could actually enter the room. You would think that at a secure military research site that this basic security feature would be in place. It was not. The computer room door was left wide-open at all hours.
I reported the incident to the security team who immediately had the computer room locked. The employee was given a stern dressing-down and warned. I heard from the people working at the site a few months after I had moved on that the culprit had been caught trying his old trick again and had been fired on the spot. So, what had he gained at the expense of his career? a few minutes of uninterrupted access to a CPU. It wasn’t as if he was doing important work at the time; he had been playing a computer game.
Friday, 2 September 2011
The Commodore-64 and contemporary programming.
I was just starting out in my high tech career in 1982 when the Commodore-64, the first commercially successful home computer, was introduced. It was cheap, at under $600, and a large number of applications and games were produced for it. Though I wanted one, I couldn’t afford it with a young family while transitioning careers. However, the schools were anxious for programs that could be used as teaching aids and were generous about lending them to anyone who could write a few lines of code. I took full advantage of that opportunity and wrote many little games that could be used in the classroom. Eventually, I was given a retired Commodore-PET—a much more limited version of the C-64—and so happily wrote little programs for my boys to play with.
Like the Apple II, released about the same time, the Commodore did not have an operating system as we know the term today. It came with a BASIC interpreter and, by using low-level “poke” and “peek” commands, programmers could access the very limited monitor and sound chip. Magazines, like Byte, regularly printed the hex codes for accessing various functions of the C-64, and printed out entire programs for users to type into their computers. The C-64 did not come with a disk drive; Programs had to be stored on cassette tapes. If you were a fast typist you could input most of an entire program in the time it took for the tape drive to load its contents into RAM.
Though there was a huge gap between the home computer and the serious mainframe computers I used at work, I did learn some valuable programming lessons on the C-64 and PET. Because it was such a primitive and limiting interface programmers had to be constantly aware of what they were putting into RAM. A program would simply run out of room at about 32 KB as the rest of RAM was given over to the BASIC interpreter and some low level functions, such as communicating with the keyboard. In other words, from the programmer’s point of view, every bit counted.
This meant that one had to learn how to write efficient code. However, it reinforced another bad programmer habit: it discouraged the imbedding of comments in the code to explain what was going on because comments took up valuable RAM. There was an entire class of programmers who could write dense complex code that was unintelligible to anyone else. If it broke, you were stuck because chances were good that you would not be able to unravel its secrets without a lot of help from the original programmer.
The monitor was wide enough to display 40 characters and characters were generally 8 by 8 bits. So, we never had reason to count pixels. But, within the limitations of the chunky slow graphics all sorts of small applications could be written. Most of the games I wrote involved a moving graphic, either under control of the user through keyboard commands, or control of inner logic. Given the type of programming limitations, the most effective way to discover where the graphic was in relation to other “objects” on the screen was to “peek” ahead to the next character position. If you had planned correctly you could figure out which was the bat or paddle and which was the edge of the screen. Movement was controlled by incremented or decrementing simple x and y coordinates.
It didn’t take very much code at all to replicate some of the commercially-available games. A “pong” program (bouncing ball with two paddles) could be written in less than 20 lines of code. I wrote a successful copy of the “Breakout” game (a bouncing ball smashes its way through a brick wall of differently-coloured and -valued bricks.) It was fun. But here’s something important that I learned.
I mentioned that to determine where one object on the screen was in relation to other objects on the screen, I could use a “peek” command to see what was coming next. As long as I was “peeking” ahead only one character position at a time, there was no problem. I would “collide” with another object or the screen border and reverse my coordinates to move the ball, or other object, away from the “barrier.” No problem.
But, something odd would happen if, in order to speed up my moving object, I were to increment or decrement by twos—or even some larger number. The program would “work” for a few moments and then the ball would disappear from the screen. After another few moments, the program would freeze, usually with an annoying whiny sound.
The only way out was to “break” into the code and go looking for the problem. The first few times I did this, without really understanding what was going on, I was annoyed to discover that my code had been changed. Sections of lines had been erased and some characters had been turned into unrecognizable junk. I fixed the code, ran it again, same result, same changes in the code.
Hum….
I eventually figured out what was happening. The Commodore, in its primitive state, did no error-checking on its own. Whatever you wrote, it would do—or die trying (which it often did). When I started peeking ahead by more than one character position at a time, there was a good chance that I would miss the actual screen boundary—and my “ball” would keep moving in the direction it had been going. No, the virtual ball would not emerge from the side of the monitor, but it would leave the area of code that described the monitor to the system. There wasn’t a heck of a lot more in RAM in those days, so the ball would “move” through the area of RAM where the program code resided. As it bashed into areas it had no business being, it made changes until the program could no longer function.
Modern programs cannot behave like that. The operating system makes sure that code instructions do not access areas in RAM where they shouldn’t be. The operating system itself is protected. The areas allotted to other users or applications are out of bounds. The program code itself is out of bounds. If a program does increment or decrement outside of the area it is supposed to be confined to, an immediate fatal error is issued bringing the program to a halt. That’s why programmers are supposed to always know where their program is operating and what, exactly, it is doing inside of RAM.
Of course, they usually don’t have a clue. Programming has become automated and the layers of complexity between the program code and the underlying machinery have become so thick that no one can really know. “Code generation” programs abound so that the programmer doesn’t need to know anything about the physical nature of the computer. “Drivers” (which seem to be permanently out-of-date) wrap every piece of hardware in nice thick mushy layers of code so that no metal is seen by the programmer—or user. A result: users aren’t the only ones with no understanding of the physical processes that make their computers function.
Like the Apple II, released about the same time, the Commodore did not have an operating system as we know the term today. It came with a BASIC interpreter and, by using low-level “poke” and “peek” commands, programmers could access the very limited monitor and sound chip. Magazines, like Byte, regularly printed the hex codes for accessing various functions of the C-64, and printed out entire programs for users to type into their computers. The C-64 did not come with a disk drive; Programs had to be stored on cassette tapes. If you were a fast typist you could input most of an entire program in the time it took for the tape drive to load its contents into RAM.
Though there was a huge gap between the home computer and the serious mainframe computers I used at work, I did learn some valuable programming lessons on the C-64 and PET. Because it was such a primitive and limiting interface programmers had to be constantly aware of what they were putting into RAM. A program would simply run out of room at about 32 KB as the rest of RAM was given over to the BASIC interpreter and some low level functions, such as communicating with the keyboard. In other words, from the programmer’s point of view, every bit counted.
This meant that one had to learn how to write efficient code. However, it reinforced another bad programmer habit: it discouraged the imbedding of comments in the code to explain what was going on because comments took up valuable RAM. There was an entire class of programmers who could write dense complex code that was unintelligible to anyone else. If it broke, you were stuck because chances were good that you would not be able to unravel its secrets without a lot of help from the original programmer.
The monitor was wide enough to display 40 characters and characters were generally 8 by 8 bits. So, we never had reason to count pixels. But, within the limitations of the chunky slow graphics all sorts of small applications could be written. Most of the games I wrote involved a moving graphic, either under control of the user through keyboard commands, or control of inner logic. Given the type of programming limitations, the most effective way to discover where the graphic was in relation to other “objects” on the screen was to “peek” ahead to the next character position. If you had planned correctly you could figure out which was the bat or paddle and which was the edge of the screen. Movement was controlled by incremented or decrementing simple x and y coordinates.
It didn’t take very much code at all to replicate some of the commercially-available games. A “pong” program (bouncing ball with two paddles) could be written in less than 20 lines of code. I wrote a successful copy of the “Breakout” game (a bouncing ball smashes its way through a brick wall of differently-coloured and -valued bricks.) It was fun. But here’s something important that I learned.
I mentioned that to determine where one object on the screen was in relation to other objects on the screen, I could use a “peek” command to see what was coming next. As long as I was “peeking” ahead only one character position at a time, there was no problem. I would “collide” with another object or the screen border and reverse my coordinates to move the ball, or other object, away from the “barrier.” No problem.
But, something odd would happen if, in order to speed up my moving object, I were to increment or decrement by twos—or even some larger number. The program would “work” for a few moments and then the ball would disappear from the screen. After another few moments, the program would freeze, usually with an annoying whiny sound.
The only way out was to “break” into the code and go looking for the problem. The first few times I did this, without really understanding what was going on, I was annoyed to discover that my code had been changed. Sections of lines had been erased and some characters had been turned into unrecognizable junk. I fixed the code, ran it again, same result, same changes in the code.
Hum….
I eventually figured out what was happening. The Commodore, in its primitive state, did no error-checking on its own. Whatever you wrote, it would do—or die trying (which it often did). When I started peeking ahead by more than one character position at a time, there was a good chance that I would miss the actual screen boundary—and my “ball” would keep moving in the direction it had been going. No, the virtual ball would not emerge from the side of the monitor, but it would leave the area of code that described the monitor to the system. There wasn’t a heck of a lot more in RAM in those days, so the ball would “move” through the area of RAM where the program code resided. As it bashed into areas it had no business being, it made changes until the program could no longer function.
Modern programs cannot behave like that. The operating system makes sure that code instructions do not access areas in RAM where they shouldn’t be. The operating system itself is protected. The areas allotted to other users or applications are out of bounds. The program code itself is out of bounds. If a program does increment or decrement outside of the area it is supposed to be confined to, an immediate fatal error is issued bringing the program to a halt. That’s why programmers are supposed to always know where their program is operating and what, exactly, it is doing inside of RAM.
Of course, they usually don’t have a clue. Programming has become automated and the layers of complexity between the program code and the underlying machinery have become so thick that no one can really know. “Code generation” programs abound so that the programmer doesn’t need to know anything about the physical nature of the computer. “Drivers” (which seem to be permanently out-of-date) wrap every piece of hardware in nice thick mushy layers of code so that no metal is seen by the programmer—or user. A result: users aren’t the only ones with no understanding of the physical processes that make their computers function.
Subscribe to:
Posts (Atom)