Once again I was asked about DSNDB01.SPT01 compression in DB2 10. Some still remember a few commits made just as DB2 10 became generally available (GA) discussing how SPT01 compression wouldn’t be needed in DB2 10. Those first comments were based on the fact the a lot of the information in SPT01 was being moved to large objects (LOBs) and LOBs cannot be compressed. If SPT01 data was being stored in LOBs and LOBs can’t be compressed, there would be no need for compression.
Have you ever wondered exactly what some of the system parameters (or DSNZPARM keywords) actually do for you (or to you)? Some are so straightforward, just looking at the keyword gives away all you need to know. However, there are some, even after research their meaning can still sometimes elude you. And that’s assuming you can even find their description (as in some DSNZPARM keywords delivered via the maintenance stream). It’s those DSNZPARM keywords I want to talk about today. Or rather, the kind I want to hear from you about today.
APAR Friday: A little something for the programming side; a fix for a small DB2 10 compatibility issue
APAR Friday: A ZPARM “gotcha” and a ZPARM stored procedure
It looks like an all DSNZPARM APAR Friday today. I have two APARs, both dealing with ZPARMs in one way or another, one is a HIPER, and both sound pretty interesting.
DFSORT, UTSORTAL, IGNSORTN, SORTNUM, and the DB2 utilities
Today’s blog post is going to start out with a discussion on what should be specified for two DSNZPARM keywords that will affect your utility processing. Regardless of what you specify, even if you just take the defaults, their values will alter your utility behavior.
The ZPARMs are IGNSORTN and UTSORTAL, both are on the DSN6SPRM macro.
When UTSORTAL, the more important of the two keywords in my opinion (more on that later), is set to YES, again the default in DB2 10, it allows DB2 to use real time statistics, always available in DB2 10, to determine the sort work data set sizes. If NO should be specified, it forces you to either specify the sort work data sets explicitly in the JCL or use the SORTNUM clause in the utility’s control cards…… Continue reading »
Deprecated: Such a cool word yet a word so misunderstood
I wanted to talk about the DSNZPARM keys deprecated in DB2 10. And yes I do realize that I listed them out in a previous post. However, this time I wanted to discuss why it’s important today, maybe even before migrating to DB2 10, to plan on how their eventual departure from DB2 may affect you.
Then someone pointed out to me that sometimes when we say something is “deprecated” in a future release of DB2, it can sometimes get misinterpreted, or misunderstood. In fact, there has been extra verbiage added to the DB2 10 Installation and Migration Guide (GC19-2974) to help alleviate future misunderstandings…… Continue reading »
APAR Friday: Another parallel REORG enhancement
Well over a year ago (Feb 2011) I blogged about the addition of the PARALLEL keyword that was made available on the REORG TABLESPACE LIST utility control statement. (See “APAR Friday: Another great REORG enhancement”
)
As a result of the group of fixes mentioned in the above blog post, a single execution of REORG happens with a list of partitions. It does happen in parallel; that’s good news. However, sometimes, someone may want to still run the list of partitions serially… one partition at a time……. Continue reading »
APAR Friday: Small glitch with DSNZPARM keyword DDLTOX
Back on July 11, 2011 ( I can’t believe it’s been a year almost already) I wrote about a new DSNZPARM keyword that was introduced that applied a timeout controls on DDL, different from the rest of the timeout knobs that already existed in DB2. That post along with all the details about the ZPARM can be found at “An additional timeout control is added to DB2 for z/OS”
…… Continue reading »
APAR Friday: Enhance REORG TABLESPACE PART performance
If you are interested in improving the performance of your partition REORGs, here’s a code update that should be of interest. All you need to do is stay current on your maintenance and add an additional keyword here and there. Magically, you have better performance…… Continue reading »
There is a correction in DB2 9 and DB2 10 to how DB2 automatically converts from index based partitioning to table based partitioning using the system parameter IX_TB_PART_CONV_EXCLUDE (introduced by APAR PM45829, see below). The system parameter controls whether all columns are used during the conversion or only significant columns are used. The cover contains a nice explanation that includes examples…… Continue reading »


Recent Comments