Mainframe Modernization: Transitioning to GUI
[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”] Mainframe debugger built on Eclipse Debug Framework. Example shows COBOL; PL/I, IBM C Language®, and HLASM also supported.
Over the past decade, more and more companies have begun to adopt standardized software development tools across multiple languages and platforms within the enterprise. Among the reasons for the adoption rate, graphical development environments have matured over the past couple of decades, enabling programmers to be more productive. Intuitive and standardized interfaces mean less training and quicker adoption. Also, many mainframe developers are close to retiring, and the new generation set to fill their ranks won’t have TSO/ISPF skills, and will probably not want to acquire them.
From a mainframe perspective, this means the long legacy of 3270 character based tooling will slowly turn and head for the sunset.
Having worked with numerous shops on modernizing their mainframe development environment, I’ve seen some be more successful in their rollout than others, so I’d like to share some tips and techniques.
Increase screen real estate — two (or more) monitors
People, developers included, like to get the most amount of work accomplished with the minimum amount of effort. The current trends of GUI development environments and cheap flat screen panels means that developers can now have the tasks (views) that they do most frequently, open and available all of the time. No more searching through your system tray for an active window to restore, it can simply be accessed by going to a different window.
If you haven’t increased your development screen real estate already, understand that it’s vital to a successful deployment of a new, modernized mainframe development environment. No one is going to stop using TSO/ISPF one day, and completely switch over to a new GUI environment the next. So make sure developers have at least enough screen real estate to have both a 3270 emulator and a GUI IDE active simultaneously. Simply put, more is better here.
A good example of developers naturally choosing the easiest, quickest environment to accomplish a task in is the ability to drag and drop PDS members from one PDS to another in a GUI. It’s simple, and intuitive, and far quicker than the multiple ISPF panels you’d otherwise have to navigate. Once you’ve done a PDS drag and drop, you’re unlikely to go back. That would be, simply put; unproductive.
Transitioning to a new development environment is a lot easier, and a lot less frustrating, if you can easily ask someone questions about usability and functionality. I’ve seen sites designate a full time product administrator while others designate lead sponsors in every development team. Whatever works best in your shop. These contacts should be enthusiastic and creative, evangelists essentially. Along with helping with the “how to’s,” they often wind up setting up sharable profiles, debug configurations, and other community resources that ease and speed the transition.
Here’s a great way to leverage social media. By setting up mechanisms where developers can discuss their issues with colleagues accelerates the learning process and speeds adoption of newer technologies. And there’s a cross mentoring effect that comes into play here. Veteran mainframe developers can help the new generation of mainframers with their platform and application specific expertise, and the new generation can help the veterans with their in-depth knowledge of graphical IDE functionality.
Regularly scheduled internal online meeting
One of our larger customers is rolling out a modernized mainframe GUI development environment to some 300 internal developers and 300 external contractors dispersed all around the U.S. To help in their rollout, every other week they have a one hour “lunch and learn,” with an online webcast where they can do demos/presentations. They cover issues that have been submitted to their blog (as per above), along with any other questions or comments that people want to share. It’s very successful, with an average attendance of seventy-something participants. They also invite vendors to present as well. We at Compuware have been asked to demo some of our product functionality during these sessions, which brings us to our last tip…
Regularly scheduled vendor interaction
Transitioning your mainframe development environment from TSO/ISPF to a modernized graphical IDE is a significant journey, and varies for every shop depending on how they’ve configured and equipped their TSO/ISPF environment over the past few decades. And, with past predicting future, just about every shop will take a unique approach to their mainframe development modernization, and buy, build, configure a new environment that best meets their particular needs.
Include your vendor(s) in this journey. It’s new territory for them as well, and they’re also seeing, as per this blog, other companies on similar journeys, and can share success factors with you. Both parties will benefit when there’s a continuous discussion of progress and challenges along the way.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]
Latest posts by Tyler Allman (see all)
- The New Challenge of Running IMS Applications - January 19, 2017
- Compuware’s Topaz Workbench Bridges Mainframe Generations - March 3, 2016
- Mainframe Modernization: Transitioning to GUI - May 22, 2013