Enable JavaScript.

1973: The Mohawk Project

As I write this story, the use of paper checks has been replaced, to a great extent, by electronic payment methods, but in the 1970's paper checks predominated. Processing all of the millions of checks that flowed through banks each day was both expensive and complicated. IBM had a long history of helping banks to automate check processing by means of specially designed equipment and software systems. The Mohawk project, which was announced as the IBM 3895 Optical Check Reader, was a major attempt to reduce costs by optically reading the amount of each check. But the Mohawk was a complete Rube Goldberg1, and my small contribution to its development was truly bizarre.

A stack of checks would be placed in Mohawk's hopper, and the machine would then pass each check through a series of stations where a variety of operations could be performed. First, the information encoded in magnetic ink (MICR) on the bottom of the check was read. This information was used to determine where the amount could be found on the check. The amount was optically read at the next station, and that value, along with the MICR data, was passed to a computer which decided what to do with the check.

The amount could be printed in the MICR line, the check could be endorsed on the back, it could be photocopied, and it could be sorted into one of twelve pockets. Then, as a double check, after all of the checks of a bunch were processed, an adding machine tape was read and compared to the checks that had been processed. Considering all that it could do, the banks involved in this project were quite enthusiastic.

My job was to write a set of Assembler language macros that could be used to generate a program to be downloaded to the 3895 to tell it how to interpret the MICR line to control the optical reader. Before starting work on this project, I visited the Mellon Bank in Pittsburg with one of the project planners. This was to be a test site for the new machine. I was impressed by the sheer size of the check clearing problem. I saw a room the size of a football field filled with machines the size of a desk. At each of them was a woman who keyed the amount of a check into its MICR line. What a mind-numbing job!

When I explained my role in the project to bank officials, they told me that they needed to be able to convey through my macros something like "If the transit code is between 5999 and 8000 and the routing code equals 123456789, then the amount field is at position (750, 175) on the check." This wasn't going to be easy to achieve. A special-purpose processor had been built into the Mohawk that consisted of a comparator that could be used to test a single character of the MICR line at a time. For example, was the character at position 4 less than, equal to or greater than the number 8? From the results of a series of such tests, one could determine the numeric value of the MICR positions tested. It is not, however, a trivial exercise.

Back in IBM's Glendale Laboratory in Endicott, NY, I told the project planners and engineers what I had learned, arguing that the single character comparator was completely inadequate to its real task. Regardless, my arguments fell on completely deaf ears. But to be fair to the engineers, this was well before the advent of microprocessors. A simple thing like the comparator was built out of discrete electronic components, and was therefore quite expensive. They had both cost and schedule constraints to meet, and they were done with that part of their design. Their attitude was that this was a software problem that could be solved by project programmers. This left me with a difficult problem, but only six weeks in which to solve it.

I thought about the problem for several days, running simple exercises through a paper version of a single character comparator. I found that it would be possible to provide the banks with the kind of logical expressions they wanted, but it wasn't going to be at all easy to do so through macros. It was also clear that I would never be able to design, code, and debug the macros in only six weeks if I worked directly in the macro language. I needed to develop and test a prototype in some better language, that could then be recoded quickly in macros. Fortunately, I had just learned APL (literally, "A Programming Language"), one of the most powerful programming languages ever developed. Furthermore, I could use a teletype terminal for interactive APL coding and debugging, which would be a huge advantage; otherwise, it would be batch jobs using punched cards.

My manager was somewhat skeptical about this idea since he knew of no one familiar with APL, but I convinced him that this was the only way the job could be done in time. Initially, we thought I would spend about three weeks in APL prototyping and that there would be three weeks left for rewriting the APL code as Assembler macros. In fact, however, I spent nearly five weeks in APL work, with only one very long week needed for the Assembler macros. The result was probably the strangest set of Assembler macros ever written, but they worked and had required only a minimum amount of additional debugging. All of the hard design and debugging work had been done in APL where they could be done with relative ease.

"Translating APL code into Assembler macros? What a wierd thing to do!" Of course, any program can be written in Assembler language, because Assembler is just a small step away from the actual instructions that a computer executes. Assembler macros are another small step beyond that, essentially parameterized sets of Assembler instructions. High-level languages, like Fortran, PL/I and COBOL) jump us many steps higher. They enable programmers to think and code in terms of abstract concepts that are much more familiar to human beings, such as logical relations among entities. These languages provide programmers with a wide variety of services, thereby eliminating a lot of drudgery.

APL takes this to the limits. Wikipedia has a good description of the history and ideas of APL, so I won't repeat anything here. In this project I used whatever APL functions and operators I needed and then developed equivalent (though limited and specialized) Assembler macros. The results were very strange. I must admit, however, that I did get trapped in a very common APL syndrome. The language is so powerful and concise that it is tempting to write whole programs in a single statement. I spent one whole day doing this, only to discover, the next day, that I didn't understand the statement I had written. But it worked, and I was sure it did, so I proceeded with other parts of the project.

