Jul 01

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.

Continue reading »

Share
May 09

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

RSURecommended Service Upgrade

PTFProgram Temporary Fix

PEPTF in Error (I just love it when you use an acronym to define an acronym)

APARAuthorized Program Analysis Report

HIPERHigh 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:

http://www.ibm.com/servers/eserver/zseries/zos/servicetst/ .

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:

http://www.ibm.com/software/data/db2/support/db2zos/ .

Share
Tagged with:
May 03

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.

Continue reading »

Share
Tagged with:
Apr 18

Today, we have three APARs that I thought sounded useful.  One affects REALSTORAGE_MANAGEMENT, the second the WLM_REFRESH supplied stored procedure, and the last one that deals with statistics feedback.

Continue reading »

Share
Tagged with:
Apr 10

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.

Continue reading »

Share
Tagged with:
Apr 04

DB2 11 for z/OS added a new subsystem parameter (aka DSNZPARM) that gives more control over free space in a heavily updated table space called PCTFREE_UPD.  PCTFREE_UPD is a keyword on the DSN6SPRM macro.  It can be set to AUTO or to an integer value between 0 to 99 and is used as the default for the PCTFREE FOR UPDATE small_int keyword on a CREATE or ALTER TABLESPACE SQL statement when a value is NOT specified.

Continue reading »

Share
Tagged with:
Jan 26

Today’s fix is a pretty straight forward one.  You all know how fast log apply helps improve recovery times for a table space, right?

Just in case, here’s a short reminder….

Continue reading »

Share
Tagged with:
Aug 23

Today we’re going to take a look at the resolution to a few issues with some stored procedures that are shipped as part of DB2 for z/OS; GET_CONFIG and ADMIN_INFO_SQL.

Continue reading »

Share
Tagged with:
Aug 23

The title almost says it all.    All changes to DSNWMSGS for the first half of 2013 are published with this APAR.

PM80017: 2013 DSNWMSGS CHANGES-FIRST SET

This APAR is for both DB2 10 and DB2 9.  It closed last month on July 16, 2013 with no special handling.

The superseding PTFs are UK95893 for DB2 10 and UK95894 for DB2 9.

This may be a short post for a small fix but it updates something I use a couple of times a week.

Share
Tagged with:
Jul 17

Today’s discussion focuses around three APAR resolutions that came available the last weeks of May and June 2013.   Although the title of today’s post is a tiny bit of a stretch, all three do have something to with some kind of pool in DB2.

Continue reading »

Share
Tagged with:
preload preload preload