Sometimes, old-time mainframers get together and talk about the good old days. I was there; those days weren’t so good. I started out in college learning to be very proficient with a key punch machine; I was ecstatic when I was able to get access to an IBM^® 3270 and enter my code and have it stored on disk. It was the first example I had of not accepting the status quo and being open to new technologies that would make my job easier. Over time I have been open to the many improvements in the developer experience.

With that, I can say that I feel that today is the golden age for the mainframe. This is the best time to be a developer working on mainframe applications. Here are some of the areas in which today’s mainframe outshines “the good old days.”

• Communications—The ability to access systems and work remotely is a huge improvement over the way we used to have to drive into an office to fix errors, then wait while they were confirmed. We may think that our always-on culture is disruptive, and it can be, but contrast that with having to stop what you are enjoying and drive to the office for an unknown amount of time. Working on the mainframe means you are working on a critical system, so there will always be disruptions; the difference is that now there are far fewer. It has also enabled “work from home,” which used to be impossible, or at least very difficult. We can now work from anywhere.
• A choice of interfaces—In addition to the “classic” Interactive System Productivity Facility (ISPF), there are also now Eclipse and Virtual Studio (VS) Code solutions, among others. The ability to have multiple displays on multiple monitors and not have to remember keywords makes it so much easier to work. Sure, you could, over time, be proficient in ISPF, but that’s it—it took time, and developers should not have to go through an initiation process to be productive. It’s much better to start out day one with a modern, familiar interface that is easily upgraded and configured.
• New perspectives—I learned from those who came before me, and many of them insisted things were “better than before,” and, in fact, “just perfect.” There was a tendency to not change because change was risky. Now, with new developers coming to mainframe development, we see that things have changed, there are new ideas. I think some of these ideas were there before, but because of limitations in technology, they couldn’t be implemented. Now, with a fresh look, we are seeing that the ideas were sound, and the technology has caught up so we can implement them. Where these ideas and practices were previously discarded because we looked at them and they wouldn’t work, we are now benefiting from them. It is great to have this new perspective to spur us on to greater improvements.
• Automation, and automation of automation—Automation is a good concept, but it has been the victim of what I mentioned above. We either tried it and it never worked, or we implemented it with a complex process and don’t really want to touch it because it is fragile. Now is the time to reevaluate and benefit from new technologies. I know that when I look at what is available with webhooks and REST APIs, I am amazed at the possibilities. It is so much easier to set up automation now than it was in the past. Where I might have given up previously, I am now eagerly looking to new automations, putting something into place and then a few months later, adding to it.

This also applies to automating your automation. By this, I mean that you may have already automated test scripts. If so, great! But if you don’t automate them, the alerts, and, really, the whole process, then you are missing out on some great benefits. In short, look at everything—including code reviews—and see if there is some way that manual tasks can be automated and supplemented.

• Graphical displays—Going from a card deck to seeing the code on a 24×80 display was a huge advancement. I worked in that box for, well, a long time, before graphical displays became possible. Having my program charted out—automatically—was a game-changer. I am a visual learner and to see my program—and the connections of my program with others—right there on my monitor was amazing. My days of “playing computer” or interactively debugging for analysis were over. I could see the structure of the program, drill down into a paragraph, and see the flow of data, of the field from where it entered, how it was processed, and then left to another program, file, or database. This graphical display meant I could take on any new program, understanding it quickly, and have confidence in my changes. It was an instant improvement in productivity.
• Agile scrum—I was taught to write new programs in a modularized way—stub out sections, test, then fill in the logic. This was a good practice I followed and was a way to catch errors early. However, this was done for multi-month waterfall projects. We didn’t take the best practice and move it to the next level. The game changer came when we were able to implement a source code management (SCM) solution, BMC Compuware ISPW (now BMC AMI Code Pipeline), which enabled multiple developers to work on code at the same time. That helped us keep track of versions and enabled an Agile scrum framework for mainframe development, which delivered huge increases in productivity and quality. I’ve found that taking an open approach with our SCM and build and deploy, through the use APIs and webhooks, ensures that development teams can continuously improve their agility.
• Code coverage—I remember when testing was guesswork and sometimes bluffing. You ran your new code through as much data as you could find with the assumption that it should hit your changes, then you could verify they were right and that you didn’t break anything. But that was just it, you had to assume, and that is where the bluffing came in for a code review. The testing took a lot of time to run and was not very effective. Code coverage provided proof that the lines I changed were tested. No more guesswork, no more bluffing. It also meant that I could test with much less data than I had been using, so I could test sooner and more often. I could save the massive datasets for final testing.

