IT and business management are increasingly concerned with the rising costs associated with their highly complex and ever-growing mainframe and distributed systems data centers. They are also concerned about controlling outages and mitigating the lack of transparency that they have into cost drivers—including in their outsourced environments.

It’s no secret that the dreaded “skills gap” is affecting the mainframe market. It’s getting harder and harder to find people who know COBOL or Assembler, and organizations that rely on these systems often have open job postings because there’s no perfect match for the positions they’re trying to fill. So what can companies and government agencies that rely on Big Iron do to foster the next generation of mainframers?

Anyone who has been working on mainframes for any length of time knows that things are always changing. Many people can remember when DB2 was new (1983), the client-server period, and the need for Service-Oriented Architecture (SOA). And, I’m sure, can come up with a much longer list. I don’t want to look backwards at old ideas, I want to take a whirlwind look at what’s coming soon to (at least) a presentation near you.

Mainframe IT professionals always get excited when IBM announces a new version of its stalwart mainframe z Systems platform. And on July 17, 2017 IBM announced its latest and greatest mainframe hardware, dubbed the IBM z14. Coming more than two years after the IBM z13, the previous major upgrade z System upgrade, IBM is bolstering the platform with a slew of useful new and improved capabilities.

Having worked ‘on The Mainframe’ for almost 20 years at a variety of clients and sites I’ve come about a number of taboos within the Mainframe ‘ecosystem’ that are sometimes just doing my head in and just need to be broken.

These taboos can be seen across the playing field and when I say across, I do mean across. Ranging from banks to insurance companies, from airlines to pension funds and from governmental institutions to ‘narrow-lane truck and heavy container warehouses’ and heard through the vox populi. Yes there are actually global warehouses running their stuff on The Mainframe (and for darn good reasons too!), but that’s maybe something for another blogpost…

People keep asking me why I am so excited about the Blockchain, and why I see it as an enabler for the mainframe. I am obviously a fan of the mainframe, and I see a lot of activity in a number of verticals that are creating a really neat rebirth where the mainframe is concerned (beyond where it has existed for many years). Retail is wrestling with Omnichannel, Healthcare is wrestling with personalized health records and of course Finance is wrestling with Blockchain.

Hopefully all System z users are aware of the Monthly Licence Charge (MLC) pricing mechanisms, where a recurring charge applies each month. This charge includes product usage rights and IBM product support. If only it was that simple! We then encounter the “Alphabet Soup” of acronyms, related to the various and arguably too numerous MLC pricing mechanism options. Some might say that 13 is an unlucky number and in this case, a System z pricing specialist would need to know and understand each of the 13 pricing mechanisms in depth, safeguarding the lowest software pricing for their organization! Perhaps we could apply the unlucky word to such a resource. In alphabetical order, the 13 MLC pricing options are AWLC, AEWLC, CMLC, EWLC, MWLC, MzNALC, PSLC, SALC, S/390 Usage Pricing, ULC, WLC, zELC and zNALC! These mechanisms are commercial considerations, but what about the technical perspective?

The traditional 3270 mainframe development environment deserves respect. It has enabled developers to create and support some of the world’s most enduring business-critical software applications running on ‘Big Iron’ boxes around the word. Many of these core systems continue to deliver today for banks, government departments and large enterprises, decades after they first went live.

I was working recently with a mixed bag of people from a company, who were trying to predict the future and see how that company needed to change in order to get where they thought they ought to be going. One issue came up fairly quickly, and that was that 2020 isn’t that far ahead. As a result, the group started to think about 2025 as date for the changes to be made. The room had a mixture of IT people, execs, a variety of managers, and a number of people from different parts of the organization. I thought it would be interesting to contemplate some of the ideas that came up at the session.