Enable JavaScript.

1973: Shark Attack

I finished my presentation and asked if there were any questions. A voice from the back of the hall angrily boomed out "Who in hell put this on the agenda? We've got all the tools we need. We just need to learn how to use what we have."

I stood there stunned. I had come to the symposium because I thought I had something good to offer, and now I was being put down in a particularly harsh fashion. I shrunk inside myself, not knowing what to say. The chairman of the symposium came to my rescue as other people in the audience began to shout down my heckler. He adjourned the meeting for a coffee break and quickly came to me.

"Clarence Poland was completely out of line." he said to me. "Your presentation was fine and your tool looks interesting. Let me talk to Clarence, and after the break I'll open the meeting for further questions to you."

I found a seat off to the side of the auditorium and breathed deeply to regain my composure. Several people came to me and expressed their disgust at what had happened. I could see a number of people around Clarence. I couldn't hear what was being said, but they seemed pretty agitated. What had I gotten myself into?

The IBM Research Division had sponsored the symposium on Systems Performance in San Jose, CA. Those were still the days when computers were large, expensive resources that each needed to be carefully managed for maximum effectiveness. Understanding how to measure, analyze and tune various aspects of a running computer for optimum performance was important and worth considerable time and effort.

Several hundred people from all over IBM were attending the symposium, and until Clarence's outburst the talks had been both interesting and informative. This was my first professional conference, and I was pleased that my presentation had been accepted. I was especially pleased that my managers in the IBM Endicott programming laboratory had paid for me to attend, since the whole subject of performance analysis had nothing to do with my current assignment.

My presentation was a holdover from my last programming project for the Field Engineering Division in White Plains. I had done well as a PL/I applications programmer, and because of my interest in systems programming, had come to the attention of two of the senior programmers in our lab. Lance Dibbern and Jack Deignan were like gods to me. There wasn't anything they couldn't do with a System/360. They had come to us as Senior Field Engineers and were probably among the last group of human beings who completely understood computers — from electronics to operating systems. I had been flattered when Jack asked me to help him develop a PL/I program to analyze system performance data. It was still an application program but one about systems.

System/360 computers automatically logged a wide variety of data about what was happening in the system as part of their System Management Facility. Whenever some event occurred in the system, such as the starting or ending of a job, information about that event was accumulated in a record, time-stamped, and logged. This data was primarily used for accounting purposes, but Jack thought it could also tell him a lot about how well the system was performing.

Jack's idea was to throw this data onto intervals of time at various scales, in which counts of events were summarized so that he could see what was happening in the system in each interval. For example, it would be possible to determine how many input/output operations were being directed to a given disk drive in each second. There were electronic monitors that could do this, but they were expensive and not readily available. Jack thought he could get pretty much the same information from the logged SMF data. However, this data was in an extremely awkward format, consisting of varying length records that included a time stamp followed by one or more data segments that each had an identifier field and one or more data fields. A complex program to process the records would be required.

I worked on this project for almost a year1. Given the limited memory sizes of the systems that would run the new analysis program, it wasn't possible to read in any more than one record at a time, so comparing records to see what was happening wasn't possible. My solution was to break each record into what I called "atoms"2 that each consisted of a time stamp, an identifier field, and exactly one data field. The atoms were then written to a file, the file of atoms sorted by time stamp, and then reprocessed. This time, as each atom was read, its identifier determined how its data would be processed. In some cases, the data needed to be distributed over a set of intervals, while in other cases it was only necessary to increment or decrement a counter. The end result was Jack's performance analysis report.

I completed the project, but Jack had transferred to another IBM location. This left me with a program that no one else in our lab was interested in, so I put it on the shelf, and went on to other projects. Soon thereafter, I transferred to Endicott for a real job as a systems programmer. This probably should have been the end of the performance analysis program for me, but I still hoped to find someone else who would take it over. When I heard of the San Jose Performance symposium, it seemed like an ideal way to find a new home for my program, and besides, attending the symposium would give me a chance to learn more about the field of performance analysis.

So I sat through two days of presentations, and on the third, with a good deal of nervousness, gave my talk. Other than some high school plays, I'd never had to speak before a large audience, certainly not to say anything on my own, before an audience of experts. But I was armed with my tube of carefully prepared flip-charts, so I got up and did it, and was pretty happy with myself until Clarence Poland started in on me. He had been highly critical of nearly everything throughout the symposium. I learned later that he was a self-proclaimed expert in this field and was promoting a different performance analysis tool, one that he had sponsored.

When the symposium resumed after the break, the chairman said I would take further questions, and began by recognizing Clarence… again! What was I in for now?

