"If it ain't broke, don't fix it."
--Anon

To finish the (admittedly somewhat lame) analogy of health clubs, once you get a regular routine, it's easier to keep at it. But why do Preventive Service Planning (PSP) at all? And why is it so much more complicated for WebSphere users? The answer to the first question is simply that the fixes are there to prevent you from running into problems others have. Most of us are not bleeding-edge users intent on inserting every new technology directly into our production processes. We leave that trailblazing to others. And one of the benefits of that choice is that IBM will make fixes available to us before we hit the same snags as those intrepid explorers. And the truth is that the vast majority of us will rarely, if ever, run into a fix from IBM that will break something already working (unlike "fixes" from other software vendors).

Author's Note: I can already hear three people (you know who you are) screaming about CPYFRMIMPF and the infamous library list fiasco. Feel free to rant and rave about these horrible transgressions in the forums, but please also compare that to the number of times you installed a new Windows service pack only to find that the machine stopped working and there was no fix short of reinstalling the operating system.

As OS/400 (now i5/OS) has evolved, the process of keeping it up-to-date has become more complex. So complex, in fact, that simply explaining the procedures will take more than one column. In this column, I'm going to define the terms that are bandied about in PSP and then show you how to use your machine and IBM's Web pages to figure out your machine's current state of health. I'll also explain why WebSphere users need to be especially careful when ordering and/or applying fixes. Finally, I'll throw in the "old fashioned" (but easy!) way of ordering the fixes.

In next month's column, I'll bring to your attention some new ordering options that you may not know about, as well as introduce you to the brave new world of image catalogs (this feature alone is worth the price of admission; someone at IBM deserves a big gold star for this baby). I'll also give you the latest information from IBM on the preferred order to apply things.

Some Definitions

Before I get into the PSP process, I think I should define a few terms for you. Even if you don't do a lot of problem reporting, you should still know these terms. And while I've heard most of them used casually or in different contexts, I think it's important to have the official definitions. First are the ways that problems are reported and tracked:

Problem Management Record (PMR)

A PMR is generated when you, the customer, report a problem to IBM. A PMR may be an educational issue that can be solved with a simple command. For example, on my new V5R3 machine, the KEYLCKPOS of my IPL attributes was shipped with a value of *MANUAL, which caused every IPL to be a manual IPL. While nobody is quite sure how this occurred, the fix is easy: Use the CHGIPLA command to change the setting to *NORMAL.

Design Change Request (DCR)

This is a fairly nebulous area, especially when products overlap the iSeries boundary (like WebSphere). WebSphere enhancement requests have at one point or another been done via DCR, first through the now-defunct Feature Request Database (FRD) and then through the Fully Integrated Tool Set (FITS), which I've actually never seen and cannot find. That aside, if you wish to ask IBM to change something in the iSeries operating system, the official route is to go to the Design Change Request page. Since you'll be asked to provide a PMR number, my guess is that it will help to have one (indicating that you have reported the problem officially).

Authorized Program Analysis Report (APAR)

An APAR is generated when, in response to a DCR or a PMR, IBM decides that a fix needs to be made to existing code. The APAR is then the instrument used to track the issue until it is resolved.

Program Temporary Fix (PTF)

The final stage of the process is the PTF. Once IBM actually writes new code to address the issue in the APAR, it is packaged as a PTF and is ready to make its way to your machine (provided the PTF is for the version of the operating system that you are running and that the associated product is installed on your box).

What's Preventive Service Planning?

PSP is the way that you get fixes and enhancements to your iSeries operating system and licensed program products like WebSphere. Back in the old days, there were really only two sets of fixes: individual PTFs, which were written in response to some sort of request, and cumulative PTF releases (or cumes), which were semi-regular packages of all the PTFs for a given version of the operating system.

