Managing IBM i PTFs in the New Millennium

IT Infrastructure - Other
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

PTF processing has gotten more complex, but the tools have gotten better as well.

By Joe Pluta

Unless you're running one of the old beige boxes in a closet somewhere (and don't kid yourself, some of those still exist), then PTFs are the lifeblood of your system. PTFs for the i are a bit different than for most of the rest of the world; they're not the necessary evil of the Windows world, where you need to constantly apply fixes just to keep your machine from dying a horrible death and taking your business with it. Instead, they're usually more of a force for good, providing additional features and better performance, especially for the more advanced capabilities such as Web applications and relational database access.

PTFs in the Olden Days

I find it interesting that nowadays I know more about the operation of the machine than I did in the past. This is different than most things--like, say, my car. When I was a carefree youth, I knew how to get my 1972 Buick Electra 225 running with a matchbook cover and an eraser; these days, the engine light goes on and it's a trip to the mechanic.

 

With the System/3x and even the early AS/400s, most of the operations activities were handled by other folks; I was just a programmer. During the SSA years, being as I often worked the night shift, I did my share of operations activities, including applying PTFs, but to be honest it was unusual for me to mess with that sort of thing. These days, since I have machines of my own, I need to know all of this; I've even replaced the disk drives on my old Model 270. It's a good thing, then, that IBM has continued to pour lots of money into this particular area, especially since the process has become much more complicated over the years.

 

In days of yore, we ordered PTFs, got a tape, and assigned a weekend to applying it. This was the full system backup weekend. While the daily backup procedure has changed quite a bit over the years, especially with the availability of cheap terabyte and even petabyte storage, the system backup is still pretty much the same concept: drop the machine, save everything, save it again in case the first save is corrupted, and then bring the system back up. Since it was a long-running process, it was something you didn't just do off the cuff; once a month usually worked out pretty well. On PTF weekends, we added a few more steps, including applying PTFs and doing another system save; thus we tried to limit PTF application to once a quarter.

 

And for the most part, this worked out fine. On rare occasions, you ran into a bug that was so horrendous that you needed an immediate fix, so you would apply it as soon as possible, but that was a rare occasion indeed. In general, though, you never thought of PTFs individually; they came in a big blob on a tape and you applied them all and went on with your business. It was a simpler, gentler time....

The Brave New PTF World

I don't even know if we called them "cumulative PTFs" back then, but that's what they were. A cumulative PTF (also known as a "cume") contains all the PTFs since the release of the operating system, and originally that was all a midrange shop ever really needed. Cumes were issued a few times a year, and we applied them on roughly the same schedule. That is, if we were good, although the stability of the operating system was such that cumes were often overlooked in accordance with the "if it ain't broke" rule.

 

This stopped being enough a while back. Right about the time that the system moved from essentially a closed system of RPG and a proprietary database and instead became a super-open machine with Java and UNIX and WebSphere and SQL, IBM also began delivering system updates via "group PTFs." You can argue the cause and effect relationship of complexity and stability, but the truth is that the system has so much more functionality that it requires more fixes and upgrades. I can't think of a single business computer that is as complex as an IBM i, so I guess I don't begrudge it the additional software support required.

 

Group PTFs (or simply "groups") are released more regularly than cumes. I assume the name comes from the fact that the PTFs are not for the entire system, but are instead grouped together, each group relating to a specific area of the system. For example, the Java runtime has its own group PTF; this allows you to apply all the fixes for Java in one shot without having to go through an entire cume. Why would you do this? Because, in theory, all of the PTFs in a group have been tested together and will bring your system to a "known" state, whereas if you applied PTFs individually you might install one that interacted unpredictably without the presence of another one. Typically, such dependencies are handled by the PTF process--individual PTFs have prerequisites and co-requisites for just this purpose--but software gets more and more complex, and things do slip through. In order to avoid possible side effects, I recommend that unless advised specifically by IBM to install an individual PTF, always install PTFs using groups and cumes.

 

This interdependency will only continue to grow; some i software is now so inextricably linked that certain groups automatically install other groups. The WebSphere group, for example, installs a variety of other groups, including the Java group, the DB2 group, and the HTTP group, among others.

 

Given these interdependencies, you might wonder why you would install groups at all. Why not just install cumes three or four times a year? The reason is that group PTFs are more responsive. Groups show up monthly or even weekly in the case of the really serious ones. The most serious ones are the ones known as the HIPER group. When I first saw the term, I thought HIPER meant HIgh PERformance, but it really means High Impact PERvasive, which is simply IBM jargon for "really serious." You should review these PTFs regularly to see if PTFs exist that are pertinent to your environment. Data loss and security issues usually fall into this group. But other groups, especially those for WebSphere and database, often provide performance enhancements that make life better for your end users, so staying current is a good idea.

PTF Delivery

The best thing about PTFs is that IBM has really spent a lot of time on the PTF delivery process. Delivery mechanisms exist to fit just about every shop, ranging from old-fashioned mailed on media to the latest and greatest electronic delivery.

 

Since I have a relatively slow communications line, I can't realistically use electronic delivery. For example, take the latest cume package for V5R4, release number C8305540 released on November 11, 2008. (Note that you can actually tell the version and date from the name: the second character is the year, 2008; the next three are the Julian day, 305; and the last three digits are the version/release/modification level, 540.) Anyway, that release is about 8GB in size, and on my connection that's literally days of download. So I prefer the old-fashioned media method.

 

On the other end of the spectrum, you can use the SNDPTFORD command from a command line to connect directly to IBM and download fixes right to your i. It's fast and easy and doesn't require much intervention on your part. Your biggest decision here is whether to use save files or optical images, something I'll touch on again momentarily. If you choose the save file route, you can immediately install the PTF using the standard GO PTF menu; optical images require a little more work.

 

You might not want to use this method, though. For example, you may want to install PTFs on multiple machines or you might need to save the PTF packages on offline storage (in case you have to reapply them--say, after a scratch install). For these situations, IBM has yet another option available in the form of IBM Fix Central, which, as its name suggests, is a central repository of fixes. This is a nicely designed site that walks you through the process of ordering PTFs and making them available for download. The server at IBM will package up all the software very nicely and then make it available for you for download. And as if that weren't enough choice, you can even choose how to download the packages, either via traditional FTP client or through the more automated Download Director.

 

FTP is pretty simple: IBM creates a directory on its server that you can access to pull down the data and then sends you an email with the information detailing where the fix package is located. You use the standard FTP client on the i, or, if you're so inclined, you can easily create an FTP script to pull down all the data. Lots of people have done this already. The FTP-to-the-i route is a little older technologically speaking and has been superseded by the SNDPTFORD command, but some people prefer the control of FTP and they've already got procedures in place. Alternatively, you can use any of the freeware or shareware FTP client programs and download the software to a PC or to a network drive.

 

Download Director is even easier. It's a Java applet that runs inside your browser and manages the entire download process. Like a very focused version of an FTP client, it's very good about restarting and allowing you to pause the download or even restarting in case of a connection failure.

 

Either way (FTP or Download Director), you end up with a bunch of .bin files in a folder somewhere, which leads us to the last topic, applying the PTFs.

Applying PTFs

Back in the olden days when media was the only option, you actually installed directly from the tape. In more recent years, you install from optical media, but the idea is the same: you insert the media and start a process that installs the software directly from the media. The single biggest problem with this approach occurs when you have a media error. Since packages can span a dozen disks, it's possible (and very painful) to get an error on disk number eight after hours and hours of work.

 

IBM has gotten around that particular problem with the introduction of the virtual optical drive and the image catalog. A virtual optical drive is what it sounds like: a virtual device that takes the place of an optical drive but that can be pointed to a specific folder to get its data. The process is pretty simple, involving several commands:

 

  •   CRTDEVOPT: Create a virtual device. Use the option RSRCNAME(*VRT).
  •   CRTIMGCLG: Create an image catalog, which is basically a folder where the fix package will reside.
  •   ADDIMGCLGE: Add data from a disk into the catalog.

 

