Fallback (backout) is a return to the prior level of a system. Fallback can be appropriate if you migrate to z/OS® V2R1 and, during testing, encounter severe problems that can be resolved by backing out the new release. By applying fallback PTFs to the "old" system before you migrate, the old system can tolerate changes that were made by the new system during testing.

Fallback is relevant in all types of configurations, that is, single-system or multisystem, with or without resource sharing.

As an example of fallback, consider a single system that shares data or data structures, such as user catalogs, as you shift the system image from production (on the "old" release) to test (on the new release) and back again (to the old release). The later-level test release might make changes that are incompatible with the earlier-level production release. Fallback PTFs on the earlier-level release can allow it to tolerate changes made by the later-level release.

As a general reminder, always plan to have a backout path when installing new software by identifying and installing any service required to support backout.

Fallback is at a system level, rather than an element or feature level. Starting with V2R1, there is no longer support for the fallback staging of mixed levels of JES2, JES3, and SDSF. That means that you cannot back out an element or feature including JES2, JES3, and SDSF; you can only back out the entire product.

Fallback and coexistence are alike in that the PTFs that ensure coexistence are the same ones that ensure fallback.

If your fallback plans include making a clone, refer to Making a copy of your system software (cloning).