Placeholder for adding Db2 V13 issues surfaced by CMOD.
Db2 V13 has been/is being tested with CMOD, no issues found to date.
Ed
Thanks, Ed. Our shop is working on Db2 V13 upgrade now and I came here looking for info just like this. If anything is found I will let the group know; although I expect it won't be ready to test around here for a couple months yet.
Just confirming, nothing special about Db2 V13 (yet).
CMOD isn't exploiting anything new in V13 (yet), and it's been ages since we hit anything in V12.
Ed
This is not a new error. We've been running Db2 V13 for many months now.
We brought up a new Db2 back end and when we brought up ODF we hit:
QuoteARS0013E ODADMIN DB Error: DB2 FOR OS/390 ODBC DRIVER SQLSTATE=58004 ERRLOC=2:56:9 CAF "CONNECT" failed using DB2 system:DCDO RC=08 and REASON=00f30055 -- SQLSTATE=58004, SQLCODE=-99999, File=arssys.c, Line=955
ARS4337I The ARSODF instance ARCHIVE is terminating
Explanation is here:
https://www.ibm.com/docs/en/db2-for-zos/13?topic=codes-00f30055
Ended up increasing IDBACK to 500 which resolved the issue.
Ed
PH56940: ABEND0C4 RC10 AT DSNXOD3 OFFSET04726 MAY OCCUR FOR THE QUERY USING SINGLE INDEX ACCESS
Error description
ABEND0C4 RC10 AT DSNXOD3 OFFSET04726 MAY OCCUR when explaining
an SQL statement whose access path contains single index access.
KEYWORDS: ABEND0C4 SQLEXPLAIN SQLACCESSPATH
Local fix
Avoid Explain on the impacted SQL statement.
Problem summary
****************************************************************
* USERS AFFECTED: *
* All users of Db2 12 and Db2 13 for z/OS who *
* explain queries whose access path contains *
* single index access. *
****************************************************************
* PROBLEM DESCRIPTION: *
* ABEND0C4 at DSNXOD3 offset 04726 may *
* happen when explaining an SQL *
* statement whose access path contains *
* single index access. *
* Abend only happens when the accessed *
* storage is not available. Otherwise, *
* incorrect information may be populated *
* into column IBM_SERVICE_DATA of *
* PLAN_TABLE. *
****************************************************************
* RECOMMENDATION: *
* Apply corrective PTF when available *
****************************************************************
For example:
EXPLAIN ALL SET QUERYNO = 1 FOR
SELECT C1,C2 FROM T1
WHERE T1.C1 = 100;
Index IX(C1) is chosen to access T1. When populating data into
PLAN_TABLE, an invalid array index zero is used that may result
in ABEND0C4 at DSNXOD3 offset 04726 or incorrect information in
column IBM_SERVICE_DATA of PLAN_TABLE.
Problem conclusion
Db2 has been modified to correctly process the aforementioned
SQL statement.
Additional Keywords ABEND0C4 SQLEXPLAIN SQLINDEX
PH57851: ABEND0C4 MAY HAPPEN AT DSNXOGP:0AB44 FOR QUERY WITH MULTI-INDEX ACCESS.
Error description
ABEND0C4 may happen at DSNXOGP:0AB44 for query with multi-index
access.
The abend happens during choosing access path for query.
ADDITIONAL SYMPTOMS:
ABEND0C4 MIDX DSNXOGP OFFSET0AB44 OFFSETAB44 0AB44 AB44
Local fix
BYPASS/CIRCUMVENTION:
Please try adding OPTIMIZE FOR 1 ROW to discourage optimizer
from using multi-index.
Problem summary
****************************************************************
* USERS AFFECTED: *
* All users of Db2 12 and Db2 13 for z/OS who *
* has queries whose access path contains *
* multiple index access. *
****************************************************************
* PROBLEM DESCRIPTION: *
* ABEND0C4 at DSNXOGP offset 0AB44 may *
* occur for an SQL statement whose *
* access path contains multiple index *
* access. *
****************************************************************
* RECOMMENDATION: *
* Apply corrective PTF when available *
****************************************************************
ABEND0C4 at DSNXOGP offset 0AB44 may occur for an SQL statement
whose access path contains multiple index access.
The abend is intermittent depending on the availability of
certain storage.
Problem conclusion
Db2 has been modified to correctly process the aforementioned
SQL statement.
Additional Keywords ABEND0C4 SQLEXPLAIN SQLINDEX MIDX
SQLACCESSPATH
Output from my DISPLAY GROUP command:
*** BEGIN DISPLAY OF GROUP(........) CATALOG LEVEL(V13R1M501)
CURRENT FUNCTION LEVEL(V13R1M503)
HIGHEST ACTIVATED FUNCTION LEVEL(V13R1M503)
HIGHEST POSSIBLE FUNCTION LEVEL(V13R1M503)
PROTOCOL LEVEL(2)
GROUP ATTACH NAME(....)
Ed
Just updating this to say that CMOD hasn't exposed any new errors in Db2 since my last update.
Ed
I learned that new function level is available for Db2.
At this time, there is no plan for CMOD to require any of these new functions.
Db2 13 - What's new - Function level 507 (PH64907 - April 2025)
Function level 507 introduces online conversion of table partitions from PBR to PBG, enhanced concurrency for system temporal tables, LASTUSED support for application plans, more flexibility for temporal and archive-enabled tables, and greater than 64 GB allocation quantities.
CMOD has surfaced the follow Db2 defect:
PH68886: Db2 FOR z/OS ODBC TRACED THE BIGINT VALUE INCORRECTLY
Error description
When BIGINT is in use, the Db2 for z/OS ODBC application trace shows an incorrect value.
Subject: Deprecated DB2 TABLE/TABLESPACES regarding ARS INDEX TABLES
Problem Description:
This week, the DB2 DBA's brought up the topic of old Tablespace constructs being deprecated. Looks like all of the recently defined Index Data tables are being defined with Supported constructs. Older Index Data tables were defined with constructs identified as Deprecated.
Will this Impact Production Support without Upgrading these Objects? Do they need to be upgraded to be properly supported? Same with the Indexes associated to these Tables/Tablespaces.
Note: This answer was provided by Db2 Support. If you have a question contact Db2 support, not CMOD support.
Note: This is all unofficial information unless promulgated via an IBM announcement
If you create the objects with APPLCOMPAT level V13R1M503 or lower then you can create deprecated objects. If you are using SPUFI or DSNTIAD or DSNTEP2 then you would need to bind those plans with APPLCOMAT(V13R1M503) or lower.
Note, however, that Db2 VNext will not support the following:
Simple, segmented or classic partitioned tablespaces;
BRF or basic (6 byte) format pagesets;
hash pagesets;
synonyms;
VTAM connectivity.
You have till approx. 2031 till V13 will be out of support.
_________________________________________________
Follow-on question:
All of the Index tables after 2019 seem to be created ok(partition by growth), but we have 2900+ tables that are Simple tables (TYPE of SPACE). 39 of them are ARS* SYSTEM TABLES. All need to be converted before 2031, right? Don't want to wait until the "last minute".
_________________________________________________
Reply from Db2:
> All need to be converted before 2031, right?
Yes.
This is an OAM APAR that affects Db2 Allocations
OA68939: UPDATE OAM'S OBJECT SUPPORT SAMPLE JOBS TO WORK WITH NEW VERSIONS OF DB2
https://www.ibm.com/support/pages/apar/OA68939
Error description
As of APPLCOMPAT V12R1M504, Db2 has deprecated support for the
creation of Segmented (non-UTS) tablespaces. This has caused
OAM Db2 sample jobs to implicitly create PBG tablespaces
instead of segmented which is desired at V12R1M504 and higher.
Within our CBRILOB sample, the LOB tablespace is being created
as PBG, however the auxiliary table space is still defined as
segmented which causes Db2 to return with SQLCODE-769.
CBRILOB requires an update to remain compatible with PBG.
Local fix
If APPLCOMPAT is V12R1M504 or higher, then Add PART clause to
the CREATE AUXILIARY TABLE. This will cause the auxiliary table
to become compatible with the LOB table space which is being
created as PBG at APPLCOMPAT V12R1M504 or higher.
Example:
CREATE AUXILIARY TABLE osg_hlq.OSM_LOB_AUX_TBL
IN osg_hlq.OSMLATS
STORES osg_hlq.OSM_LOB_BASE_TBL
COLUMN OTOBJ
PART 1;
Output from my DISPLAY GROUP command:
*** BEGIN DISPLAY OF GROUP(........) CATALOG LEVEL(V13R1M505)
CURRENT FUNCTION LEVEL(V13R1M506)
HIGHEST ACTIVATED FUNCTION LEVEL(V13R1M506)
HIGHEST POSSIBLE FUNCTION LEVEL(V13R1M506)
PROTOCOL LEVEL(2)
GROUP ATTACH NAME(....)