Five Things Mainframe Developers Should Know About Open-Systems Development
Five Things Mainframe Developers Should Know About Open-Systems Development
As more apps engage mainframes, IT organizations must move to more integrated, cross-platform DevOps models that enable mainframe/open-systems teams to develop side-by-side.
Join the DZone community and get the full member experience.Join For Free
In response to accelerated release cycles, a new set of testing capabilities is now required to deliver quality at speed. This is why there is a shake-up in the testing tools landscape—and a new leader has emerged in the just released Gartner Magic Quadrant for Software Test Automation.
As applications span more platforms, the days of open-systems and mainframe developers sitting in silos on opposite ends of the office are coming to an end. Enterprises need their developers to understand concepts and code tied to both front-end and back-end systems.
So, what should these developers learn about each other? A multitude of stark technical and terminological differences exist between the two computing worlds, for lack of a better word, but in this two-part series, we’ll just focus on a few high-level concepts.
Go here to read what open-systems developers should know about the mainframe. In this post, we’ll explore five things mainframe developers should know about open-systems development.
1. Open-Systems Developers Wear Many Hats
Greenfield development is easier in open-systems than on the mainframe, in part, because there are more examples of how to do things, places to get help and thousands of snippets of code available online and in open source libraries via Stack Overflow and GitHub.
2. Open-Systems Development Is Open and Lightweight
Open-systems developers tend to have a lighter-weight development process than mainframe developers. In some cases, open-systems teams have spent a decade refactoring their code to be more modular and thus easier to change in small increments. These applications are usually composed of hundreds or thousands of files that are always compiled and run together, and you don’t need JCL to run them.
Generally, access and control are more open than in mainframe development. Developers have easy pre-built access to modern runtimes and can access their development environments from anywhere at any time.
REST-enabled applications with well-defined APIs are standard in open-systems development because REST APIs easily evolve over time and many platforms have a plugin architecture with plugins for just about anything you can imagine.
Typical distributed applications have multiple tiers that divide the applications into logical chunks. Many have a user interface on the web tier, a business-logic tier to handle transaction work and a data tier using a DBMS like DB2. The business-logic tier may use J2EE/JEE to handle transactions rather than the CICS and IMS transaction managers you would use on the mainframe.
Developers usually have the ability to fully compile and run a copy of the application locally on the desktop environment without a need to worry about what other developers are doing. After completing work in their local environment, automation is typically used to move the application into shared testing and production environments.
3. Open-Systems Development Is Big on Performance
Most distributed applications tend to be online, so open-systems developers don’t have to deal with batch-processing windows, making it easier to focus on 1) making their programs multi-threaded to take advantage of the many CPUs available on modern servers and 2) achieving good application performance—not to say mainframe developers don’t worry about performance, too.
Multithreaded applications simultaneously run two or more program threads that access the same memory space. These threads are, therefore, lighter-weight than one thread trying to accomplish multiple things. Multithreading reduces idle time and maximizes CPU time, improves application response time, and improves the adaptability of an application.
Multithreading isn’t exclusive to open-systems computing, but it’s done differently than on the mainframe, where the COBOL run-time itself doesn’t support multithread execution and it’s not possible to have a “pure” COBOL multithreaded application. Instead, individual COBOL programs compiled with THREAD can be run multithreaded, but they need some help. IBM Enterprise COBOL for z/OS, V6.1 Programmer’s Guide suggests an application server, C/C++ drivers, Java threads and PL/I tasking are all ways to invoke the THREAD-compiled COBOL programs to accomplish this.
As more web and mobile applications access the mainframe, open-systems and mainframe developers must think about how their applications impact each other, rather than focus solely on how their applications perform. Mainframe applications need to perform well for web and mobile applications to perform well.
4. Automation and Orchestration Are the Expected Norms of Open-Systems Development
Though more modernization is coming to the mainframe in the form of cloud-integrations, IDEs, automation, visualization, APIs and more, manual processes and outdated tools are still staples and hindrances to agility in that space. This is in stark contrast to the agile, automation-fueled world of open-systems development.
Open-systems developers run development from cloud- and web-based IDEs and typically expect to do daily integration builds. They use open source and software stacks with several integrations with various tools to innovate rapidly. Use of automated unit testing is commonly part of the development process.
Automated builds and pipeline management make it possible to push up to hundreds of builds per day, and, vice versa, instantaneous rollbacks with self-healing remediation properties are becoming more prevalent.
Through automated infrastructure orchestration with built-in monitoring and analytics, open-systems developers can focus on development as well as see how an application is being used and how often, rather than spending time supporting infrastructure.
Even communication and collaboration are being improved through automation under things like ChatOps that connect people, bots, and tools.
Finally, more open-systems teams are spending less time waiting on resources by leveraging the cloud. They only have to pay for the seconds their applications run, and it’s easy to lift and shift applications to any platform at any time.
Developers get easy and instant access to pre-built frameworks in the cloud like AWS Amazon machine images/instances and any major software provider, installed perfectly and ready in minutes.
5. Open-Systems Developers Were Early Adopters of DevOps
Whereas most mainframe teams are just beginning to entertain DevOps, and many more are still in the process of convincing stakeholders to transition, most open-systems teams were early adopters of the philosophy and have been practicing it for years.
Open-systems teams are DevOps focused. Development and Operations collaborate seamlessly and transparently in de-siloed processes and integrated toolchains. They stay in close communication, from planning to deployment. They are nimble in decision-making and pivoting away from or toward ideas based on feedback. They fail fast and continuously learn from mistakes. They use what they learn to continuously innovate.
The days of mainframe and open-systems developers existing apart from one another are quickly coming to an end. As more web and mobile activity engages the mainframe, IT organizations must transition to more integrated, cross-platform DevOps models that enable mainframe and open-systems teams to collaborate and develop side-by-side. Watch the webcasts below to learn how.
Published at DZone with permission of Steven Kansa , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.