Heirloom Computing

Old Code is NOT Bad Code

Voyager 1 fires thrusters for the first time in 37 years.

Running a proprietary assembler program written over 40 years ago, engineers at NASA were able to use the Voyager’s thrusters to replace the altitude correction engine that had degraded over the last 40 years. This extends the lifetime of the voyager 1 probe for another 2 or 3 years.

Is there a finer example than this that old code is not always bad code? Old code also continues to fulfill vital roles for NASA in the same way that it does for your business.

I did not start to write this article with the expectation that I would be comparing mainframe applications to rocket science, but when the facts fit…

Just like the incredible continuing value of the assembler code running on Voyager 1 let us take a moment to remember the incredible value of the code living on your mainframe.

Re-purposing hardware and executing decades-old code on it has significantly extended voyage 1’s life expectancy. We can use the same analogy for existing mainframe applications.

If we migrate the application using Heirloom, we are changing the hardware environment but keeping the existing code and giving it a new lease on life. This will extend the lifetime of these applications and actually increase their value to your company. Migrated applications do not just run in a new environment, their data, previously hidden away in an EBCDIC silo, suddenly becomes accessible to the rest of the enterprise. Imagine adding decades of experience in the form of your company’s data to a big data model designed to generate actionable business insights.

CI/CD with COBOL and CICS

Introduction

Reading about Continuous Integration, Continuous Deployment (CI/CD), unit testing, etc., all seem a million miles away from daily life on the Mainframe.

In fact, there is a basic question to be answered for all projects, “Why do we need to do continuous integration?”. Agile guru Martin Fowler puts it best (he usually does) when he says:

Continuous Integration is a software development practice where members of a team integrate their work frequently; usually, each person integrates at least daily… Each integration is verified by an automated build… to detect integration errors as quickly as possible.

Large software projects are plagued with integration issues, developer 1 changes code and breaks developer 2’s code. If you are not following a continuous integration approach, this will only be discovered near release, resulting in many late nights for the developers and even more grey hairs for the project owners. It is at this point that coding standards fall precipitously, and “hacking” a change to “make it work” can ensure that the next project delivery starts with, often, severe technical debts. Unless you are the US government, this debt will have to be paid, resulting in longer release cycles and missing features.

At Heirloom, we develop our products and our code every single day following industry best practices and are extremely proud to call ourselves agile.

That’s great for Heirloom as a commercial software development company producing a completely automated mainframe workload migration platform, but what about our customers?

Well, our tooling enables our customer’s mainframe code to fit into industry best practice CI/CD environments and processes just like the one below. Because mainframe code compiled with Heirloom runs on the Java VM, we are in a great position that we can utilize all the Java infrastructure that has been built in the last few years to support enterprise application development.

How Do We Implement This?

Let’s start with the developer workstation. Heirloom is delivered as both a development environment and a Java framework.

The development environment is an Eclipse perspective. We add COBOL and PL/1 as fully supported languages to the industry-standard Eclipse development environment.

We can follow a full development cycle here:

Edit … Compile … Debug … Test … Commit

The code being worked on in the image above is a standard CICS application presenting a BMS screen to the user. With Heirloom, BMS screen definitions are automatically transformed into HTML5 templates, with the initial template design mimicking the green screen that mainframe users are familiar with. See an earlier post for a typical green screen sample program Mainframe Migration? Why?

The version control system (VCS) that we use at Heirloom is Gitlab (we used Bitbucket before that, and our clients have used similar hosted services or their own internal repositories).

The Continuous Build Server that we use runs the  Jenkins open-source automation server.

All our notifications back to the developers are done using Slack channels.

So what is the process flow?

1. Developer makes and tests code changes in eclipse and commits them to the VCS
2. A notification is sent to a slack channel, visible to all developers
   
3. The Jenkins server is also notified of the change, checks the code out of the repository, and starts the build, test, and deploy process. Our build pipeline looks like this:
4. When all the tests are run, Jenkins pushes the newly created artifacts to our overnight build area and creates versioned artifacts in a maven repository. Jenkins then notifies the developers that the build was good (or not) on a different slack channel.

Summary

Heirloom migrates not just your mainframe code to a new platform, the Java VM. It also enables you to transform your developer and integration processes. When you use Heirloom, your mainframe projects and developers are now citizens of the open systems world and can adopt industry best practices for continuous integration and deployment.

A pre-requisite that many people may have noticed for all this to work is that there is a set of tests that can be run automatically as part of the build and integration process, and that is the topic for the next article.

Mainframe Migration? Why?

This article investigates why organizations should consider Mainframe Migration, the migration options they have, and the steps they need to take to transform their mainframe workloads to run on the cloud.

Let’s set the scene a little bit for a typical large organization that runs business-critical applications on the mainframe.