I am more excited about mainframe development than I have ever been—I envy developers today with everything they have available. The applications they will be able to envision, the connections, and the things they will be able to accomplish to keep the mainframe going in the decades to come will be amazing. All of this will be done faster and with much greater quality than we could have ever imagined back in the slow old days. These are truly the good new days for the mainframe, and I am glad I had a small part in building it.

Keeping mainframe development moving at the speed required by the business can be a challenge. Many monolithic applications, developed and added onto over the course of years, or even decades, are self-contained. As software development and delivery become more modernized with automation and orchestration, the cost of leaving these applications alone is growing more expensive than breaking them apart and connecting them to macro and microservices. In a time of doing more with less, many leaders are taking a second look at their root mainframe problems and seeking ways to generate value faster.

It’s not COBOL, it’s what has been done with it

The size of COBOL programs is often cited as a barrier to accelerating the release velocity of mainframe applications. COBOL’s functionality as a programming language is why it has remained the same for half a century. It’s not the language, but its implementation that is the real problem. With numerous functions housed in one program, it becomes difficult for developers to understand, edit, and compile legacy code and then test their changes. Even if they change only a few lines, they need to check out the entire program and test it, then fix anything that breaks along the way.

Figure 1.  Why maintaining COBOL applications is a development nightmare.

Transforming the mainframe as a growth platform

Whether they’re trying to unlock value of mainframe data, grow artificial intelligence for IT operations (AIOps), or enforce compliance and increase digital agility, enterprises see the mainframe as a growth platform. Most enterprises that embark on modernization journeys discover that they can’t offload 20 percent of the mainframe’s workloads to other platforms. But that doesn’t mean they aren’t optimizing the developer experience and making it easier for multiple developers to work concurrently on the mainframe. One big step forward is providing the tools to help developers break apart monoliths into separate, callable subprograms that are easier to understand, update, and test. This enables new functionality to be infused onto mainframes and prepares the way for Java- and Git-based source code management (SCM) so multiple developers can work on the same application. Being able to track a data field through the program from input to output and visualize static and dynamic interoperability, along with dependencies, logic, and syntax, helps developers understand monolithic application functions and circumvent problems, giving them more confidence in their changes and making development teams faster and more agile.

Figure 2.  What if monoliths could be refactored into separate callable components? They can be.

Long-term modernization, immediate value

Modernization itself isn’t fast, but there’s no real reason to stay stuck with the status quo. Developers want to build on growing solutions, and the sooner enterprises transform monoliths into functional modern applications, the sooner they can curb development costs by enabling more developers to work on the mainframe. Having a diagnostic tool that can scan and visualize an application’s underpinnings is critical when there are literally millions of lines of code. Seeing how an application really works in real time with runtime visualization can show developers where the problems are before they break the application.

Being able to find and comment out dead code that cannot be logically executed, no matter which data you use, eliminates a lot of technical debt as developers refactor modern applications that leverage REST APIs, Git, or Java. A lot of blame is pointed at COBOL, but even COBOL applications can still deliver value as teams undergo long-term modernizations and digital transformations.

BMC AMI DevX Code Insights (formerly BMC AMI DevX Code Analysis), available nowprovides the functionality to help developers uncover business logic and create new subprograms that are ready to compile and use. It is already accelerating the transformation of monolithic code into more modular and usable programs.

BMC AMI DevX Code Insights also gives developers the ability to identify and comment out dead code. The new Quick Fix capability, available with a right-click on the diagnostic or the identified line, will comment these lines, which prevents any future developers working on the code from wasting time by assuming those lines are valid.

Figure 3. The new Quick Fix capability can be used to comment lines for developers.

BMC AMI DevX Code Insights is designed to help developers maintain and extend their applications with confidence by enabling them to:

