Sometimes I feel like I am a waling advertisement for DB2 maintenance, like it’s the only thing I blog about. Although it may seem like that (and I actually hope it doesn’t), I do try to publish blog entries that cover general information that I think could be of use to the many. I try to stay away from the stuff that is obviously a fix for a program error; 0C7, 04E, or some other system threatening abend or return code.
Posted Wednesday, February 11, 2015
Sometimes receiving an extra cup of coffee, a second handful of M&M’s, a few more minutes of sleep, or a little extra time to get to your destination is a good thing. We most all enjoy the occasional “more”. However it you are talking DB2 for z/OS and happen to be running an INDEX REBUILD, too much can lead to certain disaster.
Unless you are running your DB2 10 or DB2 11 subsystem right at the bleeding edge of DB2’s maintenance, it is possible that you could crash your DB2 by simply running a REBUILD INDEX against an unique index having a few too many duplicate keys.
Posted Friday February 6, 2015
Testing for RSU service package RSU1501 is now complete. This February 2, 2015 4th Quarter “1st Addendum Quarterly Report” (60 KB PDF file) is based on the 4th quarter 2014 service ( RSU1412) and contains ALL service through the end of November 2014 not already marked RSU. This service also includes PE resolution and HIPER/Security/Integrity/Pervasive PTFs and their associated requisites and supersedes through December 2014.
This week I am celebrating APAR Friday on a Monday. For this weeks APAR Friday, I have a couple of APARs that could have on impact on that you do with your subsystem parameters (aka DSNZPARMs). One APAR is even marked HIPER.
Posted Tuesday, January 6, 2015
If you are licensed for DB2, it’s time to get your updated copy of the DB2 11 for z/OS Diagnostics Guide and Reference (LY37-3222-02). As in the past, this update is only available via a PTF.
Posted Monday, December 8, 2014
Testing for RSU service package RSU1411 is now complete. This December 2014, 3rd Quarter 2014 “2nd Addendum Quarterly Report” (60 KB PDF file) is based on the October 2014 service ( RSU1409) and contains ALL service through the end of October 2014 not already marked RSU. This service also includes PE resolution and HIPER/Security/Integrity/Pervasive PTFs and their associated requisites and supersedes through October 2014.
Applying maintenance to your DB2 subsystem(s), and other systems you may have installed, is critical to those systems running successfully. The Consolidated Service Test (CST) environment allows an RSU (recommended service upgrade) to be made available to customers after the maintenance included in the RSU has been tested together on a z/OS platform. This all works well with our DB2 service strategy.
Continue reading »
Posted Monday, November 10, 2014
Testing for RSU service package RSU1410 is now complete. This November 2014 3rd Quarter 2014 “1st Addendum Quarterly Report” (56 KB PDF file) is based on the October 2014 service ( RSU1409) and contains ALL service through the end of September 2014 not already marked RSU. This service also includes PE resolution and HIPER/Security/Integrity/Pervasive PTFs and their associated requisites and supersedes through September 2014.
I have mentioned a few times on this blog that I NO LONGER post here. If you are interested in the stuff I write, I would strongly suggest following me at Getting the Most out of DB2 for z/OS at it.toolbox.com. There you will find my latest post. This site is a mirror and I only put stuff here after it has been published for a while at it.toolbox.com.
What follows are the URLs for all of my blog post published on it.tool.com for the months of April, May, and June.
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
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
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:
Today’s post started out as one of my APAR Friday post, in fact my first post for the month of May. However, the more I read about what this APAR delivered, the more I released it was much much more. Then I decided that this is too much to simply be another APAR Friday post. This APAR Friday post has to be special. Or at least it makes available some functionality that I think is pretty cool so therefore it automatically becomes special in my eye.