Who said it ain't broke? We need to check our sources. Plus, in the world of information systems, we need to assume everything, while not necessarily broken, can always be improved.

Why Do PTFs?

Last week on Midrange.com, I was happily surprised to see a thread entitled "If everything is working fine, why do PTFs?"

"Happily" is probably the wrong word. Thankfully ecstatic is what I am. Not because of the question but because of the answers.

To provide some context, the original thread began with this post from Paul Nelson:

"If everything is working fine, why do PTF's?

This is a question I got from a client yesterday. I seem to recall somebody posting a link here some years ago to justify staying reasonably current.

He wants more than just the standard arguments about IBM insisting that one be at a certain level, et cetera, et cetera. It went right over his head when I asked him if he changes the oil in his car on a regular basis. He lives in the city and doesn't own a car.

Please chime in."

Almost all of the posts that followed were affirming the value of PTF applications and keeping current in general. That's awesome! From this little survey, we see a majority of people understand that keeping current is the equivelent of "an apple a day keeps the doctor away." Except this apple is constantly improving its taste, smell, and nutritional value.

The "if it ain't broke" argument isn't valid if you're not reading the PTF details, and that, in keeping with the medical theme, is the equivalent of not bothering to get a regular doctor checkup because you're not showing symptoms of anything serious. Meanwhile, your cholesterol could be through the roof. It may sound a little harsh for me to say, but the "if it ain't broke" argument in the context of information systems patching is being willfully ignorant in the face of hard evidence. If we look at the list of Group HIPER PTFs for IBM i 7.1, we will find dangerous "hard stop" APARs that are prevented by PTFs. We'll find APARs about IPL failure, disk failure, fibre channel adapter failures, RAID problems...this is pretty severe stuff. Outside of the "hard stop" problem prevention, other PTFs contain standard bug fixes. All the minor issues, nuances, problems, or whatever you want to call them get addressed and repaired, either by customers finding and reporting them or IBM finding and repairing them first. Many of us probably don't recognize most of those as problems because we keep on the bleeding edge of PTF application, we haven't come across them yet, or perhaps they don't apply to how we individually interact with IBM i. Either way, they do get fixed.

But it ain't broke, right?

I usually make a big deal about the importance of PTF application from time to time, usually when there's a snazzy new HTTP server or Java update or most definitely a Technology Refresh that's about to go live. Those are the advancements paid for by our yearly SWMA charges. My argument has always been "if we're paying for it, we should use it." I won't go into all the details because I've covered the topic heavily in the recent past. Have a look at my article PTFs: How to Manage Them and Why You Need To for details.

While Mr. Nelson and the majority of posters were certainly from the "keep it current" camp, the ones we need to reach are the "steady as she goes" crowd.

I did some work for a shop a few years ago that ran a little AS/400e Model 250 for forever and a day. I remember their IT director stating things like:

"It just sits there and runs."

"There's no need to patch it."

"We'll upgrade it when it dies."

That little 250 sat there and ran for a long time.

Then it died.

It was neither a peaceful nor dignified passing. It was entirely preventable with some, if I recall correctly, DASD-related PTFs that were never applied, let alone deliberated.

The real head-shaker: They hadn't brought the system down for a full system save in four years, and the backup job was omitting about 1/4 of the objects that should've been saved. The recovery, if you could call it that, was a horrendous experience for all involved.

Another "past life" example is when my old shop purchased a shiny new propane generator with enough fuel to keep the company going for two weeks without needing the tanks refilled. As long as we had propane delivery, we'd still be in business. The maintenance guys would fire that loud sucker up every week for 60 seconds to make sure it ran. Every month, they'd cut the power to the server room to ensure the systems would failover to the UPS for a few seconds before the generator would kick in and pick up the power slack. That test would take about 10 minutes or so.

Since we were located in Eastern Canada, it was only a matter of time before we had a major snowstorm. This particular storm knocked out our power for three days. The generator lasted about 25 minutes...because nobody was assigned the task to check the oil level.

PTF application, in my humble opinion, should be mandatory at the IBM i operating system software, security, and Licensed Internal Code levels, along with Technology Refreshes, while other PTF Groups are optional. It will probably never happen because it's recommended to have a full system save before applying those. However, I haven't had a CUME application cause a major system outage. Ever. Having those important PTFs auto-downloaded and marked for delayed application on the next IPL would be very, very useful. Since the likelihood of that happening anytime soon is as remote as a Chicago Cubs World Series parade, it's up to the IBM i community (customers, IBM Business Partners, Independent Software Vendors, hardware resellers, and IBM itself) to promote the mindset that PTF application should happen on a regular basis and that two very valid arguments for it exist.

The first argument is to take advantage of the many new features that will help our businesses. I'm actually looking forward (stoked even!) to update my HTTP Group PTF this weekend so I can take advantage of some performance improvements and feature updates included within. Steady as she goes? We're in IT. We're supposed to be doing things bigger, better, and faster. Getting those PTFs on is a real luxury that we can't afford not to have.

The second argument is that as bulletproof as IBM i is, it is not entirely infallible. It's an operating system written by humans. It does need patching. It does need maintenance. Somebody somewhere could've had a major system issue that was fixed by way of a PTF. We don't want to be the person who could've done a very small amount of work to ensure our systems wouldn't succumb to the same fate...but didn't.

Test critical and backup systems. Top up the fuel levels. Check the oil. Replace the batteries in the smoke detectors. Put child safety locks on the cupboards. Buy a scratching post so your cat doesn't claw up your couch. I realize the gentleman who was referred to on the Midrange post doesn't drive, so whatever analogy works for him, I'd respectfully ask that he please use it.

A little thorough preventative maintenance will go a long way.

Steve Pitcher works with iTech Solutions, an IBM Premier Business Partner. He is a specialist in IBM i and IBM Power Systems solutions since 2001. Feel free to contact him directly This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

IBM i Shops Pivot to Battle COVID-19

Energy, Vibe, and Atmosphere

Murphy’s Security Law