1. Your mainframe and your mainframe applications just run.
2. It causes no heartache, no troubles; when was the last time it “went down”?
3. If it weren’t for the pesky leasing payments and the endless contract renewal discussions, you probably wouldn’t give it too much thought.

But there are a few vague, uneasy feelings:

1. Perhaps you are not as responsive to your customers’ requirements as you could be.
2. At month-end, quarter-end, and year-end, the batch jobs are only just completed within the batch window.
3. There are a lot of grey beards in the PL/1, COBOL teams
4. Adding a new type of customer contract takes months with the mainframe screens and seemingly minutes with the web team.
5. Let’s face it a green screen does not have the possibility to represent data that a modern web browser supports

Would you rather be working with this green screen? A COBOL/CICS application that has been deployed to Pivotal Cloud Foundry using Heirloom.

Or with this Angular and D3 application that is also running on Pivotal Cloud Foundry and using exactly the same back-end COBOL/CICS program to run the amortization calculation?

Your company’s “front-end” applications are being delivered using industry best practices, continuous integration, and continuous deployment, CI/CD of the applications is de rigueur, and perhaps most importantly, your customers are extremely happy with the features, the responsiveness, and the look and feel. These applications and the teams that create them are agile in a way that the Mainframe group is not.

At the same time, these web applications are now capable of the same reliability as your mainframe environment, not because every single component works all the time but because every component has fail-over redundancy built-in. It is a different reliability model but one to which the organization is gradually becoming accustomed.

Your company is also becoming accustomed to hardware costs for running the non-mainframe applications to actually fall each year and yet still eke out higher and higher performance. Need to have a little performance kick for black Friday? Just automatically scale out some more application instances, and pay for the extra throughput performance ONLY when it is needed.

So now the scene is set, check back here for the next post, where I will lay out various Mainframe Migration options and the pros and cons of each one.

COBOL/CICS Hooks Up With Pivotal Cloud Foundry

Would you be skeptical of a claim from a vendor that stated you can take existing mainframe workloads (online and batch), and automatically transform them (with 100% accuracy) into instantly agile Java applications that can immediately be deployed to the cloud? You wouldn’t be alone. For many of our initial client meetings, there’s a palpable sense of disbelief (or healthy skepticism, if you prefer).

So, here’s another 3-minute video from Ian White, Heirloom Computing’s VP of Engineering, that demonstrates that claim, using Pivotal Cloud Foundry (PCF).

TL;DW? These are the (simplified) steps:

What happened? We took an online mainframe application and deployed it to PCF in 3 minutes. No misdirection, real code, real results, and a re-platforming project lifecycle that puts you in control (so you can avoid black-box solutions).

For us at Heirloom Computing, Cloud Foundry is a great example of how Heirloom maximizes the power of open-source stacks to provide clients with a way to include high-value mainframe workloads in strategic initiatives (e.g., cloud, digital transformation, etc.). One that protects existing functionality, but also one that is seamlessly integrated with an agile ecosystem.

Amazon Alexa Hooks Up With COBOL/CICS (On The Cloud)

Gary Crook, President & CEO

There’s a lot of chatter about how to make mainframe workloads agile. I have contributed to that chatter myself. The discourse is essential. Boiled down, my assertion is that the mainframe ecosystem is foundationally not agile (and never will be). No amount of DevOps tooling or vendor misdirection is going to change that.

In my last article, I made the following statement:

Mainframe workloads are an essential part of any digital transformation strategy, but those workloads will persist in a different form. One that protects existing function, but also one that is seamlessly integrated with an agile ecosystem.

Below is a (3-minute) video that implements the above statement. It was put together inside 2 hours by Heirloom Computing’s VP of Engineering, Ian White.

COBOL & The Definitive State of the World’s Greatest Legacy Ecosystem

TL;DR — see picture left, or… a career COBOL’er makes a compelling argument that legacy application systems (COBOL et al) on the IBM Mainframe are killing IT digital transformation initiatives.

So, a heads-up… this article is going to be self-serving (at least to start with, perhaps longer), as I’ve come to the conclusion that it is necessary for me to “introduce” myself in an attempt to establish a greater level of credibility than I might otherwise be able to muster!

I’ve been working for over 30 years. My entire career has been in the “COBOL space”, the vast majority of it working with Global 2000 companies to deliver COBOL application development & deployment platforms that were primarily focused on adding value to the IBM Mainframe (“The World’s Greatest Legacy Ecosystem”).

I have worked at the “coal face” developing bespoke commercial COBOL applications. I have worked developing COBOL compilers and runtimes. I have led global teams of astoundingly brilliant people that have built COBOL ecosystems from scratch. Back in 2010, myself and a group of others with similar career profiles, and significantly greater areas of expertise, founded Heirloom Computing to bring a new COBOL ecosystem to market.

Heirloom leverages open-source software stacks (primarily Java); one that immediately exposes existing business rules from mainframe workloads as a collection of Java interfaces and RESTful services so they are immediately available to other applications; one that from day 1 is absolutely guaranteed to accurately retain existing business logic, data integrity, and security profiles; one that allows application developers (using Eclipse) to continue in COBOL, or Java, or both, so IT can “iterate away” from a constrained model to an agile one, at a pace that is determined by their own unique business drivers. This approach removes the “re-platforming” risk and makes the workload instantly agile.

We did this because we believe (and our investors and customers have validated) that IT needs to get beyond decades-old legacy systems if they are going to compete in a digital world.

Credibility enhanced? Either way, on we go…

The IBM Mainframe is without a doubt (and by far) “The World’s Greatest Legacy Ecosystem”. Its reliability, pervasiveness, and keeper of systems of record are unmatched. Today, however, that proud legacy is increasingly burdensome. These (crucial) systems: are severely & systemically constrained (and today, agility really matters); have paralyzed IT with a (fearful non-viable) “do nothing” strategy which consequently inhibits execution of strategic initiatives (like digital transformation) that are needed to compete. And up to this point, we’ve not even mentioned the operational expense nor the risks of an ever-aging/depleting skills pool.

Some of these systems, especially in government, have eroded/warped to the point that paper processes have been introduced to integrate legacy workloads with new services! This is NOT a failure of DevOps, nor tooling, but a failure of leadership and the brutal reality that mainframe systems of record are inherently NOT agile because a) they were never designed that way, and b) the COBOL ecosystem itself (an archaic compute-model, a procedural language, a failure to embrace open source, a lack of application frameworks, an entrenched culture, …) is NOT agile.

In article, after article, after article, IT leaders and analysts have clearly identified the challenge. Progressive enterprises like GE and Capital One are already working on solutions. Mainframe workloads are an essential part of any digital transformation strategy, but those workloads will persist in a different form. One that protects existing function, but also one that is seamlessly integrated with an agile ecosystem.

LJM Global Cyborg Specialist Forges Alliance with Heirloom Computing to Deliver on Mainframe Transformation Demand in Australasia

SAN FRANCISCO & SYDNEY–(BUSINESS WIRE)–LJM Global Cyborg Specialist (LJM) is partnering with Silicon Valley software firm Heirloom Computing to meet demand from the Australasia market for automated mainframe workload transformations to Java and the cloud.

LJM will leverage their quickly expanding footprint in Australasia as the exclusive systems integrator for Heirloom’s ground-breaking Heirloom platform.

“There’s real leadership from enterprise CIO’s in Australasia who understand that standing-still with legacy systems is not an option when executing digital transformation strategies,” said Larry McGean, LJM’s CEO. “LJM shares this outlook and is now uniquely positioned to help CIO’s deliver lT for legacy workloads which are aging fast, and approaching a tipping point. Critically, they are already inhibitors to the execution of an increasing number of strategic initiatives.”

Kevin Moultrup, Heirloom’s COO, added, “Our team has been working with LJM for several years now, and we are excited to formalize our partnership with LJM to deliver high-quality proven software solutions to Australasia’s most recognized companies.”

About Heirloom Computing

Heirloom Computing is a global enterprise software company that partners with Systems Integrators to implement initiatives that enable the Global 2000 to automatically modernize legacy application systems to Java and the cloud where they can be aligned with broader strategic initiatives such as digital transformation — whilst guaranteeing to retain existing business logic and data integrity. For more information about how Heirloom can increase agility, and save IT departments time & money, please visit http://52.23.23.73.

About LJM Global Cyborg Specialist

In coordination with its field offices in Sydney and Melbourne, LJM purses software solution opportunities around the globe. Specializing in company-wide implementations of packaged systems such as SumTotal Payroll, Workday HR Integrations, Blue Prism IPA, QlikView/Sense, and now automated mainframe workload transformations with Heirloom. For more information, please visit http://ljmcyborg.com.

Moving Beyond COBOL

Gary Crook, President & CEO

I’ve been involved with COBOL for most of my professional career. It is a language that has many unique characteristics, not all positive. Loved by few and (unfairly) vilified by many, it has persisted because it is extremely good at what it was built for — encapsulating business rules.

Many of you who have experience with the COBOL eco-system will appreciate the quiet reality of the absolute dependence that we all have on it as we proceed through our working day. The rest of you will likely be somewhat perplexed that anyone even uses COBOL today, and no doubt bemused by the bold assertion that your daily life without COBOL would result in unadulterated chaos. Well, despite the many predictions over recent decades of COBOL’s demise, this reality is not going to change anytime soon. That said, it would be remiss of us to not acknowledge the strategic intent of enterprise IT to convert COBOL to Java.

