In the beginning, you had to meticulously write out your assembly language computer program - instruction by instruction - and then flip switches to enter it into the computer. Fast forward a few years and FORTRAN made its entrance. It was highly useful, but not for business applications. A bit later, COBOL came along, and the business folks were off and running. With this miracle-language, they could design records that all looked alike so that they could be fed through a simple sieve and processed at the blazing speed of the day. The software wouldn't need to handle special cases because every record would be exactly the same.

Although many other languages came along in the 1970's and beyond, at Catastrophic Automation Inc., H. P. observed that everyone knew that COBOL was the only real choice for developing enterprise-class software.

It was solid engineering in the seventies, and when you get down to it, not much has changed since then.

This is because COBOL was based on the only data structure anyone would ever need: the fixed width record. Every client record with everything it entailed, consisted of exactly 2000 EBCDIC characters, as was decided long ago. The first 40 bytes were the client first name, the next 30 the last name, etc. This structure had survived in-tact through the 80's and 90's because, if we're to be honest, nobody really needs those accents in their name, and it's not like there would ever be a need to store any additional information, right?

Around the year 2000, a new technology had made its way into the mainstream, and it created an issue that needed working around. You see, those new-fangled e-mail addresses had to be stored somewhere too. A decision was made by the COBOL data analysts: email addresses could have at most 50 characters (EBCDIC only). Any email address that was longer than 50 characters would be arbitrarily truncated.

Now this might seem a bit harsh, but realistically, the company had trained the Postal Service to figure out and deliver mail with truncated street addresses many years ago. Eventually, the Postal Service simply gave up trying to get people to put the whole address on the envelope, and simply accepted cut-off street addresses; the computers couldn't process them, but humans looking at the parcel could figure it out and get them to their proper destination. Those modern-day internet postmasters would just have to accept the realities of enterprise class software and be taught to deal with truncated email addresses in the same way.

Even so, customers were annoyed and users were grumbling. Worse, around 2010 the last Visual Basic and Delphi programmers were finally converted to C#. As a consequence of this, management felt that the time was ripe for a bold new initiative: a happy marriage had to be forged between the C#-ies, the Javans, and the COBOLists. The strategy was simple: since the Javans and C#-ies had web services, the COBOLists would have web services too. Only the latest technologies and methodologies would be used. After all, if you're going to modernize, you may as well go all-in and do it properly!

The COBOList data analysts were highly confident in their abilities to take on this new mission. After all, they were trained professionals with decades of experience designing large scale COBOL systems; how hard could it be to design web services? Input from the other analysis teams was not required, because the COBOList data analysts told management that they could easily handle it.

About a month later, the first iteration of the first cross-platform COBOL web service specification was handed to a C#-ie. Henceforth, every web service would be created with the following pattern: each supported operation would have one string as input and return one string. Both strings would be exactly 2000 characters long - in EBCDIC. The first 40 characters of the input string would be the client first name, the next 30 the client last name, ...