When the project was finished, I took time to write an IBM Technical Disclosure Bulletin2 about one aspect of my design. These bulletins were published by IBM to protect its rights to techniques of possible value. At the time, software ideas could not be patented. My idea was a way of expanding logical expressions by means of matrices, something that no one else has probably ever needed to do; but then, who else has ever been stuck programming a one-character comparator?

As far as the Mohawk device was concerned, it had a fatal flaw that destroyed its usefulness to the banks. Its optical reader did well with printed amount fields, but could successfully read only about half of all hand written amounts. As a result, entirely too many checks were rejected and had to be reprocessed using the old manual methods. This destroyed the cost effectiveness of the Mohawk device. Still, it had been an interesting and technically challenging project.

1Wikipedia defines a « Rube Goldberg » as a deliberately over-designed machine that performs a very simple task in a very complex fashion, usually including a chain reaction.

2Demers, R. A., Matrix Method of Modifying Logical Expressions, IBM Technical Disclosure Bulletin EN875-0186, vol. 18, no. 12, May 1976.

1973: Le projet Mohawk

Au moment où j'écris cette histoire, l'utilisation des chèques bancaires en papier a été remplacée, en grande partie, par les méthodes électroniques de paiement, mais dans les années 70, les chèques en papier prédominaient. Le traitement de tous les millions de chèques qui passaient par les banques chaque jour était cher et compliqué. IBM a une longue histoire à aider les banques à automatiser ce traitement par des systèmes spécialement déssinés d'équipements et des logiciels. Le projet Mohawk, qui était annoncé comme « IBM 3895 Lecteur de Cheques », était un essai majeur pour réduire les coûts en lisant optiquement la somme sur les chèques. Mais, la Mohawk était tout entier un « Rube Goldberg1 » et ma petite contribution dans ce développement était vraiment étrange.