Let me pause a moment here to explain how the worlds of mailed media and download media intersect. The ADDIMGCLGE command has two formats, physical media and electronic media. In the physical media version, the DEV keyword is used to identify the optical device where the media is located. You run this command for each disk. The electronic media version uses a FROMFILE keyword and assumes that you've loaded the files you downloaded using FTP or Download Director into a folder accessible to the i. This would be an IFS folder to which you've copied the files (in fact, I suppose it could be a QNTC folder, which actually represents a connection to another machine on the network, although I've never tried that).

 

In either case--physical or electronic delivery--you end up with an image catalog containing all of the disks from your PTF package. At this point, the real magic occurs, because you now run a command called VFYIMGCLG that runs through all of the disks and makes sure no bits got twiddled or that you tried to install a copy of Sim City into your i. In the physical media world, this process--loading the data from the disks and then verifying the entire catalog--is a wonderful protection against bad media.

 

And finally, you run the magic PTF installation option: GO PTF, option 8. From this point on, the installation chugs through the entire installation process, not requiring anything from you other than time. Most importantly, you don't have to switch disks. And those who have been following along here may have realized that, as long as everything goes well, you can theoretically do this entire process remotely--especially if you download the media, since it's simply a matter of copying the package to the target machine's IFS and then creating an image catalog. And even for those like me who need physical media, all is not lost: the packages that you download from IBM are actually nothing more than the ISO images of the disks that they would mail you. You can create an image from optical media on any PC using a standard CD ripping tool, such as Roxio, and then treat those images the same way you would the electronically downloaded media (conversely, you can download the media and burn them to CD; just remember that the PC packages typically use the extension .iso, while the files downloaded from IBM will have a .bin extension).

 

Now, be warned: you shouldn't do this process unless you have a Plan B to be able to access the machine in case of a catastrophic error. On rare occasions, applying a PTF has been known to cause a machine to fail on IPL, or even more annoying, the IPL required by a PTF has been just enough to send a piece of hardware over the edge, and at that point you're probably going to have to visit the machine physically. The moral of the story is that even though you may not have to be there, don't absolutely count on not having to be there, lest you tempt Murphy and his minions.

A Last Visit to SNDPTFORD

There may still be times when you need to get a single PTF. The last time I did it was to get the ANZOBJCNV tool to test my application for V6R1 compatibility. SNDPTFORD straddles the line between the old technology and the new by providing support for image catalogs but also skipping them and using the standard download, load, and apply procedure. This support is made available via the DLVRYFMT parameter; if you specify *IMAGE on this parameter, you'll get an image file that can then be loaded into an image catalog. Otherwise, the PTF will be retrieved as a save file, and you use the traditional LODPTF (option 1 from the GO PTF menu) followed APYPTF (option 2).

So Many Choices...

To summarize, then, IBM provides a wide range of PTF support options. The processes support all of your basic business goals--from keeping current on cumulative releases to installing specific individual fixes--and the technology provides options for any size of shop with just about any skill level. And we haven't even addressed the capabilities of centralized support using Management Central or the new complexities introduced by the Hardware Management Console (HMC). More material for another day...

PTF processing has gotten more complex, but the tools have gotten better as well.

By Joe Pluta

Unless you're running one of the old beige boxes in a closet somewhere (and don't kid yourself, some of those still exist), then PTFs are the lifeblood of your system. PTFs for the i are a bit different than for most of the rest of the world; they're not the necessary evil of the Windows world, where you need to constantly apply fixes just to keep your machine from dying a horrible death and taking your business with it. Instead, they're usually more of a force for good, providing additional features and better performance, especially for the more advanced capabilities such as Web applications and relational database access.

PTFs in the Olden Days

I find it interesting that nowadays I know more about the operation of the machine than I did in the past. This is different than most things--like, say, my car. When I was a carefree youth, I knew how to get my 1972 Buick Electra 225 running with a matchbook cover and an eraser; these days, the engine light goes on and it's a trip to the mechanic.

 

With the System/3x and even the early AS/400s, most of the operations activities were handled by other folks; I was just a programmer. During the SSA years, being as I often worked the night shift, I did my share of operations activities, including applying PTFs, but to be honest it was unusual for me to mess with that sort of thing. These days, since I have machines of my own, I need to know all of this; I've even replaced the disk drives on my old Model 270. It's a good thing, then, that IBM has continued to pour lots of money into this particular area, especially since the process has become much more complicated over the years.

 

In days of yore, we ordered PTFs, got a tape, and assigned a weekend to applying it. This was the full system backup weekend. While the daily backup procedure has changed quite a bit over the years, especially with the availability of cheap terabyte and even petabyte storage, the system backup is still pretty much the same concept: drop the machine, save everything, save it again in case the first save is corrupted, and then bring the system back up. Since it was a long-running process, it was something you didn't just do off the cuff; once a month usually worked out pretty well. On PTF weekends, we added a few more steps, including applying PTFs and doing another system save; thus we tried to limit PTF application to once a quarter.

 

And for the most part, this worked out fine. On rare occasions, you ran into a bug that was so horrendous that you needed an immediate fix, so you would apply it as soon as possible, but that was a rare occasion indeed. In general, though, you never thought of PTFs individually; they came in a big blob on a tape and you applied them all and went on with your business. It was a simpler, gentler time....

The Brave New PTF World

