Simplifying Complex Concepts

As our regular readers know, we're fans of simplification in our code. Today's application needs are getting more complex every day, but we advocate that developers strive to hide as much of that complexity as possible. Open Access is one tool that can help in that aim; subprocedures are another. The nitty-gritty detailed code must be there but it doesn't need to be in the forefront.

When it comes to talking about our beloved IBM i system to non-i people, simplification is also important. Most of us understand the things that make our platform unique (e.g., single-level storage, object orientation, TIMI and the integration of not only DB2 but also most of the other bits and pieces needed to make a business application system run).

But can we explain these concepts in a few words, holding the attention of the listener while getting across succinctly the value of these concepts? Most of us can't. We get caught up in the technical details that seem so cool but can sometime muddy the waters of understanding the business value.

Here's help. Hopefully you all followed the 25th anniversary celebration activities earlier in the year, including the publication of 25 vignettes, each celebrating one aspect of the power of our platform. We looked forward to reading each one as they came out--25 nice rah-rah moments for the IBM i community.

Recently, we've gone back to revisit some of those vignettes in a slightly different context, using them as vehicles to advocate for the i platform to the uninitiated. Rather than simply relegating these to the annals of history or preaching to the choir, maybe we could make use of some of them to preach to others.

You probably read them, but how well do you remember them? For example:

• How is TIMI like a pair of shoes?
• How can car keys be used to describe the value of single-level storage?
• What does Harry Potter have in common with IBM i? 
• An operating system without an integrated database is like a hotel room without a bed--unthinkable.

We all need to be advocates of our platform. Even if you don't know of any potential threats to the platform in your own shop, it's still wise to ensure that the powers that be truly understand the value of what you have.

Do yourself, and your business, a favor by arming yourself with some of the simple analogies embodied in these vignettes so that you can drop them into conversations and meetings to illustrate the value of IBM i.

From our System i Developer iAdvocate page you can download the whitepaper that IBM created with the 25 vignettes and you can also get a set of PowerPoint slides in case you get a chance to insert some of these into a presentation. You may even want to remind yourself and your colleagues of these gems by downloading and printing a poster of the 25 vignettes here.

You'll also find many other iAdvocate resources on the Web page mentioned above. It never hurts to be prepared for the occasion that may arise to advocate for the best platform there is!

Random Musings on IBMi25, Liberty and ACS

The 25th anniversary celebrations of our favorite system are beginning to wind down as we approach the finale on June 25. If you missed any of the 25 chapters of the story they have been gathered together into a whitepaper that you can download from here. The official Facebook page also recently featured some interesting pictures from the Japanese celebrations--IBMi25 cookies! Take a look when you have five.

Catching Up on Our Reading

We were catching up with some of our reading backlog and came upon Tim Rowe's blog on Java application servers for IBM i. For us the most interesting news was that there's a new version of Websphere Application Server (WAS), known as the Liberty Profile, which should resolve one of the issues we've always had with WAS: application deployment. We still shudder at the memory of the bad old days of WAS when we were first teaching people WebFacing and trying to deal with the deployment issues that arose. Over the years things have improved tremendously--but it always struck us as being more complex than necessary. With this new version it seems that is all in the past.

Deployment in Liberty is apparently as simple as dragging the app into the runtime directory and it gets started automagically. We've got used to this level of simplicity with deploying PHP applications--nice to think that we'll be able to do the same with Java apps. One other interesting feature is the fact that Liberty allows you to bundle the server itself, along with its configuration detail, into the delivery package. That's nice.

IBM i Access Client Solutions (ACS)

This has been in technology preview for some time now and has now been GA'd. You can find the details on how to obtain the GA version on this Web page. Note that you'll have to scroll down a bit as the top of the page still talks to the technology preview. We've been using this on our Macs since we blogged about it back in July 2012. It still has a few rough edges, but we're hoping they will have been smoothed out in the GA version. From the screen shots we've seen it certainly looks a lot cleaner. Of course this is just going to make us even more frustrated that we can't get a native version of RDi but we know it is on IBM's to-do list. We've heard that one of the major barriers to the Mac port is the verifier. While we like the verifier a lot, if living without it means we can get a native Mac version sooner we're all for it.

Commenting on Comments

