Note: This section is specific to DB2 for z/OS.
By default the behavior is for tablespaces to be created implicitly during table creation. The exceptions to this are:
- The tablespace named by the curam.db.zos.32ktablespace property is created explicitly by the datamanager and tables exceeding the 4K row limit are placed in this tablespace.
- Tablespaces identified in the Tablespace.properties file are created explicitly by the datamanager. If the table specified for the tablespace exceeds the 4K row limit the tablespace is defined in the 32K BUFFERPOOL. Otherwise, it will take the default setting.
When using the Tablespace.properties file the format of the entries is:
Comments are specified by the "#" character in column one.
Note: If the tablespace for the table that exceeds the 4K row limit is defined in the Tablespace.properties file then this tablespace will be used over the one defined in the property curam.db.zos.32ktablespace.
Note: When using DB2 for z/OS version 8 the use of the default 32K tablespace (curam.db.zos.32ktablespace) can result in SQLCODE -913 errors during login, but could also occur in other contexts. To avoid these errors you should do one of the following:
- Ensure your Cúram default 32K tablespace is segmented (SEGSIZE; see the DB2 Universal Database for z/OS SQL Reference Version 8 for more information).
- Explicitly define tablespaces for each Cúram table that defaults to the 32K tablespace (e.g. SELECT * FROM SYSIBM.SYSTABLESPACE WHERE NAME = <curam.db.zos.32ktablespace value>) and assign each table to a specific tablespace via the Tablespaces.properties file.
(This is not an issue when using DB2 for z/OS version 9 because tablespaces are segmented by default.)
Note: In DB2 for z/OS version 9 the behavior of the
ALTER TABLE DROP PRIMARY KEY SQL statement changed as follows: "If the table space was implicitly created, the corresponding enforcing index is dropped if the primary key is dropped." Most production users would typically explicitly create their tablespaces and would not be impacted by this change, but in test environments this may not be the case. The symptom of this issue is an SQLCODE -551 error on a
DROP INDEX statement following the
ALTER TABLE DROP PRIMARY KEY statement. To avoid this error you can either:
- Manually remove the generated DROP INDEX SQL statement from the Data Manager -generated SQL to take into account the new behavior; or,
- Explicitly define the tablespace and specify it in the Tablespace.properties file. For example, for the USERS table, your Tablespace.properties file would contain: