2022-09 PROFILE Table usage Part One

This month I begin a two-part topic because it is just too large to do in one blog entry!

In the Beginning

The DSN_PROFILE_TABLE was introduced sometime in DB2 V8, but it was not until DB2 9 that it started to be used for system profiling when IBM introduced three new commands: DISPLAY PROFILE, START PROFILE and STOP PROFILE. This first appearance of PROFILES was a bit limited and could control only a few ZPARMs – and four of those just for EXPLAIN purposes.

How does/did it look?

To get it working, you must first create all the required tables and indexes. (The DDL is in the db2hlq.SDSNSAMP member DSNTIJSG.) In bold and italics are the DB2 10 and higher versions:

SYSIBM.DSN_PROFILE_TABLE
CREATE TABLE SYSIBM.DSN_PROFILE_TABLE 
      ( "AUTHID"                VARCHAR(128)
       ,"PLANNAME"              VARCHAR(24)
       ,"COLLID"                VARCHAR(128)
       ,"PKGNAME"               VARCHAR(128)
       ,"LOCATION" "IPADDR"     VARCHAR(254)
       ,"PROFILEID"             INTEGER       NOT NULL
           PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY
       ,"PROFILE_TIMESTAMP"     TIMESTAMP     NOT NULL WITH DEFAULT
       ,"PROFILE_ENABLED"       CHAR(1)       NOT NULL DEFAULT 'Y'
        ,"GROUP_MEMBER"          VARCHAR(24)                       
       ,"REMARKS"               VARCHAR(762)                       
       ,"ROLE"                  VARCHAR(128)                      
       ,"PRDID"                 CHAR(8)                           
       ,"CLIENT_APPLNAME"       VARCHAR(255)                      
       ,"CLIENT_USERID"         VARCHAR(255)                      
       ,"CLIENT_WRKSTNNAME"     VARCHAR(255)                      
      );                                                          
CREATE UNIQUE INDEX SYSIBM.DSN_PROFILE_TABLE_IX_ALL
      ON SYSIBM.DSN_PROFILE_TABLE                 
      ( "PROFILEID"                               
      );                                          
CREATE        INDEX SYSIBM.DSN_PROFILE_TABLE_IX2_ALL
      ON SYSIBM.DSN_PROFILE_TABLE                 
      ( "PROFILE_ENABLED"                         
       ,"AUTHID"                                  
       ,"PLANNAME"                                
       ,"COLLID"                                  
       ,"PKGNAME"                                 
       ,"LOCATION" "IPADDR"                        
       ,"PRDID"                                   
       ,"ROLE"                                    
       ,"CLIENT_APPLNAME"                         
       ,"CLIENT_USERID"                            
       ,"CLIENT_WRKSTNNAME"                       
       ,"GROUP_MEMBER"                            
       ,"PROFILE_TIMESTAMP" DESC                  
      );                                          

SYSIBM.DSN_PROFILE_HISTORY – Same columns as DSN_PROFILE_TABLE apart from

REMARKS -> STATUS VARCHAR(254) and no index.
SYSIBM.DSN_PROFILE_ATTRIBUTES
CREATE TABLE SYSIBM.DSN_PROFILE_ATTRIBUTES                        
      ( "PROFILEID"             INTEGER       NOT NULL            
           REFERENCES SYSIBM.DSN_PROFILE_TABLE ON DELETE CASCADE  
       ,"KEYWORDS"              VARCHAR(128)  NOT NULL            
       ,"ATTRIBUTE1"            VARCHAR(1024)                     
       ,"ATTRIBUTE2"            INTEGER                           
       ,"ATTRIBUTE3"            FLOAT                             
       ,"ATTRIBUTE_TIMESTAMP"   TIMESTAMP     NOT NULL WITH DEFAULT
       ,"REMARKS"               VARCHAR(762)                       
      );                                                          
CREATE UNIQUE INDEX SYSIBM.DSN_PROFILE_ATTRIBUTES_IX_ALL          
      ON SYSIBM.DSN_PROFILE_ATTRIBUTES                            
      ( "PROFILEID"                                                
       ,"ATTRIBUTE_TIMESTAMP"   DESC                              
       ,"KEYWORDS"                                                
       ,"ATTRIBUTE1"                                              
       ,"ATTRIBUTE2"                                              
       ,"ATTRIBUTE3"                                              
      );                                                           

SYSIBM.DSN_PROFILE_ATTRIBUTES_HISTORY same columns as DSN_PROFILE_ATTRIBUTES apart from

REMARKS -> STATUS VARCHAR(254)  and no index.

Notice the RI between the DSN_PROFILE_ATTRIBUTES and DSN_PROFILE_TABLE keyed on PROFILEID. Also notice that there are no indexes on the HISTORY tables and also no RI.

So What Could You Do?

With this new functionality you could use a profile to override four ZPARMs, namely NPGTHRSH, OPTIOWGT, STARJOIN and SJTABLES. To do so, you first inserted a row into the DSN_PROFILE_TABLE with some sort of filter, at this time only COLLID and PKGNAME, and then one or more inserts in the DSN_PROFILE_ATTRIBUTES table using the PROFILEID that you either just used, or got generated for you, in the DSN_PROFILE_TABLE using the KEYWORDS column and ATTRIBUTEn column(s).

Always on?

The column PROFILE_ENABLED in the DSN_PROFILE_TABLE informs Db2 whether or not to consider this profile when the START PROFILE command is issued. Setting it to N puts all of this profile’s records “to sleep”.

Not Just ZPARMs

It also enabled three global changes (no filters allowed) for BPname, MAX_RIDBLOCKS and SORT_POOL_SIZE. All of these are just for modelling production systems in test to then get a better, more accurate, EXPLAIN result and have *no* effect on the actual system at all.

Finally, IBM added some Accelerator-only support which had to be done with IBM involved.

Interestingly enough, there was a complete chapter about using profiles to monitor and report on SQL but there was also an update to the docu:

Important: The use of profile tables to monitor and capture information about the performance of SQL statements is deprecated, and not recommended.

So, I will not even bother going into detail about the monitor settings.

What Was the Difference?

The major difference between the SQL and ZPARM settings, was the ability to use different filter column values like AUTHID or IPADDR/LOCATION.

The DSN_PROFILE_HISTORY has the same columns as the DSN_PROFILE_TABLE, except that REMARKS is called STATUS and gets a value set by the START PROFILE command. Basically, a string that starts with REJECTED – or ACCEPTED – and then a text string describing why the profile was, or was not, accepted for use.

What’s in an ATTRIBUTE?

The DSN_PROFILE_ATTRIBUTES table contains the option that should be overridden when the Profile is active and the filtering allows it. The columns of interest are KEYWORDS and the three ATTRIBUTEn columns.

BUFFERPOOL Modelling

BPname (where name is any of the valid names like 0 through 49 or 32K1 through 32K9 etc.) in the KEYWORDS column. ATTRIBUTE1 and ATRIBUTE3 are set to NULL and ATTRIBUTE2 contains a positive integer value for the size of the BUFFERPOOL (for production modelling).

RIDPOOL Modelling

MAX_RIDBLOCKS in the KEYWORDS column, ATTRIBUTE1 and ATTRIBUTE3 are set to NULL, and ATTRIBUTE2 contains a value from 0 to the maximum value that you can set MAXRBLK in that subsystem (for production modelling).

STARJOIN Control

STAR JOIN in the KEYWORDS column, ATTRIBUTE2 and ATTRIBUTE3 are set to NULL, and ATTRIBUTE1 set to DISABLE or ENABLE.

MIN STAR JOIN TABLES in the KEYWORDS column, ATTRIBUTE1 and ATTRIBUTE3 are set to NULL, and ATTRIBUTE2 contains a value from 3 to 225.

INDEX ACCESS Control

NPAGES THRESHOLD in the KEYWORDS column, ATTRIBUTE1 and ATTRIBUTE3 are set to NULL, and ATTRIBUTE2 contains one of the following values:

 -1 use index access if possible

 0 access path based on cost, the normal way Db2 works

 1 to nnnn Db2 should use index access on tables for which the total number of pages (NPAGES) is less than nnnn. Make sure that your Db2 Catalog statistics are up to date before you specify a value of 1 or greater.

IO Control

IO WEIGHTING in the KEYWORDS column, ATTRIBUTE2 and ATTRIBUTE3 are set to NULL, and ATTRIBUTE1 is set to DISABLE or ENABLE (deprecated in DB2 10).

SRTPOOL Modelling

SORT_POOL_SIZE in the KEYWORDS column, ATTRIBUTE1 and ATTRIBUTE3 are set to NULL, and ATTRIBUTE2 set to a positive integer up to the maximum value of SRTPOOL. That is the new SRTPOOL (for production modelling).

Production Modelling

In this case, the EXPLAIN output got changed to output which PROFILE value was active at the time of the EXPLAIN. The REASON column in the DSN_STATEMNT_TABLE gets set to “PROFILEID nnnn” for the profile number that was active at the time of the EXPLAIN.

When Was this Done?

The DSN_PROFILE_ATTRIBUTES_HISTORY has the same columns as the DSN_PROFILE_ATTRIBUTES_TABLE except that REMARKS is called STATUS and gets a value set by the START PROFILE command. Basically, a string that starts with REJECTED – or ACCEPTED – and then a text string describing why the profile was, or was not, accepted for use.

So that was it for DB2 9 – not that much but a very good start if you ask me!

System Profile Monitoring

Then in DB2 10 came “system profile monitoring”, which is where this system got very useful indeed! It then got the ability to Monitor Connections, Monitor Threads and Monitor Idle Threads.

New Keywords for Connections and Threads!

MONITOR CONNECTIONS in the KEYWORDS column, ATTRIBUTE1 is a “two part” column value. The first part is either WARNING or EXCEPTION. A warning causes a console message every five minutes depending on the diagnosis level. An exception issues the diagnosis level and rejects any new incoming connection requests. The second part is either not there or it is _DIAGLEVEL1 which issues a DSNT771I console message and _DIAGLEVEL2 which issues a DSNT772I console message with more details. ATTRIBUTE2 is a positive integer to indicate the threshold for the maximum number of remote connections. It must be less than or equal to CONDBAT. ATTRIBUTE3 is NULL. Filtering is only by the LOCATION column.

MONITOR THREADS in the KEYWORDS column, ATTRIBUTE1 is a “two part” column value. The first part is either WARNING or EXCEPTION. A warning causes a console message every five minutes depending on the diagnosis level. An exception issues the diagnosis level and can cancel the thread depending on the filtering criteria otherwise the thread is queued. The second part is either not there or it is _DIAGLEVEL1 which issues a DSNT771I console message and _DIAGLEVEL2 which issues a DSNT772I console message with more details. ATTRIBUTE2 is a positive integer to indicate the threshold for the maximum number of server threads. It must be less than or equal to MAXDBAT. ATTRIBUTE3 is NULL. Filtering on nearly all columns is allowed.

Db2 11 Docu Update

In Db2 11, an extra bit of documentation was added when filtering by Collection identifier, package name, client user name, client application name or client workstation name. When the total number of queued and suspended threads exceeds the threshold, Db2 fails subsequent SQL statements and returns SQLCODE -30041 to the client.

For example, suppose that a profile for a package is started. That profile uses ATTRIBUTE2=2. If five threads request to run the package, two threads run concurrently, two threads are queued and suspended, and Db2 fails the SQL statements for the fifth thread.

And Finally IDLE?

MONITOR IDLE THREADS in the KEYWORDS column, ATTRIBUTE1 is a “two part” column value. The first part is either WARNING or EXCEPTION. A warning causes a console message every five minutes, depending on the diagnosis level. An exception issues the diagnosis level and cancels the idle thread. The second part is either not there or it is _DIAGLEVEL1 which issues a DSNT771I console message or _DIAGLEVEL2 which issues a DSNT772I console message with more details or WARNING_MESSAGE_FOR_IDLE_TIMEOUT (only for WARNING) which issues DSNT771I and/or DSNT773I. ATTRIBUTE2 is a positive integer to indicate the threshold for the maximum number of seconds an active server thread can stay idle.

That’s all for this month, next month I will go into detail about the Filters, the new stuff In Db2 11, 12 and 13 as well as examples of different things you can do nowadays.

As always I would love to hear any comments or criticism about this topic!

TTFN

Roy Boxwell

APAR Update

This month we have a nice spread of fixes! All checked on the 6th of September 2022.

HIPERS:

PH48073 UI82094 UI82095 WHEN UPDATE SET CLAUSE CONTAINS A SCQ WITH A MINUS SIGN, AN INCORROUT OR AN ABEND (ABEND0C4 AT DSNXGDT2 OFFSET00980) MAY


Interesting for RTS and Statistics:

PH45916 UI81253 UI81254 COPYUPDATEDPAGES IS INCORRECT AFTER LOAD WITH INLINE COPY, INCREMENTAL COPY GETS SKIPPED, RECOVER REQUIRES LOG APPLY

PH46767 UI82201 UI82202 DROP INDEX LEAVES ORPHAN ROWS IN SYSIBM.SYSCOLDIST

PH47090 UI81865 UI81866 SYSIBM.SYSINDEXSPACESTATS(STATSLASTTIME) DOES NOT GET UPDATED FROM LOAD REPLACE WITH INLINE STATISTICS SPECIFIED.


For Query performance:

PH47354 UI81962 UI81963 THE FILTER FACTOR FOR THE IN SUBQUERY PREDICATE MIGHT BE ESTIMATED TOO HIGH SO THE INEFFICIENT INDEX MIGHT BE PICKED UP.


For IAG2 users:

PH46570 Just Db2 13 UI81635 IAG2 ABEND04E 00C90105 IN DSNIASFP ERQUAL 0CA4
PH47249 UI82028 UI82029(IAG2) ABEND04E RC00C90101 AT DSNIASFP ERQUAL5001


For FTB users:

PH48078 UI82129 UI82130 FTB SIZE EXCEEDS THE VALUE OF ZPARM INDEX_MEMORY_CONTROL


Now come the three tables containing all the APARs.

First are the Real-time Statistics APARs – If the RTS are incorrect then any Utility generation or Access path decision based upon them could also be incorrect.

Next are the RUNSTATS APARs – If RUNSTATS causes data problems this, obviously, can have a major impact upon performance after the following BIND, REBIND or dynamic SQL PREPARE.

Finally, come the SQL PERFORMANCE APARs – In here are all relevant performance APARs as well as HIPERs that do not fit into any other category. A HIPER warrants a check in all cases.

All three tables have the same headings:

APAR – The assigned APAR for the problem.

CLOSED – This is the date in YYYY-MM-DD format when the APAR was closed.

STATUS – This column is NEW, NEW & CLOSED, CLOSED, MODIFIED or PE xxxxx. A PE means that this APAR went PE and the xxxxx is the corrective APAR. Modified does not mean the PTF has really been changed. It is just that IBM, for some reason or other, has updated the modified date. Sometimes this is to signify a new PTF or that a PTF has gone PE or even HIPER. In the next release of this page I will remove modified unless I see a real change as there are 100’s of them for no reason!

Db2 12 – If the PTF is for Db2 12 then it is listed here else N/A or OPEN.

Db2 13 – If the PTF is for Db2 13 then it is listed here else N/A or OPEN.

HIPER – Contains Y if the APAR is a HIPER. Can also contain (Y) if it is OPEN but presumed to be a HIPER, else it is blank.

Description – This is the APAR description taken from the header text. Sometimes I add extra details if the description is misleading or incorrect.

Note: If the PTF column has OPEN it means that the PTF was still open when the last check was done; of course it could have been Closed since this post was updated. Every year all APARs that were closed over two years ago are deleted.

RTS APARs:

APARCLOSEDSTATUSDb2 12Db2 13HIPERDescription
PH063562020-03-04 UI68224N/A REORG OF A PARTITION IS SETTING SOME STATISTICS INCORRECTLY IN RTS ( REORGINSERTS AND REORGAPPENDINSERTS )
PH161462020-10-05 UI71920N/A REORG UTILITY ISSUING DSNU3343I MSG FOR UPDATESIZE
PH207582020-10-20 UI72171N/A REBUILD INDEX SHRLEVEL CHANGE OF DIRECTORY INDEX DSNDB1XA GETS DSNU590I WITH RC00C900AE BUT COMPLETES SUCCESSFULLY
PH228382020-06-17 UI70107N/A GETPAGES COLUMN OF SYSINDEXSPACESTATS AND SYSTABLESPACESTATS CAN MAX OUT AND NOT GET INCREMENTED WITH SUBSEQUENT GETPAGE REQUESTS
PH265712020-09-02 UI71381N/A RTS GETPAGES VALUE WRONG IN SYSINDEXSPACESTATS FOR DEFER YES INDEXES
PH271522020-09-14 UI71536N/A DB2 ABEND04E DSNITCUS ERQUAL5002 DURING ONLINE REORG OF DSNDB06.SYSTSCOL
PH277312020-12-23 UI73288N/A INCORRECT NPAGES VALUE IN SYSIBM.SYSTABLESPACESTATS AFTER MASS DELETE AND LOAD RESUME, THEN RUNSTATS GETS RC00E40214 DSNUSUPT
PH311242021-01-28 UI73674N/A REBUILD INDEX SHRLEVEL REFERENCE OF DIRECTORY INDEX DSNDB1XA OR DSNDB01X GETS DSNU590I WITH RC00C900AE BUT COMPLETES SUCCESSFULL
PH314982021-01-06 UI73361N/A NO RTS UPDATE DURING RUNSTATS TABLESPACE SHRLEVEL REFERENCE UPDATE ALL IN V12 FL505 AND ABOVE.
PH322242020-12-30 UI73321N/A LOAD REPLACE AND REBUILD INDEX DO NOT RESET SYSIBM.SYSTABLESPACESTATS.GETPAGES
PH348072021-03-29 UI74649N/A EXTRA CPU COST OF MASS DELETE
PH355892021-05-04 UI75212N/A AFTER A PIT RECOVER , RTS REORGLASTTIME IS NULL AND DSNACCOX DOES NOT EXTRACT THE OBJECT FOR REORG
PH395032021-08-23 UI76887N/A ABEND04E RC0090101 IN DSNILKPD:1001 CAN OCCUR ON A QUERY IF STATS SAY TABLE IS EMPTY AND BUFFERPOOL SIZE IS ZERO
PH414802021-11-12 UI78060N/AYABEND04E RC00C90D01 DSNONLLE ERQUAL53AC DURING DISASTER RECOVERYRECOVER OF DB2 CATALOG AND DIRECTORY
PH459162022-06-29New & ClosedUI81253UI81254 COPYUPDATEDPAGES IS INCORRECT AFTER LOAD WITH INLINE COPY, INCREMENTAL COPY GETS SKIPPED, RECOVER REQUIRES LOG APPLY
PH470902022-08-08New & Closed UI81865UI81866 SYSIBM.SYSINDEXSPACESTATS(STATSLASTTIME) DOES NOT GET UPDATED FROM LOAD REPLACE WITH INLINE STATISTICS SPECIFIED.

RUNSTATS APARs:

APARCLOSEDSTATUSDb2 12Db2 13HIPERDescription
PH163452020-04-01 UI68772N/A     CODE TO SUPPORT FUTURE NEW FUNCTION WITH RUNSTATS UTILITY
PH194312020-02-13 UI67909N/A     RUNSTATS ABEND04E RC00E4001A – DSNUSSIN+0434 WHEN STPRIN01 DD STATEMENT IS NOT ALLOCATED
PH207452020-08-12 UI71041N/A     DB2 UTILITY LOOPS WHILE ALLOCATING SORT WORK DATASETS.
PH215962020-04-01 UI68767N/A     RUNSTATS TABLESPACE TABLE(ALL) INDEX(ALL) REPORT YES UPDATES SYSINDEXES.FULLKEYCARDF WITHOUT A MESSAGE.
PH228962020-05-03 UI69321N/A     RUNSTATS USE PROFILE ENDING WITH RC08 AND MSGDSNU611I DUE TO BAD SYNTAX IN PROFILE_TEXT OF SYSIBM.SYSTABLES_PROFILES
PH229332020-07-06 UI70419N/A     ACCESS PATH DEGRADED AFTER INDEX CHANGED TO EXCLUDE NULL KEYS
PH252772020-09-21 UI71670N/A     RUNSTATS CONSUMES LOTS OF REAL STORAGE WHEN USER SPECIFY FREQVAL COUNT(1000)
PH259792020-07-17 UI70631N/A     RUNSTATS FAILED WITH REASON=X’00E40213′ CAUSE=X’00C9004F’
PH282562020-11-11 UI72533N/A     RUNSTATS USE PROFILE ENDING WITH MSGDSNU611I OR MSGDSNU048I DUE TO BAD SYNTAX IN PROFILE_TEXT OF SYSIBM.SYSTABLES_PROFILES
PH285572020-10-07 UI71989N/A    YLow Dynamic Statement cache (DSC) hit ratio caused by IDAA statistics block storage leak 20/10/16 PTF PECHANGE
PH290622020-11-05 UI72412N/A     ABEND04E RC00E40231 DURING A RUNSTATS TABLESPACE INDEX
PH304692020-12-15 UI73163N/A     RUNSTATS USE PROFILE ABENDS S0C4 IN DSNXA02
PH312042020-11-24 UI72763N/A     RUNSTATS WITH MANY OBJECTS IN LISTDEF DOES NOT PROCESS ALL OBJECTS AND PROCESSES OTHER OBJECTS MULTIPLE TIMES
PH324482021-01-07 UI73367N/A     RUNSTATS UTILITY IS NOT COLLECTING THE SYSCOLDISTSTAT THAT IS BEING SPECIFIED (EG. FREQVAL COUNT 10 MOST)
PH332262021-02-26 UI74173N/A    YDB2 BUFFER MANAGER OPEN PAGESET STORAGE LEAK
PH341232021-03-01 UI74210N/A     RUNSTATS DOES NOT COLLECT DISTRIBUTION STATISTICS FOR SINGLE COLUMN COLGROUP FOR SEGMENTED MULTI-TABLE TABLE SPACES
PH352672021-06-01 UI75649N/A     RUNSTATS DOES NOT UPDATE COLUMN SYSCOLDIST.CARDF CORRECTLY WHEN NUMCOLUMNS > 1
PH375452021-07-14 UI76330N/A     RUNSTATS ABENDS0CF RC0000000F IN DSNUSEOF.
PH401892022-03-30 UI79958N/A    YRUNSTATS AT PARTITION LEVEL GOT ABEND04E RC00E40213 WITH CAUSE 00C9004F
PH435032022-03-31 UI79966N/A     RUNSTATS TABLESPACE REGISTER NO FAILS WITH RC00C90637 OR ABEND04E WITH RC00C90101 AT DSNIOW ERQUAL 2002
PH442462022-04-01 UI79986N/A    YABEND04E RC00E2000F DSNSVSFB+00A2A DURING A RUNSTATS TABLESPACE WITH EXCLUDE NULL KEYS INDEX
PH455332022-05-20 UI80643N/A     INCORRECT VALUE OF CARDF IN SYSIBM.SYSCOLDISTSTATS WHEN RUNSTATS COLLECTS KEYCARD STATISTICS ON DPSI INDEX
PH463512022-06-01ModifiedN/AUI80817 INCORRECT VALUE OF CARDF IN SYSIBM.SYSCOLDIST WHEN RUNSTATS COLLECTS KEYCARD STATISTICS ON DPSI INDEX
PH467672022-08-31New & ClosedUI82201UI82202 DROP INDEX LEAVES ORPHAN ROWS IN SYSIBM.SYSCOLDIST
PH471832022-07-19 UI81531UI81532 RUNSTATS USE PROFILE GOT TIMEOUT ON WAITING SYSCOLDISTSTATS TABLE X LOCK DURING LOCK ESCALATION.
PH484072022-09-02New & ClosedUI82237UI82238 RUNSTATS AT PARTITION LEVEL GETS ABEND04E RC00E40213 WITH CAUSE 00C9004F
PH49119 NewN/AOPEN COLCARDF IN SYSIBM.SYSCOLUMNS IS INCORRECT (RESET TO ZERO) AFTER A REORG AT PARTITION LEVEL USING INLINE STATISTICS

SQL PERFORMANCE and general HIPERs:

APARCLOSEDSTATUSDb2 12Db2 13HIPERDescription
PH071952020-03-31 UI68741N/A    YERRONEOUS SQLCODE -136 CAN BE ISSUED FOR A QUERY WHEN THE SORT KEY LENGTH IS NOT ACTUALLY TOO LONG
PH113762020-08-27 UI71295N/A     ABENDSOCF DSNUSEOF +X’07F42′ DURING REORG WITH INLINE STATISTICS EXECUTED ON MULTI TABLE TABLESPACE.
PH11864  OPENOPEN SQL SELECT RETURNS INCORROUT AFTER TABLE WITH LOB COLUMNS IS UPDATED
PH158962020-02-13 UI67906N/A     AUTOBIND DOES NOT TRY TO REUSE THE ACCESS PATH FROM CURRENT PACKAGE COPY SO ACCESS PATH COULD CHANGE, AFFECTING PERFORMANCE
PH162712020-01-29 UI67631N/A     PAIR-WISE STAR JOIN CHOSEN WHEN NESTED LOOP IS THE BETTER CHOICE
PH175112020-04-08 UI68926N/A     BLOCK SPARSE INDEX USAGE ON CERTAIN JOIN PREDICATE PUSHDOWN CASES.
PH178992020-01-04 UI67248N/A    YINCORRECT OUTPUT CAN OCCUR WHEN AN INDEX ON EXPRESSION INDEX IS USED.
PH179672020-04-09 UI68971N/A    YABEND RC00C90206 MESSAGE DSNI013I DSNIIDIS POTENTIALLY INCONSISTENT DATA ERQUAL 5002
PH181532020-02-28 UI68151N/A     AN INEFFICIENT ACCESS WITH INDEX+LISTPREFETCH IS CHOSEN WHILE DIRECT INDEX ACCESS CAN AVOID SORT FOR SQL WITH ORDERBY/GROUPBY
PH186482020-04-03 UI69157N/A    YABEND0C4 DSNISGSU USING INSERT ALGORITHM 2 IAG2
PH187392020-02-03 UI67690N/A     FTB DB2 12 FOR Z/OS NEW FUNCTION
PH187662020-02-21 UI68040N/A     INEFFICIENT INDEX SELECTION CAN OCCUR WITH A QUERY CONTAINING UNION ALL AND ORDER BY
PH189442020-02-05 UI68041N/A    YDB2 INTERNAL SERVICEABILITY APAR FOR INSERT ALGORITHM 2 – IAG2
PH189452020-03-18 UI68489N/A    YABEND04E 00C90101 DSNIDM DSNISFPI ERQUAL 5001 DURING INSERT IN TO A TABLE USING INSERT ALGORITHM 2 – IAG2
PH190442020-02-10 UI67374N/A     ACCESS PATH CHANGES FROM R-SCAN TO NON-MATCHING INDEX SCAN WHEN TABLESPACE IS CHANGED FROM SEGMENTED TO PARTITIONED
PH190712020-01-05 UI67253N/A     INCORROUT NO ROWS RETURNED WHEN RUNNING A QUERY WITH PARALLELISM
PH194082020-03-23 N/A    N/A     QUERY PERFORMANCE ISSUE MAY OCCUR WHEN A MULTI-INDEX PLAN WITH LARGE UNCERTAINTY IS USED
PH194832020-02-13 UI67378N/A    YDISALLOW LOCK AVOIDANCE FOR SINGLETON SELECT WITH ISOLATION(CS) AND CURRENTDATA(YES)
PH200332020-01-13 UI67370N/A     THE REBIND TRIGGER PACKAGE COMMAND WITH THE APREUSE(WARN) OPTIONCAN CAUSE THE SYSPACKDEP AND SYSDEPENDENCIES ROWS TO DISAPPEAR.
PH200972020-03-16 UI68427N/A     INEFFICIENT INDEX CAN BE CHOSEN WHEN TWO COMPETING INDEXES CONTAIN A SUBSET OF THE SAME COLUMNS
PH201242020-03-25 UI68623N/A    YDB2 11 – INCORROUT WITH DEGREE ANY USING COUNT DISTINCT WHEN PARALLELISM PROCESSING IS ACTIVE.
PH202392020-03-09 UI68273N/A     INEFFICIENT INDEX CAN BE CHOSEN BASED ON HIGH UNCERTAINTY PREDICATES.
PH202472020-02-11 UI67810N/A    YINCORROUT FOR A QUERY WITH OUTER AND INNER JOIN WITH A CORRELATED SUBQUERY AND VALUE FUNCTION
PH204322020-04-09 UI68964N/A     IN DB2 12, PIPELINED INNER(ACCESSTYPE=O) IS USED WHEN BETTER ACCESS PATH EXSITS
PH208622020-04-03 UI68808N/A    YPOSSIBLE INCORRECT OUTPUT WHEN OFFLOADING QUERY W/ HEX() SCALAR FUNCTIONIN EBCDIC SCHEME TO IBM DB2 ANALYTICS ACCELERATOR V7
PH211522020-02-18 UI67959N/A     FTB ABENDS0C4 RC0000003A DSNSLD4 DSNSVSFB OFFSET0075E
PH211532020-03-31 UI68737N/A     INCORROUT FOR A CLONE TABLE WITH -DIS DB(DBR000) SPACENAM(TSXXR000) RESTRICT ADVISORY
PH211612020-02-10 UI67794N/A     ABEND04E RC00E72018 AT DSNXSMRE P630 OCCURRED WHEN USING SPARSE INDEX ACCESS WITH HASHBOTH
PH212992020-03-16 UI68428N/A     ABEND04E RC00E70005 AT DSNXOTS M099 MAY ISSUED FOR QUERY WITH JOIN TO AN XML TABLE
PH213772020-03-25 UI68626N/A    YWRONG RESULT FOR SELECT WITH HAVING
PH213862020-02-13 UI67902N/A     ABEND04E RC00C90101 AT DSNIDM DSNIPSFI ERQUAL5007 OCCURRED WHEN AN OUTER JOIN QUERY CONTAINS A UDF FUNCTION
PH214772020-04-28 UI69248N/A    YINCORROUT FOR LEFT JOIN QUERY
PH215152020-03-09 UI68275N/A     ABEND04E RC00E70005 AT DSNXOV1 M315 FOR QUERY THAT REFERENCES A TABLE UDF
PH215802020-02-20 UI68034N/A     POOR PERFORMING RSCAN AP CHOSEN OVER NON-MATCHING INDEX SCAN WHEN TABLE IS CREATED AS VOLATILE
PH216412020-03-16 UI68434N/A     POSSIBLE INCORRECTOUT WHEN OFFLOADING CHAR SCALAR FUNCTION WITH THE FIRST PARAMETER AS DATETIME
PH217452020-07-08 UI70453N/A     ABEND04E RC00E70005 AT DSNXRSFN M205 DURING SQL PROCESSING
PH217932021-01-05 UI73335N/A     ABEND04E RC00E2000D AT DSNXESTR DSNSVSFB OFFSET00A18
PH218172020-03-04 UI68218N/A     UNNECESSARY SORT PERFORMED FOR IN SUBQUERY WITH FF1R
PH218302020-04-14 UI69002N/A     INEFFICIENT ACCESS PATH CAN BE CHOSEN WHEN THE QUERY CONTAINS A SUBQUERY THAT RETURNS A SINGLE ROW
PH219162020-03-25 UI68631N/A     ABEND04E RC00C90101 IN LOC=DSNIDM DSNKFLOK 1001 DURING FAST TRAVERSAL PROCESSING
PH221722020-05-29 UI69769N/A     FIRST LEG IN A MULTI INDEX ACCESS PATH CONTAINS HIGH UNCERTAINTY PREDICATE RESULTING IN POOR PERFORMANCE
PH221862020-07-31 UI70861N/A    YPOOR PERFORMANCE FOR A QUERY CONTAINING AN EXPRESSION JOIN PREDICATE AND AN INDEX ON EXPRESSION INDEX IS …
PH222242020-04-08 UI68924N/A     ABEND04E RC00E70005 AT DSNXGDT2 M111 MAY OCCUR FOR QUERY UNDER INSENSITIVE SCROLL CURSOR AND ORDER BY
PH223852020-04-15 UI69032N/A    YINCORRECT OUTPUT CAN OCCUR WHEN AN INDEX ON EXPRESSION INDEX IS USED AND THE QUERY USES HOST VARIABLES.
PH224362020-03-11 UI68315N/A    YINCORROUT USING THE STRIP BIF AND APPLCOMPAT = V10R1
PH226172020-03-25 UI68630N/A     DISABLE AGGRESSIVE QUERY BLOCK MERGE WHEN A SARGABLE JOIN PREDICATE DOES NOT EXIST.
PH226332020-08-10PE PH31619UI70980N/A     CHANGE THE RID POOL THRESHOLD FROM APS ESTIMATE TO ACTUAL WHEN POSSIBLE
PH226882020-05-01 UI68577N/A     DB2 12 FOR Z/OS INTERNAL SERVICEABILITY UPDATE
PH227102020-03-16 UI68437N/A     DIFFERENT RESULTS ARE RETURNED FROM A QUERY OFFLOADED TO IDAA BETWEEN V5 AND V7 USING BIF_COMPATIBILITY = V9_DECIMAL_VARCHAR
PH228582020-03-31 UI68746N/A     ABEND04E RC00E70005 AT DSNXROJ1 M524 FOR A QUERY THAT USES AN ACCESS PATH WITH SPARSE INDEX
PH229332020-07-06 UI70419N/A     ACCESS PATH DEGRADED AFTER INDEX CHANGED TO EXCLUDE NULL KEYS
PH232302020-05-07 UI69391N/A     PAIR-WISE STAR JOIN ( PWJ ) CHOSEN WHEN THERE IS A MORE EFFICIENT ACCESS PATH
PH232382020-06-10 UI69968N/A     DB2 12 FOR Z/OS FTB NEW FUNCTION
PH232552020-04-20 UI69109N/A     REMOTE QUERY USING MULTIPLE UNION ALL CLAUSES RECEIVES SQLCODE30020 OR ABEND04E RC00E70005 AT DSNXRSBC P041
PH232602020-06-24 UI70240N/A    YDSNKTRAV GOT A PAGE NUMBER X’FFFFFFFF’ AFTER CHECKING A LEAF PAGE AND CAUSED ABEND04E DSNKTRAF:2029
PH233432020-05-27 UI69715N/A    YABEND04E RC00C90101 AT DSNIDM DSNIRNXT ERQULA5029 OCCURRED ON A QUERY WITH CTE AND FULL OUTER JOIN
PH234032020-04-01 UI68773N/A     INCORRECT JOIN ORDER CAN BE CHOSEN FOR A QUERY WITH SIDEWAYS REFERENCES
PH235932020-04-14 UI69007N/A    YINCORRECT ORDER WHEN EXECUTING QUERY WHICH INCLUDES FULL OUTER JOIN AND ORDER BY AND AN OLAP FUNCTION
PH235942020-06-10 UI69974N/A    YINCORROUT FOR QUERY WITH INLIST (IN-LIST) ACCESS PATH (LESS ROWS THAN EXPECTED)
PH236442020-07-31 UI70859N/A     ABEND04E RC00E70005 AT DSNXRUNA M200 WHEN RUNNING A QUERY
PH239432020-04-23 UI69168N/A    YINCORROUT NULL RETURNED INSTEAD OF A COUNT FOR A QUERY USING PERCENTILE_DISC(0) WITH NULLS IN THE DATA AND DESCENDING ORDER
PH242792020-07-08 UI70454N/A    YOPTIMAL ACCESS PATH IS NOT USED WHEN AFTERJOIN PREDICATE WITH CHILD PREDICATE AS JOIN PREDICATE DOESN’T PROVIDE EXTRA
PH243372020-05-04 UI69325N/A     PERFORMANCE PROBLEM CAN OCCUR WITH TABLE EXPRESSIONS AND MORE UNION DISTRIBUTION
PH246672020-06-02 UI69831N/A    YABEND04E 00C90101 LOC DSNIDM DSNKDPG ERQUAL 500A OCCURRED DURING INDEX PAGE DELETION FOR FTB
PH249792020-07-01 UI70375N/A    YLOOP MAY OCCUR WHEN PARALLELISM IS ENABLED AND LOOPING OCCURS IN DSNXOLDP
PH250452020-08-28 UI71313N/A    YLIST PREFETCH ACCESS WAS CHOSEN ON THE INNER TABLE WHEN DYNAMIC PREFECH MAY BE BETTER.
PH251482020-06-01 UI69794N/A     ABEND0C4 RC00000010 AT DSNXOGBM OFFSETC29E MAY OCCUR FOR QUERY WITH COLUMN EXPRESSION AS THE LAST PREDICATE AND TABLE IS EMPTY
PH251962020-09-01 UI71349N/A     FTB SERVICEABILITY FIXES FOR DB2 12 FOR Z/OS
PH252402020-06-02 UI69834N/A    YIRLM SUPPORT TO HANDLE ERROR RETURNED FROM DB2 P-LOCK EXIT WHEN DRIVEN FOR SHARED STATE TRACKING ONLY
PH254482020-11-23 UI72734N/A    YINCORROUT FOR AN INNER JOIN QUERY THAT USING CTE, MORE ROWS THAN EXPECTED WILL RETURN
PH255072020-06-25ModifiedUI70250N/A     INEFFICIENT ACCESS PATH AFTER CONVERSION TO UTS
PH256892020-11-03 UI72379N/A     EVEN WITH DB2 V12 DESCSTAT=NO, DESCRIBE CURSOR FOR STATIC QUERY RETURNS COLUMN NAMES INSTEAD OF COLUMN NUMBERS OR ORDINAL POS
PH257002020-08-25 UI71239N/A     INEFFICIENT ACCESS PATH EXCLUDES MULTI-INDEX ACCESS AFTER CONVERSION TO UTS
PH257352020-06-29 UI70324N/A     ABEND04E RC00E70005 AT DSNXGARI M621 FOR A QUERY WITH AN ACCESS PATH USING A VIRTUAL TABLE IN ITS OUTER JOIN
PH258012020-06-17 UI70116N/A    YABEND04E RC00C90101 LOC DSNIDM DSNKTRAV ERQUAL501C OCCURRED DURING INDEX SPLIT WITH FTB
PH258592020-06-17 UI70114N/A    YFTB STORAGE LEAK IN EXTENDED LSQA CAUSED BY DSNKFTOM – DSNV508I
PH258972020-07-28 UI70793N/A    YABEND0C7 AT DSNXRDEC OFFSETE380 FOR QUERY CONTAINS MULTIPLICATION ON DECIMALS WHEN CURRENT PRECISION = DEC31
PH259492020-12-11 UI73092N/A    YABEND04E 00C90105 AT DSNIASFP 0CA4 DURING INSERT WORKLOADS USING INSERT ALGORITHM 2 – IAG2
PH261092020-06-25 UI70271N/A    YFTB OVERLAY ABEND04E RC00E2002F DSNKFTOM DSNSVSFM OFFSET008AE
PH261152020-07-10 UI70500N/A     ABEND0C4 RC00000038 IN DSNXOPDS AT OFFSET00188 OR OFFSET0018C CAN OCCUR FOR QUERY WITH AN XMLAGG FUNCTION
PH26180  OPENOPEN CARTESIAN PRODUCT RESULTING FROM INCORRECT JOIN ORDER
PH263262020-07-31 UI70860N/A     ABEND04E RC00E70005 AT DSNXOSR :P002 MAY ISSUED FOR QUERY HAVE PREDICATE USE LISTAGG WITH DISTINCT
PH264022020-06-30 UI70325N/A     FTB ABEND04E 00C90101 LOC=DSNIDM DSNKMDEL ERQUAL 5010 OCCURS DURING MASS DELETE OPERATION
PH264202020-11-09 UI72485N/A     ACCESSTYPE=O IS USED TO PUSHDOWN JOIN PREDICATES ON TABLE EXPRESSION OR VIEW WHEN BETTER ACCESS PATH EXISTS
PH264322020-08-11 UI71022N/A    YINCORRECT ORDER RETURNED ON SQL STATEMENT WITH INLIST SUBQUERY AND INDEX CAN NOT MATCH ALL THE COLUMNS IN THE INLIST PREDICATE
PH26498  OPENOPEN(Y)ABEND04E RC00C90101 DSNISFPI ERQUAL5019 WHEN USING INSERT ALGORITHM 2 IAG2
PH265822020-08-24 UI71214N/A    YINEFFICIENT ACCESS PATH INCLUDING A NESTED LOOP JOIN TO THE INNER TABLE USING RSCAN
PH266332020-07-30 UI70837N/A     SUB-OPTIMIAL ACCESS PATH IS USED FOR A STAR JOIN QUERY WHEN A DIMENSION TABLE RETURNS 0 ROW
PH266442020-10-21 UI72188N/A    YRC00C90101 AT DSNOPUFF ERQUAL500A
PH267512020-08-20 UI71166N/A    YINCORRECT OUTPUT OR POOR PERFORMANCE FOR CORRELATED QUERIES WITHCOMPLEX JOINS
PH268152020-07-13 UI70523N/A    YFTB INSERT ABENDS0C4 RC00000038 PIC38 IN DSNKTRAV OFFSET1B81A
PH268232020-08-31 UI71329N/A    YSQLCODE171 FOR SQL REPLACE ON UNICODE GRAPHIC CHARACTER WHEN there’s surrogate pair
PH268452020-07-13 UI70523N/A    YFTB INSERT ABENDS0C4 RC00000038 PIC38 IN DSNKTRAV OFFSET1B81A
PH268792020-07-20 UI70672N/A     ABEND04E RC00E70005 AT DSNXGSGP M002 MAY ISSUE FOR QUERY WITH GROUP BY THAT CONTAINS SAME COLUMN MORE THAN ONCE
PH269172020-07-15 UI70569N/A    YPOOR PERFORMING QUERY DUE TO LESS INDEX MATCHING PREDICATES DETECTED WITH MULTIPLE QUERY BLOCKS WITH NESTED TABLE EXPR
PH270782020-09-04PE PH35088UI71423N/A    YABEND0C4 RC04 AT DSNXEDSC+03D32 OR ABEND04E RC00E70005 AT DSNXEBR:M705 CAN OCCUR ON A QUERY
PH271002020-08-11 UI71023N/A     BEST INDEX IS NOT USED WHEN QUERY HAS A BETWEEN AND PREDICATE ON PARTITION KEY AND SOME PARTITIONS ARE EMPTY
PH272072020-08-04 UI70899N/A    YABEND04E RC00E501A1 AT CSECT DSNVSRX OFFSET03186 WHEN CANCELLING A COMPLEX QUERY WHICH CONTAINS MULTIPLE PAIR WISE JOINS
PH273202020-07-29 UI70814N/A     FTB ABENDS0C4 00000011 IN DSNKFTDL OFFSET0117C DURING DELETE PROCESSING FOR INDEX KEY X’FFFFFFFF’
PH273302020-08-28 UI71312N/A     SLOW SQL PERFORMANCE CAN OCCUR WHEN FETCH FIRST N ROWS ONLY OR OPTIMIZE FOR N ROWS IS SPECIFIED AND THERE ARE NO STATS ON TABLE
PH273352020-10-02PE PH32375UI71890N/A     ABEND ON RID SPECIFIC DELETE AFTER MASS DELETE
PH275082020-08-03 UI70877N/A    YPOOR PERFORMING ACCESS PATH CHOSEN WHEN AN INDEX THAT CAN MATCH ON JOIN PREDICATES MAY BE INCORRECTLY PRUNED
PH275552020-08-26 UI71269N/A     IN DB2 12, SUB-OPTIMAL ACCESS PATH IS USED FOR QUERY CONTAINING A VIEW OR TABLE EXPRESSION WHICH HAS MULTIPLE OUTER JOINS
PH276162020-10-01 N/A    N/A     POOR PERFORMING QUERY DUE TO IMPACT OF UNDERESTIMATED JOIN SIZE TO THE DECISION OF JOIN PREDICATE PUSH DOWN
PH276712020-08-20 UI71162N/A     SQLCODE410 OR SQLWARN366 ON AN UPDATE OF A DECFLOAT COLUMN WHEN DECP HAS DECIMAL=COMMA
PH276872020-09-02 UI71392N/A     PROVIDE RELIEF FOR QUERIES REACHING THE LIMITS OF ZPARM MAX_OPT_STOR
PH277302020-09-22 UI71704N/A     ABEND04E RC00E70005 AT DSNXRRPO M104 WHEN FULL OUTER JOIN ON PREDICATE COLUMN IS DECFLOAT
PH278222020-08-20 UI71171N/A    YDEFAULT_INSERT_ALGORITHM SUBSYSTEM PARAMETER CHANGE OF DEFAULT FROM 2 TO 1
PH278402021-02-05 UI73843N/A     INCORROUT FROM QUERY THAT REFERENCES A LARGE VARCHAR FOR BIT DATA COLUMN AS A JOIN PREDICATE FOR SORT MERGE JOIN
PH279142020-09-02 UI71393N/A     ABEND0C4 RC00000010 IN DB2 DIST AT DSNXOTS FOR OFFSET11FC2 OR OFFSET11EE0
PH280502020-09-10 UI71492N/A    YR-SCAN IS USED WHEN MATCHING INDEX EXISTS
PH281042020-09-04PE PH36908UI71428N/A     LOAD FORMAT DELIMITED OF DECIMAL FIELDS WITHOUT A DECIMAL POINT SPECIFIED CAN FAIL WITH MSGDSNU333I AND DISCARDING THE RECORD
PH281792020-10-22 UI72212N/A     CREATE INSTEAD OF TRIGGER ON A VIEW CAN GET AN UNEXPECTED SQLCODE -552 ERROR
PH281822020-09-25 UI71784N/A     INDEX LOOK ASIDE SUPPORT WHEN INDEX FAST TRAVERSE BLOCK(FTB) IS IN USE
PH282282020-09-10 UI71496N/A     ABEND0C4 RC38 AT DSNXOW1 OFFSET03490 FOR A QUERY WITH OVER 32767COLUMNS IN PREDICATES OR UNION DISTRIBUTION
PH282642020-09-04 UI71430N/A    YINCORROUT MAY HAPPEN FOR AN SQL STATEMENT REFERENCING A TABLE EXPRESSION OR VIEW OR SQLTABLEUDF WHICH CONTAINS MULTIPLE JOINS
PH284342020-09-02 UI71390N/A     BLOCK JOIN PREDICATE PUSHDOWN WHEN THE TARGET SUBQUERY CONTAINS A MATERIALIZED WORKFILE
PH284432020-12-07 UI72960N/A     ABEND04E RC00D3440B DSNLXOQS AT LOGICAL OFFSET 0378
PH285082020-10-28 UI72281N/A     ABEND 0C4 AT DSNXGRDS.DSNXODTX+00206 MAY OCCUR WHEN THE QUERY CONTAINS GROUPING SET AND THERE IS A GROUP BY IN THE BODY OF A
PH285512020-09-29 UI71812N/A     BACK OUT CERTAIN CASES OF IMPLICIT CAST INDEXABLE SUPPORT THAT INTRODUCED IN V12
PH286212020-09-15 UI71567N/A     XMLQUERY AND XMLTABLE ADD INVALID DATA WHEN INPUT MESSAGE GREATER THAN 1M
PH287312021-01-07 UI73383N/A     ABEND04E RC00C90101 AT DSNIDM DSNISRID ERQUAL500A OCCURRED FOR A SECOND FETCH FROM A ROWSET CURSOR
PH288102021-01-28 UI73671N/A     MSGDSNT286I INDICATES APREUSE WAS NOT SUCCESSFUL WHEN THE ACCESSPATH BEING REUSED CONTAINS CORRELATED SPARSE INDEX IN TBL EXPR
PH289232020-10-20 UI72172N/A     INEFFICIENT ACCESS CAN OCCUR WHEN A PREDICATE VALUE FALLS OUTSIDE THE RANGE OF H2KEY/L2KEY
PH291022020-10-27 UI72276N/A     ABEND04E DSNKTRAV ERQUAL505B RC00C90101 FTB TRAVERSAL
PH291432020-10-05 UI71927N/A    YSTORAGE LEAK FOR PREDICATE PROC MAY OCCUR WHEN EXECUTING A PACAKGE ON FL505
PH291752020-10-19 UI72147N/A     SQLCODE199 REBINDING AN SQLPL PACKAGE WHICH CONTAINS SQL WITH A TABLE EXPRESSION THAT HAS AN ORDER BY WITH VARIABLE
PH293362020-09-22 UI71351N/A    IRLMCORRECT RESULTANT HELD STATE FOR FTB PLOCKS WHEN PLOCK EXIT WOULD HAVE EXITTED WITH ERROR.
PH294822020-10-19 UI72148N/A     POSSIBLE INCORROUT WHEN QUERY W/ TEMPORAL PREDICATE IS OFFLOADEDAND BOTH OPERANDS OF TEMPORAL PRED ARE LITERALS WITH CHAR/VARCHA
PH295662020-11-13 UI72590N/A      INCORROUT MAY HAPPEN FOR QUERY WITH UNION ALL AND ORDER BY
PH296122020-10-05 UI71930N/A    YINCORROUT USING LISTAGG. MISSING SQLCODE -137 AND INCORRECT LENGTH REPORTED.
PH296662020-10-01 UI71877N/A     DB2 12 SERVICEABILITY FOR INFLUENCING ACCESS PATH SELECTION
PH296762020-10-16 UI72118N/A     ABEND04E RC00C90101 AT DSNKTRAV 5058 DURING INSERT VIA FTB
PH298422020-10-19 UI72148N/A     POSSIBLE INCORROUT WHEN QUERY W/ TEMPORAL PREDICATE IS OFFLOADEDAND BOTH OPERANDS OF TEMPORAL PRED ARE LITERALS WITH CHAR/VARCHA
PH299182021-01-19 UI73538N/A     ABEND0C7 AT DSNXRDEC OFFSET8960 MAY BE ISSUED FOR A QUERY THAT REF A VIEW OR AN SQL TABLE UDF THAT CONTAINS RECURSIVE CTE
PH299792020-10-27 UI72275N/A    YINCORRECT OUTPUT FOR SELECT USING MAX() OR ROWNUMBER() OVER() FUNCTION USED WITHIN INSERT
PH300402020-10-27 UI72279N/A    YINCORRECT OUTPUT CAN OCCUR WITH AN ACCESS PATH USING PAGE RANGE SCREENING.
PH301362020-12-30 N/A    N/A     POOR PERFORMING QUERY DUE TO INEFFICIENT JOIN ORDER CHOSEN AFTERQUERY BLOCK MERGE
PH302312020-11-17 UI72634N/A     ABEND04E RC00E70005 DSNXOACM M120 FOR A QUERY WITH A COMMON TABLE EXPRESSION AND COLUMN WITH A COLUMN MASK
PH302932020-11-16 UI72614N/A     ABEND04E RC00E2000C DSNSVSVB OFFSET0A54 FOR A QUERY USING SORT
PH303572020-10-28 UI72302N/A     SUBOPTIMAL QUERY PERFORMANCE DUE TO GLOBAL OPTIMIZATION TRANSFORMATION OF NONCORRELATED IN-SUBQUERY PREDICATE
PH303652020-11-09PE PH34584UI72487N/A     PREDICATES THAT ARE PUSHED INTO A VIEW CONTAINING UNION ALL CANNOT UTILIZE EXPRESSION INDEXES.
PH303662020-12-15 UI73164N/A    YDSNICUMW 5003 OR DSNIOW 5003 00C90101 ABENDS OCCUR WHEN THE DATAPAGE IS RE-FORMATTED BY AN INSERT THREAD RUNNING IAG2
PH303962021-01-06 UI73347N/A     OPTIMAL ACCESS PATH MIGHT NOT BE USED FOR A JOIN QUERY WHICH CONTAINS BOTH LOCAL PREDICATE AND JOIN PREDICATE ON SAME COLUMN.
PH304102020-11-05 UI72426N/A     DB2 MAY CHOOSE TO MATERIALIZE CERTAIN QUERY BLOCKS THAT SHOULD BE CORRELATED VIA PIPELINING
PH304672020-12-14 UI73119N/A     ABEND04E RC00E70005 AT DSNXOPCO M096 FOR AN SQL STATEMENT SATISFYING ALL CONDITIONS DESCRIBED IN THIS APAR
PH304682020-10-28 UI72283N/A    YINCORROUT COULD OCCUR FOR A QUERY WITH WHERE NOT EXISTS OR HAVING NOT EXISTS IF THERE IS ALSO A GROUP BY ON A
PH305942020-11-10 UI72503N/A    YINFINITE LOOP MAY OCCUR FOR AN SQL STATEMENT WITH MULTIPLE OUTER JOINS AND IN-SUBQUERY PREDICATES
PH307382020-11-05 UI72422N/A    YABEND0C4 00000004 RC04 PIC04 DSNB1DCM +0123E
PH307792020-12-03 UI72907N/A     ALLOW INDEXABILITY FOR SET COLUMN FUNCTIONS UNDER CERTAIN CONDITIONS
PH309782021-06-01ModifiedUI75643N/A     SUBSYSTEM PARAMETER TO ENABLE INDEX IN-MEMORY OPTIMIZATION (FTB) FOR NON-UNIQUE INDEXES
PH309792020-11-23 UI72742N/A    YDATA CORRUPTION AFTER REORG COMPLETED WITH RC00 WITH PH28092 INSTALLED, RC00C90206 ERQUAL5007, INCORROUT, ABEND0C4 DSNURBXD
PH309822020-11-30PE PH38003UI72850N/A     INEFFICIENT LESS MATCHING INDEX CHOSEN.
PH311182021-01-06 UI73357N/A     INEFFICIENT JOIN ORDER AND JOIN TYPE CAN BE SELECTED AFTER QUERYBLOCK MERGE
PH311462021-01-20 UI73548N/A     ABEND0C4 RC0000003A RC04 PIC3A DSNSVSVB +00CB0 FOR THE QUERY WITH HUGE NUMBER OF UDFS
PH313852020-11-30 UI72849N/A     PERFORMANCE ISSUES CAN OCCUR WHEN A QUERY CONTAINS A UNION ALL
PH314902021-01-06 UI73359N/A     ABEND0C4 DSNXRSOR +146 @ UI62958
PH315662022-01-12 UI78898N/A    YUSER RECEIVED AN UNEXPECTED ABEND04E RC00E70100 IN DSNXGRDS DSNXISB7 P110 ON AN INSERT STATEMENT
PH316192020-12-01 UI72872N/A    YPOOR PERFORMING SQL QUERY DUE TO LIST PREFETCH INCORRECTLY FALLING BACK TO RSCAN DUE TO A NEGATIVE RID LIMIT THRESHOLD
PH316212021-01-07 UI73365N/A     POOR PERFORMING QUERY WHEN DB2 SELECTS INDEX + LIST PREFETCH AP FOR LEADING TABLE WHILE INDEX IS CLUSTERING AND CAN AVOID SORT
PH316802021-02-15 UI73982N/A     POOR PERFORMANCE CAN OCCUR FOR A QUERY WITH TABLES HAVING DIFFERENT CCSID’S
PH317752022-01-05 UI78823N/A    YA LINEAR INDEX WITH > 255 PIECES IS NOT RECOVERED BY RESTORE SYSTEM UTILITY
PH317962021-01-08 UI73397N/A    YA QUERY USING DEGREE=’ANY’ MAY HAVE IDENTICAL ROWS RETURNED
PH318722021-02-02 UI73756N/A     AN INEFFICIENT ACCESS PATH IS CHOSEN AFTER A TABLE EXPRESSION ISMERGED
PH319092020-12-24 UI73307N/A     INSERT STATEMENT WITH TIMESTAMP FUNCTION TO INSERT INTO A VARCHAR/CHAR COLUMN MAY GET SQLCODE -408 INCORRECTLY RETURNED
PH320972021-02-02 UI73760N/A     THE QUERY USING OFFSET CLAUSE WITH UNION AND HOST-VARIABLE CAN RETURN EMPTY RESULT SET
PH323552021-02-12 UI73972N/A    YINCORRECT RESULT WITH NO ROWS RETURNED FOR QUERY FROM TABLE FUNCTION USING LITERAL
PH323752020-12-30 UI73320N/A     INSERT ROW FAILS WITH SQLCODE161 AFTER PH27335/UI71890 HAS BEEN APPLIED 20/12/04 PTF PECHANGE
PH323762021-01-06 UI73362N/A    YADDITIONAL TAG SORT AND SORT POOL VERIFICATION.
PH324682021-01-20 UI73559N/A     INEFFICIENT ACCESS CAN BE CHOSEN FOR A QUERY CONTAINING A FF1R CLAUSE
PH326612021-01-07 UI73394N/A     ABEND04E RC00E70005 AT DSNXEFDA OFFSET035FC FOR A QUERY THAT REQUIRES A VERY LARGE RID SORT.
PH326882021-03-03 UI74227N/A     POOR PERFORMANCE CAN OCCUR FOR A QUERY WITH FF1R.
PH326902021-02-18 UI74060N/A    YINCORROUT WHEN A SAME EXPRESSION ALIAS APPEARS IN THE SELECTION LIST MULTIPLE TIMES AND THIS QUERY RUNS ON PARALLELISM
PH327262021-03-03 UI74226N/A     POOR PERFORMANCE CAN BE SEEN WHEN A QUERY CONTAINS MULTIPLE PREDICATES.
PH329822021-01-20 UI73560N/A     POOR PERFORMING SQL QUERY WHEN THE QUERY HAS MULTIPLE RANGE OR BETWEEN PREDICATES WHICH QUALIFIED MULTI-INDEX ACCESS
PH329852021-02-03 UI73782N/A     ABND0C4 REASON00000004 AT DSNXGRDS DSNXOLIT OFFSET004DC MAY OCCUR FOR QUERY WITH STATEMENT CONCENTRATION ENABLED
PH331282021-02-10PE PH41952UI73918N/A     POOR PERFORMANCE CAN OCCUR FOR A QUERY CONTAINING A FFNR
PH331962021-04-19 UI74989N/A     PERFORMANCE ISSUE WHEN SPARSE INDEX WAS CHOSEN AND THERE EXISTS PREDICATES THAT ARE CAST TO VERY LONG LENGTHS
PH332852021-03-11 UI74393N/A     INCORRECT ACCESS PATH WHEN A VALUE COMPARE OR A BETWEEN PREDICATE WITH ARITHMETIC EXPRESSION ON DECIMAL VARIABLES AND A
PH333392021-03-03 UI74234N/A     LACK OF IFCID 376 REASON 3 (TIMESTAMP) IN DB2 V12 TRACE WHEN APPLCOMPAT = V10R1 AND BIF_COMPAT IS NOT CURRENT
PH334142021-03-29 UI74634N/A    YRECOVER UTILITY DOES NOT CORRECTLY RECOVER THE COPY YES INDEXES CAUSING DATA/INDEX MISMATCH
PH334432021-02-10 UI73921N/A     ABEND04E RC00C900D0 AT DSNXROHB OFFSET23DC4 MAY OCCUR FOR NOT NULL LOB/XML COLUMN INVOLVING IN OUTER JOIN
PH336362021-03-08 UI74325N/A     INCORRECT OUTPUT FOR AN SQL STATEMENT THAT REFERENCES A VIEW WITH MULTIPLE OUTER JOINS
PH340452021-03-15 UI74443N/A    YINCORRECT SORT ORDER IN OUTPUT OF SELECT STATEMENT
PH340462021-03-29 UI74636N/A     INCORROUT FOR A QUERY WITH EXISTS PREDICATE IN CASE EXPRESSION AND OUTER JOINS
PH340562021-04-02 UI74752N/A     ABEND04E RC00E70005 AT DSNXOW2D P333 MAY HAPPEN WHEN UPDATING A VIEW WITH AN ISNULL PREDICATE
PH340962021-02-16 UI74002N/A     ABEND0C4 RC38 DSNXOGA OFFSETAE6C AE6C WHILE RUNNING COMPLEX QUERY
PH341782021-05-03 UI75206N/A     SUB-OPTIMAL ACCESS PATH CAN BE CHOSEN FOR THE QUERY
PH341892021-04-07 UI74812N/A     ABEND04E RC00C90101 AT DSNIDM DSNIWNRF ERQUAL5006 MIGHT HAPPEN WHEN A QUERY WITH LEFT OUTER JOIN AND SORT MERGE JOIN IS USED
PH342412021-04-12 UI74891N/A     ABEND0C4 RC38 DSNXECST OFFSET09F6 09F6 WHILE RUNNING COMPLEX QUERY
PH342472021-03-12 UI74421N/A     INEFFICIENT INDEX CHOSEN IN A RANGE-LIST ACCESS PATH.
PH342922021-06-23 UI76040N/A    YROLLBACK AFTER ALTER TABLE ALTER COLUMN SET WITH DEFAULT DOES NOT RESTORE PRIOR DEFAULT VALUE
PH344252021-03-08 UI74327N/A     INCORRECT OUTPUT OF CASE WHEN COMPARING VARCHAR COLUMNS
PH344652021-04-16ModifiedUI74966N/A    YABENDS0C4 IN DSNIASFP OFFSET001A8 DURING INSERT WORKLOAD USING INSERT ALGORITHM 2 – IAG2
PH344682021-04-20 UI75007N/A     ABEND04E RC00C90101 AT DSNKTRAV ERQUAL5021 VIA FTB TRAVERSAL
PH345842021-03-30 UI74673N/A    YABEND04E AT DSNXOB2 M105 ON A REBIND PACKAGE 21/03/23 PTF PECHANGE
PH346422021-05-17 UI75437N/A     INCORROUT WRONG ROWS RETURNED FOR A QUERY WITH MULTIPLE JOINS WITH NOT EXISTS CORRELATED SUBQUERY
PH346892021-04-02 UI74759N/A    YINCORRECT OUTPUT FROM SELECT WHEN NULL HOST VARIABLE WAS USED IN A PREDICATE AGAINST NOT NULL COLUMN
PH348072021-03-29 UI74649N/A     EXTRA CPU COST OF MASS DELETE
PH348592021-05-05 UI75254N/A     DB2 12 FOR Z/OS NEW FUNCTION FOR FTB (FAST TRAVERSE BLOCKS)
PH349032021-03-17 UI74490N/A     ABEND04E RC00E70005 DSNXOFL M120 OCCURS ON UNION ALL
PH349082021-04-13 UI74918N/A     ABEND0C4 RC04 IN DSNXSRME OFFSET061A FOR SELECT USING TABLE EXPRESSION AND HYBRID JOIN
PH350802021-03-23 UI74586N/A     SQLCODE16061 ISSUED FOR A QUERY USING XMLCAST
PH350882021-04-07 UI74809N/A    YHIGH CPU DUE TO LONG PREPARES AND LOW HIT RATIO IN DYNAMIC STATEMENT CACHE WHEN DYNAMIC SQL PLAN STABILITY IS ENABLED
PH354642021-04-20 UI75013N/A     INEFFICIENT INDEX CHOSEN BETWEEN COMPETING INDEXES WHEN ONE CANDIDATE PROVIDES INDEX ONLY
PH355962021-04-07 UI74814N/A    YINSERT SPLITTING PAGE INTO FTB LEAF NODE GOT DSNKFTIN:5002 ABEND BECAUSE OLD PAGE THAT CAUSE THE PAGE SPLIT WAT MISSING IN FTB.
PH358722021-06-17 UI75961N/A    YABEND0C4 RC4 DSNURWBF+0B012 IN PARALLEL LOAD TO THE SAME PARTITION
PH359592021-04-13 UI74908N/A    YINCORROUT FOR QUERY WHERE LEADING TABLE IN ACCESS PATH IS ACCESSED WITH AN EQUAL UNIQUE INDEX AND NEXT TABLE HAS PREFETCH
PH360932021-07-30 UI76541N/A     INEFFICIENT JOIN TYPE CHOSEN WHEN THE SAME INDEX IS USED WITH LESS MATCHING COLUMNS
PH361472021-04-29 UI75178N/A     ABEND04E RC00E20018 AT DSNSTKGG OFFSET00D76 ISSUED FOR A QUERY ON VIEW AND ITERATING ENTRIES OF DSNXOV1 IN FORMATTED DUMP TRACE
PH361792021-06-02 UI75667N/A     DB2 12 FOR Z/OS ENHANCEMENT – APREUSE supports page range screening
PH362122021-10-28 UI77851N/A     JOIN PREDICATE PUSHDOWN IS BEING ELIMINATED UNDER SOME CIRCUMSTANCES.
PH362222021-05-14 UI75411N/A    YINCORRECT OUTPUT (TOO FEW ROWS RETURNED) POSSIBLE ON FULL OUTER JOIN RUNNING W/PARALLELISM, OUTER & INNER TABLES W/INDEX ACCESS
PH362972021-06-23 UI76046N/A     INEFFICIENT ACCESS PATH WHEN A POOR FILTERING INDEX LEG FOR RID LIST ACCESS IS CHOSEN FOR A JOIN 21/05/27 PTF PECHANGE
PH363002021-08-11 UI76686N/A     UNNECESSARY MULTI-INDEX LEGS ARE GENERATED WHEN A QUERY CONTAINSA HIGH UNCERTAINTY PREDICATE
PH363562021-05-24 UI75545N/A    YUNEXPECTED NULL RESULT IN QUERY RESULT.
PH364062021-05-07 UI75288N/A     INSERT KEY INTO FTB PROCESS DETECTING INCONSISTENT STRUCTURE MODIFICATION NUMBER THEN GOT DSNKFTIN:5043 ABEND
PH364302021-05-13 UI75393N/A    YINCORROUT WHEN A TABLE EXPRESSION IS ACCESSED BY ‘O’ ACCESS TYPE WHILE ITS BODY IS A SINGLE TABLE QUERYBLOCK AND INDEX IS USED
PH364342021-05-13 UI75392N/A     DB2 12 FOR Z/OS INTERNAL SERVICEABILITY UPDATE (Improve Create / Free FTB log recs)
PH365072021-08-18 UI76828N/A    YINCORROUT ON QUERY WITH MULTIPLE LEFT JOINS, COALESCE AND SPARSE INDEX
PH365312021-05-13 UI75391N/A    YABEND04E RC00C90101 AT DSNKINSN ERQUAL5009 AND DSNKFTIN ERQUAL5066 FOR FTB INSERT PLOCK FAILURE
PH365402021-05-11 UI75345N/A     AN INEFFICIENT ACCESS PATH USING LIST PREFETCH+SORT IS CHOSEN WHEN DIRECT INDEX ACCESS PROVIDES BETTER PERFORMANCE.
PH367372021-07-19 UI76363N/A     RIDPOOL FAILURES FOR QUERY WITH MULTI-INDEX ANDING AND NO QUALI FYING RIDS FOR SECOND INDEX
PH369082021-08-03 UI76579N/A     BACKING OUT THE BEHAVIOR FOR LOAD FORMAT DELIMITED FOR DECIMAL FIELDS WITHOUT A DECIMAL POINT THAT WAS IN 21/05/04 PTF PECHANGE
PH369782021-06-18 UI75978N/A     FTB MESSAGE MSGDSNT351I ISSUED INCORRECTLY
PH370192021-08-03 UI76581N/A     DB2 12 FOR Z/OS NEW FUNCTION FOR APREUSE
PH371162021-07-06 UI76220N/A     ABEND0C4 RC38 IN DSNSVSFB OFFSET0758 WHILE EXECUTING DYNAMIC SQL AND DYNAMIC PLAN STABILITY IS ACTIVE
PH371192021-08-03 UI77291N/A     INCONSISTENT ACCESS PATH FOR THE QUERY USING BETWEEN PREDICATE VERSUS RANGE PREDICATE
PH371512021-08-24 UI76897N/A     IAG2 ABEND04E RC00C90101 DSNIBHRE ERQUAL5007
PH371712021-06-15 UI75893N/A     INCORROUT MAY OCCUR FOR A QUERY USING INLIST OR BETWEEN WHICH CONTAINS COLUMNS
PH374162021-11-02 UI77911N/A     EXPLAIN PROVIDES INCORRECT ESTIMATE OF SU/TIME FOR QUERY.
PH374722021-06-25 UI76090N/A     WORKFILE ABENDS0C4 PIC4 AT DSNIWNRF OFFSET0DE50
PH378522021-07-22 UI76410N/A     DSNTIAUL INCORRECT OUTPUT CAN HAPPEN FOR SELECT FROM UTF-16 VARGRAPHIC COLUMN
PH380032021-09-21 UI77249N/A     SLOW QUERY PERFORMANCE FOR LEFT OUTER JOIN QUERY
PH382122021-07-07 UI76239N/A    YABEND04E RC00C90101 AT DSNKFTBU ERQUAL5061 AND DSNK1CNE ERQUAL5006 DURING FTB CREATION
PH382612021-10-18 UI77686N/A    YDSNIIDIS:5002 OCCURRED DUE TO A MISSING INDEX ENTRY CAUSED BY A FAILURE OF SERIALIZATION BETWEEN CREATE INIDEX AND INSERT.
PH382742021-08-04 UI76596N/A     ABEND04E RC00E2000C AT DSNXRSPL DSNSVSVB OFFSET00A54 WHEN INVOKING AN ADVANCED TRIGGER WITH HANDLER
PH384152021-10-25 UI77810N/A     POOR INDEX MAY BE CHOSEN FOR QUERY WITH MULTIPLE PREDICATES ON THE SAME COLUMN
PH385512021-08-06 UI76633N/A     ABEND04E RC00E2000F IN DSNSVSFB +00A2A WHILE RUNNING STORED PROCEDURES
PH386402021-08-09 UI76642N/A     DB2 PARALLELISM TASK ABEND04E RC00C90101 IN WORKILE MODULE DSNIWNRF ERQUAL 5010
PH388722021-09-02 UI77010N/A     UPDATE THE LENGTH OF THE ASCE AND PRHW – Fix in error see PH40706
PH391052021-10-18 UI77687N/A     DB2 12 FTB INDEXTRAVERSECOUNT = 4294967295 FOR OBJECTS NOT ENABLED FOR FTB
PH391112021-09-15 UI77157N/A     POOR PERFORMANCE OF AN UDPATE STATEMENT THAT CONTAINS A TABLE EXPRESSION ON THE NULL PADDING SIDE OF AN OUTER JOIN
PH392862021-08-23 UI76886N/A    YABEND0C4 RC003B AT DSNXODN OFFSET00600 AND ABEND04E RC00E2000D DSNLXDAL DSNSVSFB OFFSET00A18 LEAD TO DB2 ABTERM RC00E50702
PH393032021-10-18 UI77691N/A     ABEND04E RC00E70005 AT DSNXOP1 M150 FOR A CREATE FUNCTION
PH394132021-09-02 UI77014N/A     SQLCODE104 ISSUED WHEN REBIND ADVANCED TRIGGER WHICH CONTAINS A CALL STATEMENT WITH TABLE LOCATOR AS ITS PARAMETER
PH395842021-09-21 UI77253N/A     INEFFICIENT ACCESS PATH CHOSEN WHEN A QUERY CONTAINS A FF1R CLAUSE AND AN INDEX ACCESS CAN BE MATCHING
PH396312022-01-28 UI79120N/A    YABND0C4 RC10 IN DSNVXUL0 +00324 AFTER CANCEL THREAD
PH396772021-09-07 UI77044N/A     AN ALL ZERO PAGE ERROR – ABEND DSNKTRAV:5021
PH397512021-09-14 UI77134N/A     THE INEFFICIENT JOIN SEQUENCE MAY BE CHOSEN, WHEN THE JOIN TABLE HAS A CORRELATED PREDICATE
PH398222021-09-27 UI77334N/A     DB2 12 SERVICEABILITY FOR INFLUENCING ACCESS PATH SELECTION AND SUPPORTING INDEXABILITY FOR SQL STMTS USING IMPLICIT CAST
PH398752021-09-02 UI77013N/A     ABEND04E RC00E70005 DSNXOACM P070 WHEN A COLUMN MASK IS DEFINED
PH400032021-09-27 UI77336N/A    YCORRELATED SQL ISSUE, WHEN A TRANSITIVE CLOSURE PREDICATE IS GENERATED IN A SUB-QUERY INSIDE A CASE-WHEN CLAUSE.
PH402162022-01-21 UI79013N/A     BLOCK JOIN PREDICATE PUSHDOWN WHEN THE TARGET SUBQUERY ACCESS PATH IS TABLESPACE SCAN
PH402432022-04-19 UI80210N/A     DCC NEW FUNCTION FOR DB2ZAI V1.5
PH402692021-09-16 UI77189N/A    YABEND04E RC00E72068 AT DSNXSRME OFFSET01024 DUE TO A TIMING WINDOW WHEN USING INDEX FAST TRAVERSE BLOCK (FTB)
PH402732021-11-09 UI78000N/A     IMPROVE PERFORMANCE OF FTB STORAGE POOL ADMF INDEX MANAGER CL20
PH402742021-11-01 UI77882N/A     SQL0119N MIGHT BE ISSUED WHEN THE QUERY REFERENCES A VIEW AND THERE IS GROUP BY AND UNION ALL IN THE VIEW
PH402822021-09-21 UI77258N/A    YABEND04E RC00E2000C DUE TO STORAGE LEAK IN SUBPOOL ADMF AGL 64.
PH404322021-09-21 UI77254N/A     POOR PERFORMING QUERY WHEN AN INEFFICIENT JOIN ORDER IS CHOSEN FOR QUERY WITH FETCH FIRST N ROWS ONLY CLAUSE
PH404612021-11-02 UI77909N/A     ABEND04E RC00E70005 DSNXOSTP M210 CAN OCCUR ON A CREATE TRIGGER WHICH CONTAINS MORE THAN ONE CALL STATEMENT
PH405272021-10-26 UI77824N/A    YINCORRECT OUTPUT RETURNED BY A QUERY WHOSE ACCESS PATH IS BASED ON A DB2ZAI HOST VARIABLE MODEL
PH405392021-10-07 UI77500N/A     FTB DEADLOCK OCCURS WITH SYSTEM ITASK – CORRID=014.IFTOMK01
PH405432021-10-01 UI77407N/A     SLOW QUERY PERFORMANCE COULD OCCUR WHEN LIST PREFETCH IS CHOSEN
PH407062021-11-10 UI78014N/A     ABEND0C4-04 IN DSN3ID80 WITH PTF UI77010 APPLIED 21/09/17 PTF PECHANGE
PH409812021-12-14 UI78548N/A     ABEND0C4 AT DSNXRSOR OFFSET00136 FOR QUERY WITH VIRTUAL TABLE ACCESS ON TABLE EXPRESSION WITH CASE EXPRESSION
PH410552021-12-27 UI78742N/A    YSTORAGE LEAK WHILE RUNNING DRIVER PACKAGES WITH INCORRECT CLIENTAPPLCOMPAT SETTING
PH412052022-02-14 UI79308N/A     ABEND04E RC00E72068 AT DSNXSRME OFFSET0106E CAN OCCUR WHEN A TABLE EXPRESSION OR A VIEW CONTAINS UNIONALL
PH412122022-01-12 UI78897N/A    YINCORRECT OUTPUT MAY OCCUR FOR A QUERY USING XMLTABLE FUNCTION.
PH412162021-11-17 UI78137N/A     ABENDS0C4 RC04 PIC04 RC00000004 IN DSN3ID80
PH413072021-11-17 UI78136N/A     PERFORMANCE ISSUE WHEN THE JPP IS NOT ALLOWED FOR QUERY USING VIEW WITH UNION ALL INCLUDING A SMALL TABLE
PH413312021-12-08 UI78449N/A     ABEND0C4 RC11 DSNXOSL OFFSET074C8 ON A CREATE TRIGGER STATEMENT
PH413352021-12-04 UI78403N/A     ABEND04E 00C90101 AT DSNICMTC ERQUAL 5004
PH413502021-11-29 UI78295N/A    YINCORRECT OUTPUT MAY OCCUR WHEN IMPLICIT CAST IS PERFORMED FROM SMALL INT TO INT
PH414362022-01-24 UI78933N/A    YABEND04E RC00E70005 AT DSNXRFN:M509 MIGHT HAPPEN FOR A QUERY WITH A CORRELATED SUBQUERY CONTAINING FETCH FIRST N ROWS ONLY
PH414462021-12-22 UI78714N/A    YPOSTPONED ABORT ENTERED INTO AN INFINITE LOOP IN DSNB1CLM DUE TODB2 INTERNAL CONTROL BLOCK POINTING TO ITSELF
PH414482021-11-02 UI77914N/A     ABEND0C4 RC10 AT DSNXOCS OFFSET03770 WHEN RUNNING QUERIES WITH VIEWS OR TABLE EXPRESSIONS WITH JOIN RELATIONS
PH415352021-12-09 UI78457N/A    YHIGH ECSA USAGE AFTER DB2 ABNORMAL TERMINATION
PH415672021-11-23 UI78244N/A     DB2ZAI: A LONG RUNNING DB2ZAI DAEMON THREAD CANNOT BE PROPERLY HANDLED EVEN AFTER -STOP ML COMMAND
PH416272022-02-21 UI79152N/A    YDB2 SHOULD PROCESS DIFFERENT TIMESTAMP DIGITS WITH SAME LENGTH, BUT ACTUALLY NOT
PH416702021-12-14 UI78560N/A     ABEND04E RC00E70005 AT DSNXOSSF M909 WHEN A FNMEDIAN OR PERCENTILE_CONT/PERCENTILE_DISC IN A TABLE EXPRESSION IS NOT
PH417512021-12-01 UI78344N/A     DB2 12 FOR Z/OS NEW FUNCTION
PH417932022-05-26ModifiedUI80317N/A    YSQLCODE904 RC00C90084 TYPE100 FOR STATIC SQL STATMENT FROM A PACKAGE RUNNING WITH ISOLATION LEVEL RR
PH419432021-11-22 UI78223N/A    YINCORRECT OUTPUT MAY OCCUR FOR SUBSEQUENT QUERIES WITH A SINGLE UNION ALL AND DB2ZAI ENABLED
PH419522022-01-07 UI78851N/A     DB2 MAY CHOOSE DIRECT INDEX ACCESS OVER INDEX PLAN WITH SORT WITH LOWER COST
PH419782021-12-07 UI78424N/A     DISTRIBUTED CONNECTION CONTROL (DCC) PROCESSING OF IFCID0402 FORDB2ZAI DESIGN CHANGE TO PRODUCE DELTA VALUES
PH420462022-01-27 UI79100N/A     ABEND04E RC00C90101 AT DSNOTFLA ERQUAL5001 FOR QUERY WITH A COMBINATION OF XMLSERIALIZE AND ORDER BY
PH420812022-01-27 UI79099N/A    YAN UNEXPECTED SQLCODE406 RESULTS FROM USING THE MULTIPLY_ALT BUILT-IN FUNCTION WHEN USING BIGINT ARGUMENTS.
PH421982021-12-28 UI78765N/A     SQLCODE -805 MIGHT ISSUE FOR A DROPPED TRIGGER IN SMALL TIME WINDOW
PH424692022-01-24 UI79037N/A    YINCORROUT MAY HAPPEN WHEN THERE IS CORRELATED SUBQUERY WITH EXISTS OR NOT EXISTS WITH FFNR CLAUSE AND A HYBRID JOIN IS USED.
PH425172022-03-23 UI79856N/A    YINCORROUT MAY HAPPEN FOR QUERY USE HYBRID JOIN AND IOE INDEX
PH425722021-12-28 UI78763N/A     INEFFICIENT R-SCAN IS SELECTED FOR TABLES OF 3RD VIEW JOINED
PH425542022-01-04PE PH45702N/A    N/A    YDB2 V11 ABEND04E RC00E2000F ON DSNSVSFB OFFSET08C6 DURING DBET PROCESS.
PH425782022-02-14 UI79305N/A    YLATCH CONTENTION AFTER DB2 RESTART AND LPL RECOVERY HAS COMPLETED
PH425822022-02-01 UI79151N/A     ABEND04E RC00E72068 AT DSNXSMUA OFFSET017F0 MAY HAPPEN TO SQL STATEMENT THAT CONTAINS ORDER BY ON THE RESULT OF UNION ALL
PH429752022-01-27 UI79112N/A     SMF FIELD QISTFTBSIZE EXCEEDS ZPARM INDEX_MEMORY_CONTROL
PH429992022-03-09 UI79656N/A     ABEND04E RC00E70005 IN DSNXOSJT M110 MAY OCCUR FOR A QUERY WITH MULTIPLE OUTER JOINS WHEN STAR JOIN IS ENABLE
PH430832022-03-10 UI79673N/A     LOOP OCCURS IN DSNXOEXB DURING THE PREPARE OF A QUERY WHICH CONTAINS OUTER JOINS AND AN IN SUB-QUERY PREDICATE
PH433382022-02-14 UI79313N/A    YINCONSISTENT DATA AND VARIOUS ABENDS IN DSNIRNXT FOR PBR RPN TABLESPACE AFTER RECOVER USING AN INLINE COPY CREATED BY REORG.
PH434602022-07-11 UI81408UI81409YABEND04E RC000C90101 AT DSNGEPLC ERQUAL5064 MIGHT HAPPEN WHEN EXECUTING A PACKAGE IF REBIND IS OCCURRING AT THE SAME TIME
PH434952022-03-10 UI79683N/A     COMMIT LSN ENHANCEMENT IN V12 IS DISABLED.
PH435472022-02-17 UI79400N/A     INEFFICIENT ACCESS PLAN CAN BE PICKED FOR QUERIES WITH FETCH FIRST N ROWS ONLY / OPTIMIZE FOR N ROWS CLAUSE
PH435622022-02-22 UI79465N/A    YINCORROUT OR ABEND04E RC00C20305 MAY OCCUR FOR A PREDICATE COMPARING ROWIDS FROM DIFFERENT TABLES, DIRECT ROW ACCESS IS USE
PH435652022-02-14 UI79317N/A    YINCORROUT WITH FTB AND NON-UNIQUE INDEXES WITH GREATER THAN PREDICATE
PH435692022-03-04 UI79586N/A     ABEND04E RC00E70005 MIGHT HAPPEN AT DSNXOMB M020 FOR A QUERY WHEN HYBRID JOIN IS SELECTED
PH436632022-02-08 UI79219N/A    YDB2 THREAD ABEND ABND=0C1-00000001 from ssidDIST asid
PH437062022-05-27ModifiedUI80740N/A     IAG2 ABEND04E 00C90105 IN DSNIASFP ERQUAL 0CA4
PH437282022-02-22 UI79437N/A     WORKFILE ABEND04E RC00C90101 DSNISFW ERQUAL500B
PH437352022-03-10 UI79674N/A     AFTER ISSUING A DISPLAY STATISTICS COMMAND DISPLAY STATS(ITC) LIMIT(*), DB2 INVALIDLY ISSUES AN ABEND04E 00F9000C
PH437972022-02-22PE PH47264UI79458N/A    YABEND04E 00F31100 – Plus Early APAR PH41216
PH437982022-03-16 UI79767N/A     ACCESS PATH IS NOT REUSED ON REBIND PACKAGE WITH APREUSE FOR TABLES WHERE EXPANSION_REASON <> ‘ ‘ IN THE PLAN TABLE
PH438062022-03-24 UI79873N/A    YDB2 SUBSYSTEM ABNORMAL TERMINATION WITH RC00D94001 AFTER ABEND04E RC00E20028 DUE TO AN OVERLAY BY REORG REBALANCE
PH439492022-03-24 UI79862N/A    YDB2Z AI SQL OPTIMIZATION DASHBOARD DISPLAYS THE PACKAGE ERROR MESSAGE
PH440622022-02-24 UI79486N/A     ABEND04E RC00E70005 DSNXOV0:M101 MAY OCCUR FOR SQL THAT REFERENCES AN UDF THAT CONTAINS AN XMLSERIALIZE FUNCTION
PH440732022-03-08 UI79643N/A    YDB2 CRASHES WITH ABEND04E RC00E50079 DSNURMPG +386 AND 04F RC00E50054 AFTER RESTART(CURRENT) OF LOAD UTILITY
PH441092022-03-31 UI79969N/A    YALLEVIATE QUIESCING BEHAVIOR CHANGES DURING THE POPULATION OF NEW V12 SPACE LEVEL ATTRIBUTE FOR ALTER TABLESPACE PROCESSING
PH441192022-06-07ModifiedUI80920UI80921 SYSIBM.SYSTABLEPART LIMITKEY COLUMN HAS AN INCORRECT VALUE AFTERREORG ON A SUBSYSTEM WITH DECIMAL=COMMA IN THE DSNHDECP
PH441372022-03-14 UI79717N/A     SQLCODE904 WITH RC00D50001 AND RESOURCE 0000090A MIGHT OCCUR WHEN XMLCAST AND XMLQUERY OCCURS IN THE WHERE CLAUSE
PH441812022-04-01 UI79984N/A     ABEND04E RC00C90101 IN DSNICUBC ERQUAL5004
PH442112022-03-14 UI79710N/A    YQUERY PREDICATE PUSHDOWN INTO CTE SUBQUERY UNION LEG, FOR SUBQUERY WITH FFNR, MAY CAUSE INCORRECT OUTPUT
PH442312022-03-14 UI79718N/A     ABEND0C4 RC38 AT DSNXOYP1 OFFSET09BF6 issued for CREATE OR REPLACE PROCEDURE
PH442602022-05-17ModifiedUI80553N/A     ABEND0C4 RC04 AT DSNXOSEP OFFSET063C8 MAY OCCUR WHEN QUERY CONTAINS CTE OR TABLE EXPRESSIONS
PH442912022-07-20 UI81583UI81584YABENDS0C4 RC00000038 RC38 AT DSNIACCH+19B92 OR ABEND04E RC00C90101 AT DSNISRTI ERQUAL534C
PH443562022-03-22 UI79841N/A    YWORKFILE ABEND04E RC00C90101 IN DSNIWKFD ERQUAL5005 AND DB2 CRASH WITH MSGDSNV086E RC00F30801
PH443622022-06-13ModifiedUI80989N/A     ABEND 04E RC00E70005 AT DSNXOBM P030 WHEN QUERY HAS A CORRELATED PREDICATE THAT COULD BE USED AS A SPARSE INDEX KEY
PH44421  OPENOPEN DB2 12 FOR Z/OS NEW FUNCTION TO SUPPORT DB2Z AI
PH446182022-04-11 UI80090N/A    YABEND04E RC00E70005 DSNXESX4 P403 CAN OCCUR FOR AN OUTER JOIN QUERY REFERENCING A LOB COLUMN WITH A SHORT INLINE LOB LENGTH
PH446282022-04-11 UI80089N/A    YPRECONDITIONING APAR FOR A FUNCTION IMPROVEMENT OF IN-MEMORY RLFTABLE AUTO REFRESH IN DATA SHARING GROUP
PH446312022-06-06ModifiedUI80891N/A     ABEND0C4 RC00 AT DSNXRDEC OFFSET087F8 WHEN MIGRATING AN EXTERNALSQL PROCEDURE TO A NATIVE SQL PROCEDURE
PH447012022-04-01 UI79998N/A     ABEND04E RC00E70005 AT DSNXOGP ERQUALP666 MAY HAPPEN FOR THE QUERY WITH MORE THAN 1023 QUERY BLOCKS
PH448402022-06-21New & ClosedUI81105N/A     ABEND0C4-3B IN DSNWARDS OFFSET024F8 – See PH48139
PH449162022-07-27 UI81675UI81676 EDM STORAGE CAN GROW BEYOND VALUE OF EDMCSTMTC AND BEING NOT CONTRACTED
PH449282022-04-11 UI80091N/A    YINCORRECT OUTPUT CAN OCCUR WHEN AN EXPRESSION-BASED INDEX IS USED
PH449722022-06-02ModifiedUI80862N/A     MESSAGE DSNP007I RC00D70002 ISSUED FOR WORKFILE EXTEND FAILURE ON 32K WORKFILES
PH449832022-04-20 UI80092N/A     DB2Z AI SYSTEM ASSESSMENT PERIODICALLY INSERTS RECORDS INTO TABLES MORE FREQUENTLY THAN THE STATIME_MAIN SYSTEM PARAMETER
PH449992022-04-28ModifiedUI80349N/A    YINCORRECT RESULT SET COULD BE RETURNED WHEN USING JSON SQL
PH450852022-04-05 UI80027N/A     SQLCODE=-725 MIGHT BE RETURNED WHEN OFFLOADING A QUERY WHICH REFERENCES A VIEW WITH CTE HINT
PH451002022-06-01ModifiedUI80840N/A    YABEND04E 00C90101 AT DSNICUMW ERQUAL 5003
PH452002022-06-02ModifiedUI80859N/A    YDB2 ABEND04E 00E2000F IN DSNSVSFB OFFSET00A6A AND DB2 CRASH MSGDSNV086E REASON 00F30801
PH452622022-04-25 UI80308N/A    YABEND0C4 AND STORAGE OVERLAY AFTER WILD BRANCH IN DSN9SCN9 TO INVOKE THE FRR ROUTINE DURING DISPLAY DB COMMAND EXECUTION
PH45272  OPENOPEN USING QUERY ACCELERATION WITH PREPARE ATTRIBUTES CLAUSE ‘ CONCENTRATE STATEMENTS OFF ‘ MAY CAUSE PERFORMANCE IMPACT
PH45322 NewOPENOPEN ABEND04E RC00E2000C AT DSNSVBK OFFSET00A54 MAY HAPPEN WHEN THREAD HANDLES A LARGE NUMBER OF ALTER STATEMENTS.
PH453582022-05-20ModifiedN/A    UI80601YWHEN RUNNING SQL DATA INSIGHTS Z16 WITH ZAIU GET ABEND=U4039
PH453692022-06-15ModifiedUI81024N/A     PERFORMANCE ISSUE WHEN SPARSE INDEX WAS CHOSEN BUT IT SPILLS INTO PHYSICAL WORKFILE
PH454832022-05-12ModifiedUI80499N/A     ABEND04E 00E20018 AT DSNSLD4 DSNSTKGG OFFSET00F76
PH455812022-05-06ModifiedUI80442N/A    YABEND04E RC009C0101 AT DSNKINSL ERQUAL5033 DURING INSERT
PH456432022-05-11ModifiedUI80483N/A     SQL STATEMENT POOR PERFORMANCE DUE TO INEFFICIENT JOIN ORDER FOR SUBQUERY IF THERE ARE TWO TABLES JOIN ON UNIQUE KEY.
PH457022022-05-03ModifiedN/A    N/A    YDB2 V11 REAL STORAGE CREEPS AFTER APPLY APAR PH42554/PTF UI78803 22/04/14 PTF PECHANGE – PH45702 Db2 11
PH457482022-05-11ModifiedUI80481N/A    YAN INCORRECT RESULT CAN BE RETURNED FROM A QUERY WITH UNION ALL THAT INCLUDES AN ORDER BY CLAUSE WITH OFFSET SPECIFIED.
PH457902022-05-11ModifiedUI80484N/A     DB2 MAY MATERIALIZE A SIDE WAY REFERENCED TABLE EXPRESSION/VIEW, WHILE JPP CAN PROVIDE BETTER PERFORMANCE.
PH460282022-05-28ModifiedN/A    UI80758 DB2Z AI SYSTEM ASSESSMENT PERIODICALLY INSERTS RECORDS INTO TABLES MORE FREQUENTLY THAN THE STATIME_MAIN SYSTEM PARAMETER
PH460582022-07-05New & ClosedUI81303N/A    YCROSS LOADER (LOAD WITH INCURSOR) GETS ABENDS0C1 ABENDS0C6 PECHANGE 22/05/19 PTF
PH461652022-06-16ModifiedUI81044N/A    YABEND04E RC00E70005 AT DSNXEPP M180 CAN OCCUR IN IN A V12/V13 COEXISTENCE ENVIRONMENT.
PH462062022-06-09ModifiedUI80959UI80960YAUTOMATIC GRECP RECOVERY 014.ASUTOGREC HANG UP AFTER ABEND0C4 PIC38 IN DSNIFLAA DUE TO ZERO PAGE SET CONTROL BLOCK POINTER
PH462092022-06-06ModifiedN/A    UI80890 UNEXPECTED VALUE WHEN QUERY FROM THE PLAN TABLE
PH462122022-06-02ModifiedN/A    UI80863 ABEND04E RC00E70005 DSNXOV0:M101 MAY OCCUR FOR SQL THAT REFERENCES AN UDF THAT CONTAINS AN XMLSERIALIZE FUNCTION
PH462212022-07-19 N/A    UI81536YIN A DATA SHARING GROUP, RLF WAS STARTED UNEXPECTEDLY BY OTHER MEMBER’S NOTIFICATION WITH SCOPE LOCAL
PH462952022-06-17ModifiedN/A    UI81087YABEND04E RC00E70005 DSNXESX4 P403 CAN OCCUR FOR AN OUTER JOIN QUERY REFERENCING A LOB COLUMN WITH A SHORT INLINE LOB LENGTH
PH463122022-05-28ModifiedN/A    UI80761 SQL STATEMENT POOR PERFORMANCE DUE TO INEFFICIENT JOIN ORDER FOR SUBQUERY IF THERE ARE TWO TABLES JOIN ON UNIQUE KEY.
PH463132022-05-28ModifiedN/A    UI80762 DB2 MAY MATERIALIZE A SIDE WAY REFERENCED TABLE EXPRESSION/VIEW, WHILE JPP CAN PROVIDE BETTER PERFORMANCE.
PH463142022-06-03ModifiedN/A    UI80871YAN INCORRECT RESULT CAN BE RETURNED FROM A QUERY WITH UNION ALL THAT INCLUDES AN ORDER BY CLAUSE WITH OFFSET SPECIFIED.
PH463192022-06-29 N/A    UI81245 ABEND0C4 RC04 AT DSNXOSEP OFFSET063C8 MAY OCCUR WHEN QUERY CONTAINS CTE OR TABLE EXPRESSIONS
PH463232022-06-02ModifiedN/A    UI80849YABEND04E 00C90101 AT DSNICUMW ERQUAL 5003
PH463482022-06-03ModifiedN/A    UI80880YABEND0C4 AND STORAGE OVERLAY AFTER WILD BRANCH IN DSN9SCN9 TO INVOKE THE FRR ROUTINE DURING DISPLAY DB COMMAND EXECUTION
PH463492022-06-01ModifiedN/A    UI80818 ABEND04E 00E20018 AT DSNSLD4 DSNSTKGG OFFSET00F76
PH463682022-06-29 UI81246UI81247YAN INCORRECT RESULT CAN BE RETURNED FROM THE TIMESTAMPADD BUILT-IN FUNCTION IF THE INPUT TIME EXPRESSION HAS HOUR 24.
PH463762022-07-08 UI81376UI81377 ADDITIONAL GETPAGES WHEN A NON RESULT SET STORED PROCEDURE CALLSADDITIONAL PROGRAMS (PACKAGES) DURING EXECUTION.
PH464122022-07-12 N/A    UI81433 ABEND 04E RC00E70005 AT DSNXOBM P030 WHEN QUERY HAS A CORRELATED PREDICATE THAT COULD BE USED AS A SPARSE INDEX KEY
PH464412022-06-07ModifiedN/A    UI80916 POOR QUERY PERFORMANCE FOR QUERY REFERENCING SPECIAL REGISTER SUCH AS CURRENT TIMESTAMP, WHEN NOT REOPT(ALWAYS) OR REOPT(ONCE)
PH464872022-07-19 N/A    UI81549 ACCESS PATH IS NOT REUSED ON REBIND PACKAGE WITH APREUSE FOR TABLES WHERE EXPANSION_REASON <> ‘ ‘ IN THE PLAN TABLE
PH465642022-05-31ModifiedUI80796N/A     DB2Z AI SYSTEM ASSESSMENT (SA) MISSING INFORMATION IN SOME TABLES THAT SUPPORT SA
PH46567 NewN/A    OPEN(Y)EDM POOL ABEND04E RC00C90101 IN DSNGERBK ERQUAL 5015
PH465702022-07-22ClosedN/A    UI81635 IAG2 ABEND04E 00C90105 IN DSNIASFP ERQUAL 0CA4
PH466032022-05-31ModifiedN/A    UI80807 DB2Z AI SYSTEM ASSESSMENT (SA) MISSING INFORMATION IN SOME TABLES THAT SUPPORT SA
PH466042022-05-31ModifiedN/A    UI80813 ABEND0C4 RC38 AT DSNXOYP1 OFFSET09BF6 issued for CREATE OR REPLACE PROCEDURE
PH466182022-06-24 N/A    UI81417 PERFORMANCE ISSUE WHEN SPARSE INDEX WAS CHOSEN BUT IT SPILLS INTO PHYSICAL WORKFILE
PH466192022-06-21ModifiedN/A    UI81106 MESSAGE DSNP007I RC00D70002 ISSUED FOR WORKFILE EXTEND FAILURE ON 32K WORKFILES
PH46655  OPENOPEN(Y)WLMHEALTH IS BEING IMPROPERLY SET TO 1
PH46767  OPENOPEN DROP INDEX LEAVES ORPHAN ROWS IN SYSIBM.SYSCOLDIST
PH468752022-06-29 N/A    UI81255YCROSS LOADER (LOAD WITH INCURSOR) GETS ABENDS0C1 ABENDS0C6
PH471002022-07-18 N/A    UI81528YDB2 ABEND04E 00E2000F IN DSNSVSFB OFFSET00A6A AND DB2 CRASH MSGDSNV086E REASON 00F30801
PH471412022-08-22ClosedUI82057UI82058 PERFORMANCE ISSUE CAN OCCUR DUE TO LACK OF JOIN PREDICATE PUSH DOWN
PH471532022-07-12 UI81425UI81426 POOR QUERY PERFORMANCE MAY OCCUR FOR A QUERY THAT CONTAINS OR PREDICATE REFERENCING MULTIPLE TABLES.
PH472302022-07-07 N/A    UI81355YSQLCODE904 RC00C90084 TYPE100 FOR STATIC SQL STATMENT FROM A PACKAGE RUNNING WITH ISOLATION LEVEL RR
PH472492022-08-19ClosedUI82028UI82029 (IAG2) ABEND04E RC00C90101 AT DSNIASFP ERQUAL5001
PH472642022-07-29New & ClosedUI81719UI81720 ABEND04E 00F31100 AFTER ASSOCIATE CALL 22/07/28 PTF PECHANGE
PH473542022-08-16ClosedUI81962UI81963 THE FILTER FACTOR FOR THE IN SUBQUERY PREDICATE MIGHT BE ESTIMATED TOO HIGH SO THE INEFFICIENT INDEX MIGHT BE PICKED UP.
PH47374 NewOPENOPEN(Y)ABEND04E RC00C90101 DSNOTFLA ERQUAL5021 FOR A QUERY THAT CONTAINS AN INLINE LOB AND THERE IS A WORK FILE INVOLVED
PH47397  OPENOPEN INSERT ABEND04E RC00C90101 DSNISFPI ERQUAL5001 USING IAG2
PH476442022-07-21New & ClosedUI81608UI81609 ABEND04E RC00E70005 MIGHT HAPPEN AT DSNNQTOP M679 FOR QUERY USING XMLTABLE
PH477062022-08-17New & ClosedUI81978UI81979 ABEND04E RC00E70005 ABEND HAPPENS ON A REBIND WITH A MERGE STATEMENT WITH AN INCLUDE COLUMN
PH47795 NewOPENOPEN ABEND04E 00C90101 AT DSNK1CNE ERQUAL 5005 DURING NORMAL DB2 PROCESSING (FTB)
PH479262022-08-05New & ClosedUI81840UI81841 SQLCODE510 MAY BE ISSUED FOR AN AMBIGUOUS CURSOR WITH A COMMON TABLE EXPRESSION CTE
PH48013 NewOPENOPEN(Y)EXCESSIVE DB2 STORAGE BEING ALLOCATED BY BUFFER MANAGER IN ADMF GLOBAL CL1 POOL. THIS IS FOUND IN CSA/ECSA CAUSES OUT_OF_CSA
PH480732022-08-24New & ClosedUI82094UI82095YWHEN UPDATE SET CLAUSE CONTAINS A SCQ WITH A MINUS SIGN, AN INCORROUT OR AN ABEND (ABEND0C4 AT DSNXGDT2 OFFSET00980) MAY
PH480782022-08-29New & ClosedUI82129UI82130 FTB SIZE EXCEEDS THE VALUE OF ZPARM INDEX_MEMORY_CONTROL
PH480852022-08-17New & ClosedUI81980UI81981 ABEND04E RC00E70005 IN DSNXRITV M106 CAN OCCUR FOR A TRIGGER
PH48099 NewOPENOPEN POOR QUERY PERFORMANCE MAY OCCUR FOR A QUERY THAT COULD TAKE ADVANTAGE OF REVERSE INDEX SCAN
PH48139 NewOPENOPEN(Y)DB2 ABEND0C4-3B IN DSNWARDS OFFSET 00C5C (Caused by PH44840 UI81105)
PH48149 NewOPENOPEN DIS STATS(ITC) DOES NOT CALCULATE INDEX TRAVERSE COUNT WHEN FTB FUNCTION IS DISABLED.
PH48384 NewOPENOPEN(Y)ABEND04E RC00C90101 IN DSNGEDM.DSNGEDYI:0000 CAN OCCUR WHEN RUNNING SQL WITH DYNAMIC PLAN STABILITY ENABLED
PH48493 NewOPENOPEN ABEND04E RC00E72018 AT DSNXSING P040 MIGHT HAPPEN FOR A QUERY SATISFYING SOME CONDITIONS
PH48602 NewOPENOPEN(Y)INCORRECT OUTPUT CAN OCCUR WHEN AN EXPRESSION-BASED INDEX IS USED