In response to our 25th Anniversary blog "RPG: A Rose by Any Other Name" not many took on the challenge of coming up with new meanings for the initialism RPG but Jean Mikhaleff did raise an interesting point about the lack of an IBM supplied CVTRPGSRC which could go all the way to free-form or stop somewhere along the way. In fact IBM does provide one form of /Free conversion tool, but it is built into RDP and not available as a regular system command.  Even then it is a line-at-a-time conversion which pays no attention to the data type etc. of the operators and therefore misses many opportunities to convert. The result can be very ugly with much switching in and and out of /Free syntax.

Back in the mists of time when RPG IV was being designed, a deliberate decision was made that IBM would only supply minimal tooling (e.g., the original CVTRPGSRC, which simply converted from the old RPG/400 syntax to RPG IV). The thought was that third-party tool vendors would offer better tooling and that this would provide choice in the marketplace. To an extent this happened and Linoma Software's RPG Toolbox nicely filled this gap. There were other offerings too but as far as we know Linoma's tool is the only one currently marketed that offers the kind of flexibility that Jean was talking about. There is also a free option in the form of Craig Rutledge's "Path to /Free"--an essay and accompanying tools which you can find here. For those who find that a commercial tool never does quite what they want, Craig's tools allow you to customize the code to exactly meet your requirements.

Actually one person did take us up on the challenge. Skip Meyn suggested that RPG = Robust Programming Guidelines, because "you can do anything you want." We also received a suggestion via email that "Remarkably Powerful Gentleman," might be appropriate as it spoke to its capabilities and its standing in the community. But given that the RPG compiler team is currently led by a woman, suggesting a male gender for the language doesn't seem quite right--and "Gentleperson" just doesn't cut it!

Don't think we've quite hit the perfect meaning yet guys and gals, but keep trying.

In response to John Clayton's comment about the fact that RPG is far more than 25 years old, much as we hate to admit it, we're both old enough that we've used the language ourselves longer than 25 years! We only limited the timeframe of the piece to tie into the IBM i 25 year anniversary celebrations going on now.

In response to an earlier blog "How Old Is Your OS?", Dan Devoe took the prize (if that is an appropriate term) for highlighting the fact that his local CE is still servicing some white boxes running V3R2 and earlier releases. It is of course a great compliment to the longevity and stability of the system that these keep going--but really, people--risking your business on an unsupported OS? Does that really make much sense, particularly when many could probably pay for the new hardware with the savings on power and cooling usage! Can anyone beat V3R2?

RPG: A Rose by Any Other Name ...

Today’s IBM i 25 chapter begins by musing about the meaning of RPG’s name. In one of our earliest blog posts back in July 2007, we blogged about the name of the RPG language and whether it should have a new one to match its new personality. We had suggested “Borg” since RPG seems so good at assimilating the best features from other languages. Many of you offered alternative suggestions.

In reading today’s anniversary chapter, Susan learned something new—although Jon claims he knew it long ago. When RPG IV was introduced, the name “RPG” was officially declared to be no longer an acronym—or, more correctly as Scott Klement pointed out recently, an initialism. For those who didn’t realize this, to be an acronym, apparently it must be pronounceable as a word, such as NATO. If it is simply spelt out, as RPG is, it’s technically an initialism.

While the letters RPG may not officially stand for anything any more, RPG, the language, means a great deal to many thousands of programmers around the world and the users of their rock-solid, efficient, modern business applications.

In many ways it’s a good thing that RPG no longer stands for “Report Program Generator” because it has been many, many years since RPG’s primary function was reporting. It has evolved radically over the years.

If the picture that comes to your mind when you think of RPG is of columnar logic with multiple conditioning indicators and nary a hint of SQL, it’s time to wake up, Sleeping Beauty—you’ve missed a lot in the last 25 years. IBM i’s modern RPG IV is barely recognizable as a relative of the AS/400’s original RPG/400.

Today’s RPG logic is written in free format. It also utilizes libraries of homegrown, open-source and third-party functions in addition to RPG’s own library of more than 70 BIFs (built-in-functions). As a result, what would have been dozens of lines of indicator-laden, columnar “old-style” RPG are replaced by simple, powerful expressions.  And RPG’s data access has “grown up” too. Support for a huge variety of native data types and a deeper level of integration with SQL than is seen in almost any other language makes RPG a natural partner for IBM i’s integrated DB2 database.

