During Phase 3 of the installation or migration verification
process, you can test SPUFI to ensure that it is working properly.
Procedure
To test SPUFI:
- Log on to TSO.
- Enter ISPF (this might be done for you, depending on your
site's standard practice).
- On the DB2I defaults panel, change the Db2 name
to the Db2 subsystem
name you entered on panel DSNTIPM during installation. Then select
DB2I on the ISPF Primary Option Menu.
- Select SPUFI on the DB2I menu.
- Enter the library name 'prefix.NEW.SDSNSAMP(DSNTESA)'
as input to SPUFI on line 1, the DATASET NAME parameter.
If
your site uses the comma as a decimal point, the library name entered
must be for the tailored version of job DSNTESA that was modified
by the installation CLIST.
- Define an output data set name on line 4, the output DATASET
NAME parameter of the panel.
This allows you to review
the output.
- Press ENTER, and examine the results.
These
SQL statements require a significant amount of Db2 processing;
you could have to wait for the output.
- Run steps 5, 6, and 7 three times:
- Once with member DSNTESA, which uses a set of SQL statements to
create a short-lived table space and table.
- Once with member DSNTESC, which creates objects that support EXPLAIN information.
If you
are migrating from Db2 11, DSNTESC is
customized by the installation CLIST to migrate your Db2 11 PLAN_TABLE, DSN_FUNCTION_TABLE,
DSN_STATEMNT_TABLE, and DSN_STATEMENT_CACHE_TABLE to Db2 12 using a schema name of DSN8C10. If these Db2 11 tables have a different schema name, edit
DSNTESC to use your schema name.
Migration of
these tables from a prior release should not be performed more than once.
Also, some
table spaces that are created by DSNTESC specify non-default buffer pools, BP8K1 and BP16K1. Verify
that these buffer pools are enabled on Db2 before you process
this DDL.
- Once with member DSNTESE, which retrieves the EXPLAIN information.
What to do next
If any step fails or abends, be sure that the Db2 subsystem name is specified in the NAME field
on the DB2I Defaults panel.
If you must drop either a Db2 11 or Db2 12 PLAN_TABLE,
remove the appropriate comments from the job to issue the DROP statements.
Also,
make sure that the user ID that you are using is authorized. If the
name that you specified for either the SYSADM or SYSADM2 subsystem
parameter is a primary authorization ID, use this name. If the sample
authorization exit and RACF® are
installed, and both SYSADM and SYSADM2 are known to Db2 as secondary authorization IDs, you can run
these jobs under a user ID in either of these RACF groups. Then, correct any other problems
and rerun the scenario from the last successful step.