Reference: START command
The START command initiates the IMS Database Recovery Facility processing. The syntax and use of the START command is described here.
Syntax for START command
Parameters for START command
You can specify only one START command for a single execution, and it is the last command processed in the list. If you have specified any commands following the START command, they will result in errors and the process will end.
Use the following parameters with the START command.
- VERIFY(LIST,ALLOC,OPEN)
- This parameter specifies the VERIFY level that you want IMS Database Recovery
Facility to perform. When VERIFY is specified, no recovery or
output processing is performed. VERIFY is used to verify the recovery assets that are needed to
perform the requested action.
You do not need to stop the database to use the VERIFY parameter. However, if you do not stop the database when using VERIFY, the results may differ from an actual recovery that is performed when the database is stopped. For example, the list of log data sets that are needed for a recovery do not include the active log when using VERIFY, and you can do a new change accumulation or an image copy when the database is stopped.
If you specify VERIFY without any options, it defaults to VERIFY(LIST).
Note: When verifying logs, if the databases are allocated or updated during the VERIFY, only archived logs can be verified. In this case, the recovery (without VERIFY) will show a different number of logs since the databases will be deallocated by recovery. - ERROR(CONT,STOP)
- Tells IMS Database Recovery
Facility whether
to stop or continue when an error authorizing or recovering a DBDS
named in the recovery list is encountered.
- CONT
- Indicates that recovery of DBDS entries in the recovery list is to continue, other than the one for which an error was encountered.
- STOP
- Indicates that the IMS Database Recovery Facility is to shutdown all recovery tasks and end processing. This is the default.
- READNUM(nn [,tn])
- You can use this parameter to override the values set in the FRXDRFxx member
for the execution of this START command. Note: If the values of either nn or tn are omitted or set to zero, the default values are imposed. The values entered here have precedence; they override the system defaults and any override values set in the FRXDRFxx member.Note: For a more detailed description of this parameter, see Environmental control statements.
- RCVTIME(timestamp,TSR,PITCA,PITR(CHECK,NOCHECK))
- You must specify the RCVTIME parameter whenever you want to:
- Perform a timestamp recovery - RCVTIME(timestamp,TSR)
- Perform a point in time recovery - RCVTIME(timestamp,PITR)
- Perform a point in time recovery using a point in time change accumulation data set -RCVTIME(timestamp,PITCA)
The RCVTIME parameter is optional when you want to create an incremental image copy. If OUTPUT(ICR) is specified without RCVTIME, the image copy is created to the current time. If RCVTIME(timestamp) is specified, the image copy is created to the specified time stamp. The state of the database at the specified (or implied) time determines the type of image copy that is created:- If the database is allocated, a concurrent image copy is created.
- If the database is not allocated, a batch image copy is created.
For more information about the incremental image copy function, see Environmental control statements, OUTPUT parameter.
- timestamp
- Timestamp format reference: Reference: Timestamp format.Restriction: If your z/OS® system adjusts leap seconds in the STP (Sever Time Protocol) environment, the timestamp value specified for RCVTTIME, except for PITCA, is corrected using the leap second offset value (CVTLSO) on z/OS when performing the IMS Database Recovery Facility job. Then, the IMS log record to be applied is selected by comparing it with the timestamp value on the IMS log record. Since it is not the leap second offset value when the IMS log record is created, if there is a change in the leap second offset value between the time the IMS log record is created and the time the IMS Database Recovery Facility job is executed, you need to specify the timestamp value in consideration of the change.
- TSR
- Use time stamp recovery (TSR) to perform a time stamp recovery. When a TSR is
performed, the IMS Database Recovery
Facility checks the
status of the databases being recovered to make sure that they are not allocated
or in use at the specified timestamp. You must have issued /DBRecovery commands
or UPDATE DB commands with the START(QUIESCE) keyword from all online IMS
systems which had them in use, and there must not be any batch jobs updating the
databases at the time specified by the RCVTIME parameter. A listing of the RECON
can help you determine valid timestamps for performing a TSR. There must be no
ALLOC record for any database data set or area being recovered that spans the
recovery time.
When performing a TSR recovery, IMS Database Recovery Facility verifies that all related DBDSs are also being recovered to the same time. For each related DBDSs which are not being recovered, message FRD6024A is issued to warn you of this condition. Recovery fails if any related DBDSs are not also being recovered.
Input which is available for use by TSR is:- A prior image copy, concurrent or batch
- A complete change accumulation which has a stop time earlier than the recovery timestamp specified
- Archived logs (SLDS or RLDS) which have a stop time later than the stop time from the input image copy and earlier than the recovery timestamp specified
- If the input image copy is a concurrent image copy, then log data prior to the image copy stop time might be needed in order to resolve any in-flight work at the time the image copy was taken
- PITR
- Use point-in-time recovery (PITR) to perform a point-in-time recovery. When a PITR is performed,
the databases being recovered can be in any state; they may be allocated or unallocated. There is no
restriction on database allocation status if point-in-time recovery is selected. All committed
updates, up to and including the specified recovery time, are applied to the database data sets and
areas in the recovery list. If you specify the PITR parameter, the recovery time can be specified to
any time before the current time.
When performing a PITR recovery, IMS Database Recovery Facility verifies that all related DBDSs are also being recovered to the same time. For each related DBDSs which are not being recovered, message FRD6024A is issued to warn you of this condition.
Input which is available for use by PITR is:- A prior image copy, concurrent or batch
- A change accumulation which has a stop time earlier than the recovery timestamp specified, but only if there is a deallocation point (DBRECOVERY command) between the CA stop time and the PITR recovery time. This is the only way for the IMS Database Recovery Facility to ensure that all database updates on the CA data set are committed
- Archived logs (SLDS or RLDS) which have a stop time later than the stop time from the input image copy and earlier than the recovery timestamp specified.
- If the input image copy is a concurrent image copy, then log data prior to the image copy stop time may be needed in order to resolve any in-flight work at the time the image copy was taken
When you specify PITR, you can also specify the following options.- CHECK
- Use CHECK to indicate that recovery fails when IMS Database Recovery Facility discovers that there are related DBDSs which are not being recovered to the same time. This processing ensures that DBDSs are not recovered to inconsistent times, causing integrity issues. This is the default value.
- NOCHECK
- Use NOCHECK to allow recovery to continue when IMS Database Recovery Facility discovers that there are related DBDSs which are not being recovered to the same time. Specifying NOCHECK means that you are responsible for ensuring related DBDSs are recovered consistently.
- PITCA
- Use point in time change accumulation (PITCA) to perform a point in time recovery, using a point
in time change accumulation data set as input. IMS High Performance Change
Accumulation Utility is able to generate a point in time change accumulation file
to a point in time where databases are still online. This CA file is called a PIT
HPCA and contains only committed updates. This type of CA is marked invalid in the
RECON to prevent usage by other utilities. Use PITCA to perform a point in time
recovery using only a prior image copy and a PIT HPCA as input. No additional data
sets containing log updates are used as input to this recovery.
When IMS High Performance Change Accumulation Utility marks the PIT HPCA file invalid in the RECON data sets, DBRC switches the contents of the RUN and START time fields in the record. Therefore, the timestamp you specify on the RCVTIME parameter must be the RUN time of the CA record as recorded by DBRC. In order for the IMS Database Recovery Facility to select the PIT HPCA file, the CA record must be marked ERR and the CA data set name must have the suffix ".HPCAP".
Input which is available for use by PITCA is:- A prior image copy, concurrent or batch
- A PIT IMS HP Change Accumulation Utility point in time change accumulation data set which has a RUN time matching the recovery time specified, is marked in ERR, and has a suffix of “.HPCAP”
- RCVTYPE(LASTIC,LASTPITCA)
- The RCVTYPE parameter is used whenever you want to recover using
only:
- A prior image copy, it may be concurrent or batch
- An IMS HP Change Accumulation Utility point in time change accumulation data set which has a RUN time matching the recovery time specified, is marked in ERR, and has a suffix of “.HPCAP”
- LASTIC
- Use last image copy (LASTIC) to perform a recovery using only the latest usable batch image
copy. No logs or change accumulation data sets are used.
The latest image copy where the database data set (DBDS) area was not allocated for the time the image copy was taken are used for the recovery. There are several types of image copies. Batch is one where the DBDS area has been stopped. A concurrent image copy (CIC) can be taken while the DBDS area has not been stopped. However, a CIC can also be taken while the DBDS area has been stopped. It is still recorded as a CIC. Any type of image copy taken while the DBDS area has been stopped are used for a LASTIC recovery.
LASTIC is another way of specifying a time stamp and performing either a full recovery or a time stamp recovery (TSR). A new parameter, RCVTYPE, allows for either LASTIC or LASTPITCA. A LASTIC recovery uses only the image copy. If there were changes made after the IC was taken, then this is a TSR. Otherwise, it is a full recovery.
Unlike RCVTIME, recoveries with LASTIC can be to different times and can be full recoveries or time stamp recoveries. The RECOV record that is recorded to DBRC reflects this. For time stamp recoveries (including PITR), the CHECK option causes IMS Database Recovery Facility to fail the recovery when there is a DBDS area that should also be recovered to the same time but is not. When NOCHECK is specified, IMS Database Recovery Facility does not make this check. Because LASTIC does not have a constant RCVTIME and the resulting recoveries can be a mixture of full and time stamp recoveries, CHECK is not possible for LASTIC. Although NOCHECK is implied, CHECK and NOCHECK are not allowed with LASTIC. An error message is issued if either is specified.
The use of RCVTYPE(LASTIC) is:- Mutually exclusive with RCVTIME
- Allowed for OUTPUT(PRO | DUP | BOTH)
- Not allowed for OUTPUT(ICR | ICRCA)
- LASTPITCA
- Use LASTPITCA to perform a point in time recovery using an image copy and the last point in time
change accumulation (PIT HPCA) as input. No log data sets are used.
Using LASTPITCA is another way of specifying a timestamp and the recovery is always a point in time recovery (PITR). A new parameter, RCVTYPE, allows for either LASTIC or LASTPITCA.
The RECOV record that is recorded to DBRC reflects the type of recovery. For time stamp recoveries (including PITR), the CHECK option causes IMS Database Recovery Facility to fail the recovery when there is a database data set (DBDS) area that should also be recovered to the same time but is not. When NOCHECK is specified, IMS Database Recovery Facility does not make this check. Because LASTPITCA does not have a constant RCVTIME and the resulting recoveries can be a mixture of full and time stamp recoveries, CHECK is not possible for LASTPITCA. Although NOCHECK is implied, CHECK and NOCHECK are not allowed with LASTPITCA. An error message is issued if either is specified.
The use of RCVTYPE(LASTPITCA) is:- Mutually exclusive with RCVTIME
- Allowed for OUTPUT(PRO | DUP | BOTH)
- Not allowed for OUTPUT(ICR | ICRCA)
- ICNUM(nn [,tn])
- The system defaults and any override values you set in the FRXDRFxx member
for nn and tn are overridden
by the values supplied in this START command. Note: If you omit or set the values of either nn or tn to zero, the default values in FRXDRFxx are imposed. The values you enter here take precedence; they override the system defaults and any override values set in the FRXDRFxx member.Note: For a more detailed description of this parameter, refer to Environmental control statements.
- LOGNUM(nn [,tn])
- The system defaults and any override values you set in the FRXDRFxx member
for nn and tn are overridden
by the values you supply in this START command. Note: If you omit or set the values of either nn or tn to zero, the default values are imposed. The values entered here have precedence; they override the system defaults and any override values set in the FRXDRFxx member.For a more detailed description of this parameter, refer to Environmental control statements.
- STACMD(OFFLINE,LOCAL((imsid)),GLOBAL)
- Use STACMD to tell IMS Database Recovery
Facility what the disposition of
the DBDS should be after it has been recovered.
STACMD is not issued when VERIFY is also specified. The following are the subparameters of
STACMD:
- OFFLINE
- Indicates that after recovery of DBDS entries in the recovery list, the resource is to be kept offline. This is the default.
- LOCAL((imsid))
- Indicates that after recovery of DBDS entries in the recovery list, the START command is issued against the specified IMS subsystem , imsid.
- GLOBAL
- Indicates that after recovery of DBDS entries in the recovery list, the
START command is issued with the GLOBAL keyword and applies
to all sharing subsystems.Note: IRLM must be active when the GLOBAL keyword is used. If IRLM is not active, the command is rejected.
Note: The START command will not be issued for databases for which the recovery was not successful. Also, if the indexes for a database are recovered using the ADD IB() command and either the primary database or the indexes for a database have an error in recovery, IMS Database Recovery Facility will not issue the START command for either the primary database or the indexes for a database. - DBRCMD(NONE,LOCAL((imsid)),GLOBAL,NOFEOV,SWIOLDS)
- Use DBRCMD to tell IMS Database Recovery
Facility to issue the DBRECOVERY
command before attempting to recover the DBDSs in the recovery list. DBRCMD is not issued when VERIFY is also specified.
- NONE
- Indicates that the DBRECOVERY command should not be issued for any entry in the recovery list. This is the default.
- LOCAL((imsid))
- Indicates the DBRECOVERY command is issued on the specified IMS subsystem,
imsid.
- NOFEOV
- Indicates that the NOFEOV parameter is specified on all /DBR commands that are issued, including the last one. This means that a log switch is not done.
- SWIOLDS
- Indicates that after all databases have been taken offline by using the /DBR command, a /SWI OLDS command is issued on the specified IMS system.
- GLOBAL
- Indicates that the DBRECOVERY command is issued with the GLOBAL keyword and
applies to all sharing subsystems which have resources registered to DBRC.Note: IRLM must be active when the GLOBAL keyword is used. If IRLM is not active, the command is rejected.
If the GLOBAL keyword is specified, DBRC sets the Prohibit Authorization flag in the RECON data set to ON (PROHIBIT AUTH = ON) to prevent any further authorization of the database.
However, before calling Index Builder, IMS Database Recovery Facility checks the Prohibit Authorization flag in the RECON for the DBDS to be recovered, and if it is ON, issues the CHANGE.DB AUTH command to turn the flag OFF. In this case, in the case of HALDB, the command is issued to the HALDB master. Therefore, if the IMS Database Recovery Facility jobs are divided per partition for a HALDB for which the Prohibit Authorization flag is ON, and if those jobs are executed in parallel with ADD IB also specified, each IMS Database Recovery Facility job will issue a CHANGE.DB AUTH command to DBRC for the same DB (HALDB master), causing a conflict and resulting in authorization to fail. As a result, ABEND U0385-0000001B will occur.
To prevent this problem from occurring, do not issue the /DBR GLOBAL command using DBRCMD from IMS Database Recovery Facility, but instead enter the /DBRECOVERY GLOBAL command directly to IMS with the NOPFA option before running IMS Database Recovery Facility, and then run the multiple IMS Database Recovery Facility jobs divided into partitions in parallel. This method prevents the Prohibit Authorization flag in the RECON data set from being turned ON, so the CHANGE.DB AUTH command is not issued and no contention occurs.
- NOFEOV
- Indicates that the NOFEOV parameter is specified on all /DBR commands that are issued, including the last one. This means that a log switch is not done.
- SWIOLDS
- Indicates that after all databases have been taken offline by using the /DBR command, a /SWI OLDS command is issued on all active IMS systems.