Still think that RPG = Green Screen? Think again. Many shops are running interactive Web and mobile applications with logic powered by RPG. Or if you prefer, RPG code can easily provide the business logic underpinnings of Web services, stored procedures and other services to applications written in PHP, Java, Python, Ruby, .NET, etc.

Inevitably there are things that RPG doesn’t understand natively and that IBM cannot add to the language in a meaningful timeframe. The pace of change in today’s IT world is just too fast. That’s why Open Access was recently added to the language. It allows for the development of drivers to add new functionality while maintaining RPG’s powerful data marshaling capabilities. For example, you can write a driver to call a currency conversion Web service from RPG, allowing any RPG program to treat access to real-time currency conversion data as if it were a huge database in the sky. Simply set the key values for the currencies involved and issue a CHAIN operation. The conversion rate is returned as if it were being retrieved from a database column.

In our next EXTRA article, due out in the next couple of weeks, we’ll take a look back at 25 years of RPG. We’ll post the link in the comments section here when it’s available, so check back if we’ve piqued your interest. Or follow us on Twitter @JonParis or @SusanGantner.

And don’t forget to join in the celebration with all 25 chapters leading up to IBM i’s 25^th  birthday at  http://bit.ly/ibmi25.

In the meantime, it seems a shame to waste a perfectly good initialism as RPG. Maybe we could unofficially assign one—or a few. How about Renegade Programming Gurus? Robust Programming Genus? Real Problems Gutted?

 

 

Looking Back on 25 Years

 

 

 

 

 

 

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?

 

IBM i 25 - Join the party

In celebration of the 25th anniversary year of IBM i, we're joining IBM and many others in reminiscing about our experiences with this fabulous platform which has defined our careers. Check out the IBMi25 Facebook page (bit.ly/ibmi25)  - you don't need a Facebook account to see it - for some very clever vignettes and videos about our platform. Join the party.

We are still covering our earliest AS/400 experiences and, so far in the story, we haven't met each other yet. So we're including remembrances for each of us individually - Jon is first this time! 

Jon - Joining IBM and COMMON in Toronto

As I mentioned at the end of the previous "history" post, after 18 months on contract I joined IBM full time. The actual hiring was somewhat rushed through as (unbeknown to me at the time) my manager had decided that I was the prefect person to present two sessions on the new COBOL compiler at the upcoming COMMON conference in Toronto. As far as I can tell his decision was based entirely on the fact that my background was as midrange systems user and not a Lab Rat. It certainly was not based on my public speaking skills. The last time I had done any public speaking was more than 5 years earlier.

As the day approached I became more and more terrified. I think I barely slept for the two or three days prior to the event. That terror climaxed as I walked into the room and found myself faced with more than 100 eager faces - all waiting for me. I fumbled my heap of foils - scared silly that I was going to drop them and lose the sequence. "Foils" ? In those days of course there was no Powerpoint (or Keynote in my case) and no laptop connected projector. Just black and white transparencies and an overhead projector. I remember very little about the sessions - way too nervous I guess - but apparently I did well enough that over time I was tasked with more and more presentations at various customer briefings and User Group events.

That COMMON conference was a milestone in a number of ways.  For one it was the first to ever be held outside of the United States, second it was the first to feature the AS/400. I'll leave Susan to tell you about the other distinction that this conference held.

It was around this time that I first made contact with the lovely lady who is now my partner in every sense of the word. I was tasked with acting as the liaison between the COBOL team and the Rochester education groups. That included the folks in the Business Partner teams as well as the education groups who were responsible for updating users and the field force on upcoming product releases. This was when I first got to know people like John Sears and Ed Simon who many of you will remember from COMMON and the IBM Tech Conferences. It was in this role that I first communicated with Susan. We didn't meet (and then only a brief corridor introduction) until the subsequent COMMON conference in Chicago. At this point I should note that Susan remembers none of this which merely goes to prove that she is far more memorable than I am!

Susan - Introducing the Latest in Programmer Tools
In the fall of 1988, COMMON was in Toronto. It was an exciting time for those of us who had eagerly awaited this brand new system, the AS/400. This was the first COMMON conference after the announcement and for many attendees, it was their first chance to see and interact with one.

