Rather than take full or partial system backups at regular intervals, you can decide to follow the continuous backup approach and use your journals to update your latest backup. There are three tasks to the continuous backup procedure:
The following sections explain these steps and suggest some implementation alternatives. The choices you make affect the procedures you follow regularly and the length of down time you experience if you ever must restore backed-up data.
Depending upon the size of your journal data sets and the number of transactions you process, your journals can be spun many times during the day. When a journal spins, its contents are condensed and offloaded into a journal accumulation file.
The systems administration and operations staff at your site decide how many journal accumulation files to keep on DASD before merging them together into one. The default threshold is 2. To change this default, edit the value of the $SPINLIM$ parameter in your spin procedure. The spin limit must not be greater than the limit specified in the installation parameter $JSRGDG$. For more information about $JSRGDG$, refer to
TIBCO Object Service Broker for z/OS Installing and Operating.
The following example illustrates how you can use the standard SORT JCL to merge journal accumulations after every two journal spins. The JCL for this example is derived from member SPINMRG in the JCL data set.
This JCL uses standard sorting facilities and exit routines. The sorting procedure for merging journal accumulations reads in all existing journal accumulations (for example, as generation data sets within a GDG), eliminates old duplicate pages and outputs a master accumulation file to disk. If DASD is initially used for the GDG, the GDG base must be deleted and redefined if you switch to tape.
While the sample JCL uses sort exit S6BSPX35, an alternative exit, S6BSPU35, is available if you want to be able to recover segment pages using journal images to a specific point in time.
The point-in-time recovery option, enabled by the use of S6BSPU35, uses much more journal file space than recovery to the latest quiesce point that S6BSPX35 gives you. To allow point-in-time recovery, S6BSPU35 saves all journaled page images, unlike S6BSPX35, which saves only the latest version of each. For more information on point-in-time recovery, refer to
Chapter 8, Recovery Procedures.
Using the continuous approach, you can merge your master accumulation file with your latest complete backup as frequently as your recovery needs require. In most cases, we recommend a daily refresh of your complete backup.
To refresh your latest backup, use the sort program to read in your journal accumulation file (or files) and your latest complete backup. The sort exit routines write information about the input and output records in an ARCHLOG and eliminate the older versions of duplicate pages. The output from this sort is a new system backup that includes all page updates recorded in the journal accumulation files.
After you create your new backup, you must run the S6BBRPTR (Batch Pointer Check) utility against it to verify the accessibility of all pages in the backup. The S6BBRPTR utility is described in
TIBCO Object Service Broker for z/OS Utilities.
