Understanding fallback
Fallback (or backout) is a return to the prior level of a system.
Fallback can be appropriate if you upgrade to
z/OS 3.1
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 that are made by the later-level release.
In general, always plan to have a backout path when you install new software. Identify and install any service that is required to support backout.
Fallback is at a system level, rather than an element or feature level. As of z/OS V2R1, there is no support for the fallback staging of mixed levels of JES2 and SDSF. As a result, you cannot back out an element or feature that includes JES2 and SDSF. Rather, you must 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, see Making a copy of your system software (cloning).