Understanding fallback
Fallback (or backout) is a return to the prior level of a system.
Fallback can be appropriate if you migrate to 
z/OS V2R4
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, JES3, and SDSF. As a result, you cannot back out an element or feature that includes JES2, JES3, 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.
z/OS
V2R4 level before the new functions can be used. Therefore, be careful not to use new functions
until you are fairly confident that you do not need to back out your z/OS V2R4
systems because fallback maintenance is not available in these cases. To determine the requirements
for using a particular new function, refer to the appropriate element or feature information.If your fallback plans include making a clone, see Making a copy of your system software (cloning).