• Quickly understand unfamiliar code with structure and logic charts
• Track data fields through the program from input to output
• Break apart monolithic programs using Code Extract
• Gain information on how an application really works in real time with runtime visualization

Let’s not underestimate how hard COBOL development can be. It is difficult to quickly understand, make changes with confidence, and then test. Eliminating dead code—and, more importantly, breaking apart programs to manageable sizes with modern syntax—will empower mainframe application developers to deliver quality code, faster.

Listen to the Modern Mainframe podcast, “Refactoring Monolithic Mainframe Code,” to hear how IT leaders are thinking about modernizing mainframe code and the tactics they’re using.

Many of us have experienced the phenomenon: New code reaches production and abends, then abends again and again. Multiple users could each be attempting the same abending transaction on their mobile phones over and over, or automated processes could be reattempting after each failure. These scenarios could create a runaway abend situation that negatively impacts performance and availability. A bug in one application could have effects that spread throughout your system, causing headaches for engineers and negative experiences for your customers. So, how can you shave minutes off of your response time and limit the impact?

BMC AMI DevX Abend-AID recently introduced a new option to help improve webhook notifications. Abend-AID will keep a running count of repeatedly occurring identical abends, allowing you to set thresholds—100, 1000, or maybe even just 10 times, and notifying you once this threshold has been reached so you can respond.

So, with runaway notifications solved, what can be done to resolve the underlying issue? This is where BMC AMI Ops Automation comes in. BMC AMI Ops Automation can be configured to react to abend notifications, triggering an event and driving an automation rule to take an in-context action based on the information provided in the notification.

Some examples of these automated actions include:

• Canceling the job
• Generating an alert
• Gathering additional diagnostic data
• Emailing developers so they can analyze the situation and provide a solution
• Opening an incident ticket
• Running an EXEC to perform custom automation

Applications running on the mainframe can be accessed by many concurrent users, and defects can spiral out of control unless you receive immediate notifications with automation ready to respond. BMC AMI DevX Abend-AID and BMC AMI Ops Automation deliver these capabilities to support you and your customers. For more information, visit our BMC Community post.

Moving established mainframe development processes to DevOps can seem like a daunting task. Automation helps free developers from performing manual tasks and gain faster delivery while improving quality, but how can this be adopted at scale?

Often, Jenkins is used to build a pipeline from a base framework of webhooks and APIs, but alternatives such as GitHub Actions and Azure DevOps extensions have arrived.

Fortunately, each of these options can make implementation much easier than expected. I think of them as templates you can use that provide the functionality of an API, but without the need for the related coding. Each solution has its own name for these templates: Jenkins Plugins, GitHub Actions, and Azure DevOps Extensions. We at BMC are committed to your DevOps success and offer the following extensions to assist you in building your mainframe DevOps pipelines.

BMC AMI DevX Total Test

• Azure DevOps extension for DevX for Total Test enables users to run automated test scenarios and test suites.
• GitHub Total Test Action allows users to run test scenarios and test suites using a GitHub Action.

BMC AMI DevX Code Pipeline

• Azure DevOps Code Pipeline​ Source Code Downloader Extension enables users to download BMC AMI DevX Code Pipeline members from the mainframe to the PC. Source code can then be accessed on the PC, for example, for SonarQube analysis and reporting.
• Azure DevOps Code Pipeline​Operations Extension allows developers in Azure to execute Code Pipeline ​operations, such as Generate, Promote, Deploy, or Regress on the mainframe. Developers can also seamlessly integrate their Code Pipeline​ build process in Azure DevOps.

BMC AMI DevX Workbench for Eclipse

• Azure DevOps Topaz Utilities Extension provides access to various BMC AMI DevX utilities, such as submitting jobs on the mainframe.

BMC AMI DevX Code Debug

• BMC AMI DevX Code Coverage plugin allows Azure DevOps users to extract code coverage results from a BMC Code Coverage repository, which can then be viewed in SonarQube.

BMC AMI Strobe

• Azure DevOps BMC Strobe Measurement Task Extension allows Azure DevOps users to set up automated BMC AMI Strobe measurements and get custom callback notifications when complete.

Continuous improvement is about building on success and finding even more ways to expand. As the market changes, so do you, and so do we. You can benefit from these new aids now and expect more in the future.

