Construction without commuting

This is a story about a distant past. Not so many years, really, but the software construction world was quite different forty years ago. What was innovative then is now merely commonplace. In a word, telecommuting.

In the mid 1970's, I was working in France on a project for the French statistics bureau, INSEE. One aspect of this work is described in a previous post. The project involved the creation of a system to capture all of the data collected in the French census of 1975, and was part of a larger project, with "Colibri" as its code name*. Those with an interest in the history of census taking, and a reading knowledge of French may find it fascinating to read about this time in the history of INSEE.

The system we built was very ambitious for the time, and definitely on the cutting edge. It involved a central computer, located in Lille, attached to about 50 terminals** distributed throughout France, in 17 different locations. At these terminals, over 100 employees, mostly women, worked one of two shifts a day. Their work was to type in the information collected on the millions of individual census forms.

Our work was to develop the software system to support this. The hardware was an IBM 370 mainframe computer with telecommunication channels connected to all of the terminal locations. This was managed using IBM's SNA protocol as implemented in VTAM. On top of all this, we ran the teleprocessing monitoring system which our company*** sold, MULTIFASTER. Besides necessary bits and pieces to connect everything together, our main task was to create small programs, each one of which would handle a single transaction. A transaction was basically one screenful of information coming from one of the terminals. The small program would then validate the information and store it in a database, and that was all it did. Each such small program was called, also, a transaction. Confusing, I know.

The system we developed consisted of a collection of transactions. Each transaction was initiated from one of the terminals connected to the system. There were transactions to paint input screens onto the 3270 terminal. After the operator had filled in the blank fields, she would press the transmit key. There were transactions to accept the transmissions from the terminals, validate the information and store it in the database.

We were three software engineers writing the transactions: Marcel Sellem, Raymond Hédin, and myself. We all commuted from the Paris area to Lille to do the work at the site of the central computer. The programs were prepared on punched cards (80 column cards) and given to the operators to compile.

Once the entire system was built, it went into operation, and the data entry personnel went to work. Their work lasted for several years.

We all shifted our attention to other projects, but it remained my job to maintain the system. Every software system has bugs, and these needed to be addressed. We also had contractual limits on how much time the computer spent working on each transaction, so there was some tuning to be done as well.

At first, I did the necessary maintenance work by commuting to Lille. But then, suddenly, this innovative thought hit me: I could create a transaction which would let me edit the programs of the system. The system was a collection of loosely-coupled transactions. All that I had to do was add a new one. I did this.

The editor, due to the characteristics of the 3270 terminal had to be extremely simple. Each screen showed me three lines at a time from the program file on which I was working. The middle line could be edited. Above and below it were two lines of context: the line before and the line after the one that I could change.

Due to a limitation**** of the editing software behind the scenes, I had to work through the file in order from top to bottom. Each time that I deleted a line, edited a line, or inserted a line, I would press the transmit key, and the information would be sent to the central computer where the actual editing of the file was performed.

Once I had made all of the changes to the file, I used the same system to create a new file, written in job control language (JCL), which would direct the compilation of the modified program. I would then phone an operator in Lille, tell them where the file of JCL was located, and have them run it. Running it would compile the modified program file. If all of that was successful, I could cause the modified program to go into service.

I built all of this while at Lille doing the maintenance work that had taken me there. Once it was built, I no longer needed to commute! Instead, I would go to the INSEE head office, nearby in Paris, log in to the system from a terminal they had there, and make the needed changes.

Since the new editing transactions were part of the system, I could also modify them remotely! Of course, this would have to be done very carefully, because if I were to break the editing transactions, I would have to go all the way to Lille to fix them.

This is how I was able to do software construction without commuting, back in the 1970's.

* COLIBRI is an acronym from the French COdification en LIgne des Bulletins du Recensement Individuels roughly translated as "encoding on-line of the individual forms of the census."

** These were IBM 3270 terminals, sometimes called "green screens" because they were monochromatic black and green screens.

*** The company for which I worked was named CAP Sogeti Logiciel, and at the time, I thought it was a small company. Turns out it was a branch of one of the largest software organizations in Europe.

**** The editing software was not intended for interactive use. So calling this one of its limitations is really unfair. It was actually a feature of the editing software to allow user-supplied code to be executed as each line was considered. I took advantage of that feature to paint a new screen onto the 3270 terminal, and the editor waited until the user responded to that with a command to do some edits before continuing on to the next line.