If you’re paying for vendor maintenance, it makes sense to use that to your advantage
Last month, I wrote a piece called “Know Where Your Maintenance Stands.” The article focused on IBM-provided maintenance. Consider this a lengthy addendum. This time, we’re talking about vendor maintenance. We’re talking about upgrade problems. We’re talking about being caught in an unsupportable nightmare. It’s a cautionary tale.
Given that IBM i 7.4 was released a few short weeks ago, I’ve been talking to many customers about when they’ll be upgrading to it. Many who’ve come to 7.3 recently feel little tension for change. Those on 7.2 feel the crunch a little bit more. They understand 7.2 is a little longer in the tooth and wanted to wait for 7.4 to make the move. And there are some stragglers on 7.1 who paid double their software maintenance this last year or so and they want to do get to 7.4. For them, we’re talking about a two-step upgrade because you can’t go directly from 7.1 to 7.4. They’ll have to go to 7.2 or 7.3 before going to 7.4.
What about shops running older versions of IBM i? They’re still out there. I brought a company from 6.1 to 7.3 in a two-step upgrade about a week ago.
What about even older than that? What if you’re on something like V5Rx? Some people are wriggling uncomfortably in their chairs while reading that sentence. Yes, there are systems out there running some V5Rx currently. And they need help.
It’s not an insurmountable feat to move people forward from those very old operating systems to modern-day supported releases. They just need supported hardware or cloud to run it on. I’ve brought a couple of V5R4 customers to 7.3 in the cloud in the last year. Luckily, passing the object observability tests weren’t an issue. In order to get to 6.1 or above, your objects must be observable. You need to have a couple of PTFs on so that the operating system knows what 6.1 is and enables you to run an Analyze Object Conversion (ANZOBJCVN). If you pass that test, your objects can be recovered to a new version. For those customers, vendor software tied to serial numbers weren’t an issue either. Some vendors base their license keys on the serial number, processor tier, processor core count, and/or even the partition ID. If something changes, the software either stops working or kicks out messages to the QSYSOPR message queue nonstop.
This is where leaving your system back on a very old release can get problematic. I’ll give you a couple of examples.
Customer X is running a POWER5 with V5R4. They wanted to move to a POWER9 and get back on IBM maintenance. The absolute first thing I did was run an Analyze Object Conversion. Lo and behold, there were issues with three vendor packages. All the custom objects were fine. So for the next few hours I acquainted myself with vendors the customer didn’t even know were still in business. I had never heard of them either, but I initiated my Google-Fu and put in some calls to vendors in the UK, Florida, and Minnesota. All three of them were still in business and were amazed at the old versions still being used in production. One of those vendors had a serial number tied to their license keys. The cost for new keys? $150 USD. The other two vendors wanted the customer back on yearly support to get the post-6.1 observable objects. The cost? $600 USD combined. And they agreed to assist with migration issues if they came up. Very reasonable. The customer has no idea how lucky they were. It could’ve been much worse.
Customer Y is also running a POWER5 but with V5R2. They have one vendor solution on the system, and everything else is homegrown. The customer tells me they wanted to move about 10 years ago, but the cost of migrating the vendor solution was too large to justify due to the manual object change work that would have to be done. So they figured they’d run out the clock on the software and system, hoping the business would find another solution. Fast-forward to 2019 and the customer is still paying hardware maintenance on this machine to IBM. The yearly cost of maintenance far exceeds the cost of the original migration. They ask me to see what I can do. They did not pass the Analyze Object Conversion test. If the vendor can help them, then they’re open to go cloud or POWER9. And the horsepower on the POWER5 is so weak compared to a POWER9 S914 that it wouldn’t take much of a machine to accept the workload.
So I track down this vendor who still exists and still supports that product as part of their “legacy” code base. The software is tied to the serial number. But the support the vendor offers isn’t on that version. It had been rebranded twice and bolted onto another package in the last 20 years. When the customer inquired 10 years ago, they were already 10 years out of support. The vendor took two days to find someone to even identify the product was something they actually made. The vendor says it would take about $1500 to put the customer back on maintenance again. Not bad. But here’s the rub: the software version is so old that they claim to be unable to even generate license keys for it anymore. That means the customer is past the point of no return. They’re left with iron too expensive to maintain, with no helping hand to get them to a less-costly solution. And their plan of running out the clock continues until they replace the product with another one, leaving IBM Power Systems behind and spending far more than if they had kept their investment up to date every couple of years.
Modernization can mean many things. Slow and steady progression is one of them. If you’re paying for vendor maintenance, it makes sense to use that to your advantage. Vendors don’t want to leave any customer behind, and many will do whatever they can to keep an existing customer. Customer X is a great example of that. There are some who are more expensive than others, and when I was a customer I hated the idea of paying money because my serial number changed. But when you look at it in retrospect, you can see the one-time cost can be a drop in the bucket compared to, like Customer Y, being 15 to 20 years out of date on both hardware and software and looking for a path forward.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online