To learn more about how automation can help improve the developer experience and increase productivity, listen to our podcast, “Liberate Mainframe Developers by Automating Repetitive Tasks.”

In John Steinbeck’s novel, The Grapes of Wrath, he called Route 66, a well-known United States highway, “The Mother Road.” In the novel, it was the path the Joad family took from the Dust Bowl state of Oklahoma to the state of California. Route 66 still survives in many places, but Interstate 40 has replaced a large segment of it and the roadway was decommissioned in 1985. While Route 66 was an innovation that stitched the country together, it was itself replaced.

What caused this? Route 66 partially solved the problem of routing—if the signs still said “66,” you knew you were on the right road. You still had to pay attention when there where shifts in the road, but you had some help. What it didn’t solve was slowdowns and stops in the small towns and larger cities along the way. These all added up to a long journey.

The interstate highways like I-55, I-44, and I-40 that replaced it, often in parallel, offered a way to avoid any slowdowns or stops. They eased navigation by limiting choices and distractions. They were also safer. While Route 66 may be a choice for a fun, long trip, you take the interstate highways when you need to get to the west coast fast.

When looking at mainframe development, I see many organizations still stuck in Route 66 mode. They have manual processes with slowdowns and stops along the way. There could be a clearly defined path to go from ideation to production, and developers could take pride that it is better than it was before. But mainframe development isn’t what it could be. There are alternative, parallel paths that will eliminate the stops and slowdowns.

Here are some ways to get your mainframe development onto the interstate:

• Get a map—Lay out your processes. What is your route from ideation to delivery? By laying it out, you can start to look at the procedures you have in place and the tools that support them. The chart located here can help you.
• Examine slowdowns—Starting with your map, look for places where there is a handoff, or a manual process, and seek to automate it. Look at places where there is a check or a human involved, and determine if that is really needed. If it is, what could be done to speed it up? Is the proper information available? For example, you could use automated code quality checks to speed code review.
• Build bridges and better routes—Just as Route 66 was altered over time to make it flow better with new bridges and routes, you can learn about the technologies that can assist you. For example, look for Webhooks and REST APIs for your current products. A great resource is the BMC Mainframe DevOps page.
• Initiate automated pipelines—In the same way that interstates were built and opened up in sections, you can also open up your pipelines one process at a time. You don’t have to wait for it to all be complete before you can begin to benefit. Focus on areas of greater benefit first, then link them. Setting up a whole interstate must have been a daunting process, but the route was planned, and then built in sections. You should do the same.

You can guide your teams to a new alternative parallel path that will eliminate the stops and slowdowns. Once you have established your modern, automated processes, you will continue to use them to provide quality solutions quickly to your users. The old ways will, like Route 66, only be a discussion point for nostalgia.

I was recently at a Detroit Tigers baseball game with my fellow BMC product managers. Watching the pitchers and batters, I was struck once again by the speed with which the batter must decide whether or not to swing at the ball. In a split second, the batter must gather and process data, then act. Really, the process isn’t all that much different from how our systems respond to abends.

It has been determined that a fastball takes about four-tenths of a second to travel from the pitcher to home plate. A batter needs about a quarter second to see the pitcher’s grip on the ball, where they let go of it, and where it’s travelling—and then make their decision.

A similar split-second gathering of information needs to be done when abends occur. Before the data is gone, all the clues need to be located and saved for presentation. There is an urgency to gather the information, and then present it to the developer.

A batter’s decision making is based on experience and the ability to understand the pitcher’s tendencies; their stance, how they pitch in certain situations, etc. Players look at scouting reports and discuss pitchers before the game so they have some idea of what to expect, based on past performance. BMC AMI DevX Abend-AID uses a similar approach, sharing knowledge and notes of your “opponent”—the abend. Abend-AID is able to leverage decades of experience to help developers quickly diagnose and resolve abends.

The urgency in gathering information is carried forward to notifications. When users are being affected, you need to get developers assigned to the issue, armed with the right information, as soon as possible. Abend-AID provides a new ability to send rapid alerts to Slack or Microsoft Teams, or create trouble tickets. In the time it takes for a baseball to reach the plate, you can have an alert on your phone with a link to the report.