It was for that reason that a handful of intrepid IBMers (including me) decided to hold an impromptu "hands on experience" for attendees with the new programmer tool on this system - PDM. Since it was impromptu, we had lots of hurdles to overcome, including getting the AS/400 system we were to use down the hall to an appropriate room. Since the system was brand new and much in demand, you'd think we would have been very careful about this move. We weren't. We pretty much shoved the system (obviously one of the smaller boxes - well, small in its day) down the hall, sliding it along the carpet. It fell over a few times in the process. But of course, it got to the other end and IPLed just fine - just one of many stories of the ruggedness of AS/400. We had a few instructor-led exercises for attendees to go through to experience the new PDM tool for the first time. This was the beginning of the notion of holding lab sessions at COMMON - a traditional that carries on still today.

Of course, the irony of the many hoops I jumped through to convince programmers to use PDM in 1988 will not be lost on many of you who know that I'm currently spending a lot of time convincing people to stop using PDM & SEU and use RDP/RSE instead. But it's really not incongruous. PDM & SEU were the latest technology for AS/400 programmers in 1988. RDP is the latest technology for programmers on IBM i today. I'm still doing the same thing, 25 years later!

Surprise Someone!

Preface: In case you missed it, IBM has kicked off an ongoing IBM i 25th anniversary celebration. We will continue our tributes and reminiscences here in the weeks to come, leading up to the actual anniversary in June. Thanks to those of you who have shared your early memories so far. You can follow the bigger celebration by viewing the IBMi25 Facebook page (bit.ly/ibmi25). There are some really fun things happening there.

But today's blog is not about what happened 25 years ago - it's about what is happening today - in your IBM i shop. If someone walked into your shop today, would all the applications look like they might also be 25 years old?

We don't mean for this to ignite the debates on whether green screens are evil or whether they are the most practical and robust way to do data entry. We're not necessarily talking about putting a pretty face on all your existing applications, important as that may be.

What we're talking about today is anticipating the needs of the business and your end users - and not just meeting those needs - perhaps even exceeding them. Surprise someone with what You and i (to borrow Steve Will's line) can do for them.

Look around your shop and talk to the people running the business and we're sure you'll find many ideas of ways you can make their lives easier and make the business more efficient and profitable. Maybe there's a function crying out for a mobile app that runs on a tablet or smart phone to better enable people in the field or on the shop floor to work smarter. Maybe a dashboard would help executives make better decisions. Maybe a browser-based report with the ability to sort, filter and export the data to a spreadsheet would more efficiently replace a collection of spooled file reports currently languishing in OUTQs somewhere.

If you're thinking - "Sure, but I can't do any of those things, I'm just an RPG programmer" - think again. It is probably much easier than you think.

This post was inspired by a recent discussion with a software vendor at a conference. He was frustrated - not because he wasn't able to talk to a lot of programmers and explain to them how his product could make it simple for RPGers to write and deploy mobile applications - he had talked to and convinced many that they could, indeed do this. However, far too many of them seemed to be filing that information away for when it may be needed "someday" - when someone comes to them to ask them for a mobile app that runs on i.

Sadly, far too often, when a need for a web or mobile app or a dashboard arises in a company that runs its business on i, the IBM i programmers are not the first people that come to mind as being able to implement such things. Sure, they are good at keeping the payroll checks printing and the invoices going out, but modern, web and mobile things? That's a job for - well, almost anyone except our RPG programmers.

Why? Perhaps because far too often that's all we've provided. If you're waiting for someone to come and ask you for a mobile or web app or a BI solution, you may be waiting a long time. They may never ask you - they may ask the Oracle DBA (who is there because of some small stand-alone application that crept in when no one asked you), or go out and find a "Windows solution" (and we use that term very loosely!).

So what can you do? Surprise someone.

Find a small project that can have a big impact with relatively little effort - most likely with the help of a tool or two. Some of those tools may be free; some may have a cost, but even then, most of them have free trials available. You may be amazed at what you can do in a very few hours with the help of some of these tools. We'll be talking about a couple of free ones in our next EXTRA article appearing in a week or so. Check the comments below for a link to it when it is published.

The goal here is to do something quickly - not taking weeks of planning and months of development time. Create something in a few hours or, at most, days that may not be perfect, but will cause people to say "I never knew you could do things like this!"

You'll find that it can be great fun to spread your wings and do something new and different. And most importantly, you will establish yourself as the go-to person for modern applications. Perhaps the person you'll surprise most about what You and i can do is yourself. Go ahead - surprise someone this week.

Close Encounters of the AS/400 Kind