Cume releases are pretty extensively tested. IBM doesn't put out a new cume lightly; it is expected that the vast majority of iSeries owners will be able to apply a cume release with little fear of compromising their system. So in the simpler, gentler times of yore, you might just apply the cume a couple of times a year and maybe have to apply an individual PTF if you reported a specific problem.

Not So Simple Anymore

Since then, things have gotten a bit more complicated with the introduction of "group PTFs," which are packages of related PTFs for a given product. The idea is that, rather than apply one humungous cumulative fix package that includes all possible fixes, you instead just grab the groups that your particular system needs. Additionally, group PTFs are sent out more frequently, especially for newer products that have needed a little more "shakeout" than others (WebSphere Application Server comes to mind).

Group PTFs usually add features and fix leading-edge problems with things like SQL or WebSphere. If you run vanilla RPG applications, you might never apply a group PTF. But if you're doing extensive Java work, you might need to apply the Java group PTF on a regular basis.

There is also a unique set of PTFs known as the "High Impact and PERvasive" fixes (HIPERs). HIPERs fix really nasty bugs and are put out quickly, often fixing other PTFs. Unfortunately, because of the short cycle nature of these PTFs, HIPERs seem to be a little more prone to being defective, typically breaking something unrelated to the original problem. Even if you're keeping completely current on group PTFs, it might still be prudent to not apply the HIPERs unless you need specific fixes.

Prudent vs. Proactive

I want to emphasize that the occurrence of PTFs that break things is very small. While a couple of iSeries customers out there (and you know who you are!) seem to regularly break the operating system, the vast majority of us will probably never run across a PTF that, when applied, causes us to lose productive time. Unlike desktop operating systems in which a service pack sometimes renders the entire system inoperative, iSeries PTFs almost never introduce problems. But that still doesn't mean you need to apply every PTF that comes out, either. Like so many things in IT, this is a business decision. And no matter how clean the process, there is still a non-zero amount of time required to apply these PTFs; some even require an IPL. So it is important to make a conscious analysis of which PTFs are appropriate for your business and how often you should apply them.

So What's Available?

The next step in the process is to find out which PTFs are available and see how this compares to your current machine. The easiest way to do that is to go to IBM's PSP site. You can go to Google and search on Preventive Service Planning, or just go here. In either case, you'll get to the Web site shown in Figure 1.

Cumulative Release First

Figure 1: Click on the top link at IBM's Preventative Service Planning Site. (Click images to enlarge.)

Clicking on the top link will take you to the main menu of the PSP system, pictured in Figure 2.

Figure 2: This page shows all PSP documents; select Current Cumulative PTF Package.

From here, select Current Cumulative PTF Package; this will expand to show the recent releases. Select yours, as shown in Figure 3.

Figure 3: The Cumulative PTF Package list is expanded; select your release.

Figure 4: This is the cover letter for the R530 cumulative PTF package.

You'll finally get to the cover page, as shown in Figure 4. Note the big red circle I added to the picture; this shows the current release number. It's actually a combination of the date (the 207th day of 2005) and the release, 530. You'll see why that's important momentarily.

Then, the Group PTFs

The next thing to do is to find out which group PTFs are available. Go back to the page in Figure 1 and click on the All Group PTFs by Release to get to the release page shown in Figure 5.

Figure 5: Go to Group PTFs for recent releases.

From here, click on the appropriate release. In Figure 5, I'm clicking on the R530 link to get the V5R3M0 group PTF list.

Figure 6: Each release has a list of the available group PTFs and their current levels.

Now you have a list of all the available group PTFs. Pay special attention to the Group Level number, which gives you a quick overview of the current state of the PTFs.

What Do I Need?

There is now a command on the iSeries, Work with PTF Groups (WRKPTFGRP, as of V5R2, I believe), that provides information for your machine, as shown in Figure 7.

Figure 7: The WRKPTFGRP command shows your machine's PTF levels.

Note that the list for my machine does not contain every product; that's because I don't have every product installed on my machine. WRKPTFGRP shows only those products installed on your iSeries.