Une pile de chèques serait mise dans la trémie d'un Mohawk et la machine passerait chaque chèque à une série de stations où une variété d'opérations pourrait se réaliser. D'abord, l'information codée en encre magnétique (MICR) à la basse du chèque était lue. Cette information était utilisée pour déterminer le lieu de la somme sur le chèque. La somme était lue optiquement à la station suivante et la valeur (et en plus l'information de la ligne MICR) était envoyée à l'ordinateur qui décidait ce qu'on devait faire avec le chèque.

La somme pouvait être imprimée dans la ligne MICR, le chèque pouvait être endossé à l'arrière du chèque, il pouvait être photographier et le chèque pouvait être trié dans une des douze poches. Puis, pour les vérifications, le ruban d'une machine à calculer était lu et comparer aux chèques qui avaient été traités. Étant donné tout ce qu'il pouvait faire, les banques qui faisaient une partie de ce projet étaient très enthousiastes.

Mon travail était d'écrire un ensemble de macros du langage Assembler. Ces macros pouvaient être utilisés à produire un programme qui pouvait être téléchargé à la Mohawk pour dire comment elle devait interpréter la ligne de MICR pour contrôler la lecture optique. Avant de commencer mon travail sur ce projet, j'ai visité la « Banque Mellon » à Pittsburg, dans l'état de Pennsylvania, avec un planificateur du projet. Cette banque serait un site témoin pour la nouvelle machine. J'étais impressionné par la taille du problème de traitement des chèques. J'ai vu une pièce de la taille d'un terrain de football qui était remplit de machines de la taille d'un bureau. Sur chaque machine, il y avait une femme qui tapait la somme d'un chèque sur la ligne MICR. Quel travail horrible !

Quand j'ai expliqué mon rôle dans le projet aux employés de la banque, ils m'ont dit qu'ils avaient besoin d'utiliser les macros pour dire quelque chose comme ça : « Si le code pour le transit est entre 5999 et 8000 et le code pour le routing est 123456789, alors la somme est à la position (750, 175) sur le chèque. » Ceci ne serait pas simple à réaliser. Un comparateur spécial avaient été construit dans le Mohawk pour tester un seul caractère de la ligne MICR. Par exemple, « Le caractère à la position 4 est-il inferior ou égal ou superior au nombre 8 ? » Des résultats d'une série de tels tests, on pouvait déterminer la valeur numérique des positions MICR qui étaient testés. Ce n'est pas, cependant, un exercice insignifiant.

Après être revenu au laboratoire Glendale d'IBM à Endicott, dans l'état de New York, j'ai raconté aux planificateurs et aux ingénieurs ce que j'avais appris. À mon avis, leur comparateur était totalement inadapté à l'objectif recherché. Quand même, mes arguments tombaient dans des oreilles sourdes. Cependant, dire la verité aux ingénieurs, c'était plusieurs années avant l'avènement des microprocesseurs. Quelque chose d'assez simple que le comparateur était construit d'éléments électroniques discrets et par conséquent très cher. Ils avaient des contraintes de coûte et de temps et ils avaient fini avec cette partie du design. Leur attitude étaient que ceci était un problème pour les programmeurs. Cela me laissait avec un problème très difficile, mais seulement avec six semaines pour le résoudre.

J'ai réflechi sur ce problème pendant plusieurs jours, faisant des exercices simples avec un comparateur en papier. J'ai trouvé qu'il serait possible de fournir les banques avec le type d'expressions logique qu'ils voulaient, mais il ne serait pas simple de le faire avec des macros. C'était clair aussi que je ne pourrais pas dessiner, coder et déboguer les macros en six semaines seulement si je travailais directement dans le langage des macros. Je devais développer et tester un prototype dans un meilleur langage qui pourrait être recodé rapidement en macros. Heureusement, j'étais venu apprendre APL (littéralement en anglais « A Programming Language »), un des plus puissants languages pour la programmation jamais développé. De plus, je pourrais utiliser un terminal compatible télétype pour coder et débouger l'APL en mode interactif, ce qui serait un avantage énorme ; autrement, ce serait un mauvais travail en traitement par lots avec des cartes perforées.

Mon patron était sceptique à propos de cet idée parce qu'il ne connaissait personne qui était familiere avec APL, mais je l'ai convaincu que c'était la seule façon dont le travail pourrait être fait à temps. D'abord, nous avons pensé que je passerais trois semaines à travailler sur APL et les dernières trois semaines à recoder sur macros. En fait, j'ai passé cinq semaines sur APL, et une très longue semaine sur macros. Le résultat était probablement les macros les plus étranges jamais développés, mais ils travaillaient bien et ils avaient eu besoin seulement d'un minimum de débouguants supplémentaires. Tout le travail difficile en design et en débouguant avait été en APL où ils pouvaient se faire aisément.

« Traduisant des codes en APL à des macros d'Assembler ? Quelle chose étrange à faire ! » Bien sûr, n'importe quel programme peut écrire en language Assembler, parce que codes en Assembler sont seulement un petit pas d'instructions qu'un ordinateur peut exécuter. Des macros d'Assembler sont seulement un autre petit pas plus loin ; essentiellement ils sont des séries de codes d'Assembler qui sont paramétrés. Les langages plus elaborés, comme Fortran, PL/I et COBOL, nous prennant plusieurs pas plus haut. Ils permettent à des programmeurs de penser et de coder en concepts abstraits qui sont plus familiers aux gens, comme des relations logiques entre des entités. Ces languages fournissent aux programmeurs une grande variété de services et de cette façon ils éliminent beaucoup de corvées.

APL va jusqu'au bout de ces idées. Wikipedia a une bonne description de l'histoire et d'idées d'APL, donc je ne les répéterai pas ici. Dans ce projet, j'ai utilisé toutes « les fonctions et les opérateurs » d'APL dont j'ai besoin et puis j'ai développé des macros d'Assembler équivalents (mais bien sûr plus limités et plus spécialisés). Les résultats étaient très étranges. Je dois admettre que je me suis pris au piège dans un syndrome commun à APL. Le language est assez puissant et concis qu'on est tenté d'écrire un programme entier en une seule phrase. J'ai passé une journée entière à le faire, mais le lendemain, j'ai découvert que je ne comprenais pas la phrase que j'avais écrite. Mais cette phrase marchait bien et j'en étais sûr, donc j'ai continué avec d'autres parties du projet.

Quand le projet est terminé, j'ai pris le temps d'écrire un « IBM Technical Disclosure Bulletin2 » au sujet d'un aspect de mon design. Ces bulletins étaient publiés par IBM pour protéger leurs droits à des techniques à valeur possible. À ce moment-là, les idées de logiciels ne pouvaient pas être brevetées. Mon idée était une façon d'élargir des expressions logiques par l'utilisation des matrices, quelque chose que n'importe qui d'autre que moi pouvaient avoir besoin de faire ; et puis, qui d'autre que moi pouvait avoir besoin de créer des programmes pour un comparateur d'un seul caractère ?

Au regard de l'appareil Mohawk était concerné, il avait un défaut fatal qui détruit son utilité pour les banques. Sa lecture optique marchait bien avec des sommes qui étaient imprimées, mais elle pouvait seulement lire un moitié des sommes qui étaient écrites à la main. Comme résultat, trop de chèques étaient rejetés et devaient être traités par les anciennes methodes manuelles. Ceci détruisait l'efficacité de Mohwak. Quand même, c'était pour moi un projet qui était interresant et qui a représenté un réel défi.

1Wikipedia définit un « Rube Goldberg » comme une machine délibérément dessiner au-delà des normes, qui exécute une simple tâche d'une façon très compliqué, généralement y compris une réaction en chaine.

2Demers, R. A., Matrix Method of Modifying Logical Expressions, IBM Technical Disclosure Bulletin EN875-0186, vol. 18, no. 12, May 1976.