As Steve Will revealed in his blog yesterday, there's going to be a lot going on in the IBM i world over the next few months to celebrate the "birth" of the AS/400 25 years ago. Yes it has been 25 years and boy does that make us feel our age a little today.

We've decided that we'll use this blog over the next few months to post a few of our own memories, so instead of writing this as a joint effort and letting you work out who-wrote-what we're going to write these pieces from our individual perspectives. What about your own early AS/400 experiences? Please tell us about them in the comments section of the blog.

Susan's Early AS/400 Encounters

25 years seems like a long time, but as they say, time flies when you're having fun! And my years on this platform have seen tons of fun.

After a few years as an IBM customer in Atlanta where I developed a passion for the System/38, I joined IBM as a S/38 specialist Systems Engineer (remember those?).  Within IBM, I started to hear rumors about a new system being developed in Rochester, Minn., which would merge the S/36 and S/38 platforms. When I learned the new system would be based on S/38, that was enough for me. I made it my mission to get to Rochester to have some kind of role working with that new, future system.

I don't remember now how I learned of the opportunity, but I discovered they were looking for Systems Engineers to visit Rochester for a few weeks to work on the new system code named "Silverlake." I jumped on that with both feet. My application must have sounded a tad desperate, because I later heard from one of the people who screened the applications that the reaction to mine was "Hey, we've got a live one here!" 

I was one of the first to participate in the residency to work with Silverlake. I was in awe of the Rochester lab and the brilliant, dedicated folks who worked there. I didn't think I could get more enthusiastic about the system but I was wrong. Being in Rochester was just where I belonged.

I did go back home to Atlanta, but not before lobbying (more like arm-twisting or maybe just begging) to become part of a group Systems Engineers who would travel the world for several months before June 1988 to do pre-announcement teaching to IBMers about the technical details of the Silverlake system. I made the team and in the months leading up to the announcement of what became known as AS/400, I was in my element. I discovered that I was not only enamoured with the system, but also with teaching--something I had not done much of until that time.

I had been working on and around the AS/400 for so long by June 1988 that the announcement itself seemed almost anti-climatic to me. Even so, I had found my niche and was thrilled at the thought of the future before me. Not long after, I moved to Rochester--it was inevitable--and found that I even loved Rochester itself--all except for the weather!

I'm no longer in Rochester and no longer with IBM, but I'm still every bit the AS/400 (aka iSeries, aka IBM i) lover that I was 25 years ago. And I'm still thrilled at the future of this platform.

Jon's Road to AS/400dom

Back in 1986 I was working as a consultant, mostly specializing in converting systems from other manufacturers to the System/38. However, at the time I first heard about the possibility of a contract at IBM I was working on a System/36. IBM, it turned out, were looking for someone who knew COBOL on the S/36 and S/38 and who also had some exposure to the internals of compilers. IBM wanted someone who could take over the maintenance of the S/36 and S/38 compilers to allow their existing staff to work on a "new product." Like most in the community, I had already heard the rumors of a new system that would replace the S/36 and S/38, so the possibility of working alongside its developers was intriguing.

Perhaps I was the only one they interviewed that had the required qualifications. Or it could have been my telling the interviewer that it would be good to have the opportunity to fix a few of the bugs in the S/38 COBOL compiler that I had discovered over the years. Either way I got the job and started work in February 1987. The first bug I handled on my own? A problem with S/38 COBOL reported by the Dallas Cowboys!

Over the months I picked up bits and pieces about the new system, including the fact that the testing was all being done on modified S/38s--there was no actual AS/400 hardware in Toronto. Even then I wasn't allowed to actually see the system it was locked away in a separate area of the machine room under additional security. This always struck me as somewhat amusing because there was really nothing to see, and, from what we read in the trade publications, the press already knew far more about the system than we lowly lab rats did.

After the AS/400 server's formal announcement things relaxed a little and having (I guess) proved myself on the S/36 and S/38 compilers I was asked to do some work on the COBOL/400 compiler. One of the first tasks I got involved with was checking the compiler and run time error messages. As part of automating the foreign language translation of the messages the English versions were being "sanitized" to get rid of words such as "execute" that caused translation problems. Some of the sanitized messages were funny, but the best we encountered was one where the term "Secondary card hopper" had been converted into the politically correct--but completely meaningless: "Not so important card hopper."

After 18 months on contract I joined the lab full time, but that's a story for another day.