If you have any comments or wishes please feel free to contact me!

TTFN,

Roy Boxwell

2022-08 IDUG Boston Review

This month is a quick run through of the z/OS presentations from the IDUG NA22 Boston – the first in-person event in three years!

It was great to actually meet and greet real people again! The only problem I had, was the extreme cold of the Hotel rooms: The expo was set to be like a freezer and, for a European person whose normal air-conditioning is an open window, it was a pretty uncomfortable experience.

If you were there physically, or even virtually, you can now download all the PDFs from all the tracks, so I have grabbed all the A, B, E Tracks and half of the F and G Tracks (Only the z/OS relevant stuff for me!)

Off we Go in Alphabetical Sequence

A01 Create value from data and where the DBA counts is an excellent overview of the modern world and where data and DBAs sit. It also contains a bunch of very nice SQL that you can indeed simply run in your shops as cut-and-paste. (I did!)
access content at IDUG.org (appropriate IDUG access required)

A02 was a very good intro into all the performance changes in Db2 12 and 13 (Check out my Db2 13 blog post as well for that matter!) and also on the hardware side with z15 and the brand new z16 box!
access content at IDUG.org (appropriate IDUG access required)

A03 & A04 were all about AI, including a bunch of example SQLs for the three new AI BiFs in Db2 13 and how to get it all working, as well as Distributed Connection control.
access content at IDUG.org (appropriate IDUG access required)
access content at IDUG.org (appropriate IDUG access required)

