Testing for RSU service package RSU1404 is now complete. This RSU closes out the last quarter of 2013. This May 2014 1st Quarter 2014 1st Addendum “Quarterly Report” (62 KB PDF file) contains ALL service through the end of December 2013 not already marked RSU. This service also includes PE resolution and HIPER/Security/Integrity/Pervasive PTFs and their associated requisites and supersedes through March 2014.
A complete list of products and tools and their tested levels is available HERE.
If you would like to learn more about this service, check out the IBM CST Web site
Consolidated Service Test and the RSU web site .
If you would like to read more about how service testing is performed, Click Here .
Acronyms used in this blog post that might be of interest:
CST – Consolidated Service Test
RSU – Recommended Service Upgrade
PTF – Program Temporary Fix
PE – PTF in Error (I just love it when you use an acronym to define an acronym)
APAR – Authorized Program Analysis Report
HIPER – High Impact or Pervasive APAR
Click Here for a list of past tested RSU service packages that are still available. You can use ShopzSeries to order preventative service.
The above tells you that the current RSU maintenance is available. What follows though is an extract from a blog post I made that discusses why it’s important to have a solid maintenance strategy. It will be repeated here every time I post the availability of new RSU as a reminder to always review your maintenance strategy. Enjoy!!!!!
I have always been troubled by the maintenance strategies some of my friends have chosen for their DB2 for z/OS subsystems. In fact, in some cases, I might almost label their strategies as reckless; they’re just asking for a DB2 problem to occur. I was thinking that maybe I’m not the only one that feels this way. So I sought out an old companion, someone I remember from back in my IMS/VS and MVS system programming days, someone I used to run around with and deal with quite frequently, someone whose relationship I swear was one of the biggest reasons for my boss being grey at age 30. That friend is a PTF, the younger sibling to an APAR, and the child of a major software component. Here is what PTF had to say about software maintenance.
I’m a PTF and I have a tough job. When something goes wrong with a piece of code, it’s my job to fix it, or least attempt to fix it. When I was first assembled, I was tested as well as I could be tested in a pseudo environment. However, I won’t really find out what I’m made of until real customers apply me. That getting applied stuff is the tough part of my life.
In my first few months, because not many customers have tried me out yet, there is a chance that I may not do exactly what I was designed to do. If that happens, it can sometimes cause some real excitement. If that should happen, they tag me with something they call PE status, a real negative stigma to carry around. It also requires a lot of friends, other PTFs, to come to my eventual rescue. The good news though, the older I get, and the more systems accept me, the more confident I become and the more comfortable my programs get accepting me.
There’s far less chance of me causing any difficulties as I age. In fact, once I’m about 5-6 months old, there is a very low probability that I will ever cause a problem. I’m now starting to feel like I am going to lead a fruitful and productive life. At the very least, by age 5-6 months, if I were to have a problem, it has been discovered and dealt with.
Now here comes the tricky part of my lifecycle. I’m designed to make some aspect of the code behave better; better being a somewhat vague term that could mean perform correctly, perform better, or even introduce a new function or option. What ever the reason for my creation, I was developed to be used. And here lies my greatest tribulation. If for what ever reason, you decide to not apply me, that in it self may be the cause of a problem. Once the code gets past that magic 5-6 month sweet spot, the odds increase terrifically that you are going to eventually hit that piece of code I was meant to “improve” (isn’t that diplomatic way of saying it). The end result is a failure will occur that could have been avoided only because you didn’t do something that you thought could have caused a problem.
Does that make any sense? Of course not! If, for example, you were to receive a recall letter for your car that fixed some defect, would you ignore the recall or choose not to have the work done on the off chance that it may break something else? Do you chose to drive an unsafe vehicle; to avoid the off chance the fix may make your vehicle unsafe? I think not. And I think you should be treating your DB2 maintenance the same way.
Remember; friends don’t let friends ignore their maintenance!”
That’s what PTF had to say. Now here’s my opinion on how you should do your DB2 maintenance. I completely believe in this strategy, I have seen it work in many various size shops, and it’s similar to what I did 30 years ago. However, there are two points I need to make here.
First, when I was a systems programmer for a bank in the 70s, my production IMS/VS systems had an average availability of 99% each month running on an old 3033.
Second, and this is the important, if you try what I suggest and have a problem, my pager doesn’t go off. So bottom line, you always have to make sure you do what you are comfortable with and what your production environment can tolerate.
With that all said, you really need to keep DB2 as current as you possibly can. In a perfect world, that means one quarterly RSU level back. By keeping the current quarter’s RSU on the shelf and installing the previous quarter’s RSU, you are essentially apply PTFs that on average are about 4-6 months old, right in DB2′s maintenance sweet spot. This also means you are moving a set of tested maintenance into production every quarter. When I look back at all of the Version 8 upgrades I have been around in the last two years, I have seen more cases than I would want to admit to where someone ran into serious problems because they were way too far back on maintenance. I can’t think of anything worse than taking a couple of hour hit only to find out the PTF that could have avoided the problem was available three months ago. And then there are the cases where someone is getting ready to order Version 8 only to find out they are so far back in maintenance that it’s going to take months to get the systems to the point that the upgrade can even be started.
Something I forgot to mention in the previous paragraphs: hipers. A maintenance strategy is important. However, it may even more important to have a solid strategy in place for applying hipers. Just by their name alone they imply something critical that should be addressed as soon as possible. In fact, I would go as far as to say that hipers should be applied weekly, or at least bi-weekly, to be effective. They are after all marked critical to your systems survival just by their name. If staffing allows for it, you should also review all hipers on a daily basis.
I also keep using the term RSU, which stands for “recommended service upgrade”. This is, in my opinion and almost everyone I work with, the only way to get maintenance. There is a team called “consolidated service test” or CST, that pulls together all of the current PTFs for a set of products, so the PTF service for z/OS and its key subsystems are together on a single RSU
If you want a couple of more recommendations, make sure you are running at least SMP/E V3.4 so you can take advantage of the SMP internet software retrieval, and order all of your maintenance from ShopzSeries .
If you are not familiar with RSU and CST, or simply need a quick update on how they work, there’s an entire set of web pages describing what it is and how to use it at:
Before passing along a few APAR examples, I want to remind you that if you ever have the need to look up a PTF or APAR, you can always use the DB2 Support web page at: