Total Pageviews

Tuesday, March 19, 2013

Language Barrier

Given all the recent press coverage of IBM's latest set of annual financial results and the prominence of the mainframe within these, figures the analyst coverage over the last couple of months around System z seems to be have in the main positive.  I have even had good feedback from a Enterprise Data Architect at a first meeting, following his recent attendance at a Gartner event. So against this largely recent positive backdrop I would like to focus on what I see as one of the barriers to the 'mainframe going mainstream' namely the language barrier.

What do I mean by the 'language barrier'?  Well as former colleague put it very succinctly when describing this issue - "we worship different gods and speak in different tongues" when we describe the characteristics of the mainframe than our distributed brethren.  Let me give you a few examples to illustrate my meaning:

OSA Cards Vs NIC
Now I am not going to attest to be a techie or a former hardware engineer, but why oh why do us z guys have to come up with a completely different TLA (Three Letter Acronym) for a network connector, namely an Open Systems Adapter when the whole industry called them Network Interface Controllers.  Check out IBM's very own website:

The first sentance for me completely encapsulates the issue I am discussing in this post:

Although the OSA card is the only NIC for z/OS, this is a bit of an understatement. The OSA card variants support Ethernet in all of its current implementations.

 If the OSA card is the only NIC for z/OS then call it a NIC and address the following issues which get replayed back to every mainframe advocate when they engage with senior IT management:

  • Mainframe skills are in short supply
  • Training people on the mainframe is time consuming and expensive
  • Re-skilling existing staff will take too long

Now I fully appreciate to take a Windows admin and retrain him/her to be a Sys Prog will never be a 2-day training course, and rightfully so, do we really need to make it so hard?  At the end of the day the mainframe is only another server that connects to storage and a network?  If we want to make the mainframe mainstream again and attract the Gen Y'ers to the platform then we need to focus not only on GUI interfaces as is so often the discussion point, but make the underlying hardware concepts in-line at least in language terms with the rest of the industry. 

Take for example the area of storage, us mainframers talk ECKD and DASD when the whole rest of the industry talks SAN.  Now I am not going to open the debate here about what is better FICON, ESCON etc... but I raise it just to highlight that in every large shop I go to there is a mainframe storage team and distributed storage team, why? If as I say the mainframe is only a server (bear with me) then to have a separate storage team to administer it, can only be seen by the CIO as reinforcing any perceptions they may have (however correct or not) that the mainframe is expensive.

What am I proposing as the answer?
Well IBM can look through the lexicon of the mainframe and when it launches a new model (the z114 replacement for example) and take the bold step of proposing a Language Harmonization Program or LHP to bring in line mainframe terms with distributed terms.  If IBM changes what it calls the components of the box and the various interfaces the whole industry will come on board and within 3-years gone will be esoteric 'z-only' phrases and the mainframe again will have moved closer to becoming mainstream...

Feel free to comment here  for other LHP suggestions or raise them at the next #mainframedebate on the 8th April at 4-5pm GMT | 11-12pm EST. Or as always please don't hesitate to get in touch directly via my Twitter account @StevenDickens3


  1. Agreed!

    I still remember feeling as if a curtain had been opened when it dawned on me that the underlying computer science behind the mainframe is just the same as that which underpins every other computing system. You may give them different names but you still have processes, threads, heaps, stacks, mutual exclusion, shells and all the other things we take for granted in the distributed world.

    Of course, there *are* differences and it's important that these are understood but the core computer science is the same...

    Ever thought of pulling together a "what mainframe/distributed people mean when they say..." charts that compares/contrasts?

    e.g. what is the mainframe word for processes? threads? do you distinguish between stacks and heaps when reasoning about memory usage, etc?

    1. I will raise with our marketing team because if the mainframe is going to become mainstream again this the language barrier need to be removed. Thanks for the comment...