The cumulative package is shown at the top, in my case it is SF99530, since I'm on R530 (V5R3M0) of i5/OS. Notice that the release number is very large, 5207. Do you recognize that number? It's the calculated date number from the cumulative package, which is currently at C5207530, or the 207th day of 2005 (August 8). I'm up-to-date on that one. In fact, a quick comparison of my machine vs. the data in Figure 6 shows that I'm current on everything except the very latest HIPERs, which just came out on November 1.

The Joys of WebSphere

OK, now you should be able to create a list of the groups PTFs you need to order. However, there are two additional complications that get thrown into the mix. The first is that ordering a WebSphere group PTF (for example, SF99272, which is the group PTF for WebSphere Application Server Express Version 5.1) automatically orders a number of other PTFs. These include the DB2 group (SF99503), the HTTP group (SF99099), the Java group (SF99269), and the business solutions group (SF99173). This makes for a very large package, typically around 4 GB. This will become important when you have to make decisions about delivery mechanisms.

Because the group is so large, if you have multiple versions of WebSphere installed on your machine, you might be tempted to get the group PTFs for each version separately. Don't do it! Why? Because each WebSphere group will also include a copy of the additional groups I mentioned above. Instead, be certain that, no matter how you order your PTFs, you order the groups for all of your WebSphere version on the same order. When you do, IBM is smart enough to combine those orders and ship you all the WebSphere groups but only one copy of the additional groups. The down side is that this single order can easily be 5 to 6 GB or more.

Now Let's Get the PTFs!

There are a number of ways to get PTFs these days. One of my favorites is still the old tried-and-true method of faxing a request to the IBM Support Family Services. I've been using this method for years, and I generally get my PTFs on nicely packaged media in a couple of business days. In my next column, I'll show you some other ways, including Fix Central and SNDPTFORD. I'll also show you how to apply the PTFs once you get them. But in the interests of keeping this readable at one sitting, I'll just end on this particular topic.

Regardless of the ordering technique, you still need to determine which PTFs to get. Using the WRKPTFGRP screen from Figure 7, you simply cross-reference against the current group list on Figure 6 and decide which groups you need. Similarly, you can check your current cume version (the top line of WRKPTFGRP) against the red circled area of the page in Figure 4. Then you build your list. In my case, let's assume that, instead of being nearly up-to-date, all of my groups were old. I would end up with the following list:

I need to make a few adjustments. First, I need to decide whether I want the HIPER or not. Let's assume I do, just for the sake of argument. Then, I have to remove all duplicate groups. As I explained earlier in the column, since I am ordering at least one WebSphere group, I won't need to order any of the following: SF99503, SF99269, SF99173, or SF99099. That leaves me with SF99530, SF99529, SF99301, SF99275, and SF99272. Also, I want to make sure I order all the WebSphere groups together, so as not to get duplicate copies of the groups that are automatically included. Figure 8 shows a PDF version of the document I would use to order the PTFs (I left out my customer number and the serial number of my machine).

Figure 8: This is the old-fashioned, tried-and-true PTF order form that has worked for years.

I am attaching a copy of this document as a Word document that you can use to make your own PTF orders.

Coming Soon

In my next column, I will show you other ways to order PTFs, but frankly, for large orders like this (this is perhaps 10 GB of PTFs), it's easier to have IBM send you the CDs than it is to attempt to download them. Not only that, but I'll show you how (as long as you have the space) you can upload all the PTFs to your machine and apply them at one time using an image catalog.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Joe Pluta available now on the MC Press Bookstore.

		Developing Web 2.0 Applications with EGL for IBM i Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform. List Price $39.95 Now On Sale
		WDSC: Step by Step Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95 Now On Sale
		Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00 Now On Sale

Also Read

Legacy application modernization: A comprehensive approach to modernize your business

How Low Code Helps Businesses Modernize their IBM i Apps

Why Migrate When You Can Modernize?