BMC user experience designer Chris Malin, who was sitting next to me at the game, had this to say, “Just like pitchers in baseball, today’s software development and operations teams can win or lose based on velocity. The mainframe is the backbone of web and mobile applications…and seconds matter. Modern software practices, like DevOps, are designed to help improve velocity, quality, and efficiency. Abend-AID’s ability to gather and present information to developers and operations teams immediately, in a modern way, provides teams the ability to speedily react and respond; keeping their critical applications up and running.”

Just as batters are able to collect data, process it, and react in fractions of a second, Abend-AID is able to gather information and present a report that notifies developers of an abend and shares root cause analysis for them to resolve it.  The good thing for you is that Abend-AID has a higher percentage of success than even the very best batters. Learn more on the BMC AMI DevX Abend-AID web page.

In my career, I’ve witnessed workplace communication evolve with technology, transforming from scribbled messages to voicemail to pagers to email and text messages. The communication technologies that win are those that make things move faster and retain a history, while also improving focus and providing better automation. That’s why today I mainly rely on chat apps like Microsoft Teams and Slack to communicate with team members.

We must constantly strive to make it easier for the mainframe to leave its “waterfall” and become an agile DevOps platform with a delivery schedule that aligns with those of distributed systems. Anything that prevents the mainframe from becoming nimbler, including communication tools, is a constraint that must be supplanted with agile-enabling innovation. Chat apps should be considered essential for mainframe teams as they work to incorporate the platform into their enterprises’ DevOps toolchains. This enables “ChatOps,” in which developers use chat to interact not only with each other, but with messages and alerts from their development tools, making these tools just another member of the team.

To support this collaboration, BMC now offers chat app notifications from BMC AMI DevX Abend-AID. Developers can create webhooks to send notifications to their teams when application abends occur in production or testing. This instantaneous notification gives team members the ability to react quickly, and includes the program name, abend code, and associated user ID, etc., along with a link to the report in the Abend-AID web viewer.

Here are the top four reasons chat apps like Teams, Slack and others will help your mainframe team address issues other communication technologies can’t as it moves from waterfall to agile DevOps.

1. Real-time dialogues: DevOps teams must be in constant communication. Anything that inhibits dialogue must be addressed. Email has its place, but chat apps are more agile because they enable real-time messaging, cutting out the send-and-receive process of email. You can see if someone is available or away without even initiating a chat. You can send your message now, or wait for the person to be available.

1. Chat apps also work on mobile devices, so a developer can elect to be available regardless of whether they are at their desk. Yes, you can be fast with email, but there’s no argument that notification through chat apps is faster. Abend-AID becomes your designated team member to alert on abends in testing or production. A developer can see this notification and let other team members know they will be responding to it. They can also ask questions of the other team members within the chat.

2. Organized conversations: Part of the success of agile and DevOps is the elimination of waste. When tasks are being handed off, there is little time to get up to speed. You need to be organized. Searching for and digging through an email chain is unproductive. Chat apps are inherently more organized than email because they contain the entire history of a conversation in one place. Anyone can join a conversation and see the complete history without needing someone to cc them on a reply or forward an email chain to give them access to the preceding discussion. The conversation can be reviewed in order, by all parties. This is critical for abend resolution, where there can be no wasted time.

3. Forced concentration: In a waterfall world, there is plenty of time to allocate for large tasks with deadlines that are months away. But in an agile DevOps environment, there are several tasks that must be completed within two weeks. This demands a higher level of discipline and concentration, and chat apps are ideal here.

1. Because messages in chat apps transmit in real-time, they more closely resemble actual conversations, unlike email, so you likely feel obliged to pay attention and respond. Chat apps also allow you to open focused channels for a team or specific project. When projects span teams, you can establish one place for quick questions, discussions, or updates. Team members can set up alerts to be notified of new posts or just notice there is a new post they have not seen. They can also scan conversations to see whether a question they have has already been answered or contribute more to an existing answer.

1. Additionally, having the team be aware of an issue and its resolution as it happens keeps everyone informed. This communication can help bring the team together.

4. Increased automation: DevOps is all about automating handoffs and breaking down walls. In DevOps, your tools become team members, handling tasks you may have done manually in the past. These new team members need to communicate with each other. Chat apps are designed to work well with webhook notifications. If you work with modern advanced software, like BMC AMI DevX Abend-AID, you can use the webhook to send notifications to your specific chat channel. If there is an error, everyone in that channel will be able to see and react in an orderly manner. These abend notifications can supplement notifications provided by BMC AMI DevX Code Pipeline​ for activities like code promotions or deploys.

As more and more mainframe sites move from waterfall to agile, they see the value in adopting better communication. In fact, it becomes essential when working in a two-week sprint to eliminate as much lag and confusion as possible. Chat apps are another part of the DevOps toolchain that will allow mainframe teams to bring the platform up to speed with the rest of IT. After all, which Agile team couldn’t benefit from having a new team member?

Learn more about webhook notifications for BMC AMI DevX Abend-AID in this BMC Community post.

Agile development is all about constantly looking at your processes to continuously improve them and make them more efficient. Take trouble ticketing, for example.

In the world of trouble ticketing, it’s one thing to be notified that there is an issue, but another to actually help with it. When developers are faced with trouble tickets, they are informed of a serious issue but are not given the context and information needed to immediately start toward a resolution. They must take the bare information and guess about the next steps as they head toward other tools. In today’s fast-paced agile, world minutes—even seconds—can count.

Let’s see how this plays out today:

1. A developer is assigned a trouble ticket informing them that an application has abended.
2. They then go over to BMC AMI DevX Abend-AID and search for the abend, using the time it occurred and the program name (if they have it).
3. Once they have located the proper Abend-AID report, they can begin to understand the root cause and work towards a solution.

Working with our customers, BMC understood the issue with the handoff that occurs between Steps 1 and 3 and we sought a way to collapse that time and provide the information right at the beginning—in the trouble ticket. To that end, we have developed a new BMC AMI DevX Abend-AID webhook for notifications, which provides developers with the means to create automated issue notifications in products like BMC Helix ITSM and ServiceNow.

The notification contains detailed information, such as program name, abend code, user ID, and more, and includes the Abend-AID report number and a link to the report in web viewer so the developer can immediately start root cause analysis. Now your developers can arm themselves with the information they need to resolve issues and get your applications running again.

Setting this up is actually quite easy; you can find more information in our BMC Abend-AID Community. Your existing tool for issue notification will probably have a clear interface to create a URL to use in the webhook or have an API where you can post the webhook information. Review the user guide for your product to learn how to create an issue using a webhook.

The BMC AMI DevX Abend-AID enhancement pays off with less developer time spent on manual tasks and more time spent on new applications that benefit your users, while demonstrating DevOps in action by accelerating the hand-off of an issue from operations to a developer. The enhancement is available with the July 2022 maintenance for Abend-AID and BMC AMI DevX Enterprise Services (CES).

Throughout our lives, we make decisions based on the facts at hand and the likely outcome of our actions. A classic moment in the film The Empire Strikes Back comes to mind. As they approach an asteroid field, C-3PO tells Han Solo, “The possibility of successfully navigating an asteroid field is approximately 3,720 to 1.” Solo replies, “Never tell me the odds!”

This type of exchange is repeated in another Star Wars film, Rogue One, with K-2SO telling Cassian Andor and Bodhi Rook the chances of failure and once again, Andor doesn’t want to hear it.

Han Solo and Cassian Andor don’t want to know the facts because they’re not relevant to their decisions. Each knows that their chances at success are nearly impossible, but they will proceed anyway. Is this how we approach our software development projects? Do we proceed without facts? There is something to be said for reckless abandon in a movie, but perhaps not in a development project. As we approach our own “asteroid fields”—the bottlenecks and other anomalies that slow development—do we want to exhibit boldness, but this time, informed by relevant information?

If yes, then what information is helpful to that decision and where do we get it? One good source of data around mainframe software development is BMC AMI zAdviser, a service provided free with current maintenance, which continuously measures your processes and uses machine learning to help improve them.

Here are some examples of information zAdviser can provide:

• Learn exactly how long it takes on average to go from checking out code until test, or even to production. You can use this metric to identify high-performing teams and learn from them.
• Identify programs that are taking significantly longer to work with. These may represent areas where refactoring can make a difference.
• What does “Good” look like? zAdviser aggregates all data allowing you to compare your KPIs to all other customers (data is kept anonymous).
• Look at percent of Abends escaping into production compared to your overall abends. These are the abends that your users are going to experience.
• A Development Manager saw that it was taking 3 weeks to test the code the developers took 4 days to write. He commented that this is what his developers have been telling him for a while but there was no concrete method of proving or showing it to senior management. If you are looking to implement automated testing, these are the metrics you can use for your baseline and for measuring progress. You can read more about it in “Improving Quality and Shift-Left Testing with BMC AMI zAdviser” by Spencer Hallman.

zAdviser provides visibility into successful practices and helps detect problem areas, delivering actionable insights so you can address them and proceed boldly but safely, avoiding the asteroid fields that can decrease the quality, velocity, and efficiency of your mainframe software delivery.

Learn more about improving your DevOps processes with actionable data in the e-book, “Charting Your Mainframe DevOps KPIs for Continuous Improvement.”

Mainframe and Git were words that didn’t seem to go together not that long ago. Git’s popularity among developers in the distributed world is no mistake. Feature branches, distributed development, pull requests, and a stable community ultimately result in a faster release cycle. These capabilities facilitate an agile workflow where developers are encouraged to share smaller changes more frequently. In turn, changes can get pushed down the deployment pipeline faster than the monolithic releases common with centralized version control systems. And Git’s rich collaboration features enable changes by multiple people to be reviewed and merged into one source. Coupled with newer developers already being familiar with using it, Git makes a compelling solution to consider for source code management (SCM).

The concept has arisen that because Git is so successful in distributed development, perhaps that success could carry over to the mainframe. Sharing of practices is a way to provide commonality and breaks down silos. Also, there is a desire to have all assets in one place. But as often the case, meshing technologies between platforms can be challenging.

But it doesn’t have to be. BMC AMI DevX Code Pipeline​‘s deploy capability integrates with multiple vendors to provide the unified deploy across platforms. This same focus on integration, and our experience in working with customers using Git over the past 7 years, have made it increasingly easy to provide an option for Git to store your development assets while still leveraging the power of DevX Code Pipeline​ on the mainframe for your build and deploy.

Here is our advice for those considering Git on the mainframe:

• Explain the rationale – Part of planning for Git is to provide the rationale. Why would teams want to consider moving to Git? Our Git for the Mainframe eBook offers a comprehensive look at Git and BMC AMI DevX Code Pipeline​. It can help developers understand the issues and the benefits to make an informed decision for their teams.
• Gradual Transition – Part of making this easy is to work on your schedule. Teams can move over to Git when they are ready (and some teams may never go to Git – an important point). Resistance is understandable if all applications must move at one time, which can be disruptive. Instead, we recommend a gradual approach where applications are moved to Git when team members are ready.
• Guidance – We have defined procedures to take you step-by-step. Even tens of thousands of programs will be manageable with this application-by-application approach. Our tools can automate the transfer from DevX Code Pipeline​ to Git. We can even assist you with copying your change history from ISPW over to Git.
• Build – When you have DevX Code Pipeline​ installed and configured, everything is there for your build and deploy. The relationships are built automatically, so all of your compile parameters and impacts are there to be leveraged.
• Deploy – With DevX Code Pipeline​ your mainframe deploys will be configured and available to work with Digital.ai, Cloudbees Flow, and HCL Launch. Switching to Git for SCM won’t cause any disruptions for deploy.
• Related Tooling – One of the reasons to use Git is to be able to use the related ecosystem of tools. BMC AMI DevX Code Pipeline​ has a VS Code DevX Code Pipeline​ extension to take you from editing your code into a mainframe build with one click. We also offer GitHub actions to automate generate, build, and deploy using DevX Code Pipeline​ on the mainframe.

It is good to have options as you plan your future. With BMC AMI DevX Code Pipeline​ we understand that and strive to stay current with trends, to be just ahead of where you are. This provides you with what your developers need, when they need it. You will be able to move forward on your initiatives with confidence.

To learn more about pairing Git with BMC AMI DevX Code Pipeline​, listen to our podcast, Git for Mainframe DevOps.