In this example, suppose you have only one tape device available, TAP01, available for backup operations. You can use a tape library, such as a 3570 or a 3590 device.
For the purposes of this example, however, you are using the device as a stand-alone. You must decide how to save two packaged business applications (one for payroll, the other for inventory), a few company-designed programs, and several user libraries.
In this situation, you could use either of the following strategies to back up your data:
v You could perform an *ALLUSR save on a weekly (*FULL) and daily (*INCR) basis
v You could create multiple control groups containing applications, libraries, or related subsets, again with weekly (*FULL) and daily (*INCR) backups.
Utilizing an *ALLUSR strategy saves all user libraries, but it does not allow specialized recoveries. An *ALLUSR save may also require that you rebuild access paths when restoring the libraries.
Splitting your application and user data into multiple control groups provides the following benefits:
v Makes recovery easier by allowing you to separate and prioritize critical
applications for a speedier, more business-efficient recovery. For example, if you use certain applications only on specific days (such as payroll), you might not need to restore that application immediately after a failure on a non-payroll day.
Conversely, if the system fails on a heavy payroll day, you want to get the payroll application back on the system as soon as possible. Similarly, some user-specific libraries may be less critical than others or than the day-to-day business applications. If you use the simple *ALLUSR approach, then selective or prioritized recovery is very difficult.
By splitting user libraries and business applications into separate control groups, you can prioritize the order in which BRMS restores your libraries and
applications. In addition, a single control group has only one media policy, and one schedule for all the libraries and applications it contains. Multiple control groups, on the other hand, allow you to run different control groups on different days. And, because they use more than one media policy, multiple control groups allow for more flexible retention periods.
v Avoids access path rebuilds by grouping based-on physical files with their dependent logical files. In some instances, the system holds logical views of data in different libraries than their based-on physical files (this is called a Database Network). The system organizes library files alphabetically, by save time, which can cause a problem if the logical files appear earlier in the list than their counterpart physical files. This problem makes recovery much more difficult. If you use an *ALLUSR save, the system saves access paths for the logical files along with the physical files. However, you might need to perform lengthy access path rebuilds after a restore operation because the system cannot restore the based-on physical file.
To avoid lengthy rebuilds, design your backups so that you do not include database networks in an *ALLUSR or a generic* backup. Separate control groups
Chapter 7. Tailoring Your Backup 119
can save the based-on physical files before their dependent logical files. This way, BRMS can restore the objects in the correct sequence, thereby avoiding lengthy access path rebuilds. However, you need to make sure that you save the physical and logical files with the same underlying SAVxxx command. If you save the logical and physical files with different SAVxxx commands, BRMS cannot save the access paths , even if you specify ACCPTH(*YES).
You can also consider a compromise between these two strategies, especially if you have smaller systems with fewer libraries. Under these circumstances, you can use a combination of *ALLUSR and your own control groups. Use one or more control groups for specific libraries, and another control group containing the *ALLUSR libraries. If you choose this strategy, you need to omit the libraries in your own control groups. This way, you can restore the items in your control groups selectively, on an as-needed basis. You can save less critical libraries on a less frequent basis.
If you save multiple control groups to single device, BRMS processes them serially, one after another. Figure 8 on page 121 illustrates how you can design a number of control groups to run in sequence.
The manufacturing application (MANUFACT) consists of libraries MANUFLIB1 through MANUFLIB5, and DISTLIB1 through DISTLIB3. These libraries now exist in three separate control groups. You can find the logical files in library
MD_LOGICAL. The logical files were built over physical files in libraries
MANUFLIB3 and DISTLIB2. To avoid rebuilding the access paths for these logical files after restore, MANUFLIB3 and DISTLIB2 were omitted from the MANUFACT and DISTRIBUTION control groups. Instead, they were included with library MD_LOGICAL in a separate control group called DBNETWORK. The ADHOC control group contains a few user libraries and a few of the smaller applications.
The FINANCE and PAYROLL control groups contain the more critical payroll and finance data.
Figure 8. Multiple Control Groups in a Serial Save
Chapter 7. Tailoring Your Backup 121
When you process multiple control groups serially, keep the following considerations in mind:
v Saving Media Information: BRMS usually saves media information at the end of each control group. However, if you are running the control groups serially, BRMS saves the media information files at the end of each control group. While this is not a problem, it can extend the runtime for the control groups. In addition, because BRMS saves the same media information in the last file in each control group, you really need only the last group of media information files. You may find it beneficial, then, not to save the media information at the end of each control group. Instead, you can save it separately by using the SAVMEDIBRM command. Whichever method you choose, you must save this information on a regular basis as BRMS uses it to restore your data. In Figure 9 BRMS processes the SAVMEDIBRM command in a separate job.
v Appending to Media: By default, BRMS uses an expired tape for each control group. Therefore, during serial operations, BRMS unloads the volume from the previous group and uses a new volume for each subsequent control group.
However, you can add the later control groups to the end of the previous tape.
To do that, specify ENDOPT(*LEAVE) and APPEND(*NO) on the Change Backup Control Group Attributes display for the first control group. Then specify ENDOPT(*LEAVE) and APPEND(*YES) for the second and subsequent control groups.