You may be able to mitigate this CPU consumption problem if you:
- Have DRDA requestors use multi-row processing and, when migrating to NFM, use multi-row processing (especially in DSNTIAUL and DSNTEP4)
- Rebind plans and packages that may take advantage of new (or better) access paths
- Implement long-term page fixing of virtual pools; review this with your systems programming staff first to ensure that real storage is available for the virtual pools.
Code Page and Character Set Issues
As part of pre-planning for migration, you audited your DB2 subsystem for coded character set (CCSID) usage. You should do this now because it’s essential that you:
- Verify the CCSIDs in DSNHDECP are valid
- Validate the CCSIDs of the data stored in your tables
- Document the code pages used by your terminal emulators.
Use migration job DSNTIJP8 to see if you have multiple CCSIDs in one encoding. Reference APARs PQ56697 and PQ89018 to confirm that your terminal emulators are configured correctly.
Failure to resolve code page issues before migration may result in lost data or a DB2 subsystem that won’t work.
Data Sharing Mixed-Mode Issues
Mixed mode refers to running a DB2 data sharing environment with one or more members running as DB2 V8 and one or more others running as DB2 V7. The data sharing members share the DB2 catalog and directory, which means there are shared plans for SPUFI, DSNTIAD, DSNTIAUL, DSNTEP2, and DSNTEP4. Binding one or more of these plans in the V8 environment may cause problems if they’re executed from a V7 member.
Consider defining packages for these plans and binding two versions of each.
There are some restrictions on issuing commands against utilities in a data sharing mixed mode environment. If you execute a utility in a V7 environment, all commands issued against the utility (such as TERM) should be issued only from the V7 environment.