How to eliminate scheduled downtime for IBM i and maximise your applications’ availability

In a recent Blue Chip webinar, Sales and Marketing Director Chris Smith caught up with Stuart Milligan from Midrange Dynamics, a company that provides affordable, feature-packed change management solutions for IBM i development teams worldwide.

Blue Chip partners with Midrange Dynamics to ensure maximum uptime for its own customers. By taking a more DevOps-based approach to delivering code on IBM i deployment, application downtime is reduced to a matter of minutes.

The challenges posed by application upgrades

Blue Chip’s IBM i Lead, Stuart Hayden, is all too familiar with the challenge downtime poses to organisations.

He explains that he has a “financial customer who runs a 24/7 workload and can’t afford any downtime”. Every three months they have an application upgrade which leads to anxieties around whether “users will be able to access the system”.

Before the work even starts, a database backup is required, followed by many hours of copying files.

“If there are any issues, they have to reverse the process and restore the database,” Hayden explains. The result is up to 48 hours of downtime, which poses a significant risk to the business.

Another customer facing downtime issues is a retail firm who deploys code three times a week.

“They have to get all of the users off the system and have two developers that work from 7 to 10am on Monday, Wednesday and Friday, manually deploying code. If they get to 10 o’Clock and some objects haven’t been deployed, what do they do?

“They have to reverse all of their changes which is expensive. It’s an increase in overtime costs and results in resource constraints as well, tying them up to working extensive hours.”

Sound familiar?

How to reduce IBM i application downtime during upgrades

Example 1:

One of Milligan’s customers is an international bank with a data centre in the UK. The firm’s transaction table has around 800 million records.

“They were doing two things,” says Milligan. “Firstly, they were trying to reorganise and get rid of all the deleted, old records. But they also wanted to update the system.”

The bank was at a loss as to whether to sacrifice uptime at weekends or during the week.

“So, several years ago, when we designed this process, we designed a methodology that enabled our customer to implement these changes even with very, very large databases, while reducing the downtime. Essentially, downtime was reduced from 15 hours to 17 seconds and the bank was able to do changes while the application itself was active.

“It takes them about 10 or 15 seconds to reorganise a complete file once a week,” says Milligan.

Example 2:

The second example Milligan provides, relates to another financial institution who were operating a huge application: 900 billion records, 2,000 tables and 8,000 change programmes in total. The organisation also wanted to implement two changes.

“The financial institution wanted to change the key of their central file, which everybody will know is a huge change,” explains Milligan.

“Furthermore, they wanted to move from DDS to DDR using modern SQL to access databases for performance and various other reasons. It was going to result in three weeks of downtime – which they just couldn’t afford.

“When we then looked at executing the entire change while active, with MDRapid, the changes took one week, and the downtime was reduced to two hours.”

What is MDRapid and how does it differ from other change control software?

MDRapid can deploy IBM i database changes in seconds.

Milligan explains:

“We prepare everything ahead of time. It’s a very highly secured and auditable stage process which links all the component parts together, whether it’s just looking at the database or programme change, and any distributed architecture as well.”

It almost makes the modernisation of database changes a maintenance activity, which is really what you want in this era of constant change.” – Stuart Milligan, Solutions Architect, Midrange Dynamics

“All applications are auditable, secured and integrated into the process. And we handle all the changes in parallel. When it’s time to do the deployment, we lock the application just long enough to move the change objects and the data and then unlock it.”

The result is significantly reduced downtime on IBM i platforms.

“MDRapid is proven to be a much more predictable and significantly lower-risk approach in achieving those same objectives. It almost makes the modernisation of database changes a maintenance activity, which is really what you want in this era of constant change.”

Integration and transparency are key

MDCMS technology has a central repository of both function and data, providing an overview of the whole process. It also integrates with all other technologies and tools such as Jira, Jenkins, Bamboo, Azure and DevOps.

“As an organisation, you have an overview; our technologies handle all of the components of the software development deployment with various modules. You can do it all on IBM i, control it from IBM i or make IBM i part of a bigger process.

“All stakeholders, developers and deployment mechanisms are always kept coordinated and visual. The key thing that makes us unique versus the other companies is that we have an entire REST API framework, which is part of the product.”

Customers can use this to build risk APIs.

“It makes the product completely extensible,” Milligan concludes.

“So, if you have a unique process, we can drive something that is very specific, even if it’s on a temporary basis. It’s very easy to spin up that change and make it an integral part of your automation process.”

Blue Chip has exclusive rights to MDRapid in the UK. If you’re looking to reduce IBM i downtime and would like to find out more about how we can enable your business’s IT, get in touch with the Blue Chip team.

GDPR

  • Cookies

Cookies

This website and our partners use cookies to provide you with the best experience. By clicking, “Accept” or continuing to browse, you agree to the use of cookies. Read our privacy policy here.