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.
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.
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….
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.
The title almost says it all. All changes to DSNWMSGS for the first half of 2013 are published with this APAR.
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.
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.
Sounds like a reasonable solution. After all, how many times has that worked for you?
Then it shouldn’t be any kind of surprise that it’s a solution that works for the folk in DB2 land also.
DB2’s problem, slow performance when trying to perform an ALTER TABLE ADD PARTITION directly related to accessing SYSIBM.SYSLRGNX. The access was using an index that did NOT include partition number. That seems like it could be a handy column when messing with adding partitions.
The solution, use a different index. In this case, an index that DOES include the partition number.
This little fix should solve this particular problem. If this is something you do, or something you thought ran a bit on the slow side, then you probably want to track down APAR PM83978.
APAR PM83978 is for DB2 10 only and closed back on June 7, 2013 (although the APAR was updated on July 15, 2013; that’s when I noticed it). This APAR has no special handling associated with it and is superseded by PTF UK94967.
Testing for the sixth service pack of 2013, RSU service package RSU1306, is now complete. This July 2013 2st Quarter Quarterly Report (115 KB PDF file) contains ALL service through the end of March 2013 not already marked RSU. This service also includes PE resolution and HIPER/Security/Integrity/Pervasive PTFs and their associated requisites and supersedes through May 2013.
This is the part of blogging that’s the most fun. When someone makes a great suggestion based on a previous blog post.
Frans dropped me a note a few days ago about another APAR in HIPER status that should be of interest to folks performing a migration to DB2 10.
It seems that an issue could come up during REORG processing of a compressed SPT01.
APAR PM81912, a DB2 10 for z/OS only APAR in HIPER status, address this issue. This APAR closed back on February 25, 2013 so it’s probably just starting to pop up in a lot of maintenance cycles.
It’s superseded by PTF UK91991. Frans pointed out that the fix PTF is on RSU 1304.
Frans, thanks for pointing this one out for us.
Here are a couple more APARs that I thought sounded interesting or are in areas that I spend a lot of time. No HIPERs or Red Alerts this time.