Clarence began with a half-hearted apology to me for his outburst, and then proceeded to reexpress his dismay that someone who wasn't an acknowledged expert in performance analysis would be given time in the symposium when there were so many people with more to contribute. Eventually, the chairman turned him off and other people asked me a number of pertinent questions. When I finally sat down, people that I had previously met at the symposium tried to assure me that I had done well, but I was still too upset, beyond hearing anything they had to say.

Fortunately, this was the last day of the symposium and I left as soon as possible. Lois and I took a weekend trip down to Monterey, Carmel and the Big Sur, but those days were lost to me in recovering from the symposium. It was Lois who finally helped me to understand that it wasn't me or anything that I had done that had been the problem. I had gone into an unknown situation cold, green and vulnerable without a sponsor. It was no surprise that I had been attacked by a self-serving shark.

Later, I did get a request for my program and dutifully sent off a copy of it, but I never heard if it was ever used. Eventually, I pitched my copy into the garbage.

But what if I had persisted? What if I had gone beyond being just the programmer of the tool, had actually used it to analyze performance data, and had proven the tool's worth? What if I had found a new sponsor for the tool in the Endicott programming laboratory? Would I have veered off onto a different career path with different long-term results? Perhaps, but the symposium was just a few years before the development of the first microprocessor. Since then, the whole subject of computer performance was made largely irrelevant by the astounding advances of computer technology, advances that were only dimly perceived in 1973, advances that reduced the cost of processors, memory and communications to insignificance.

1 Why did it take me a year to develop this program? The best answer lies in the low productivity of our work environment. These were the days before the general availability of interactive terminals or personal computers. A program had to be written on sheets of green and white striped paper and punched into decks of 80-column cards. The cards were then shipped in a station wagon from our offices in White Plains across the Hudson River to the computer center in New Jersey. There, the cards would be read into a computer where the new program was compiled and executed. The results were printed on fan-fold paper and returned to our offices in White Plains, also in the station wagon. At best, I could get a single turn-around a day. Even the slightest typing error cost a whole day's time. I learned to carefully desk-check everything. This was a time consuming process, but a side benefit was that it left me a lot of time for studying programming languages and computer science.

2 At the time of this symposium, pioneering work was being done nearby, at Xerox's Palo Alto Research Center, on the initial versions of the Smalltalk programming language. This object-oriented language encapsulates data by the operations that can be performed on it. Each such object identifies its class (itself an object) and the class defines the permitted operations. The "atoms" of my program were conceptually similar to this, though in a much more limited fashion. Later, I became a "true believer" and proponent of Smalltalk.

1973: Attaqué par un requin

J'ai fini ma presentation et j'ai demandé si il y avait des questions. Une voix à l'arrière de la salle a hurlé avec colère :
— Qui est-ce qui en enfer a mis ce truc sur le programme ? Nous avons encore tous les outils dont nous avons besoin. Nous devons apprendre à utiliser les outils que nous avons déjà.

Je me suis tenu debout. J'étais venu au symposium parce que j'ai pensé que j'avais quelque chose de bon à offrir et maintenant j'étais critiqué d'une façon particulièrement dure. Je me suis recroquevillé sur moi-même, sans savoir ce que je pouvais repondre. Le président est venu à mon secours pendant que d'autres dans le public commencaient à hurler contre le perturbateur. Il a ajourné la réunion pour une pause café et il est venu rapidement vers moi.
— Clarence Poland avait dépassé les limites. Votre présentation était très bien et votre outil semble intéressant. Laissez-moi parler avec lui et après la pause je vais ouvrir la réunion pour plus de questions pour vous.

J'ai trouvé un siège sur le côté de la salle et j'ai respiré profondément pour retrouver mon sang-froid. Quelques personnes sont venues vers moi et m'ont exprimé leur dégoût de ce qui s'était passé. Je pouvais apercevoir plusieurs personnes au tour de Clarence. Je n'ai pas pu entendre ce qu'elles disaient, mais elles semblaient très agités. Dans quoi est-ce que je me suis empêtré ?

La division d'IBM pour le Récherche avait sponsorisé le symposium sur la caractéristiques des systèmes à San Jose en Californie. C'était encore les jours quand les ordinateurs étaient des ressources grandes et cheres qu'on devait utiliser pour le maximum d'efficacité. Comprendre comment on pouvait mesurer, analyser et régler les differents aspects d'un ordinateur pour des characteristiques maximum était important et méritait le temps et l'effort considérable.