I don't even know if we called them "cumulative PTFs" back then, but that's what they were. A cumulative PTF (also known as a "cume") contains all the PTFs since the release of the operating system, and originally that was all a midrange shop ever really needed. Cumes were issued a few times a year, and we applied them on roughly the same schedule. That is, if we were good, although the stability of the operating system was such that cumes were often overlooked in accordance with the "if it ain't broke" rule.

 

This stopped being enough a while back. Right about the time that the system moved from essentially a closed system of RPG and a proprietary database and instead became a super-open machine with Java and UNIX and WebSphere and SQL, IBM also began delivering system updates via "group PTFs." You can argue the cause and effect relationship of complexity and stability, but the truth is that the system has so much more functionality that it requires more fixes and upgrades. I can't think of a single business computer that is as complex as an IBM i, so I guess I don't begrudge it the additional software support required.

 

Group PTFs (or simply "groups") are released more regularly than cumes. I assume the name comes from the fact that the PTFs are not for the entire system, but are instead grouped together, each group relating to a specific area of the system. For example, the Java runtime has its own group PTF; this allows you to apply all the fixes for Java in one shot without having to go through an entire cume. Why would you do this? Because, in theory, all of the PTFs in a group have been tested together and will bring your system to a "known" state, whereas if you applied PTFs individually you might install one that interacted unpredictably without the presence of another one. Typically, such dependencies are handled by the PTF process--individual PTFs have prerequisites and co-requisites for just this purpose--but software gets more and more complex, and things do slip through. In order to avoid possible side effects, I recommend that unless advised specifically by IBM to install an individual PTF, always install PTFs using groups and cumes.

 

This interdependency will only continue to grow; some i software is now so inextricably linked that certain groups automatically install other groups. The WebSphere group, for example, installs a variety of other groups, including the Java group, the DB2 group, and the HTTP group, among others.

 

Given these interdependencies, you might wonder why you would install groups at all. Why not just install cumes three or four times a year? The reason is that group PTFs are more responsive. Groups show up monthly or even weekly in the case of the really serious ones. The most serious ones are the ones known as the HIPER group. When I first saw the term, I thought HIPER meant HIgh PERformance, but it really means High Impact PERvasive, which is simply IBM jargon for "really serious." You should review these PTFs regularly to see if PTFs exist that are pertinent to your environment. Data loss and security issues usually fall into this group. But other groups, especially those for WebSphere and database, often provide performance enhancements that make life better for your end users, so staying current is a good idea.

PTF Delivery

The best thing about PTFs is that IBM has really spent a lot of time on the PTF delivery process. Delivery mechanisms exist to fit just about every shop, ranging from old-fashioned mailed on media to the latest and greatest electronic delivery.

 

Since I have a relatively slow communications line, I can't realistically use electronic delivery. For example, take the latest cume package for V5R4, release number C8305540 released on November 11, 2008. (Note that you can actually tell the version and date from the name: the second character is the year, 2008; the next three are the Julian day, 305; and the last three digits are the version/release/modification level, 540.) Anyway, that release is about 8GB in size, and on my connection that's literally days of download. So I prefer the old-fashioned media method.

 

On the other end of the spectrum, you can use the SNDPTFORD command from a command line to connect directly to IBM and download fixes right to your i. It's fast and easy and doesn't require much intervention on your part. Your biggest decision here is whether to use save files or optical images, something I'll touch on again momentarily. If you choose the save file route, you can immediately install the PTF using the standard GO PTF menu; optical images require a little more work.

 

You might not want to use this method, though. For example, you may want to install PTFs on multiple machines or you might need to save the PTF packages on offline storage (in case you have to reapply them--say, after a scratch install). For these situations, IBM has yet another option available in the form of IBM Fix Central, which, as its name suggests, is a central repository of fixes. This is a nicely designed site that walks you through the process of ordering PTFs and making them available for download. The server at IBM will package up all the software very nicely and then make it available for you for download. And as if that weren't enough choice, you can even choose how to download the packages, either via traditional FTP client or through the more automated Download Director.

 

FTP is pretty simple: IBM creates a directory on its server that you can access to pull down the data and then sends you an email with the information detailing where the fix package is located. You use the standard FTP client on the i, or, if you're so inclined, you can easily create an FTP script to pull down all the data. Lots of people have done this already. The FTP-to-the-i route is a little older technologically speaking and has been superseded by the SNDPTFORD command, but some people prefer the control of FTP and they've already got procedures in place. Alternatively, you can use any of the freeware or shareware FTP client programs and download the software to a PC or to a network drive.

 

