This week we return to the subject of the IBM i 25th birthday bash with some more personal reminiscences.
One shared memory is of the first time we met Malcolm Haines in the U.K. before he moved to a marketing role in the U.S. We had heard about Malcolm's incredibly successful Graffiti campaign in the U.K. and while doing a one-day event in London had asked our hosts if they could introduce us.
Long story short--we had a fascinating meeting with Malcolm (the first of many) and arranged to get some copies of the advertising collateral sent to us to help inspire the troops back home. It is amazing to us looking back to realize how powerfully these messages still resonate.
One example: "Shouldn't the system run without an army?" is every bit as relevant today as when it was first used. In fact you might ask why IBM isn't still using it, but we digress. You can see images of three of the posters used in the campaign on the IBMi25 Facebook page but since you have to dig through the "Recent posts by others" to find them, Trevor Perry also posted them here.
Jon's Memory Dump--Breaking Things
It never occurred to me that quite a lot of my work on the compiler would be spent "breaking" it! Why? Because the new S/36 compatible compilers had to mimic the behaviour of the originals. But the original compilers were written in assembler and, due to memory limitations, took quite a lot of shortcuts en-route to the executable program. Often memory patching techniques were used to ensure that a particular path was followed if certain conditions existed. The problem was that the compiler writers often made the assumption that one of a finite number of alternative paths would have been set up and therefore (assumedly to save a few bytes) had not coded for the possibility that the programmer might have managed to code something that fell through gaps in syntax validation and resulted in a "none of the above" condition. Some of the time this would cause an error to be signalled later in the process, but it was not uncommon for it to produce an executable program. Just not one that the compiler writers had even intended.
So why does this cause problems? Well one of the first lessons I learnt when working with compilers was that by the time we discovered that we had a compiler bug, at least a dozen programmers had decided it was a new "feature" and were using it in production code. Sometimes the bug had the potential for causing significant problems and so we fixed it and dealt with the fallout. More often we had to retain the aberrant behaviour and sometimes allowed the programmer to specify that they wanted the correct behavior via a compiler option. In the case of the S/36 compilers there was a lot of aberrant behavior--some of which was even documented. So we had to do our best to "break" the correctly working compiler code (which was based on the S/38 compiler) and modify it to make the same mistakes that the real S/36 compiler had made. This wasn't always possible but we tried.
Susan's Memories of Rochester, Minn.
I mentioned in an earlier post that I became fascinated with the AS/400 before it was AS/400--back when it was code-named Silverlake in the Rochester lab. After spending a few weeks on residency in Rochester and then several months traveling around the world teaching IBMers about the system-yet-to-be-named, my fascination turned into an obsession. I was more convinced than ever that the developers in Rochester were the smartest people I'd ever hope to spend time with.
But I grew up in the South--in South Carolina and Georgia --I had rarely even visited parts of the country where snow covers the ground for months at a time. Was I obsessed enough to actually move to Minnesota to be around the home of AS/400? Apparently so.
Some of my friends enjoyed laughing at my attempts to buy a snow shovel after moving to Rochester (saying to the sales person when asked what kind of snow shovel I needed, "there are different kinds?"). But I did manage to live there, snow shovel(s) and all and I loved it--not the weather, but the place and the people. By the way, it's May 1 today and I see that Rochester is expecting around 4 inches of snow tomorrow. You definitely don't move to Rochester for the weather!I worked in the AS/400 Technical Support Center in Rochester, the home of one of my heroes in the community at the time, John Sears. I found that John was indeed inspiring but there were many others in Rochester--in the support center as well as in the lab--who were equally inspiring, the many unsung heroes toiling away in the background creating amazing software. I found it impossible to be there and not be impressed at the brilliance housed in all those blue buildings (and the white buildings across the road).
My office happened to be just a few doors down from the ITSO--the group responsible for the famous Redbooks publications. As interesting as the Redbooks they wrote were, they didn't hold a candle to the experience of working with the people who wrote them. Technical field staff (aka SEs) from IBM offices all around the world came to the ITSO for extended residencies or multi-year assignments to dig into the new technologies being implemented by the developers nearby and make them practical for use by mere mortals. It was like working next door to the United Nations. I met and worked with people from places I barely knew existed and found kindred spirits from around the globe--all united by a similar obsession with (in the immortal words of Malcolm Haines) "the best computer a business can buy."
Some of the international assignees from the ITSO found a way to stay around after their assignments and have gone on to play important roles in the life of the system and the community. Perhaps the most recognizable name today from among those is Ian Jarman. Now, where have we heard that name before?