Implications of falling back

Data sharing

If any member of a data sharing group needs to fall back, consider the implications for data sharing. For more information about falling back in a data sharing environment, see Falling back in a data sharing environment.

Frozen objects

Falling back does not undo changes that the migration process made to the catalog. DB2 uses the migrated catalog after fallback. Some objects in this catalog that have been affected by DB2 10 function might become frozen objects after fallback. Frozen objects are unavailable, and they are marked with the release dependency marker O. If an object is marked with a release dependency, it remains marked forever. The release dependency marker is listed in the IBMREQD column of catalog tables. The following table lists the objects that are frozen when you fall back to a previous release.

Table 1. Objects that are frozen after fallback

RELEASE DEPENDENT MARK = O

Plans, packages, or views that use any new syntax, objects, or bind options DBRMs that are produced by a precompile in DB2 10 with a value of V10 for the NEWFUN option and when any new DB2 10 functions are being used Any package that contains a statement with CHAR(decimal), if you rebind the package in DB2 10 and you migrated to DB2 10 with the BIF_COMPATIBILITY subsystem parameter set to CURRENT.

Plans and packages become frozen objects when they use new SQL syntax, use new BIND options and attributes, or reference frozen objects. When plans and packages become frozen objects, the automatic rebind process is adversely affected.

After falling back, you can determine if any of your objects are frozen by issuing the following statement:

SELECT * FROM catalog table
WHERE IBMREQD = 'O'

SQL syntax

When you fall back to Version 8 or DB2 9, you cannot use DB2 10 SQL syntax. In DB2 10, you can run the DB2 precompiler or DB2 coprocessor on your applications with option NEWFUN(V8) to determine whether they contain syntax that is newer than Version 8. You can run the DB2 precompiler or DB2 coprocessor on your applications with option NEWFUN(V9) to determine whether they contain syntax that is newer than DB2 9.

Automatic rebind

After fallback, if you specified YES or COEXIST for the ABIND subsystem parameter, plans or packages that are bound in DB2 10 are automatically rebound on their first execution in Version 8 or DB2 9. If you specified NO for the ABIND subsystem parameter, this automatic rebind fails.

The automatic rebind also fails if you try to use plans or packages that are frozen. To make available the plans and packages that are not automatically rebound, change the SQL statements or remove the reference to a frozen object, precompile the application programs, and explicitly bind the plans and packages on Version 8 or DB2 9.

After fallback, you need to rebind SPUFI. You might need to bind SPUFI with ENCODING(EBCDIC) to avoid an error message.

Administrative task scheduler tasks

After fallback, all tasks that are managed by the administrative task scheduler in DB2 DB2 10 are not manageable by the administrative task scheduler in Version 8 or DB2 9 because of the higher task version. Use ADMIN_TASK_ADD in Version 8 or DB2 9 to delete and reinsert all tasks. You can use the ADMIN_TASK_LIST table user-defined function to read and store the characteristics of the tasks in a user table before you fall back.

Database metadata stored procedures

In DB2 10, the DB2 database metadata stored procedures have new Unicode load modules.

When you run job DSNTIJRT after migrating to conversion mode, it drops the EBCDIC-encoded versions of these stored procedures, and re-creates them as Unicode-encoded. Therefore, if you fall back after running job DSNTIJRT and you use the DB2 database metadata stored procedures, you need to make the DB2 10 load modules available to this DB2 subsystem and other members of the data sharing group.

To make your DB2 10 load modules available to this DB2 subsystem and other members of the data sharing group, complete one of the following tasks:

• Copy the DB2 10 load modules that are listed above into the Version 8 or DB2 9 prefix.SDSNLOAD libraries.
• Include the DB2 10 prefix.SDSNLOAD library in the STEPLIB of the WLM startup procedure for the database metadata stored procedures.

Other implications of falling back

Before you fall back to Version 8 or DB2 9, be aware of the following considerations:

Reactive governing

If you decreased ASUTIME values in the resource limit facility to account for the fact that the resource limit facility does not accumulate ASUTIME across SQL statement boundaries in DB2 DB2 10, you need to increase the ASUTIME values to avoid getting -905 errors.

TEMP database

If you dropped the TEMP database in conversion mode from Version 8, you need to re-create the TEMP database. Otherwise, applications that use the TEMP database fail in DB2 Version 8.

Private protocol

In Version 10, if you explicitly rebind a package or plan that was bound with DBPROTOCOL(PRIVATE) in a previous version of DB2, the object is rebound with the DBPROTOCOL(DRDA) bind option. If you fall back from DB2 10, the package or plan retains the DBPROTOCOL(DRDA) setting. If you want to run the object with private protocol in the fallback release, you must explicitly rebind it with DBPROTOCOL(PRIVATE).

Subgroup attachment

Subgroup attachment can be used after fallback only if you used the DB2 10 early code when you defined the DB2 subsystem to z/OS®.