Sunday, May 18, 2008

A SLIC Time

Hewlett-Packard’s purchase of EDS this week got me thinking about my time with Electronic Data Systems, or Ed’s Bar and Grill as some of the people there called it. I was just in the process of being made a manager at Amtec Information Services when we were purchased by EDS. The manager I was replacing, Giovanni Reynaudo, was the man responsible for me getting seriously into programming.

I had been employed as an editor at Amtec (and two other names the company had gone by) for a couple of years. During that time I had become quite proficient at writing EXEC, EXEC2 and XEdit macros, not realizing that these were programs. Giovanni spotted my work and one day asked if I would be interested in working on the coding of the proprietary typographic software that our company created. I told Giovanni that I didn’t know how to program and he told me that I did, that he had seen it. Long story short here, I became a programmer by name and occupation that week and within a year Giovanni and I were neck-deep in rewriting the SLIC and SuperSLIC languages in our own images. SLIC stood for the Symbolic Language for Illustrated Composition and it was an IBM 370 Assembler Macro language that ran on a number of IBM mainframe operating systems. SuperSLIC was what we considered the ultimate format-driven generic composition system.

When I took over the lead role in developing these two products, SLIC was about 7,000 lines of Assembler code and SuperSLIC was about 12,000 lines of code on top of that. When I left the company six years later, the software had more than tripled in size, doubled in functionality and ran 20% faster than when I had started working on it. SuperSLIC had three separate macro languages imbedded inside it and when I got hold of the software these languages were a shambles of inconsistency. I removed the inconsistencies and then worked on improving all of them.

You may wonder why one program needed three macro languages and it is a good question. In reality the program could have gotten away with only two. SuperSLIC was a two-pass composition system. The first pass created composed typographic galley: lines of type, paragraphs, illustrations, footnotes, etc. The second pass placed that galley into pages. While galley creation was a pretty straightforward process, pagination was a series of trial-and-error passes, filling a column, then another, then squaring them, then backing off space for footnotes, floating blocks of text/graphics or structure changes (from say two columns to three columns, etc.), then starting the page over with the building of the first column again and over and over.

Each process had its own macro language, which were different because they did much different things and saw much different types of data. There was a second galley macro language that could do just about anything, but it was harder to use that the main macro language which we called “structured editing.” The “unstructured editing” was very powerful, but very hard to implement correctly. There was only one form of “pagination editing.”

Besides bringing consistency to the macro languages, I brought new concepts as well. I added new commands to the languages, the concept of functions, then nesting of functions and a short-hand way of declaring multiple and or sequential search values. I made sure that everything I added was done modularly, so that a new functionality could be called and used by many different areas of the program or attached to many of the new and existing commands.

At every opportunity I looked for limitations and tried to remove them. For example, the language had seven or eight different types of floating blocks. One type would appear where it was encountered or float to the top of the next page. One type would only appear at the top of the next page. One type would appear where it was encountered or float to the top of the next column (if it fit). One type would appear where it was encountered or float to the bottom of the current page. One type would only float to the bottom of the page. One type of block was hard-coded so that it would only appear at the top of a specified page. One type of block would jump in front of existing blocks waiting to be output. I took all of the logic and mapped it to a new type of super block that could perform any and all functionality. Then I exposed this new block as a new command that allowed the user to mix-and-match the floating logic. This allowed for hundreds of different types of blocks to be created by the user, yet allowed all the existing blocks to continue working as normal even though internally they were being converted to the new super block format.

I’m actually very proud of the work I did on this software and I really loved working with the 370 Assembler language which was unforgiving but elegant and straightforward in nature.

Next time I get back to this subject, I will tell you about the biggest failure of my career and the day I showed up at work and waited to be fired.

No comments: