Opening the Mainframe Siloes: Our New GitHub Repository of Proven Mainframe Solutions (Part One)

March 28, 2021 | YULIYA VARONINA

It happened again.

You were developing a mainframe application.

Your work was flowing and you were making rapid progress.

But then, you ran into a problem that you didn’t know the answer to.

So, you began to search for a solution, hoping you’d find the answer quickly.

You start with your own stack of folders, files, notebooks, and sticky notes.

Nothing.

You turn to your colleagues for help.

Nobody around you knows the answer either.

You hop online and search through official documentation.

Your search is boring and it doesn’t turn up the answer you need.

You then browse decades of forum posts without finding the solution.

With nowhere else to turn, you are forced to piece together your own answer.

You take information from multiple sources and assemble a patchwork fix.

It solves the problem well enough, and you return to development.

But then you encounter a new problem, and the cycle repeats.

Breaking the Cycle: A Centralized Solution to Mainframe Problems

At IBA we know this cycle all too well.

We deploy a large volume of talented, experienced mainframe developers.

But like all mainframe developers, they sometimes encounter issues that they don’t have an immediate answer to. When they do, they have to look somewhere to find the solution. And for the longest time, our developers were getting caught in this same cycle of ad hoc searching for a solution.

Over time, we grew tired of this cycle. It was always frustrating, time consuming, and inefficient. We began to suspect there had to be a better approach to solve mainframe problems. And if we couldn’t find a better approach out there, then we would just have to build it ourselves.

We developed a new approach that broke this cycle of ad hoc searching for mainframe solutions. Our new approach gave our teams a single hub they could search to find answers to their mainframe questions.

Ultimately, we developed a GitHub repository for all things mainframe.

At first, we kept this repository internal to prove that it worked. But now we are sharing our repository with the community as an open-source project.

By utilizing our repository, you will be able to:

Save a lot of time, effort, and frustration when solving your mainframe problems.
Throw out some of your technical folders, notebooks, files, and sticky notes.
Discover a lot of useful, hard-to-find mainframe information in one place.
Learn some new, modern approaches to mainframe administration.
Bring real-world DevOps practices to your mainframe function.
Contribute your knowledge to the mainframe community.
Break your own cycle of ad hoc searching for mainframe solutions, and help others find answers to their questions faster and simpler.

If you are ready to explore our repository, then you can access it here.

But if you would like to know more about this project, then keep reading.

In this article, you will learn:

Why mainframe has needed a repository for a long time.
How we initially developed our repository.
What materials you will find in it.

The Core Problem: Why Mainframe Needs an Open-Source Repository

To start, let’s be clear about one thing.

We do not believe that our GitHub repository is a 100% original idea. We suspect other people have thought about consolidating mainframe materials in one place before, and that they achieved some traction with their efforts.

But fundamentally this “open source” approach remains rare in mainframe.

Historically, mainframe administration and development has been a very siloed discipline. The systems themselves are often closed, and there hasn’t been a community or network that actively shared their knowledge.

In some cases, mainframe professionals have been expressly forbidden to share information they have learned with other members of the mainframe community. In other cases, people were just afraid to open up their vaults.

The result: Every company and mainframe professional has “dug in their own direction” and created their own policies, prejudices, processes, and solutions that they have kept in-house and rarely ever shared with other professionals.

To be clear, this is not any one company or professional’s fault. Mainframe has been this way for decades. Siloes have just become a core part of the culture.

But even though it is not anyone’s fault, we all have been perpetuating the problem. And by doing so, we have created this situation where the search for mainframe information has resulted in the tortured cycle outlined above.

And while we have ultimately opened our open-source project to the entire mainframe community, when we first developed our repository we were still a little caught in this mindset, and only building a solution for ourselves.

In fact, it started with just one developer solving her own individual issue.

How We Built Our Repository: Solving Our Own Problems

Before we developed our repository, our mainframe developers searched for answers to their problems in the same ad hoc manner as everyone else.

But one day, one of our developers had enough. She was tired of working from a desktop covered in sticky notes with commands scrawled on them. She didn’t want to continue to work in this old fashioned, inefficient manner.

She decided to find a better solution. She wanted to put all of her information in a git. But first, she wanted to see if anyone else in IBA felt the same way.

So, she went to her fellow mainframe engineers. She saw that they all had their own overflowing notebooks and desktops covered in sticky notes.

She saw that everyone had a lot of great information that they were inadvertently keeping to themselves, and that even within our own organization and teams a lot of mainframe solutions were being siloed.

She also saw that many of her colleagues were as frustrated with this situation as she was, and they liked her idea of centralizing their solutions.

So, she decided to expand on her original idea.

Instead of creating a git that was only filled with her own information, she decided to create a home for “all things mainframe” by collecting information, commands, and best practices from everyone at IBA, and to centralize all of that material into an organization-wide repository.

She found a lot of support for this initiative, and it grew into a much bigger — and more effective — project than anyone had ever envisioned.

Here’s how we ultimately developed this new repository.

How We Built Our Repository: Our Five Step Process

To develop our repository, we followed five simple steps:

Defining Project Scope
Creating Core Principles
Choosing Information to Include
Populating Our Repository
Making Our Repository Truly Open Source

