I spent 27 years at IBM in the Db2 for z/OS Development and Service organization, starting in 1989, when Db2 was already established but not yet the dominant data base leader that it would soon become and continues to be.
To be a software engineer there during those years was both fun and challenging, and along with all the great people I worked with, I was motivated by the fact that what we were doing was really important.
Interestingly, when I reflect on what I consider to be my topmost personal contributions at IBM, most of them are not technical in nature. I’d like to share one such story. I acknowledge it is very self-serving, but I also believe it speaks to why IBM and Db2 are special. And importantly, for anyone hoping to jump into the mainframe world or seek out a job in that space, it is a concrete example of why there is always more to programming than writing code.
In the early-to-mid 1990s, IBM had started doubling down on its decision to make Db2 for z/OS a flagship product for the company, and increased investments in its development in order to elevate its status and solidify it as an indispensable, world-class product.
Of particular focus at that time was the area known as utilities. Db2’s utilities had come to be viewed as a bit lackluster due to staffing issues and some semi-related goings-on throughout what was then called the Santa Teresa Lab.
Along with plenty of other initiatives, work was underway on a brand new utility which could make a backup image copy of Db2 data from an existing image copy, without the need to read or access live data at all. We know this utility today as COPYTOCOPY, as it takes a copy as input, and produces another copy as output.
At that time I was a Level 3 programmer, meaning I fixed bugs reported by customers after the code was shipped and externally available. One of the challenges of that job was that Level 3 staff typically had limited insight into the design and development of any new version of Db2 prior to release, making debugging and fixing code quite difficult once it was in the field.
Recognizing this, management started a pilot program in which Level 3 staff would be invited to design meetings and updated on implementation plans. Further, we were encouraged not just to learn what was coming earlier in the cycle, but to offer feedback based on what we had seen about pain points in the code, real-world usage, etc.
Once this initiative was announced, one of the first such meetings I attended was with the team working on the yet-to-be-announced COPYTOCOPY. At this point, however, work had been underway for a couple of years, and was already nearing completion. Most of the coding was finished, much of the external documentation was written and already under review by the technical writers, and there was not a lot of decision-making left to be done.
Frankly, I understood very little of it that day and just tried to listen and absorb as much as I could, because pretty soon I would be responsible for servicing this new utility.
But I did have what seemed like an important question. In all the written material I had seen in this meeting, the new utility was called COPY2COPY. Instead of “TO” in the middle, it was the number 2.
I asked if this utility was going to be permanently named COPY2COPY.
It was, I was told.
“Why?” I asked. “Is it because the number two, when spoken, sounds like the word ‘to’?”
Indeed, that was the reason.
Apparently, in the early prototyping work, some developers got into the habit of naming variables and control block fields this way as a sort of shorthand, perhaps saving a keystroke or for some other internal reason. Soon, the utility name itself adopted this convention, and now it was about to be externalized to the world this way.
“I think you should change it,” I said rather plainly. “I don’t think it’s a good name.”
“What?!” All eyes were upon me now, casting looks of incredulity mixed with faint disdain.
“I think it should be called COPYTOCOPY.”
It was a bold statement, and I knew it. Here I was, a junior employee, who some in that room barely knew, waltzing in at the last moment and suggesting something that would involve a lot of painful work by many people, and absolutely none of it by me. I had essentially lobbed a grenade into the room from a safe distance.
“Why? What difference would it make?”
It is important to note here that to IBM’s everlasting credit, they were willing to listen to my reasoning.
“We all know we have been tasked with catapulting Db2 into the worldwide leader in this space, right? There is a big utilities push behind this too. In fact, this new utility we’re all talking about is part of that overall strategy, right?”
“Yes, of course.”
“Well, doesn’t a big part of all this include being a leader internationally too? We want Db2 to be the leader in every country, not just in the United States. I assume that’s part of the plan, isn’t it?”
“Yes, but it’s already done. Why is it so important?”
“I know it’s not up to me.” I continued. “All I can do is offer my feedback, which is supposed to be why I’m in this meeting, and then you make the decision. And my feedback is that it wouldn’t look good for an international corporation, trying to make inroads in international markets, to ship anything whose name has a gimmick that only makes sense in countries where English is spoken.”
The meeting broke up shortly after that, without further discussion or any decision being made.
I learned later that someone in that meeting who wasn’t particularly keen on adopting my suggestion nevertheless felt my argument was compelling enough to bring it forward. Again, kudos are warranted to the longstanding culture at IBM, which allowed my comments to be taken more seriously than they likely would have elsewhere. The topic was raised to the senior architect in charge of the product area and who was a key figure in Db2’s overall growth strategy. Ultimately, he concluded that the change should be made, no matter how painful.
Db2 for z/OS eventually became a billion dollar product for IBM, and for a time represented 10 per cent of the worldwide bottom line profit of the entire company.
No one knows how much of that success is attributable to the spelling of the name of one utility. But one of the great virtues of IBM has always been its ability to make good decisions which are mostly free of petty personal squabbles, unhealthy power struggles, or artificial credibility hierarchies, in order to remain professional, serious, and relevant.
I’m happy and proud to have played a contributing role. In this case, without writing a single line of code.
David Herlich is a retired Mainframe Software Engineer and SME, who spent the majority of his 33-year career at IBM, where he was a Db2 for z/OS developer and evangelist for the platform. He earned his degree in Computer Science and Mathematics from the University of California, Davis, along with a double-minor in Communications and Psychology. He now runs TheSportsTutor.com, a Silicon Valley-based sports counseling service for children and families.