Escalation due to prohibition by a SYSIBM.SYSCOPY entry
In this case (if the installation option ESCALATE=YES)
BMC AMI Copy
escalates a FULL NO, FULL AUTO, or CHANGELIMIT request when it finds a SYSIBM.SYSCOPY entry that prohibits an incremental copy.
The following table shows the SYSIBM.SYSCOPY entries that cause escalation when ESCALATE=YES. BMC AMI Copy issues messages and return codes as shown in Escalating-incremental-copies-to-full-copies for these entries.
If the installation option ESCALATE=NO, BMC AMI Copy processes these requests as shown in Escalating-incremental-copies-to-full-copies.
Condition | Entry in SYSIBM.SYSCOPY |
|---|---|
This is the first copy since a REORG was performed. | ICTYPE = W or X |
This is the first copy since a LOAD was performed. | ICTYPE = R, S, Y, or Z |
This is the first copy since a point-in-time recovery was performed 1. | ICTYPE = P |
No full copy exists. | no F entry in ICTYPE |
The last copy job for this space was terminated or the last copy was an Instant Snapshot 2. | ICTYPE = T |
The most recent full copy is a DFSMS Concurrent Copy. | ICTYPE = F STYPE = C |
The IBM CHECK DATA utility LOG NO option is specified that places the table space in COPY-pending status and index spaces in REBUILD-pending status or COPY-pending status (if copyable). A RESETMOD YES copy is required before an incremental will be valid. | ICTYPE = D |
1 See Escalation-after-a-point-in-time-recovery.
2 BMC AMI Copy bypasses creating a full copy if the space has not been updated since the ICTYPE=T row was created.
Related topic