Mainframe Development in an Eclipse World
In many ways mainframe development spent decades as a fossil trapped in amber. Wholly preserved in an inert environment. And, because ISPF was a monopoly, improvements in the process occurred at a glacial pace.
Those days are over. Mainframe development has busted out of the amber. As the lines blur between a mainframe developer and a Java developer–in many cases they are the same person–the same lines have to blur between development environments. This brings mainframe development into the Eclipse world. Eclipse is open source and exists within a very competitive universe, so it has continued to evolve features and capabilities unheard of in ISPF driven development.
Not that this isn’t without its own challenges. When we speak with Java developers the near-universal consensus is that they do all their work within Eclipse projects and often the source is retained right in their work space. However Mainframe development is very similar to the system of record applications it supports: the source is retained in one universally accepted place–on the mainframe. Mainframe developers are not comfortable with local versions of their source and most mainframe source control management products enforce the concept of a central repository. Maybe at some point the mainframe will embrace Git but that’s not today’s reality.
Further conversations with Java developers reveal that much of their work is done in the hierarchy views. Hierarchy provides a nice list, almost a to-do list, when doing refactoring or enhancement work.
So how can we bring the benefit of projects and the hierarchy view to the mainframe developer while still being consistent with the mainframe development model? We decided to introduce mainframe online projects so the mainframe developer can create a “virtual” project of programs that have a logical connection–and still have the code reside on the mainframe. This project could conceivably be an entire application, a subset of related programs from an application, or a set of support routines used across applications. Whatever makes sense to that developer.
Once created the developer can access mainframe specific hierarchy views related to their mainframe projects. These hierarchy views provide four critical lists that are the crux of any programming change, enabling the developer to know for a given program: what programs it calls; what programs call it; what copybooks it includes; and what other programs include a given copybook.
We believe that these four pieces of information, previously scattered and hard to get at, are the “North Star” of mainframe development and that mainframe developers, like their Java brethren, will begin to drive their development activities from the project hierarchy views.
Intrigued? Watch an example in action here.
Latest posts by James Liebert (see all)
- Failure Ain’t Nothing but a Learning Thing: An Agile Perspective - December 5, 2017
- DevOps and the Mainframe: The Ultimate Win-win - August 29, 2017
- How Do You Define DevOps? Six Interpretations to Help - June 29, 2017