Some system-specific prerequisites must be observed to ensure that the online save is as free as possible from error. The validation procedure supplied with FDDRL (chapter "Prerequisites for checking the online save" ) checks whether the following prerequisites are provided and, if necessary, suggests measures to comply with requirements:
Write caching with DAB may not be enabled for the home pubset.
It must be terminated before the save so that all data can be written to the disks. After the save it can be switched on again.In the case of a mirrored home pubset only the copied mirror pubset should be saved instead of the online save (see chapter "Saving Clones (SHC-OSD)").
BCAM status JV
If a BCAM status JV for sign-of-life monitoring exists, BCAM updates the JV every 60 seconds. In this case BCAM is blocked by the write lock during the online save and accepts no further connections. You must check whether the status JV is actually required by applications:If the status JV is not required, it should be deleted (
/MODIFY-HOST-ATTR STATUS-JV=*NONE).If the status JV is required, it should be moved to another pubset.
BCAM monitoring
In the case of BCAM monitoring on the console, a large number of messages are output to the console and logged accordingly in the CONSLOG file. BCAM monitoring should consequently be switched off at least during the online save (/BCMOFF).MAREN (MARENCP, MARENUCP)
If tape swapping is required during the online save with//DUMP-PUBSET, it must be ensured that MAREN is not blocked by write I/Os on the home pubset. The files concerned should be moved to another pubset.MARENCP can be blocked if the following files reside on the home pubset:
MARENCAT (volume catalog)
MARENLOG (logging file)
MARENLMF/CP (location manager file)
SYSOUT file if MARENCP was started in diagnostic mode
MARENUCP can be blocked if the following files reside on the home pubset:
MARENLOG (logging file)
MARENLMF/CP (location manager file)
SYSOUT file (all messages connected with the console application are logged here)
The console application of MARENUCP ($MARENUCP) should not use more routing codes than those actually required (A, E, G, P, T).
ROBAR-CL
If tape swapping occurs during the online save, the save via ROBAR-CL can be blocked. To prevent this blockade, the following files must be moved to another pubset:SYSOUT file (all messages connected with the console application are logged here)
Trace file (if the ROBAR trace was enabled at the start for ROBAR-CL)
The console application of ROBAR-CL should not use more routing codes than those actually required (A, E, G, N, T, U).
Databases
In the case of databases (SESAM) the SYSOUT and logging files should not reside on the home pubset.
Restrictions for the FDDRL run
The following settings exist for the FDDRL run when an online save takes place:
The online save can only be performed with subtasks (FDDRL parameter PROCESS-JOBS=*BY-SUBTASKS).
All disks of the pubset must be saved at the same time. To permit this, the FDDRL parameter TASK-LIMIT and the NUMBER-OF-DISK-SETS operand must have the appropriate settings:
In the case of DUMP-PUBSET with SAVE-ENTITY=*SINGLE-DISK and COPY-PUBSET the TASK-LIMIT must be the same as the number of the home pubset’s disks.
In the case of DUMP-PUBSET with SAVE-ENTITY=*DISK-SET the NUMBER-OF-DISK-SETS and TASK-LIMIT are calculated as follows:
>Divide the number of disks by 4 and round up the result.This results in, for instance:
at least 1 disk set in the case of 1 to 4 disks
at least 2 disk sets in the case 5 to 8 disks
At startup all subtasks wait at a synchronization point for the simultaneous setting of the write lock (HOLD-IO) for all disks of the pubset. To ensure that all subtasks reach this synchronization point, each subtask must be started and receive the necessary resources. The following requirements must be met to permit this:
Every subtask can be started. No restrictions may exist (e.g. through the job class limit).
With
//DUMP-PUBSETa tape device is available to each subtask and a suitable volume can be mounted.