Download Director is even easier. It's a Java applet that runs inside your browser and manages the entire download process. Like a very focused version of an FTP client, it's very good about restarting and allowing you to pause the download or even restarting in case of a connection failure.

 

Either way (FTP or Download Director), you end up with a bunch of .bin files in a folder somewhere, which leads us to the last topic, applying the PTFs.

Applying PTFs

Back in the olden days when media was the only option, you actually installed directly from the tape. In more recent years, you install from optical media, but the idea is the same: you insert the media and start a process that installs the software directly from the media. The single biggest problem with this approach occurs when you have a media error. Since packages can span a dozen disks, it's possible (and very painful) to get an error on disk number eight after hours and hours of work.

 

IBM has gotten around that particular problem with the introduction of the virtual optical drive and the image catalog. A virtual optical drive is what it sounds like: a virtual device that takes the place of an optical drive but that can be pointed to a specific folder to get its data. The process is pretty simple, involving several commands:

 

  •   CRTDEVOPT: Create a virtual device. Use the option RSRCNAME(*VRT).
  •   CRTIMGCLG: Create an image catalog, which is basically a folder where the fix package will reside.
  •   ADDIMGCLGE: Add data from a disk into the catalog.

 

Let me pause a moment here to explain how the worlds of mailed media and download media intersect. The ADDIMGCLGE command has two formats, physical media and electronic media. In the physical media version, the DEV keyword is used to identify the optical device where the media is located. You run this command for each disk. The electronic media version uses a FROMFILE keyword and assumes that you've loaded the files you downloaded using FTP or Download Director into a folder accessible to the i. This would be an IFS folder to which you've copied the files (in fact, I suppose it could be a QNTC folder, which actually represents a connection to another machine on the network, although I've never tried that).

 

In either case--physical or electronic delivery--you end up with an image catalog containing all of the disks from your PTF package. At this point, the real magic occurs, because you now run a command called VFYIMGCLG that runs through all of the disks and makes sure no bits got twiddled or that you tried to install a copy of Sim City into your i. In the physical media world, this process--loading the data from the disks and then verifying the entire catalog--is a wonderful protection against bad media.

 

And finally, you run the magic PTF installation option: GO PTF, option 8. From this point on, the installation chugs through the entire installation process, not requiring anything from you other than time. Most importantly, you don't have to switch disks. And those who have been following along here may have realized that, as long as everything goes well, you can theoretically do this entire process remotely--especially if you download the media, since it's simply a matter of copying the package to the target machine's IFS and then creating an image catalog. And even for those like me who need physical media, all is not lost: the packages that you download from IBM are actually nothing more than the ISO images of the disks that they would mail you. You can create an image from optical media on any PC using a standard CD ripping tool, such as Roxio, and then treat those images the same way you would the electronically downloaded media (conversely, you can download the media and burn them to CD; just remember that the PC packages typically use the extension .iso, while the files downloaded from IBM will have a .bin extension).

 

Now, be warned: you shouldn't do this process unless you have a Plan B to be able to access the machine in case of a catastrophic error. On rare occasions, applying a PTF has been known to cause a machine to fail on IPL, or even more annoying, the IPL required by a PTF has been just enough to send a piece of hardware over the edge, and at that point you're probably going to have to visit the machine physically. The moral of the story is that even though you may not have to be there, don't absolutely count on not having to be there, lest you tempt Murphy and his minions.

A Last Visit to SNDPTFORD

There may still be times when you need to get a single PTF. The last time I did it was to get the ANZOBJCNV tool to test my application for V6R1 compatibility. SNDPTFORD straddles the line between the old technology and the new by providing support for image catalogs but also skipping them and using the standard download, load, and apply procedure. This support is made available via the DLVRYFMT parameter; if you specify *IMAGE on this parameter, you'll get an image file that can then be loaded into an image catalog. Otherwise, the PTF will be retrieved as a save file, and you use the traditional LODPTF (option 1 from the GO PTF menu) followed APYPTF (option 2).

So Many Choices...

To summarize, then, IBM provides a wide range of PTF support options. The processes support all of your basic business goals--from keeping current on cumulative releases to installing specific individual fixes--and the technology provides options for any size of shop with just about any skill level. And we haven't even addressed the capabilities of centralized support using Management Central or the new complexities introduced by the Hardware Management Console (HMC). More material for another day...

BLOG COMMENTS POWERED BY DISQUS