A05 was all about getting “value” from your Db2. Are you really using all the “newest” functionality that you could?
access content at IDUG.org (appropriate IDUG access required)

A06 from Haakon Roberts was an excellent update all around Utilities and latest APARs. The highlight being, at least for me, the ICLIMIT TAPE for REORG which finally enables easy migration to UTS PBR RPN Tablespaces. The heads up about the LOAD FORMAT DELIMITED was also good!
access content at IDUG.org (appropriate IDUG access required)

A07 concerned The Trilogy of originating SQLs and how to measure and tune them. At the end was an extra part called “Additional Tuning” that is well worth a read, as it fully explains the internal Db2 data flow from SQL to RDS to DM to Media manager.
access content at IDUG.org (appropriate IDUG access required)

A08 was all about SWAT Tales and had some great interaction! The best bit was one attendee stated that his Db2 system is going through 93 x 768 GB log datasets in less than 6 hours… The important take-away was to keep up to date with PTFs, especially HIPERs (Here you can subscribe to my monthly APAR reports to aid in this), and make sure you have enough logs! Plus, take care with high performance DBAT usage. Finally: Watch out for over- and mis-use of PBG spaces!
access content at IDUG.org (appropriate IDUG access required)

A10 was all about migrating to UTS and to Db2 12 – Do not underestimate the time and effort required to do this!
access content at IDUG.org (appropriate IDUG access required)

A11 contained details about using the RTS to work as a “monitor” enabling you to get a different view of GETPAGES for example.
access content at IDUG.org (appropriate IDUG access required)

A12 tied in with the A01 presentation and was all about Dynamic SQL problems and solutions including a nice way to “purge” single SQLs from the DSC! Included some very interesting SQLs to calculate your DSC KPIs.
access content at IDUG.org (appropriate IDUG access required)

A13 was all about configuring Data Sharing as well as solving some common issues with it. It was a great intro to everything DS. Plus, it contained a list of new and improved things that came along in Db2 12 and 13.
access content at IDUG.org (appropriate IDUG access required)

A14 was all about inactive data impacting your performance. A very interesting topic that all sites probably have an issue with without really knowing it! Archive Enabled Tables could be very useful… Towards the end were a couple of nice features in Db2 with UNION ALL.
access content at IDUG.org (appropriate IDUG access required)

A15 was a journey through TRACES, SMF and IFCIDs. If you ever wanted to know about any of these things then here’s the best starting place!
access content at IDUG.org (appropriate IDUG access required)

A16 launched Python at the DBAs and sysprogs! Scary stuff! All about installing Python on z/OS and latest bug fixes etc etc. My favorite bit was the “disable auto commit” and “remember to commit before disconnect”!
access content at IDUG.org (appropriate IDUG access required)

B-Track

B01 was all about getting prepared for Db2 13. Starting with a review of all the FLs of Db2 12 right up to FL510 which is the major prereq for Db2 13, of course!
access content at IDUG.org (appropriate IDUG access required)

B02 contained a ton of details all about the “Black hole” of Db2 statistics – Page Latch Suspensions, plus a very handy list of how to fix these suspensions – if at all possible…
access content at IDUG.org (appropriate IDUG access required)

B03 took you into the first steps of the Machine Learning (ML) world. Started off with penquins and then I got sort of lost … 🙂
access content at IDUG.org (appropriate IDUG access required)

B04 was another migration session about getting from Db2 12 FL501 to Db2 13, this time incorporating Deprecated functions and Incompatible changes etc.
access content at IDUG.org (appropriate IDUG access required)

B05 gave us four different ways to migrate away from multi-table tablespaces to PBGs. From Unload/Drop/Create/Load, MOVE TABLE (Db2 12 FL508), create “%_new” tables => INSERT from original => rename original to “%_old” => rename “%_new” to original => drop “%_old”, and lastly, using a vendor tool to do the work for you!
access content at IDUG.org (appropriate IDUG access required)

B06 was all about the pre-migration query DSNTIJPE and what you do, or don’t do, with the resulting 23 odd reports.
access content at IDUG.org (appropriate IDUG access required)

B07 showed how MasterCard monitors any and all Db2 Alerts to take proactive actions before things go pear-shaped. This includes disk space, messages, sql codes, access path changes, memory, storage, DDF, physical media limits (size, extents, volumes etc.) There is a very handy full list of “things to monitor” at the end of the presentation as well. Check out the RTDX SAX tool timings!
access content at IDUG.org (appropriate IDUG access required)

B08 Explain explained – Complete introduction as to how the Db2 Optimizer makes its cost-based decision. At the end were a couple of nice “best practices” slides summing it all up very well.
access content at IDUG.org (appropriate IDUG access required)

B10 Db2 for z/OS housekeeping. This was all about a methodology for REORG/RUNSTATS/REBIND. The interesting take away here was the idea to *never* run a RUNSTATS based soley on RTS counters from the last RUNSTATS. In other words, just do a RUNSTATS when you are doing a REORG.
access content at IDUG.org (appropriate IDUG access required)

B11 was all about client configuration and was a cross-platform presentation (naturally!) It contained all you need to know about the setup and installation and use of the db2cli among many other things!
access content at IDUG.org (appropriate IDUG access required)

B12 had Tips for DBAs and programmers to help reduce costs – Always a good topic! In here was also a nice tip about keeping up to date with your COBOL compiler!
access content at IDUG.org (appropriate IDUG access required)

B13 got secure on us by using Multi-factor Authentication for Db2 z/OS. This included setting up MFA and examples of when it works or does not work.
access content at IDUG.org (appropriate IDUG access required)

B14 carried on the security theme by going into detail about how to protect yourself from Ransomware attacks. Here multi-layer protection is the best – MFA, Pervasive encryption, Separation of duties (SECADM usage…), Controlling access to Db2 datasets etc. etc.
access content at IDUG.org (appropriate IDUG access required)

B15 came back to more “normal” territory about stopping runaway applications by using the RLF tables DSNRLSTxx and/or DSNRLMTxx, including a nice selection of examples to give you a head start.
access content at IDUG.org (appropriate IDUG access required)

B16 presented a way to use MS Excel to help in analyzing performance data. A nice introduction into getting data down to the PC and then using advanced plug-ins like ToolPak.
access content at IDUG.org (appropriate IDUG access required)

E-Track

E01 was all about the Optimizer and its various access path and resultant performance. Tons of notes all about access paths make this well worth a read!
access content at IDUG.org (appropriate IDUG access required)

E02 was a recap of Continuous Delivery, going over the why’s and how’s including vendor responses, and then ran through all the FL levels that we have so far had.
access content at IDUG.org (appropriate IDUG access required)

E03 SQL Performance for application developers was an introduction, with examples, about what an application developer should know about SQL at a minimum!
access content at IDUG.org (appropriate IDUG access required)

E04 was one of my presentations all about esoteric Db2 functions – Db2 stuff that is rarely used or not well understood. Covering FIT/FTB, Spatial Indexes, REGEX, Clones and scrollable cursors. All good fun!
access content at IDUG.org (appropriate IDUG access required)

E05 was all about IBM Db2 Developer Extension and Db2 Administration Foundation – Obviously the live demos are missing but it gives you a good idea!
access content at IDUG.org (appropriate IDUG access required)

E06 Advanced Db2 Performance Tuning for Beginners – the title says it all. Six objectives done great by Joe – It covered both LUW and z/OS and contained a “Steps to Solve the Crime” section.
access content at IDUG.org (appropriate IDUG access required)

E07 was a run through of all good stuff we got in Db2 12 including comparisons between 11 and 12 and an introduction to RESTful calls.
access content at IDUG.org (appropriate IDUG access required)

E08 was a plea for testing. How to generate test data and how to actually test and measure. Included examples of PLSQL to generate test data, and proposes the mantra to Measure and Monitor what you are doing and what you have done.
access content at IDUG.org (appropriate IDUG access required)

E10 was another one of my presentations where I go into detail about all currently deprecated features of Db2 12 and 13. It gave pages of SQL that you can use to check your own Db2 subsystem, or you can download our freeware MHC2 Migration HealthCheck program that does it all for you. (This is continually updated whenever anything new is deprecated, by the way!)
access content at IDUG.org (appropriate IDUG access required)

E11 all about “Things your DBAs hear”. A very good, light-hearted look at the “normal craziness” of being a DBA these days!
access content at IDUG.org (appropriate IDUG access required)

E12 A DBA’s epic journey covered how to deal with SLOW SQL and then the taming of four common SQL “problem statements”.
access content at IDUG.org (appropriate IDUG access required)

E13 was a very apt Session code! All about the usage and requirement of RECOVER these days. It covered why you should be able to do it and preparing for it as it will be required at some time…
access content at IDUG.org (appropriate IDUG access required)

E14 was a modernization call for Db2 stored procedures and RESTful services. Examples were included as well as Hints & Tips especially around DSNULI, Parameters and File usage of existing stored procs.
access content at IDUG.org (appropriate IDUG access required)

E15 covered how to fall back from a schema change as quickly as possible! Use of high speed flash copies to a clone show you a way to handle this.
access content at IDUG.org (appropriate IDUG access required)

E16 An overview of a “true” HTAP system. This showed how using an accelerator processing the logs you can indeed get to the Holy Grail of Transactional and Analytical processing happening at the same time on the same data.
access content at IDUG.org (appropriate IDUG access required)

F-Track

F01 was all about JAVA performance – and we all need better JAVA performance these days! Kudos for the callouts on Spring Batch and Hibernate.
access content at IDUG.org (appropriate IDUG access required)

F04 Back to basics with Db2 Buffer Pools – Covered everything you would ever need to know about Db2 Buffer Pools! Set-up, Monitor, Configure and Tune.
access content at IDUG.org (appropriate IDUG access required)

F06 explained the use of Indexes, how they look internally and all about performance, including when to REORG them at the optimal moment.
access content at IDUG.org (appropriate IDUG access required)

F07 SQL went crazy using Pivot and Transpose, some for z/OS some for LUW – a real smorgasbord of SQLs!
access content at IDUG.org (appropriate IDUG access required)

F11 contained a ton of detail about connecting Clients to Servers which is not quite as straightforward as some people think…
access content at IDUG.org (appropriate IDUG access required)

F12 Ran through the Db2 Catalog and Directory as it was, as it is and how to migrate to Db2 13.
access content at IDUG.org (appropriate IDUG access required)

F13 covered how to use the TRACE facility of Db2 including all the information you could ever want to know about which Trace is which class is which IFCID…
access content at IDUG.org (appropriate IDUG access required)

F14 was all about the perennial problem of Db2 logging and Commit frequency including full information about what is logged, what is written in the BSDS and adding/removing Active Logs.
access content at IDUG.org (appropriate IDUG access required)

F16 was DSC (Dynamic Statement Cache) usage, how it actually works, how to improve it and a quick glimpse into using the IDAA (Accelerator).
access content at IDUG.org (appropriate IDUG access required)

G-Track

G02 discussed the requirement for a Next Generation DBA. Having fewer people with the skills drives the demand for AI to help out.
access content at IDUG.org (appropriate IDUG access required)

G03 was very interesting as it was all about setting up Encryption through the SECPORT which is becoming standard these days. Full of configuration Hints & Tips. Also contained a full example of running NETSTAT and loading the output up into a Db2 table every few minutes so you can analyze who is accessing using just the TCPPORT – Heaven!
access content at IDUG.org (appropriate IDUG access required)

G05 AI again but this time protecting your systems from bad DBAT problems.
access content at IDUG.org (appropriate IDUG access required)

G06 Running through old Db2 releases up to current with special regard to the problem of RECOVERY and availability as they have changed over the years.
access content at IDUG.org (appropriate IDUG access required)

G12 went into depth about cutting back-up costs by using a hybrid-cloud multi-temperature storage system. Using Db2 for z/OS Data Gate delivered through IBM Cloud Pak for Data enables all of this. The big idea here, was to take your rarely used archive data and move it into the cloud.
access content at IDUG.org (appropriate IDUG access required)

G13 brought up the use of Redirected Recovery to ease your fears of recovery. You can simply validate, with no system interruptions of any kind, whether or not you are indeed even recoverable and, most importantly, how long it really takes.
access content at IDUG.org (appropriate IDUG access required)

G14 went into the IBM Cloud Pak world again, this time with virtualization being the main theme. The fact that the data lake has “dried up” due to various problems (GDPR being amongst them!) leads to virtualization being the way forward. DaaS – Data as a Service.
access content at IDUG.org (appropriate IDUG access required)

G16 and finally… we get to the last one, and it is a *very* big one all about Db2 Security Best Practices from David Beulke. An absolute treasure trove of Do’s and Do Not’s all related to the world of Audit. Our WLX Audit also gets a shout out so well done for that!
access content at IDUG.org (appropriate IDUG access required)

Summary

All in all it was a vast amount of information to try and take-in. IDUGs are always places of learning and I always learn stuff – I am now really looking forward to the IDUG EMEA 2022 in Edinburgh coming up from October the 22nd through to the 26th.

I hope to see you there!

TTFN,

Roy Boxwell

2022-07 IBM problem data requests…

Most of us have been there … something somewhere goes wrong … things are checked, changes are undone, tests are re-run and in the end you have no idea why a failure happens.

Who You Gonna Call?

Yep, it is time to open a Case at IBM technical support … So you open a Case and you type in as much detail as possible about when and what happened but it is *never* enough! In the world of Db2, the first question that *always* comes back is “Please supply us with further information”, like:

  • SYSLOG
  • Master Log
  • MEPL
  • Detailed EREP
  • Complete SVC dump

WTF? (“What’s That For” before anyone complains)

SYSLOG

The syslog is the console of a z/OS system and any and all interesting, and sometimes not so interesting, messages from *all* running “things” are in here – it is normally enormous! The problem begins when IBM Technical Support asks “please provide us with the SYSLOG from 06:00 to 06:30 on the day of the event”.

SDSF

SDSF is your friend here and I really mean it! All you do is go to SDSF and then enter primary command LOG. From this panel you enter three primary commands, one after another, and you are done!

  • PT ODSN ‘your.dataset.name’ * NEW
  • PT 06.00.00 22/06/2022 06.30.00 22/06/2022
  • PT CLOSE

That is it! Your dataset will then just have the data from between those times. This is *extremely* handy! Note that the date format is locale-dependent and, as I am in Europe, we have DD/MM/YYYY. I am sure you know your own date format!

Master LOG

This is the first SDSF dataset in your ssidMSTR STC. So, once more in SDSF, using *MSTR as a prefix and then putting line command ? next to the sub-system in question shows you three DDNAMEs. The first one, JESMSGLG, is the one they normally need. Here you use line command XDC to get an SDSF Open Print Data Set window:

xxxxMSTR STC09394           SDSF Open Print Data Set                         
COMMAND INPUT ===>                                         SCROLL ===> CSR
                                                                             
                                                                             
Data set name  ===> 'xxxxxxx.SYSLOG.PRINT'                                   
Member to use  ===>                                                          
Disposition    ===> NEW        (OLD, NEW, SHR, MOD)                          
                                                                             
Management class     ===>           (Blank for default management class)     
Storage class        ===>           (Blank for default storage class)        
  Volume serial      ===>           (Blank for authorized default volume)    
  Device type        ===>           (Generic unit or device address)         
Data class           ===>           (Blank for default data class)           
  Space units        ===> CYLS      (BLKS, TRKS, CYLS, BY, KB, or MB)        
  Primary quantity   ===> 19        (In above units)                         
  Secondary quantity ===> 19        (In above units)                         
  Directory blocks   ===>           (Zero for sequential data set)           
  Record format      ===> FBA                                                
  Record length      ===> 121                                                
  Block size         ===>                                                    
Data set name type   ===>           (LIBRARY, blank, ... See Help for more)  
Extended attributes  ===>           (NO, OPT, or blank)                      

Here you can see I choose type FBA, LRECL 121 and a disposition of NEW for a new dataset. Hit ENTER and SDSF tells you how many lines it just wrote to that file:

PRINT CLOSED  23025 LINE

View the file and max down to the bottom:

023019 0------ JES2 JOB STATISTICS ------        
023020 -  17 MAY 2022 JOB EXECUTION DATE         
023021 -            2 CARDS READ                 
023022 -       28,616 SYSOUT PRINT RECORDS       
023023 -            0 SYSOUT PUNCH RECORDS       
023024 -        3,099 SYSOUT SPOOL KBYTES        
023025 -    50,488.70 MINUTES EXECUTION TIME     

So we know we are in the correct file! Here you can do some updating of “sensitive” data like IP address, User Name etc. Remember to just change the data, not blindly delete it! Naturally, you can delete stuff *after* the event of interest and probably a ton of stuff from *before* but be careful what you delete!

MEPL

Say what? MEPL is the Module Entry Point List and IBM need it to see which PTFs and APARs have been applied in the application address space and the Db2 system. To get a MEPL I use a normal Utility job jcl with DIAGNOSE and a DISPLAY MEPL like this:

//MEPL     EXEC PGM=DSNUTILB,REGION=32M,       
//         PARM=(ssss,'DIAGNOSEMEPL')          
//STEPLIB  DD DISP=SHR,DSN=DSNsss.SDSNEXIT.ssss
//         DD DISP=SHR,DSN=DSNsss.SDSNLOAD     
//CEEDUMP  DD SYSOUT=*                         
//SYSUDUMP DD SYSOUT=*                         
//SYSPRINT DD SYSOUT=*                         
//SYSIN    DD *                                
 DIAGNOSE                                      
    DISPLAY MEPL                               
 DIAGNOSE END                                  
