Upgrade Guide for DB2 UDB for z/OS > Preparing a Development Environment for Upgrade >

About Moving Tables

Upgrades: All upgrades.

Environments: Development environment only.

This topic is part of an upgrade process. See How to Perform the Upgrade.

Some of the tables are going to have columns added to them as part of the upgrade. When this happens, the length of the record will increase causing it to require a larger tablespace or bufferpool. Moving the identified tables to a new, larger and differently named tablespace allows you to maintain the paradigm of multiple tables per tablespace which is present for all pre-7.7 schemas.

Before you move the tables, you need to drop any standard or custom views. Complete the following procedure to find the views that are defined on a table.

NOTE:  The example used in the procedure assumes that you are creating a new 16K tablespace within the same database as the older, smaller tablespace.

To find views that are defined on a table

• Run the following SQL statement to produce the list of views:

  select * from sysibm.sysVIEWdep

  WHERE Bcreator = 'yourschema'

  AND BNAME IN ('S_ASSET', 'S_PROD_INT');

This SQL statement produces the drop statements into a sequential dataset:

SELECT DISTINCT 'DROP VIEW '||'*** yourschema.'||V.DNAME||' ;'

FROM SYSIBM.SYSVIEWDEP V

WHERE V.BNAME IN ('S_ASSET', 'S_PROD_INT')

WHERE V.BNAME = 'S_ASSET'

AND BCREATOR = 'yourschema';

In order to process these drop statements on the z/OS host, you need to create a PDS member with the output from the preceding statement. Then submit this member through DSNTEP2 using JCL.

You can also list these tables in the override.inp file. This will cause the tables to be recreated in a new database with one tablespace and one table.

If you are using the preconfigured storage control file, you do not need to move any tables as a preupgrade task. This is because the existing schema is not being preserved and all tables will be recreated in the 1:1:1 model.