Point and modification releases to IBM i have given way to the Technology Refresh, but nothing can replace a good program-maintenance strategy.

The term PTF, or "program temporary fix," has been part of the IBM vernacular for many years. It goes along with the conservative image Big Blue has cultivated of assigning a dignified term to what any other software developer would call a "bug fix." In years past, customers used to say that PTF stood for "permanent temporary fix" or "probably this fixes" since the PTF would become a permanent part of the software—if it actually fixed the customer-reported problem.

Back then, PTFs were gingerly applied to production systems and usually only after weeks of customer testing, but today's PTFs have been rigorously tested in the lab and usually are applied without incident. Every once in awhile, however, someone will have to back out of an update, since every system is unique.

As the pace of advancing technology has quickened, IBM has started to use PTFs as a way to lengthen the life of a given version of software, particularly the operating system. Realizing that upgrading to a completely new version of the OS can be disruptive and costly (particularly after the release of IBM i 6.1), IBM has chosen instead to release to the IBM i community what it is now calling Technology Refreshes. The Technology Refresh has replaced the former point and modification releases as a new release delivery mechanism. Technology Refresh is a collection of operating system software that has been developed, packaged, tested, and delivered all together as a PTF Group for a base release.

Technology Refresh essentially is licensed internal code that actually becomes part of the code stream of that version of the operating system, rather than a separate stream as for a point release. And even after installing the Technology Refresh, the system release level doesn't change. As of the release of IBM i 7.1, the company is using this approach to provide support for new hardware and firmware, new virtualization capabilities, performance improvements, and new-function enablement.

While trade-group presentations and IBM blogs make it sound as though all IBM i updates now are bundled under the Technology Refresh banner, it's not quite as clean as one might hope. Actually, there are different sets and subsets within the Technology Refresh umbrella, so it still can be a bit confusing, though the message of how you figure out what you're supposed to do and how to do it has improved greatly. Nevertheless, there still is the Technology Refresh PTF, Technology Refresh PTF Group (which includes related PTFs), the Technology Refresh Requisite (dependent PTFs), General Availability Resave (a machine code version for faster installation), the cumulative package (probably the same as the Refresh Group), Managed Add Function PTFs, "other" PTFs, and "other functions" that are released to the Refresh GA at the time.

There is a graphic on Page 12 of the new IBM i 7.1 Technical Overview with Technology Refresh Updates Redbook describing how the different PTFs interrelate. No comment is needed as I believe the diagram speaks for itself!

Figure 1: The IBM Redbook graphic depicts the interrelationship between various kinds of PTFs.

Needless to say, users continue to have questions about what they are supposed to do to keep their IBM i systems up to date. They want to know what's included in a cumulative PTF package, what the categories of fixes are, how you can tell which PTFs have already been applied, how you determine which Technology Refresh PTF Group is installed, how you order fixes over the Internet, etc.—answers to which may be found in the Guide to fixes overview on the IBM Web site.

We can't move past the question of PTFs and Technology Refreshes without touching on Resaves and Marker PTFs.

Also known as a "respin," a Resave generally is available now with each Technology Refresh on IBM i. It is an IBM term that means the re-creation of operating system and/or licensed internal code for a given release. It's often machine code, but it's now regularly being used for IBM i. A Resave can be applied to support new hardware, provide critical fixes in the system install media, apply fixes to the IPL path, or, more commonly, speed up installation time for large PTF groups.

A Marker PTF is one that can appear in the system only if the PTF has been installed with an IBM-supplied Resave. Markers are cumulative, so systems may have more than one. The highest Marker PTF number shows what level Resave has been installed.

Taking a big step back for a minute, if there is one single idea that you leave with after reading this article, it needs to be the notion that a managed system—one in which someone regularly applies PTFs and Technology Refreshes, and does so often—is the system that is far less likely to unexpectedly fail. The system administrator needs to have a management strategy for fixes in order to avoid unplanned outages. If you don't have a "program-maintenance strategy," you probably don't have good program maintenance. And you probably just as likely don't know when you need to change the oil in your car.

According to IBM (and who would know better?) three out of four defect-related problems users report are "rediscoveries" of previously reported problems. Thus, a user could have avoided the outage (and the service call) just by applying an already available fix. By keeping up with the PTFs, you will reduce system downtime, add functionality, and provide optimal system availability.

You have to ask yourself if you are the type of person who applies fixes only after a failure occurs. And you should take into account your environment; some systems simply can't go down. Do you like to run the very latest software release—or an earlier version that has been proven stable?

If you are a system administrator, you will have daily, weekly, and either monthly or quarterly duties to keep your system running smoothly and avoid downtime and data loss. You might apply new fixes daily at the same time you run a backup. Then, weekly, you will order and review PTFs and PTF cover letters, order and apply HIPER PTFs (high impact pervasive fixes), and review your hardware error log. Monthly (or quarterly), you will order cumulative PTF packages or PTF Group packages and apply them before doing a complete system save. And you probably will do a few system-cleanup functions then. It's a good idea to apply all outstanding PTFs before you do any system upgrades. More on that can be found at the IBM Prerequisite Web site.

If you have a number of systems to maintain, you may want to invest in System i Navigator, a Windows client packaged as part of the iAccess for Windows product. It is the more traditional system management console but continues to be supported. Within it resides Management Central, which allows you to send, install, and uninstall PTFs on multiple systems. There is also a compare-and-update wizard to compare a model system against multiple target systems.

So the new Technology Refresh initiative for IBM i will help system managers keep up to date with their maintenance PTFs as well as PTFs to enhance system functionality. But the lion's share of the work still will fall on the shoulders of the administrator. Hopefully, just knowing that IBM is working to make your job easier will inspire you to create a program maintenance plan and stick to it.

Chris Smith was the Senior News Editor at MC Press Online from 2007 to 2012 and was responsible for the news content on the company's Web site. Chris has been writing about the IBM midrange industry since 1992 when he signed on with Duke Communications as West Coast Editor of News 3X/400. With a bachelor's from the University of California at Berkeley, where he majored in English and minored in Journalism, and a master's in Journalism from the University of Colorado, Boulder, Chris later studied computer programming and AS/400 operations at Long Beach City College. An award-winning writer with two Maggie Awards, four business books, and a collection of poetry to his credit, Chris began his newspaper career as a reporter in northern California, later worked as night city editor for the Rocky Mountain News in Denver, and went on to edit a national cable television trade magazine. He was Communications Manager for McDonnell Douglas Corp. in Long Beach, Calif., before it merged with Boeing, and oversaw implementation of the company's first IBM desktop publishing system there. An editor for MC Press Online since 2007, Chris has authored some 300 articles on a broad range of topics surrounding the IBM midrange platform that have appeared in the company's eight industry-leading newsletters. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..