/*                                             

This will output the MEPL to SYSPRINT which starts like this:

DSNU000I    173 12:57:08.82 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = DIAGNOSEMEPL                               
DSNU1044I   173 12:57:08.83 DSNUGTIS - PROCESSING SYSIN AS EBCDIC                                                      
DSNU050I    173 12:57:08.83 DSNUGUTC -  DIAGNOSE DISPLAY MEPL                                                          
DSNU861I    173 12:57:08.84 DSNUDIAG - DISPLAY MEPL FOR SUBSYSTEM xxxx                                                 
    0000 20B92820 C2C5D7D3 0140D4C5 D7D360D3  C9D2C540 C6D6D940 C4E2D5E4 E3C9D3C2    *....BEPL. MEPL-LIKE FOR DSNUTILB*
    0020 28100000 C4E2D5C1 C1404040 F0F761F1  F461F1F6 E4C9F3F9 F3F9F340 00000000    *....DSNAA   07/14/16UI39393 ....*
    0040 28100100 C4E2D5C1 D7D9C840 F1F261F2  F361F1F5 F1F34BF4 F6404040 00000000    *....DSNAPRH 12/23/1513.46   ....*
    0060 28100200 C4E2D5C6 D4D5C6D4 F1F061F1  F761F1F8 E4C9F5F8 F8F4F040 00000000    *....DSNFMNFM10/17/18UI58840 ....*
    0080 28100240 C4E2D5C6 D7D4E2C7 F1F061F1  F761F1F8 E4C9F5F8 F8F4F040 00000000    *... DSNFPMSG10/17/18UI58840 ....*
.
.
.

It is quite long! Here in my test system nearly 5000 lines are written to SYSPRINT. Then, like with the ssidMSTR, I use ? against the job and then XDC against the SYSPRINT DD card this time to create another file with type FBA and LRECL 133 to get your.mepl.list.

Detailed EREP

Now it gets interesting… The EREP (Environmental Record Editing and Printing Program) is the API to the system LOGREC dataset where all “events of interest” on a z/OS LPAR are recorded. It contains far less than the console log but is a treasure trove of data for the IBM Technical Support.

Here’s my job to simply do a Detailed EREP as per IBM standards:

//*------------------------------------------------------------------*/
//*  EREP: DETAILED REP PRINT                                        */
//*------------------------------------------------------------------*/
//EREP     EXEC PGM=IFCEREP1,PARM='CARD'                               
//SERLOG   DD DISP=SHR,DSN=xxxxxxxx.LOGREC                            
//DIRECTWK DD DISP=(NEW,DELETE),UNIT=SYSDA,SPACE=(CYL,(50,50))         
//EREPPT   DD SYSOUT=*,DCB=BLKSIZE=133                                 
//TOURIST  DD SYSOUT=*,DCB=BLKSIZE=133                                 
//SYSIN    DD *                                                        
ACC=N                                                                  
HIST=N                                                                 
ZERO=N                                                                 
PRINT=PS                                                               
TYPE=S                                                                 
/*                                                                     
//* IF REQUIRED YOU CAN ADD DATE, TIME RANGES TO FILTER DOWN           
//* WITHIN THE SYSIN LIKE:                                             
//* DATE=(YYDDD,YYDDD)                                                 
//* TIME=(HHMM-HHMM)                                                   

Do not forget to give your LOGREC DSN for the SERLOG DD. Most of the time I get just a few rows of output and then create another file using XDC from the EREPPT DD name but this time with type FB and LRECL 133 to get the.erep.list

Complete SVC Dump

If your Db2 system receives a dump, for whatever reason, it normally writes out an SVC dump to a special dataset that can be used to analyze what went wrong. It is very important that the SVC dump is complete and *not* partial …

Default Size

The default size is only 500MB which is way too small for a halfway decent production Db2 sub-system these days. It must normally be increased to at least 16000MB. To change this you issue a console command like:

CHNGDUMP SET,SDUMP,MAXSPACE=16000M

But make sure you have enough local page datasets space to handle your normal load PLUS the size of this dump dataset…auxilliary swapping (paging) while dumping is a painfully slow experience you do not want to suffer!

If successful, the SVC dump will be COMPLETE and then you are nearly done …

File Transfer

Most of the files I have described so far are quite small but the SVC dump is a monster. You must TERSE it using JCL like:

//AMATERSE  EXEC PGM=AMATERSE,PARM='SPACK'
//SYSPRINT  DD SYSOUT=*                   
//SYSUT1    DD DISP=SHR,                  
//             DSN=xxxxxxxx.xxxxxxxx       
//SYSUT2    DD DISP=(,CATLG),UNIT=SYSDA,             
//             DSN=xxxxxxxx.xxxxxxxx.TRS,  
//             SPACE=(CYL,(99,99),RLSE)   

I use the SPACK parameter which is, according to the documentation, much better at compression than the PACK parameter. Fun factoid of the day: SPACK is the “complex” format whereas PACK is the “simple” format – Gotta love IBM for that! IBM do prefer the TERSE style of compression, and please do *not* change the file ending! Then doing a ZIP has no real bonus and just confuses the automatic systems at IBM. Leave “.TRS” at the end and they know it has been TERSED.

Then download the xxxxx.xxxxx.TRS file as BINARY to the PC and all the other files as TEXT to the PC. Then simply upload by drag-and-drop to your IBM Case and you are ready for the next question!

Have you Switched it Off and On again?

I wish I never hear this about a mainframe Db2 problem!

I hope this was of some interest, and if you have any other Tips & Tricks about getting “standard” data to IBM, I would love to hear from you!

TTFN

Roy Boxwell

2022-06 Apollo 13 has landed!

Yes, I admit it, I was surprised that IBM actually called it Db2 13 for z/OS in the end. I know IMS also had a 13 release but I still believed they would jump to 14! After all Apollo 13 was a disaster, albeit with a happy ending caused by a whole bunch of engineers working really well with the hardware and the design. I guess that was the reason for the “Apollo” code name of this release of Db2. Anyways, on to my review of all things new and interesting in Db2 13.

What’ve We Got?

The most important bit is that you *must* be on Db2 12 FL510 to even think about getting to Db2 13. This is done to make the migration as easy as possible with no gotcha’s happening along the way!

System Check First!

Remember that automatic rebind will occur for any packages created before Db2 11. This should not happen but is never a good idea in production! Further, a whole bunch of ZPARMs have been removed and so you must check to see if you set these differently than default, if so then check what will happen in your shop with the “new” values. Here’s a direct link to the docu all about new, changed and deprecated ZPARMs: https://www.ibm.com/docs/en/db2-for-zos/13?topic=13-subsystem-parameter-changes-in-db2

FL100 Hits

FL100 allows you to fallback to Db2 12 FL510 and also permits co-existence in data-sharing. This enables 24×7 availability as you go round-robin with the load libraries and bounce your Db2 members.

What Else do You get at FL100?

Index look-aside optimizations are there for INSERT, UPDATE and DELETE.

Sort

It gets seriously enhanced:

  • the ability to generate machine code enabling DECFLOAT
  • if you use grouping set, multiple distincts and PERCENTILE you also get generated machine code
  • Sort can use its very own workfile
  • larger sort tree size
  • a check for ordered data on first iteration
  • LISTAGG gets SUBSTR support
  • Ability to avoid rereading a workfile, but only if Watson Machine learning is enabled
  • Shrinking the length of long varchars (over 100 bytes), again only if Watson Machine learning is enabled
  • z15 expanded support of SORTL, this also requires Watson Machine learning to be enabled

PBG Insert

The insert mechanism for PBGs got a nice update to drive a retry if the partition lock fails on the first insert attempt. This could well stop excessive growth of PBGs with heavy insert activity.

Below-the-Bar (BTB) Reduced and Above-the-Bar (ATB) Enhanced

As in all releases of Db2, the amount of BTB storage has been reduced primarily by reducing the agent BTB storage to use ATB storage instead. This applies to dynamic SQL statement text and attribute strings. When BTB storage exceeds 64% Db2 will automatically trigger a storage contraction of all private storage pools. Further, if you are at z/OS 2.5 you can use a new dynamic allocation function by updating the ALLOCxx parmlib member and set the SYSTEM SWBSTORAGE to ATB. This reduces the overhead per open dataset from 5KB down to 4KB. It might not sound much but when you have 200,000 open datasets it all adds up! The ATB storage clean-up also got improved to stop the usage of the IARV64 REQUEST(DISCARDDATA) during thread deallocation. Now a system level timer is used to trigger these clean-ups.

ECSA Reduced

For IFI users the ECSA usage has also been reduced from 50MB down to 8MB, however, you must make sure that you set aside around 50MB in HVCOMMON and 25MB for private storage to compensate for this. There is no such thing as a free lunch after all! The DDF per thread ECSA is now down to be the same as a local thread whereas before it was always 2KB more for a remote than a local thread. When the ECSA exceeds 85% Db2 will automatically trigger a storage contraction of all allocated pools within the ECSA.

DBAT Optimizations

These reduce the frequency and number of terminations and also flatten the spike when a surge of short-term DBATs increase usage quickly.

External Security Improvements

Db2 13 now caches the plan authorization checks as long as you have z/OS 2.5 and zparm AUTHEXIT_CACHEREFRESH set to ALL. At the same time, more IDs per plan are now cached.

Enhance RECOVERY Feature

RECOVER is enhanced so that it can use TP/IP level copies when a DSNUM ALL recover is requested. Pre-requisite is that it is only allowed on objects that are based on a UTS. Previously, RECOVER required a TS/IX level Image Copy to process this. Now it will check to see if it can do the RECOVER based upon the TP/IP copies that have been done.

FL500 Hits

AI

Artificial Intelligence finally comes to Db2 for z/OS with SQL data insights. These give cognitive intelligence to Built-in-Functions and can be used in SQL queries. More on these new functions later!

Role-Based Package Ownership

This completes the ability to use Trusted Context which assigns a ROLE to an inbound connection. It can now use this role as the package owner.

Utility Changes

Page sampling is now allowed for inline statistics. Within a REORG TABLESPACE or a LOAD utility you can now use page sampling (Like you can within RUNSTATS). Before this, only row sampling was allowed and page sampling can give a much bigger saving in CPU and elapsed time.

Online Conversion from PBG to PBR

As long as you have some sort of usable partitioning key you can now use ALTER to migrate from PBGs, which are getting very big and unwieldy, to the new and much better PBR RPN type UTS spaces. After the ALTER, a REORG simply completes the migration.

FTB Expanded

Unique index maximum size for FTB is now raised up to 128 bytes and for duplicate indexes up to 120 bytes. This greatly increases the possible scope of FTB usage.

Lock Timeout Controls

CURRENT LOCK TIMEOUT special register can be used to change the TIMEOUT by the application or even the SQL Statement. This can help reduce lock contention.

Profile Updates

The profile table can now be used for local threads as long as DDF is started with AUTO or COMMAND. These tables can now also contain CURRENT LOCK TIMEOUT and also the RELEASE_PACKAGE keyword with one of the COMMIT attributes.

Active LOG Delete

You can now delete an active log while Db2 is running, using the new REMOVELOG option from the -SET LOG command without having to stop and start D2b afterwards. This is very handy when you wish to resize all of your active logs!

How fast? – Very fast!

The first “real” FL version 500 has *no* catalog changes! This simplifies migration again as there is no “real” CATMAINT. There is still a CATMAINT job but it just sets internal flags and does *not* do any changes to the Catalog.

FL501 Hits

Deadlock Priority

New built-in global variable SYSIBMADM.DEADLOCK_RESOLUTION_PRIORITY gives you the ability to set your relative weighting about “who should die” when a deadlock is detected. This is also added to the profile tables by the way.

Catalog Changes!

One duplicate catalog index is, finally, dropped and the brand new SYSIBM.SYSUTILITIES table is created and will start to be INSERTed into, more about this table later! Some of the real-time statistics (RTS) statistical columns got uprated from INTEGER to BIGINT or SMALLINT to INTEGER. This helps for really big shops where the RTS numbers just maxxed out all the time! Further, lock escalation is disabled on all RTS and RTS History tables.

Index Splits

The RTS also got three new columns in the SYSINDEXSPACESTATS table:

  • REORGTOTALSPLITS – How many index splits since last REORG
  • REORGSPLITTIME – Aggregated elapsed time for all index splits since last REORG
  • REORGEXCSPLITS – Number of abnormally long (over one second) index splits since last REORG

All of these columns give good data about your index structures and possible changes to their definitions.

AI BiFs

We get three new Built-in Functions in Db2 13 FL500:

  • AI_ANALOGY – Computes an analogy score between two values
  • AI_SEMANTIC_CLUSTER – Computes a semantic clustering score of a member argument against a set of clustering arguments
  • AI_SIMILARITY – Computes a similarity score between two values

In fact, these are the *only* BiF changes in Db2 13 up to FL501! I will not go into detail about how they work here but there is a bit of work that must be done “behind the scenes” to get these beasts working… again – no such thing as a free lunch!

SYSIBM.SYSUTILITIES

Is a very interesting catalog table that contains a list of all Utilities that have run on the machine. It is updateable by anyone with the necessary rights so I recommend at least a yearly purge or it could grow to crazy sizes… The first support is pretty basic, just EVENTID, NAME, JOBNAME, UTILID, USERID, STARTTS, ENDTS, ELAPSEDTIME, CPUTIME, ZIIPTIME, RETURNCODE, CONDITION: Blank – Active or stopped utility, E – Execution has ended, F – Execution terminated by -STA db(x) sp(x) ACCESS(FORCE) or T – Execution terminated by -TERM UTILITY, RESTART: N – not restarted, Y – restarted, NUMOBJECTS, LISTNAME, STARTLOGPOINT: RBA for non-data-sharing or LRSN for data-sharing, GROUP_MEMBER, SORTNAME, SORTCPUTIME and SORTZIIPTIME. All of the other columns are “for future use” but with those columns that are filled you can do some interesting Utility analysis! The interesting factoid about this table is that all the time columns were originally planned as being CHAR(8)… Thankfully IBM decided to change them to BIGINT columns containing microseconds thus making the table actually usable!

Getting there…

Of course you have to get to Db2 13 before you can start using all the stuff I have just been discussing. To make sure you get there as quickly and painlessly as possible, why not download our Migration HealthCheck software? It is free-of-charge, with licenced extensions, software that lists out the “state” of your Db2. This includes all the prereqs for Db2 12 FL510 which must be reached before going to Db2 13 FL100 as well as all other deprecated features!

Any Plans?

What are your plans for going to Db2 13? I would be delighted to hear from you!

TTFN

Roy Boxwell

Update: One of my valued readers asked me if I could check whether or not LISTAGG accepts ORDER BY or not in Db2 13. Sadly I can confirm that only SUBSTR was added. ORDER BY still dies a death with an SQLCODE -390. My reader had even opened an AHA Idea request for this support, which I also voted for by the way, but it was rejected by Db2 support. The question that both of us have is “Why not?” What is so hard about adding sort support? My personal theory is that, internally, it uses a LOB style object format which is not sortable, but why not just tell us? In Boston I will ask around…

2022-05 Let’s get hashed

This month I will delve into the wonderful new field QUERY_HASH in the SYSIBM.SYSPACKSTMT Db2 Catalog table.

Isn’t it Old?

The QUERY_HASH column first appeared back in the Db2 11 tables SYSQUERY and DSN_STATEMENT_CACHE_TABLE where it is used to identify dynamic SQL and enable joining between these two tables.

Now it Gets Interesting

In Db2 12 it was added throughout the Catalog to tables SYSDYNQRY, SYSPACKSTMT and DSN_STATEMNT_TABLE, thus adding the availability to Static SQL as well as finishing the Dynamic SQL support.

For Static SQL the column is actually very interesting. I will now show you a list of little queries that you can use to see what it is and how to use it at your site.

First up: Baseline

How many static SQL statements do you have in the Db2 catalog at this moment?

SELECT COUNT(*)
FROM SYSIBM.SYSPACKSTMT A
FOR FETCH ONLY
WITH UR
;

Gives me:

---------+---------+---------+---------+---------+---------+
324675
DSNE610I NUMBER OF ROWS DISPLAYED IS 1
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100

0 = 0 = 0 ?

But that includes the “dummy” stuff in all packages, so let’s rerun with a better predicate:

SELECT COUNT(*)
FROM SYSIBM.SYSPACKSTMT A
WHERE NOT (A.SEQNO  = 0
       AND A.STMTNO = 0
       AND A.SECTNO = 0)
FOR FETCH ONLY
WITH UR
;

Which shows my true list of actual SQLs:

---------+---------+---------+---------+---------+---------
319015
DSNE610I NUMBER OF ROWS DISPLAYED IS 1
DSNE616I STATEMENT EXECUTION WAS SUCCESSFUL, SQLCODE IS 100

So how many different hashes do I have?

SELECT COUNT(*)
     , HEX(A.QUERY_HASH) AS QUERY_HASH
FROM SYSIBM.SYSPACKSTMT A
WHERE NOT (A.SEQNO  = 0 
       AND A.STMTNO = 0 
       AND A.SECTNO = 0)
GROUP BY A.QUERY_HASH
ORDER BY 1 DESC
FETCH FIRST 100 ROWS ONLY
FOR FETCH ONLY
WITH UR
;

Gives me:

---------+---------+---------+---------+-----
      QUERY_HASH
---------+---------+---------+---------+-----
73671 00000000000000000000000000000000
27228 40404040404040404040404040404040
12161 00000000000000000000000025B72000
 9821 40C7C5D7C9E240404040404040404040
 7372 00000000000000000000000024CC5000
 5989 000000000000000000000000257CD000
 5324 000000000000000000000000257CB000
 4530 40404070580000800000000000000000
 4265 1372041862047A61177D116D03002220
 4033 00000000000000000000000024E2F000
 3791 000000000000000000000000257EB000
 3114 27B830EAC5C4D44040C7C5D7C9E24040
 3089 7A69031C0174677E6844533C59555533
 2881 7B7F67796A17051E04077C027E142055
 2690 1473780D166A031F575A2F432047382F
 2446 6C166B000A6E13186161751F1A255340
 2264 6D760D7A75066A7A111A691E62592154
 2248 27B8353AC5C4D44040C7C5D7C9E24040
 2098 000000000000000000000000257BA000

Now I was a bit worried about all the low-values and all the 4040 entries but thought “The low-values are probably not bound or not executable or some such.” The spaces were more worrying! Then I noticed the rows with lots of leading zeroes…

Details, Details…

At this point I thought we needed to break down the SQLs between true “real” SQLs and “fake” ones – FETCH, OPEN, CLOSE, SET etc. which are not EXPLAINable. So I added the EXPLAINABLE column to the select to see if I was right:

SELECT COUNT(*)
     , A.EXPLAINABLE
     , HEX(A.QUERY_HASH) AS QUERY_HASH
FROM SYSIBM.SYSPACKSTMT A
WHERE NOT (A.SEQNO  = 0 
       AND A.STMTNO = 0 
       AND A.SECTNO = 0)
GROUP BY A.EXPLAINABLE, A.QUERY_HASH
ORDER BY 1 DESC, 2
FETCH FIRST 100 ROWS ONLY
FOR FETCH ONLY
WITH UR
;

Gives me:

---------+---------+---------+---------+---------+--------
      EXPLAINABLE QUERY_HASH
---------+---------+---------+---------+---------+--------
73485 N           00000000000000000000000000000000
27228 N           40404040404040404040404040404040
12161 N           00000000000000000000000025B72000
 9821 N           40C7C5D7C9E240404040404040404040
 7372 N           00000000000000000000000024CC5000
 5989 N           000000000000000000000000257CD000
 5324 N           000000000000000000000000257CB000
 4530 N           40404070580000800000000000000000
 4055 N           1372041862047A61177D116D03002220
 4033 N           00000000000000000000000024E2F000
 3791 N           000000000000000000000000257EB000

Aha! So I guessed right all these, well over a third of *all* SQLs are not actually explainable and so a QUERY_HASH would be a little bit pointless.

Getting There…

So, now I added a predicate to remove all those:

SELECT COUNT(*)
     , A.EXPLAINABLE
     , HEX(A.QUERY_HASH) AS QUERY_HASH
FROM SYSIBM.SYSPACKSTMT A
WHERE NOT (A.SEQNO  = 0 
       AND A.STMTNO = 0 
       AND A.SECTNO = 0)
  AND NOT A.EXPLAINABLE = 'N'
GROUP BY A.EXPLAINABLE, A.QUERY_HASH
ORDER BY 1 DESC, 2
FETCH FIRST 100 ROWS ONLY
FOR FETCH ONLY
WITH UR
;

Which gives me much better data:

---------+---------+---------+---------+---------+--------
    EXPLAINABLE QUERY_HASH
---------+---------+---------+---------+---------+--------
372 Y           6014030D641C1325583D214B504C3750
372 Y           3E4E5C30101603600A60620574076268
312 Y           70106E0C106E150F7274790C53255340
307 Y           49335C5B4A1C6B6276101914001D6D73
248 Y           53473E64001574120C191862767E1360

Enhanced It All!

Then I enhanced the query to now join back to the SYSPACKAGE and show me columns of interest from there, especially TYPE as I had a suspicion!

SELECT A.COLLID, A.NAME, A.CONTOKEN, A.TIMESTAMP
      ,A.BINDTIME, A.VALID, A.OPERATIVE, A.LASTUSED
      ,A.TYPE, B.STATUS, B.EXPLAINABLE, B.STATEMENT
FROM SYSIBM.SYSPACKAGE  A
    ,SYSIBM.SYSPACKSTMT B
WHERE NOT (B.SEQNO  = 0 
       AND B.STMTNO = 0 
       AND B.SECTNO = 0)
  AND     A.LOCATION    = ''
  AND     A.LOCATION    = B.LOCATION
  AND     A.COLLID      = B.COLLID
  AND     A.NAME        = B.NAME
  AND     A.CONTOKEN    = B.CONTOKEN
  AND     B.QUERY_HASH  = X'00000000000000000000000000000000'
  AND NOT B.EXPLAINABLE = 'N'
ORDER BY 2 , 1
FOR FETCH ONLY
WITH UR
;

Not my TYPE

Scrolling right to the TYPE column:

----+---------+---------+---------+---------+---------+---------+----
VALID OPERATIVE LASTUSED   TYPE STATUS EXPLAINABLE STATEMENT
----+---------+---------+---------+---------+---------+---------+----
Y     Y         2021-12-23      C      Y      DECLARE DB2JCCCURSOR8 C
Y     Y         0001-01-01      H      Y      DECLARE DB2JCCCURSOR1 C
Y     Y         0001-01-01      C      Y      DECLARE DB2JCCCURSOR3 C
Y     Y         2016-09-02 1
Y     Y         2016-09-02 1
Y     Y         2016-09-02 1
Y     Y         0001-01-01 1
Y     Y         0001-01-01 1
Y     Y         2022-05-12 N
Y     Y         2022-05-12 N
Y     Y         0001-01-01 T
Y     Y         0001-01-01 T

Aha! Advanced Triggers (1) , Procedures (N) and Normal Triggers (T). Functions(F) would also be there. There’s a Gotcha here, too: RESTful Services identify themselves like a normal package but with HOSTLANG=’R’, yet they do not have a usable Hash. So now remove all of these from the picture like this:

SELECT A.COLLID, A.NAME, A.CONTOKEN, A.TIMESTAMP
      ,A.BINDTIME, A.VALID, A.OPERATIVE, A.LASTUSED
      ,HEX(B.QUERY_HASH) AS QUERY_HASH
      ,B.STATUS, B.STATEMENT
FROM SYSIBM.SYSPACKAGE  A
    ,SYSIBM.SYSPACKSTMT B
WHERE NOT (B.SEQNO  = 0 
       AND B.STMTNO = 0 
       AND B.SECTNO = 0)
  AND A.LOCATION    = ''
  AND A.LOCATION    = B.LOCATION
  AND A.COLLID      = B.COLLID
  AND A.NAME        = B.NAME
  AND A.CONTOKEN    = B.CONTOKEN
  AND A.TYPE        = ' ' -- ONLY REAL PACKAGES
  AND B.EXPLAINABLE = 'Y' -- ONLY EXPLAINABLE SQL
  AND NOT B.HOSTLANG = 'R' -- NO RESTFUL SERVICES 
ORDER BY 2 , 1
FETCH FIRST 100 ROWS ONLY
FOR FETCH ONLY
WITH UR
;

Now I get the real data out:

---------+---------+---------+---------+---------+---------+---------
COLLID     NAME    CONTOKEN TIMESTAMP
---------+---------+---------+---------+---------+---------+---------
PTFCOLL008 ADMDMEM +oæ (p8  2021-10-08-12.40.14.562716
PTFCOLL008 ADMDMEM +oæ (p8  2021-10-08-12.40.14.562716
PTFCOLL008 BUILDS  ?À ã     2016-12-28-08.50.58.486446
PTFCOLL008 CLEAN   â­â  r4   2016-12-28-08.50.59.911739
PTFCOLL008 CLEAN   â­â  r4   2016-12-28-08.50.59.911739
-+---------+---------+---------+---------+--
BINDTIME                   VALID OPERATIVE
-+---------+---------+---------+---------+--
2022-01-20-15.26.20.128052 Y     Y
2022-01-20-15.26.20.128052 Y     Y
2022-01-20-15.26.20.533383 Y     Y
2022-01-20-15.26.20.639940 Y     Y
2022-01-20-15.26.20.639940 Y     Y
-----+---------+---------+---------+---------+------
LASTUSED   QUERY_HASH                       STATUS
-----+---------+---------+---------+---------+------
2022-03-21 48534A5F7A741F0E75131067686F066A C
2022-03-21 585850457A760F066F091067686F0668 C
2022-02-18 6A0A777E720B7B671E703E40232C584B C
0001-01-01 59283E494E332341514B37572A29376F C
0001-01-01 6F051C041E1C136A0024374B293F3742 C
--------+---------+---------+---------+---------+---
STATEMENT
--------+---------+---------+---------+---------+---
DECLARE PTFTOOL-02 CURSOR FOR SELECT A . PMEMBERNAME
DECLARE PTFTOOL-01 CURSOR FOR SELECT A . PMEMBERNAME
DECLARE GET-MEMBER CURSOR FOR SELECT A . RMEMBERNAME
DECLARE PTFTOOL-02 CURSOR FOR SELECT D . PTFNO , D .
DECLARE PTFTOOL-01 CURSOR WITH HOLD FOR SELECT D . P

Finally, I get my “real” useful HASH data with text.

And Now?

So what can you do with the QUERY_HASH? One simple thing is to just use it to pull out all the duplicate (see note below!) SQLs that you have in different collections or packages:

SELECT A.COLLID, A.NAME, A.CONTOKEN, A.TIMESTAMP
      ,A.BINDTIME, A.VALID, A.OPERATIVE, A.LASTUSED
      ,B.STATUS, B.STATEMENT
FROM SYSIBM.SYSPACKAGE  A
    ,SYSIBM.SYSPACKSTMT B
WHERE NOT (B.SEQNO  = 0 
       AND B.STMTNO = 0 
       AND B.SECTNO = 0)
  AND A.LOCATION    = ''
  AND A.LOCATION    = B.LOCATION
  AND A.COLLID      = B.COLLID
  AND A.NAME        = B.NAME
  AND A.CONTOKEN    = B.CONTOKEN
  AND A.TYPE        = ' ' -- ONLY REAL PACKAGES
  AND B.QUERY_HASH  = X'621B6C6564170F63151C5E45544E4A40'
  AND B.EXPLAINABLE = 'Y' -- ONLY EXPLAINABLE SQL
  AND NOT B.HOSTLANG = 'R' -- NO RESTFUL SERVICES 
ORDER BY 2 , 1
FETCH FIRST 100 ROWS ONLY
FOR FETCH ONLY
WITH UR
;

This shows me all the packages with the selected QUERY_HASH value:

---------+---------+---------+---------+
COLLID           NAME     CONTOKEN
---------+---------+---------+---------+
MDB2VNEX_TEST    DSMALTER ) }_8
RTDX0510RCH      DSMALTER î Ö t Y
RTDX0510_AT      DSMALTER À´ Â ¢
RTDX0510_BE      DSMALTER _K W y
RTDX0510_COLL_AN DSMALTER À´ Â ¢
RTDX0510_DA      DSMALTER î Ö t Y
---------+---------+---------+---------+---------+----
TIMESTAMP                  BINDTIME
---------+---------+---------+---------+---------+----
2019-04-08-14.40.11.723943 2022-01-20-15.23.56.457297
2021-11-10-08.34.22.949593 2022-02-28-09.51.35.203521
2021-11-09-10.25.16.043349 2022-05-10-09.05.47.146861
2021-11-17-06.25.25.922112 2022-03-21-13.44.10.759957
2017-11-09-13.17.35.820393 2022-04-25-14.27.48.875174
2021-12-01-11.36.44.218374 2022-03-21-13.44.49.788358
---+---------+---------+---------+--
VALID OPERATIVE LASTUSED   STATUS
---+---------+---------+---------+--
Y     Y         2021-11-22 C
Y     Y         0001-01-01 C
Y     Y         0001-01-01 C
Y     Y         0001-01-01 H
Y     Y         2021-03-24 C
Y     Y         0001-01-01 H
--+---------+---------+---------+---
STATEMENT
--+---------+---------+---------+---
INSERT INTO DSM_ALTER VALUES ( : H ,
INSERT INTO DSM_ALTER VALUES ( : H ,
INSERT INTO DSM_ALTER VALUES ( : H ,
INSERT INTO DSM_ALTER VALUES ( : H ,
INSERT INTO DSM_ALTER VALUES ( : H ,
INSERT INTO DSM_ALTER VALUES ( : H ,

This does add an extra, pretty neat, element to the DBA’s tool kit.

Useful for You?

Do you think you will be using this feature or just let external tooling handle all of this for your system?

I would be very interested to hear any, and all, of your thoughts!

TTFN

Roy Boxwell

Note: One thing that I have noticed is that the hash algorythm is not actually that good! I get duplicates which are not actually duplicate SQLs when only one – four characters are different (typically table names!) Not really a major problem but something you had all better be aware of!

2022-04 A brief history of the Universal Tablespace (UTS) Part Two

This month I wish to finish off, what I started last month, my musings about UTS over the releases and years.

Db2 12 Changes to the UTS Picture

For Partitioned By Range (PBR), a brand-new space was created called the UTS PBR Relative Page Number (RPN) which was, in my opinion, the best thing in Db2 12! Quite simply, it allows the dynamic ALTERing of the partition and all of the related partitioned indexes DSSIZE on-the-fly even when a LOAD is running! This was great! Any users out there who have had a nightmare LOAD? Yep, now, as long as you are actively monitoring your data and index partition sizes, you can issue these ALTERs automatically and never hit the buffers like you do today.

DSSIZE gets propagated through

To enable this feature DSSIZE was improved to be settable at the data partition level and also extended to partitioned indexes. The available values were changed to allow any integer from 1 GB to 1024 GB. This allows extreme flexibility for all sizing requirements. Note, however, that NPSIs are still stuck in the middle of nowhere with just PIECESIZE as a helping hand…

Everything groovy???

So, what was wrong with this picture? Well, the change from PBR to PBR RPN was, shall we say, a little bit painful. The RID size got extended and as the RID is stored in *every* header page it required a tablespace reorg with partition-based inline image copies. Now, as you can well imagine, most people’s PBRs are pretty big, and allocating 4096 Virtual Tapes in parallel was just not going to happen! After a while IBM enhanced REORG so that you could put multiple copies on one tape, sort of like STACK, but much better – and not just for Tape but also for DASD. This has really accelerated the acceptance and usage of PBR RPN.

The future is bright!

Check this Blog entry:

https://www.idug.org/blogs/emil-kotrc1/2021/03/12/why-universal-table-spaces-uts

It is revealed that in Apollo (Db2 for z/OS vNext – Which has now been released as Db2 13 for z/OS), the ability to migrate from a PBG to a PBR will become available instead of the UNLOAD, DROP, CREATE, LOAD method which is the only way up until Db2 12. This will be very handy as the PBR RPN is the best way to go forward with large tablespaces (>60 GB) as long as you have *some* sort of available partitioning scheme, of course!

No more worries??

What do you need to worry about now? Well, you remember that huge LOAD I mentioned earlier that comes at the partition level? You must simply monitor the sizes of your partitioned objects and add a few GBs of space when required, on the fly, with no outage.

How?

Well, we have a little product called SAX+ which does exactly that! It starts the required OPx IFCID traces and computes the values against given thresholds, then automatically issues the ALTERs giving you a seamless experience with PBR RPNs. The only “problem” left now is when you are approaching the 1024 GB absolute PBR RPN physical limit. SAX+ warns you about this as well. Then you will have to either schedule a REBALANCE or a new LIMITKEY definition and REORG to spread the load again. However, when you know this well in advance it is no longer a serious problem!

Not yet at PBR RPN? – No problem!

PBRs which are not yet RPNs are monitored to warn when a threshold of usage in a data or index partition is exceeded. This also gives you more than enough lead time to get the REORG ready to switch it to RPN or just resize/rebalance your partitions.

What about PBGs?

PBGs are also fully supported within SAX+ as it can automatically add partitions, if desired, which additionally avoids SQLCODE -904’s. Plus, SAX+ adjusts the way it works depending on the MAXPARTITIONS and the actual number of allocated partitions. For example, MAXPARTITIONS 10 with a 90% warning would alert you when the ninth partition is allocated and in use. When the tenth partition gets allocated the warning switches from an LDS warning (Running out of available partitions) to a “last partition” filling up warning similar to PBRs which are not yet RPNs. This obviously helps a lot when you have MAXPARTITIONS 1 which is the IBM recommendation these days.

Anything else?

Naturally, SAX+ also takes care of the other problems that can catch you unawares:

  • Running out of Linear Datasets (LOB, PBG, XML, non-UTS space and NPSI)
  • Running out of space
  • Running out of extents and also badly fragmented extents
  • Running out of volumes
  • Running out of physical range for SEQUENCES or IDENTITY columns
  • Running out of physical range for Numeric Primary key columns
  • Running out of DBATs
  • Running out of space in SMS Storage Groups

All of the entries in the above list are very annoying when they hit you with no warning, especially running out of Linear Datasets. Think NPSIs here! Every PIECESIZE is an LDS and so you can run out of these quicker than you think.

LOG problems?

One last thing that SAX+ can help you with is detecting Db2 Log problems together with stalled logs… Not something you normally think of with a space management tool! When Db2 starts running out of space in active logs it issues the DSNJ110E message and I know shops who have “missed” this alert. The problem was that the Db2 Log SMS Storage Group was getting full *and* the tape offload had stalled… As you can imagine this scenario is not pretty, so checking you Log storage groups is probably a good idea to guarantee you do not hit this problem!

That’s enough about UTS for this month. If IBM bring out another TLA for a TLA I will scream!

TTFN,

Roy Boxwell

2022-03 A brief history of the Universal tablespace (UTS)

To understand the UTS concept it helps to look back and see what we, at least in the Db2 world, started with!

In the beginning it was simple

In the beginning were simple tablespaces with the possibility of multiple tables all mixing rows with each other that meant performance got very bad after a very short period of time. We also got single table partitioned tablespaces that required a Partitioning Index (PI) to be created before you could use the table at all. You could also create non-partitioned indexes (NPIs) that were Unique or Non-Unique and were based on the data from all partitions. You could, sort of, manage the size of these using the PIECESIZE parameter, but most shops just took the default and never used it.

Something new in V2R1

Then in DB2 V2R1, we got segmented spaces where all of any given segment only held rows for one table. This improved performance a lot, especially for insert and mass delete processing. It stayed like this right up until DB2 V8.1 when the requirement for a PI was dropped as now you could “partition by table”. This was a leap forward and also brought in the new Data-Partitioned Secondary Index (DPSI) to allow a different partitioning scheme as opposed to the actual partitioning scheme. First, only non-unique DPSIs were allowed (Just think about up to 4096 index checks for breaking a unique rule!) Unique was then finally actually allowed in DB2 V9.1 as long as the DPSI columns were a superset of the partitioning columns. 

DB2 V8.1 the *big* release!

DB2 V8.1 was also the release that renamed our good old NPIs to be non-partitioned secondary indexes (NPSIs) The rules for “When is an index a partitioned index (PI or DPSI)?” or “When is it a non-partitioned secondary index (NPSI)?” are still pretty hard to explain – and most users just seem to guess! 

Death of a PI

The drop of the PI was very good but most shops kept them hanging around as the application code was using them all over the place. DPSIs became a problem right out of the get go causing massive index probes and performance headaches right up to this day. Nowadays, the vast majority of indexes are NPSIs with a few, hopefully well chosen, DPSIs and any required PIs.

DB2 V9.1 new things appearing

Then in DB2 V9.1 along came the new kid on the block – UTS.

IBM has mentioned on multiple occasions that any new Db2 features will only be developed for UTS usage, which has been seen with the developments of CLONE spaces, HASH spaces, Currently committed locking behavior, Pending DDL, Inline LOBs, XML multi-versioning, and ALTER TABLE with DROP COLUMN. This list just keeps on growing. 

The Universal TableSpace was born!

The UTS was created with two distinct and very different flavors.

Partition-By-Range (PBR) is a single-table, segmented tablespace that is partitioned on data values that are given at the table level. Partitions can be from 1 GB DSSIZE up to 64 GB DSSIZE in DB2 V9.1 (In DB2 10 it rose to 256 GB DSSIZE.) The maximum physical size of the partitions and the corresponding partitioned and non-partitioned indexes are all, relative to each other, the same. This was a modernization of the original partitioned table space with its index-based partitioning scheme. 

PBRs got used straightaway as the benefits of the segmented definition were quickly realized. They gave fast spacemap usage for variable length rows and much faster mass delete processing. Changing the maximum possible size, the DSSIZE, of a partition or even of a partitioned index was still very nasty as it required a complete tablespace REORG to action. For NPSIs there was no real change – still just PIECESIZE here to, sort of, manage the maximum size of the datasets.

Calculating the maximum possible sizes is also “non-trivial”. For the data partition it is relatively straightforward but for the PI, the DPSI, and the NPSI it is a pretty nasty set of calculations you must do – and any mistake can quickly lead to an SQLCODE -904!

Partition-By-Growth (PBG) is a single-table, segmented tablespace that can have from 1 to 4096 partitions, each of which can be from 1 GB DSSIZE up to 64 GB DSSIZE in DB2 V9.1 (In DB2 10 it rose to 256 GB DSSIZE.) The PBG cannot have a partitioning key but can have multiple NPSIs, if desired. The PBG was basically viewed as just one huge container where you could just insert rows forever. This has benefits and drawbacks! 

Benefits are: No worries about PI and DPSI definitions as you can only have NPSIs. No worries about running out of space – I mean 4096 huge partitions is a vast amount of space! 

Drawbacks are: No PI and so no way to balance the partitions, a terrible space map search algorithm that simply kills mass insert processes and a huge problem with utilities as it is “one huge space” – and reorganizing one part in the middle of 100’s just causes grief. Plus the inherent problems in copying or cloning data are more complicated, especially if the number of parts on source and target are not the same.

It all started so easily…

In the beginning people used MAXPARTITIONS 4096 thinking “I will never need to change this” but very very quickly it turned out that this was a disastrous idea! The problem being that *all* of the partitions required some control block storage in memory, even if not physically defined or even in use! This caused massive problems and the recommendation to drop down a *lot* in the usage of MAXPARTITIONS. Over the years it has dropped down even more and so now, as of Db2 12, the IBM recommendation for a PBG definition is:

MAXPARTITIONS 1 DSSIZE 64 GB

For the older readers amongst us it should be apparent that this is the good old Linear Dataset (LDS) limit for simple and segmented spaces but rolled out in a new way! For the younger people out there, when DB2 began you could only have 2GB in one VSAM dataset, and so simple and segmented datasets got the ability to allocate up to 32 VSAM datasets, thus giving us the *massive* amount of 64GB space! Coincidence? I think not!

That’s enough about UTS for this month, come back next month for a wrap up about how Db2 12 has changed this picture and all the ways to handle these spaces in the best possible way!

TTFN,

Roy Boxwell

2022-02 ZPARMs never stop changing!

This month I want to go through some of the absolutely most important ZPARMs that control how your Db2 systems behave in a very significant manner. All of the following ZPARMs have a performance impact of some sort and we are always trying to squeeze the last drop of performance out of our Db2 sub-systems, aren’t we?

Starting with the Easy Stuff…

CACHEDYN. YES/NO, default YES. Should always be set to YES unless you do not care about saving dynamic SQL performance. Back a few decades ago, the recommendation was to have this set to NO as default! Hard to believe that these days, where most shops have 80% – 90% dynamic SQL during the day!

Now we Get to the Numerics!

OUTBUFF. 400 – 400,000, default 4,000. This is *extremely* important and you really should set it to the highest possible value you can afford in real memory! As a minimum, it should be 102,400 KB (100MB). This is the buffer that Db2 uses to write log records before they are “really” written to disk. The larger the buffer, the greater the chance that by a ROLLBACK the data required is in the buffer and not on disk. This is a big win and the default of 4,000 KB is crazy low!

Skeletons in the Closet?

EDM_SKELETON_POOL. 5,120 – 4,194,304, default 51,200. This is one of my personal favorites (I wrote a newsletter solely on this a few years ago) The default is way to small these days. I personally recommend at least 150,000 KB and actually even more if you can back it with real memory. Just like OUTBUFF, pour your memory in here but keep an eye on paging! If Db2 starts to page you are in serious trouble! Raising this can really help with keeping your DSC in control.

DBDs are Getting Bigger…

EDMDBDC. 5,000 – 4,194,304, default 23,400. The DBD Cache is getting more and more important as, due to UTS usage, the size of DBDs is increasing all the time. The default just doesn’t cut the mustard anymore so jump up to 40,960 as soon as you can.

DSC is Always too Small!

EDMSTMTC. 5,000 – 4,194,304, default 113,386. The EDM Statement Cache (really the Dynamic Statement Cache) is where Db2 keeps a copy of the prepared statements that have been executed. So when the exact same SQL statement with the exact same set of flags and qualifiers is executed, Db2 can avoid the full prepare and just re-execute the statement. This is basically a no-brainer and should be set to at least 122,880 KB. Even up to 2TB is perfectly ok. Remember: A read from here is *much* faster than a full prepare, so you get a very quick ROI and great value for the memory invested! Keep raising the value until your flushing rates for DSC drop down to just 100’s per hour, if you can! Remember to cross check with the EDM_SKELETON_POOL ZPARM as well. It always takes two to Tango…

How Many SQLs?

MAXKEEPD. 0 – 204,800, default 5,000. The Max Kept Dyn Stmts parameter is how many prepared SQLs to keep past commit or rollback. It should be set to a minimum of 8,000 or so. Raising this might well cause a large memory demand in the ssidDBM1 address space so care must be taken.

RIDs Keep Getting Longer…

MAXRBLK. 0, 128 – 2,000,000, default 1,000,000. RID POOL SIZE is the maximum amount of memory to be available for RID Block entries. It should be at least 1,000,000 and, if you can, push it to the maximum of 2,000,000. Unless you want to switch off all RID Block access plans in which case you set it to zero – Obviously not really recommended!

Sorts Always Need More Space

MAXSORT_IN_MEMORY. 1000 to SRTPOOL. The maximum in-memory sort size is the largest available space to complete ORDER BY, GROUP BY or both SQL Clauses. Remember that this is per thread, so you must have enough memory for lots of these in parallel. The number should be between 1,000 and 2,000, but whatever value you choose, it must be less than or equal to the SRTPOOL size.

Sparse or Pair-wise Access?

MXDTCACH. 0 – 512, default 20. Max data caching is the maximum size of the sparse index or pair-wise join data cache in megabytes. If you do not use sparse index, pair-wise join, or you are not a data warehouse shop, then you can leave this at its default. Otherwise, set it to be 41 MB or higher. If it is a data warehouse subsystem, then you could set this as high as 512 MB. (This ZPARM replaced the short-lived SJMXPOOL, by the way.)

Sort Node Expansion

SRTPOOL. 240 – 128,000, default 10,000. SORT POOL SIZE is the available memory that is needed for the sort pool. The default is 10,000 KB and should really be set to 20,000 KB at least, if not more! IFCID 96 can really help you size this parameter. Remember that the number of sort nodes leapt up from 32,000 in Db2 11 to 512,000 nodes for non-parallelism sorts and 128,000 nodes for a sort within a parallel child task in Db2 12. This means raising this ZPARM can have an even greater positive effect than before.

Your “Top Ten List”

These ten ZPARMs really influence how your Db2 system works and so must always be changed with great care and attention to detail. Always do a before and after appraisal to see whether or not changing them helped or hindered your system!

And Finally…

I have updated our Pocket Tool, Performance Health Check, to check and report all these ZPARMs, as well as all the other checks like the 6 Byte RBA/LRSN or the Mapping table changes or the reason for REORG etc etc. Feel free to download and run it, as it is but a click away!

If you have any comments, or other ZPARMs you think are also important for performance, feel free to drop me a line!

TTFN,

Roy Boxwell

2022-01 Fazed by phases?

This month I wish to do a quick run through, and review, of the effects of REBIND with active packages and how phases, both in and out, have given us some interesting problems to deal with!

Phase-In

As I mentioned in an earlier blog, the phase-in/phase-out was a very good idea indeed! It finally meant that we could do REBINDs whenever we wanted and no-one had to shut down servers to simply action a REBIND. This was always especially galling when it was an “empty” package or just to get an FL upgrade.

Allowed?

Remember, Phase-in is only allowed with PLANMGMT(EXTENDED) style packages and if the package is not a generated package for a trigger or SQL routine, such as a procedure or user-defined function.

Problems ahead?

The problems began soon after it was introduced in June 2019 with PH09191 and FL505. Now, it looked really good, and indeed it was, but it had one little flaw… it still required a SIX lock to do the business.

Problem solved?

This was solved in January 2021 with APAR PH28693 which changed the lock from a SIX to a much better U lock. With this APAR all of our problems were fixed and life would be good!

Nope…

Sadly, we then found out that the inactive/phased-out packages were actually causing rapid space growth in the SYSPACKCOPY (Not in SYSPACKAGE!) Remember that the phased-out packages all get copied across with a new number to the “back-up” SYSPACKCOPY for use until the active thread finally disconnects.

The Problem Gets Worse

Now these backed-up, old packages are sitting around in SYSPACKCOPY waiting until the next REBIND comes along whereupon Db2 will attempt a FREE. Various customers noticed that, for their intensely used packages, this free never really happened and so they “hit the buffers” of 14 copy_ids for packages… very nasty!

Another APAR to the Rescue!

IBM then created a new APAR, PH33295, that enhanced the FREE PACKAGE command to have a new PLANMGMTSCOPE sub-clause PHASEOUT. All this does is delete all of those old, no longer used packages. However, I can testify that doing a:

FREE PACKAGE(*.*.(*)) PLANMGMTSCOPE(PHASEOUT)

in production is one of the scariest commands I have ever issued!!! Personally, I would have preferred a brand new command like FREE PHASEDOUT PACKAGES or so…

Invalid as Well

While you are ridding yourself of 100’s of packages you could also issue the PLANMGMTSCOPE(INVALID) command which removes the phased-out and also gets rid of the dead, invalid packages which cannot ever be used anyway.

Do not Forget to Tidy up!

Once all these commands have been done, a REORG of the tablespace DSNDB06.SYSTSPKC is very highly recommended!

How have you experienced phase-in and phase-out? Do you think it’s a great feature or not?

Whatever you think, I would love to hear from you!

TTFN,

Roy Boxwell