For typically risk-averse enterprise IT organizations, moving beyond COBOL is a tricky proposition. These applications represent the competitive differentiation of the business. They are the operational and transactional backbones of the business. They are the definitive manifestation of “mission-critical”. The thought of rewriting or replacing the high-value trusted business processes embedded in these systems can induce violent shudders of apprehension.

For server-side transaction processing, Java is often (if not already) the strategic platform of choice of enterprise IT – and even in the cloud, many PaaS providers have adopted Java as a supported engine (e.g. Amazon’s Elastic Beanstalk, Oracle Cloud, Google App Engine, and yes, even Microsoft’s Azure). Our take on why targeting the Java platform makes so much sense for enterprise IT, comes down to 4 key benefits:

1. The ability to deploy and extend applications on an open/strategic platform that is proven and trusted for high-transaction workloads that demand performance, scalability, reliability, security, and manageability.

2. Consolidation of application infrastructure to a single platform. No need to deal with multiple platforms on multiple operating systems.

3. Strategically positions applications for the cloud. Many enterprises have already made a strategic commitment to the Java platform. It’s a smart move — Java has already established itself as the de facto execution engine for the cloud.

4. Improves the productivity and agility of the development organization by modernizing skills, methodology, and process.

Trump, Kushner, COBOL

Gary Crook, President & CEO

Not 3 words you’d immediately assemble together, but that’s exactly what Senior ComputerWorld Editor, Patrick Thibodeau, did yesterday.

His article was prompted by a White House announcement of an “Office of American Innovation” to oversee the modernization of federal IT.

The article then goes on to give Compuware a platform to launch a somewhat bizarre defense of COBOL, as if somehow, wrapping COBOL applications up in DevOps methodologies makes them agile, and consequently, the mainframe can be seen as (according to Chris O’Malley, Compuware’s President/CEO) “… a working environment that looks exactly like Amazon (Web Services)”.

No. It’s not. There’s no amount of makeup that you can apply to my face to make me look like Brad Pitt. Fundamentally, all the required structures for that transformation just do not exist.

There’s much to applaud with Compuware’s mission to modernize and retool the application development lifecycle on the mainframe and impart valuable new skill sets to a workforce that has been largely isolated from considering different approaches to the art of application development. However, beyond that DevOps veneer, you are still working with a language ecosystem on the mainframe. If that’s where you want to be, go for it.

As Shawn McCarthy, an analyst at IDC said later in the article: “… the challenge with older COBOL systems is that many were not designed to be extensible and everything that needs to be done has to rely on custom code”.

And that’s essentially why no matter how much makeup you apply, COBOL systems on the mainframe will never be truly agile. Instead, for as long as they persist, they will continue to be an increasingly burdensome anchor that will slowly but surely impinge on an enterprise’s ability to compete.

Heirloom Immediately Available on the CenturyLink Cloud

Heirloom Computing, Inc. today announced the certification of Heirloom (Platform-as-a-Service) under the CenturyLink Cloud Marketplace Provider Program. Heirloom is a patented software platform that automates the transformation of mission-critical enterprise COBOL/CICS applications to 100 percent Java source and the cloud.

By simply getting started with the CenturyLink Cloud Blueprint, prospective users can easily leverage the value of Heirloom and its rich development toolset called Elastic COBOL (EC) Developer. Within minutes, a Windows-based instance of EC is automatically provisioned and ready for use.

Enterprise CIOs are being challenged to increase business agility, align and consolidate infrastructure to strategic platforms such as Java and the cloud, and significantly reduce the cost of maintaining an inflexible mainframe footprint that costs the industry $70 billion annually.

Today’s Heirloom announcement provides CIOs with a low-cost, low-risk, pay-as-you-use, COBOL-to-Java solution that is readily available on the CenturyLink Cloud platform.

“The ROI of using Heirloom is as immediate as it is profound – Java apps that can run on any Java virtual machine means increased agility combined with significantly lower execution, maintenance and support expenses,” said Gary Crook, CEO, Heirloom. “We’re excited to be working with CenturyLink to meet the needs of enterprises that understand how the cloud can be used to transform legacy IT infrastructure to make their organizations instantly agile and super-competitive.”

“Heirloom is a great example of the workload breadth we’re seeing enterprises considering for migration to cloud,” said David Shacochis, vice president of platform enablement at CenturyLink. “Elastic infrastructure is transformative when applied to mainframe applications – technology like Heirloom EC makes that possible for our customers.”

About Heirloom Computing, Inc.

Heirloom Computing is on a mission to modernize the world’s business-critical enterprise software applications. Heirloom’s best-in-class tools seamlessly migrate legacy systems to private and public cloud computing infrastructures, so IT departments can reap the cost benefits of cloud computing and satisfy user demands for applications accessible via web browsers and mobile devices.

For more information about how Heirloom Computing’s legacy modernization tools can save IT departments time and money, please visit www.heirloomcomputing.com.