Plusieurs centaines de personnes de plusieurs locations d'IBM assistaient au symposium et jusqu'à l'explosion de Clarence les conférences avaient été intéressantes et informatives. C'était mon premier symposium professionnel et j'étais très heureux que ma présentation ait été acceptée. J'étais aussi heureux que mes patrons au laboratoire d'IBM à Endicott à New York aient payé pour moi pour assister, puisque le sujet des characteristiques n'avait rien à faire avec mon travail du moment.

Ma présentation était une survivance de mon dernier projet pour la division de « Field Engineering » à White Plains à New York. J'avais bien travaillé comme programmeur d'applications en PL/I et, grâce à mon intérêt en programmation des systèmes, j'étais venu à l'attention des deux programmeurs supérieurs dans notre bureau. Lance Dibbern et Jack Deignan étaient comme des dieux pour moi. Il n'y avait rien qu'ils ne pouvaient pas faire avec un « System/360 ». Ils étaient venus à notre bureau comme des « Field Engineers » et ils étaient probablement parmi les dernières personnes qui comprenaient complètement les ordinateurs : des électroniques aux systèmes d'opération. J'avais été flatté quand Jack m'a demandé de l'aider à développer un programme en PL/I pour analyser les données produites par des systèmes concernant leurs caractéristiques. C'etait encore un programme d'application, mais cettte fois-ci à propos des systèmes.

Les ordinateurs « System/360 » inscriraient automatiquement dans un fichier une grande variété de données à propos des évènements qui se passaient dans le système comme une partie de leur « System Management Facility » ou « SMF ». Quand quelques évènements se passaient dans le système, tel que le commencement ou la terminaison d'un boulot, des informations à propos de l'évènement étaient accumulées dans un record avec une estampille temporelle. Ces données étaient utilisées surtout pour faire la comptabilité, mais Jack pensait qu'elles pouvaient l'informer sur la façon dont le système jouait.

L'idée de Jack était de lancer ces données sur des intervalles de temps, à plusieurs échelles, dans lesquels les comptes des évènements étaient résumés pour qu'il puisse voir ce qui se passaient dans chaque intervalle. Par exemple, il serait possible de déterminer combien d'opérations étaient faites par un disque dure chaque seconde. Il y avait des moniteurs électroniques qui pouvaient faire ça, mais ils étaient chers et n'étaient pas facilement disponibles. Jack pensait qu'il pouvait avoir presque la même information des données SMF. Cependant, ces données étaient dans un format très difficile à traiter. Ils consistaient à des records qui varaient en longueur et qui incluaient une estampille temporelle suivie d'un ou de plusieurs segments dont chacun avaient un identificateur suivi de un ou de plusieurs de champs de données. Un programme complexe pour traiter ces records serait requis.

J'ai travaillé sur ce projet pour presque une année1. Puisque les systèmes sur lesquelles le nouveau programme courait n'avait pas beaucoup de mémoire, il n'était possible de lire qu'un seul record en même temps. Ainsi, il n'était pas possible de comparer des records pour déterminer ce qui se passait. Ma solution était de casser chaque record en plusieurs morceaus que j'appelais « atomes »2. Chaque atome était constitué d'une estampille temporelle, un identificateur et un seul champs de données. Puis, les atomes étaient inscrit sur un fichier, le fichier était trié et finalement retraité. Cette fois, quand chaque atome était lu, l'identificateur déterminait comment il pouvait le traiter. Dans quelques cas, les données devaient être distribuées parmi des intervalles, mais dans autres cas il était nécessaire d'acroître ou de décroître un compteur. Le résultat était le rapport des caractéristiques que Jack voulait.

J'ai fini le projet, mais Jack avait déménagé dans un autre bureau d'IBM. Cela me laissait avec un programme sur lequel il n'y avait pas d'autres personnes dans notre bureau qui s'y intéressaient. Ainsi, je l'ai mis dans le placard, je suis allé à d'autres projets et bientôt j'ai déménagé à Endicott pour un vrai travail comme programmeur des systèmes. Probablement, cela devait être la fin du programme des caractéristiques pour moi, mais j'espérais encore trouver quelqu'un qui l'accepterait. Quand j'en ai entendu parler au symposium à San Jose, on dirait qu'une bonne façon de trouver un nouveau habitat pour mon programme. De plus, assister au symposium me donnerait une bonne chance d'apprendre mieux le domaine d'analyses des caractéristiques.

Ainsi, je me suis assis pendant deux jours des exposes et le troisième, avec beaucoup de nervosité, j'ai fait le mien. À l'exception des pièces du théâtre au lycée, je n'avais pas encore parler devant un grand public, certainement pas à parler de quelque chose que j'ai fait, devant un public d'experts. Mais j'étais préparé avec un tableau de conférence et comme ceci je me suis levé et j'ai fait mon exposé. J'étais content jusqu'au moment où Clarence a commencé m'a attaqué. Il avait été très critique sur presque tout pendant tout le symposium. J'ai appris plus tard qu'il était expert « auto-proclamé » dans ce domaine et il faisait la promotion d'un autre programme, un qu'il avait sponsorisé.

Quand le symposium a recommencé après la pause, le président a dit que j'accepterais plusieurs questions. Il a donné la parole à Clarence Poland… encore ! Qu'est-ce que je pouvais attendre de lui maintenant ?

Clarence a commencé avec des excuses peu enthousiastes à son explosion… et puis, il a continué à exprimer encore sa consternation que quelqu'un qui n'était pas un expert dans ce domaine avait été offert l'opportunité de s'exprimer dans le symposium quand il y avait plusieurs personnes qui avaient beaucoup à contribuer. Finalement, le président lui à retirée la parole et d'autres me posaient quelques questions pertinent. Quand je me suis assis, les personnes que j'avais rencontrées auparavant au symposium ont essayé de m'assurer que j'avais bien fait, mais j'étais encore trop sous le choc, au-delà de ce qu'ils disaient.

Heureusement, c'était le dernier jour du symposium et je suis parti dès que possible. Lois et moi avons fait un voyage pendant le weekend suivant à Monterey, Carmel et le « Big Sur », mais ces jours-là étaient perdus pour moi à retrouver mon calme après le symposium. C'était Lois qui m'a aidé à comprendre qu'il n'y avait rien que j'avais fait ou dit qui avait été le problème. Je suis allé dans une situation froide, verte et vulnérable sans parrain. Ce n'était pas une grande surprise d'avoir été attaqué par un requin qui ne servait que ses propres intérêts.

Plus tard, j'ai reçu une requête pour mon programme et je l'ai envoyée, mais je n'ai pas entendu s'il avait été jamais utilisé. Finalement, j'ai jeté ma copie dans la poubelle.

Et si j'avais persisté ? Si j'étais allé au-delà d'être le programmeur de l'outil ? Si je l'avais utilisé pour analyser les caractéristiques d'un système ? Si j'avais prouvé sa valeur ? Ou si j'avis trouvé un nouveau parrain dans le laboratoire de Endicott ? Est-ce qu'il aurait été possible que ma carrière aurait pris un autre direction avec de diffèrents résultats sur le long terme ? Peut être, mais le symposium avait eu lieu peu d'années avant le développement des premiers microprocesseurs. Depuis ce moment-là, le sujet des caractéristiques d'ordinateurs centrales était devenu sans grande importance par les avancées stupéfiantes de la technologie d'ordinateurs, des avancées qui étaient seulement perçues faiblement en 1973, des avancées qui ont réduit le coût des processeurs, de mémoire et de communication à presque rien.

1 Pourquoi ai-je dû travailler une année entière à développer ce programme ? La meilleure réponse reste dans la basse productivité de notre environnement de travail. C'était les jours avant la disponibilité générale des terminales interactifs ou des ordinateurs personnels. Un programme devait être écrit sur des papiers de vert et blanc rayons et puis des paquets de cartes de 80 colonnes devaient être perforées. Puis, les cartes étaient transportées en voiture de notre bureau à White Plains au centre des ordinateurs à New Jersey, de l'autre côté du fleuve Hudson. La-bas, les cartes étaient lues par un ordinateur ou le nouveau programme était compilé et exécuté. Les résultats étaient imprimés sur des papiers en accordéon et retourné à notre bureau à White Plains. Au mieux, je pouvais avoir un seul changement chaque jour. Même la plus petite erreur coûtait un jour entier. J'ai appris à vérifier tout dans mon bureau. C'était un processus qui consommait beaucoup de temps, mais après avoir envoyé les cartes, il me laissait beaucoup de temps pour étudier d'autres langages de programmation et d'informatique.

2 Au moment du symposium, les travaux innovateurs étaient faits tout près, au « Palo Alto Research Center » de Xerox, sur la première version du language de programmation « Smalltalk ». Ce langage est orienté-objet ; les données sont mis en capsules formée par des opérations qui peuvent exécuter sur ce type des données. Chaque objet identifie sa classe (lui-même un objet) et la classe détermine les opérations permises. Les « atomes » de mon programme étaient similaires à point de vue conceptuel, mais beaucoup plus limité. Plus tard, je suis devenu un « vrai croyant » et partisan de Smalltalk.