Testing for RSU service package RSU1403 is now complete. This RSU closes out 2013 and starts with January 2014. This April 2014 1st Quarter 2014 "Quarterly Report" (118 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 February 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

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.

"Good morning,

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:

And as always, thank you for stopping by and thanks for your continued support

Willie

The above comments are completely mine, not IBM. Please see my “Statement About Content Ownership” near the top of the right hand column.

P.S. OK, I've brought this silly post script thing back again… if you like this blog and find it informative, entertaining, or even useful, why not click on the subscription icon in the top right-hand corner (it looks a lot like ) so you are automatically notified of every post. Maybe you could even recommend this blog to a friend? Every reader I get helps…(smile)…

And, as usual, please remember: "These comments are my own personal opinions only and do not necessarily reflect the positions or opinions of my employer (IBM) or their affiliates. All comments are based upon my current knowledge and my own personal experiences. You should conduct independent tests to verify the validity of any statements made in this blog before basing any decisions upon those statements. In addition, any views or opinions expressed by visitors to this blog are theirs and do not necessarily reflect mine."

IBM, the IBM logo, ibm.com, [insert IBM brand that materials relate to ONLY IF it appears on our trademark Web site], and [insert IBM product name that materials relate to ONLY IF it appears on our trademark Web site] are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml.

Disclaimer: Blog contents express the viewpoints of their independent authors and
are not reviewed for correctness or accuracy by
Toolbox for IT. Any opinions, comments, solutions or other commentary
expressed by blog authors are not endorsed or recommended by
Toolbox for IT
or any vendor. If you feel a blog entry is inappropriate,
click here to notify
Toolbox for IT.

Welcome to all things DB2 for z/OS. This is your one stop, your only stop, and your final stop to find out all you'll ever want to ...
more

Welcome to all things DB2 for z/OS. This is your one stop, your only stop, and your final stop to find out all you'll ever want to know about DB2 for z/OS. We'll be discussing how to upgrade to the latest DB2 version, have detailed "how it works" discussions, some performance tips, maintenance alerts, baby updates, with a few guest posts thrown in occasionally. In addition, you'll find all of the latest DB2 news and gossip, arrival notifications of the latest articles, books, seminars, and teleconferences, along with details on all of the major conferences. I'll occasionally be throwing in a post covering our z/OS operating system and our System z hardware. Plus, there will always be something entertaining posted every once in a while. This is the place you'll find just about anything you need to know to stay current with DB2 for z/OS, z/OS, or System z. This is also the place to get that little bit of lite reading each morning to start your day off on the right foot.
less

Receive the latest blog posts:

Share Your Perspective

Share your professional knowledge and experience with peers. Start a blog on Toolbox for IT today!

Statement About Content Ownership:The contents of this blog reflect my own personal opinions only and do not necessarily reflect the positions or opinions of my employer (IBM) or their affiliates. All content is based upon my current knowledge and my own personal experiences. You should conduct independent tests to verify the validity of any statements made in this blog before basing any decisions upon those statements. In addition, any views or opinions expressed by visitors to this blog are theirs and do not necessarily reflect mine.

Copyright 1998-2015 Ziff Davis, LLC (Toolbox.com). All rights reserved. All product names are trademarks of their respective companies. Toolbox.com is not
affiliated with or endorsed by any company listed at this site.