Posts Tagged ‘cloud’

  • December 5th, 2017

    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 voyagers thrusters to replace attitude 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 are 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…rocketship

    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 of 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 companies data to a big data model designed to generate actionable business insights.

  • November 29th, 2017

    Mainframe Migration? Why?

    This is part 1 of a series of articles investigating why organisations should consider Mainframe Migration, the options they have and the steps they need to take to transform their mainframe workloads to run on the cloud.

    Lets set the scene a little bit for a typical large organisation 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 wasn’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, year end, the batch jobs are only just completing in 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. Lets face it a green screen does not have the possibilities 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.

    mort greenscreen

    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?

    mort angular


    Your companys’ “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 to be sure but one to which the organisation 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.