Evangelizing Mainframe
Print Email

When to Sunset Your Green Screen Mainframe Development Environment

We all know there is an aging demographic in the mainframe world as experienced staff from the ’70s and ’80s start to retire, leaving companies struggling to find suitable replacements. This creates a future business risk, and is prompting organizations to consider sunsetting their traditional 3270 development environment in exchange for something more modern.

Mainframe Expertise is Essential


I’m tired of hearing mainframe applications described as legacy. Consider this fact, reported by IBM: 80 percent of the world’s corporate data resides on zEnterprise servers. Or, to put it another way: Vast numbers of organizations around the globe have core business applications running on the mainframe and will need to find a way to quickly and easily maintain and enhance them well into the future. That includes delivering new functionality for modern environments, such as Web and mobile user interfaces.

Modernizing mainframe development makes it easier for the new generation of IT staff to support mainframe applications. Today’s IT professionals want a contempory development environment that is easy to use and quick to learn while helping them to maximize their productivity. They are used to working with the programming languages that are taught in universities, such as C, C++ and Java, and intuititive development environments like the Eclipse IDE.

To their eyes, a green screen looks like something out of the Dark Ages. I showed a 3270 interface to one 20-something who could hardly believe it was actually still being used and promptly shared it on Facebook with his friends.

So how do we get this new breed of IT professionals to engage and be comfortable with the mainframe environment? And how do we increase productivity for new recruits and experienced programmers alike?

Open-Source Solutions

One approach that I have seen working well is to create a more modern, intuitive mainframe development environment, based around Eclipse and open source. Why Eclipse? Because it is a powerful development environment that is free and is fast becoming the standard for Java development. It is widely taught and used in universities so the younger generation are familiar with it.

In addition to Eclipse, there are many free open-source tools you can use, including source management systems, task process engines, schedulers and application lifecycle management systems, all with Eclipse interfaces.

Obviously, there are various tools and products available, some free, some chargeable. If you are planning to modernize, you will need to decide which software is most suitable for your circumstances, taking account of factors such as the level of existing internal experience with the products you are considering.

The important criteria for selecting products should be: Are they modern, easy to use, intuitive, industrywide solutions? And would they attract new recruits and look good on their CVs?

The Benefits

Migrating away from a 3270-based development environment toward an open-source solution can make it easier to attract recruits; you can promote the fact that you are using industry-standard software that will be familiar to them. You are likely to find it quicker and easier to train new recruits and to cross-train existing staff to work on new applications. Added to this there is a benefit for colleagues who support multiple applications because they are able to use the same consistent process across the board.

Because some of the tools you use will be open source and free of charge, it can help to bring down your software development costs.

Five Tips for Success

Having recently gone through the process of modernizing a mainframe development environment, I want to share five tips that will be useful if you are considering doing the same:

  1. Get your non-mainframe personnel involved. Open systems developers will likely have experience of using the new developer tools that you are considering, and can provide useful advice.
  2. It is a big cultural change, so make sure you involve all the key stakeholders. Ensure that they buy into the benefits of adopting the new approach before you start rolling it out.
  3. Start slow and small. Take one application at a time and then learn and extend. We created a matrix to help us prioritize, taking into account the value of the application to the business, application knowledge within the company, the complexity of the current application development environment and its risks going forward. Of course your matrix will be different.
  4. Choose carefully when to move to the new approach, ideally between releases.
  5. Involve other departments (security, procurement and business process teams, etc.), not just your developers. Other departments will need to know what you are doing and how it will affect their decisions in the future. For example, if you switch to Open Source software, you may want to cancel some of your existing software licenses.

The process of moving may take time, but the gains can far outweigh the pains.

Keith Banham has worked in IT for more than 30 years and is the R&D manager at Macro 4, responsible for the company's mainframe suite of products. Keith started as an Assembler programmer at a major bank and during his 28 years at Macro 4 has worked on many of the company’s solutions for application lifecycle management, application performance management, document management and session management. Part of his current role is the modernization of these solutions by building Web, Eclipse and mobile interfaces, as well as the modernization of Macro 4’s internal mainframe development environments.


Posted: 12/9/2014 4:34:55 AM by Keith Banham

Print Email

Join Now!