Let’s look at each step in greater depth.

Step One: Defining Project Scope

First, we defined what we needed from our repository, and we created a shared understanding of the form and format the repository needed to take.

We wanted the repository to be more than just a collection of mainframe information. We wanted it to provide a single place where people could ask their questions, communicate with each other, leave comments, make their own edits and additions, and improve the information we had collected.

After defining this expanded scope, we decided to build our project as an open-source repository in GitHub. It was the most popular, dynamically developing platform that already had a huge community. And it provided a framework for how we could create this modern approach to mainframe that natively provided all of the features we desired.

Step Two: Creating Core Principles

Next, we had to create some guidelines for our repository.

While we knew creating a repository for “all things mainframe” was a good idea, we also knew that the project could spin out of hand, and become as stuffed, chaotic, and unsearchable as other sources of mainframe answers.

To avoid this problem, we created some core principles that would impose some discipline and guide how we selected materials for our repository.

We decided to only include mainframe materials that were:

Useful: We did not want to include anything fluffy, ambiguous, theoretical, or that looked like a good solution, but which lacked any clear or common use case to deploy it. We only wanted to include practical solutions that addressed real day-to-day problems.
Tested: We did not want to include anything that sounded good on paper, but failed in real-world application. We wanted to make sure everything in our repository actually worked, and we committed to only include solutions that we field-tested or otherwise verified as effective.
Standardized: We did not want to present a dozen different solutions to the same problem, or a dozen variations to the same solution. We decided to choose the single solution that best solved the problem, and to present it in the single approach that would help the most people.
Easy to Understand: We did not want to confuse readers with long, complex, challenging command lines. We chose to write every solution as simply as possible, and to only write them with clean, clear language that anyone could understand the first time they read it.
Searchable: We did not want to make it difficult to find anything in the repository. We wanted to make sure everything in our repository was as easy to find as any other information from a quick Google search.

After we set these core principles, we used them to both validate every piece of information we put into our repository, and as guidelines to ensure our repository as a whole was developing in the right, disciplined direction.

Step Three: Choosing Information to Include

Now, we were ready to determine what types of material to include.

We didn’t want to limit its scope in any way. Mainframe is a complex topic filled with a lot of problems and solutions. If we wanted to create a true home for “all things mainframe” then we needed to include a lot of materials.

To do so, we generated a large list of potential materials that we could include in our repository to solve our most common problems.

We decided to include:

Lists of commands for working with various z/OS system utilities, subsystems, and programs. We tried to avoid an excessive description of each command, to help people who were looking to just perform a specific action that they needed to complete as soon as possible.
Scenarios to complete some z/OS system actions using various utilities, subsystems, components, programs and their combinations. For each of these scenarios we included step-by-step instructions with detailed descriptions and examples.
Examples and templates of various scripts to operate within mainframe (such as JCL, REXX, Shell, and Java). We wanted to provide as much out-of-the-box content as possible that could be quickly copied-and-pasted to deliver results.
Our own solutions and approaches to automation and bringing DevOps to mainframe. In each, we shared our own experiences — both “how to information” as well as the rakes that we stepped on, the pitfalls we encountered, and how to avoid these problems.

With these materials decided, we next needed to populate our repository.

Step Four: Populating Our Repository

Initially, we populated our repository with our own internal materials.

We pulled these materials from real-world projects that our people had completed. We poured through our teams’ sticky notes and old, thick, worn-out notebooks. And we asked around for additional materials and best practices that our experienced people knew but had never documented.

These internal materials formed the bulk of our initial repository, but we did pull from other sources. We reached out to some of our peers in the industry. We had them ask their colleagues for information as well. And we performed online searches of documentation, forums, and other far-reaching sources.

We tested and validated every one of these solutions before we posted them to our repository, and by the end of our initial pull we had developed a pretty robust set of resources that we knew solved mainframe problems efficiently.

Step Five: Making Our Repository Truly Open Source

Finally, we began to use our repository internally.

Along the way, we further tested each of the materials in our repository — and the repository as a whole — in the real-world for almost an entire year. At the end of that year, we felt confident that our repository delivered real results, and made the process of finding solutions to mainframe problems much faster, simpler, and easier than conventional searches.

We also felt certain that other members of the mainframe community could derive similar benefits from our repository. With that in mind, we decided to open it up to the entire community and make it 100% open-source.

Today, anyone in the mainframe community can:

Access our repository, and use any of the materials in it.
Bookmark it, subscribe to it, or fork or clone it to use locally offline.
Create their own private repository based on their own unique needs.
Become an active, public contributor and make our repository better.

We will explore each of these cases in more depth in our next article, but for now just know that our repository is available to you, for any way you want to use it — just click here to access it and get started.

Next Steps: Leveraging Our Repository and Learning More

This was part one of a two part series on our new mainframe repository.

In part two, we explore our repository’s most common use cases in much greater depth. We will also explore some of the more technical information you might find in our repository and how to best leverage it.

But if you’d like to just get started with our repository, then you can access it here. And if you’d like more personalized information on how to best use it, contribute to it, or to work with us in general, reach out and contact IBA.

Opening the Mainframe Siloes: Our New GitHub Repository of Proven Mainframe Solutions (Part One)

Table of contents