Recovers before or after images of historical resource definitions from the journal.
<CCV210>
<Recover>
<LocationCriteria>
<LocationType> Journal </LocationType>
</LocationCriteria>
<ObjectCriteria>
<ListCount> element_count </ListCount> 1
<ListElement> 2
<ObjName> resource_name </ObjName>
<ObjGroup> resource_group </ObjGroup>
<ObjType> resource_type </ObjType>
<ObjectInstance> object_instance </ObjectInstance>
</ListElement>
More list elements…
</ObjectCriteria>
<ProcessParms>
<RecoverImage> Before | After </RecoverImage> 3
<RollbackOption> No | Yes </RollbackOption> 4
</ProcessParms>
</Recover>
</CCV210>
You cannot recover changes to CICSPlex SM relationships, such as Add and Remove (that is, changes to xxxINGRP resource definition types). However, you can recover changes to the resource definition types List, ResGroup, and ResDesc.
If the resource type is ResDesc or List, then the <ObjGroup> element is ignored, and may be omitted.
If no current resource definition exists (it has been deleted), then the after image of the most recent of the selected changes must be empty (reflecting the deletion).
If you omit the <RollbackOption> element when recovering before images, the before images are recovered with no rollback processing.
When recovering after images, omit the <RollbackOption> element; if you specify this element, it is ignored.
<CCV210>
<Recover>
<OutputData>
<ReturnCode> return_code </ReturnCode> 1
<ReasonCode> reason_code </ReasonCode>
<TaskNo> CICS_task_number </TaskNo>
<ListCount> element_count </ListCount>
<ListElement> 2
<ReturnCode> return_code </ReturnCode>
<ReasonCode> reason_code </ReasonCode>
<ObjName> resource_name </ObjName>
<ObjType> resource_type </ObjType>
<ObjGroup> resource_group </ObjGroup>
<Config> CICS_configuration </Config>
<ObjectInstance> object_instance </ObjectInstance>
<Action> CREATE | UPDATE | DELETE | SKIP </Action> 3
</ListElement>
More list elements…
</OutputData>
</Recover>
</CCV210>
When recovering before images, the Recover command skips all except the oldest of the selected changes for a resource definition.
When recovering after images, the Recover command skips all except the most recent of the selected changes for a resource definition.
API command (READ access authority):
The following tables describe combinations of return and reason codes that are specific to the Recover API command. For a complete list of reason codes that can be generated by this and other API commands, see Reason codes.
The following table describes rollup return and reason codes for the entire command:
Return code | Reason code | Description |
---|---|---|
04 | EB | Some of the objects failed recovery. |
08 | EC | All of the objects failed recovery. |
The following table describes return and reason codes for each list element:
Return code | Reason code | Description |
---|---|---|
04 | CD | Resource definition already in the state required for recovery. |
04 | E5 | Recovery skipped for ineligible duplicate. Either:
|
08 | 03 | BAImage object not found in journal. |
04 | E6 | Recovery skipped deletion of non-existent definition. To recover an empty image (the before image of a creation, or the after image of a deletion), the Recovery command was going to delete the current resource definition. However, the resource definition no longer exists, so the Recover command performed no action. |
08 | E7 | Recovery failed because the rollback chain was
broken. This reason code identifies the BAImage object that would have been recovered if the rollback chain was unbroken. Reason code E9 identifies the BAImage object that broke the rollback chain. |
08 | E8 | Object data inconsistent with the object instance
BAImage. Either:
|
08 | E9 | Recovery rollback chain broken by this BAImage
object. The before image of this BAImage does not match the after image of the next most recent selected BAImage for the resource definition. |
08 | EA | Recovery failed because the target CICSPlex® SM resource group for recovery contains a different version of this resource definition. |
For details on how the CICS® Configuration Manager ISPF dialog interface uses the Recover command, see Recovering historical versions of multiple resource definitions.