Troubleshooting
Problem
During a recent conversion to the DFSMSrmm Tape Management System, the
DFSMSrmm Support Mission came across a concept know as 'CYCLE ABUSE'
with respect to retention of GDG datasets. This is not a function of the
DFMSMrmm Tape Management System, but it is a concept that was being
applied by the tape management system that was being converted from.
Both Tape management systems were using a 'BYDAYSCYCLE COUNT' type of
retention. However, It was discovered that the previous Tape Management
System would actually identify the CYCLE retention that would keep the
datasets the longest and that CYCLE retention would be applied. This is
the concept that is referred to 'CYCLE ABUSE'. The architecture of the
DFSMSrmm Tape Management System does not have this function/concept
known as 'CYCLE ABUSE'. For a subset of these 'CYCLE ABUSE' tapes,
DFSMSrmm sets the retention to the CYCLE retention that would keep these
datasets the least amount of time. If a client wants to see the same
type of behavior in DFSMSrmm as what is referred to as CYCLE ABUSE(set
the oldest retention).
DFSMSrmm Support Mission came across a concept know as 'CYCLE ABUSE'
with respect to retention of GDG datasets. This is not a function of the
DFMSMrmm Tape Management System, but it is a concept that was being
applied by the tape management system that was being converted from.
Both Tape management systems were using a 'BYDAYSCYCLE COUNT' type of
retention. However, It was discovered that the previous Tape Management
System would actually identify the CYCLE retention that would keep the
datasets the longest and that CYCLE retention would be applied. This is
the concept that is referred to 'CYCLE ABUSE'. The architecture of the
DFSMSrmm Tape Management System does not have this function/concept
known as 'CYCLE ABUSE'. For a subset of these 'CYCLE ABUSE' tapes,
DFSMSrmm sets the retention to the CYCLE retention that would keep these
datasets the least amount of time. If a client wants to see the same
type of behavior in DFSMSrmm as what is referred to as CYCLE ABUSE(set
the oldest retention).
Symptom
There are 4 different possible scenarios that can occur:
1) - "Non-Mixed BYDAYSCYCLE for non-GDG datasets", which is when multiple
copies of the same tape dataset (with the exact same DSN but on
different volumes) are all getting the same BYDAYSCYCLE COUNT.
a) - This is the expected behavior and just uses the normal
BYDAYSCYCLE rules to retain datasets. The other Tape
Management SYSTEM and RMM should agree with each other in
this scenario.
2) - "Mixed BYDAYSCYCLE for non-GDG datasets", which is when multiple
copies of the same tape dataset (with the exact same DSN but on
different volumes), but different versions/copies of the dataset
are getting assigned different BYDAYSCYCLE COUNTs
a) - This is the scenario where RMM retains the datasets by the
lowest COUNT value, whereas the other Tape Management System
retains the datasets with the highest COUNT value.
3) - "Non-Mixed BYDAYSCYCLE for GDG datasets", which is when different
generations (belonging to the same GDG base) are getting the same
BYDAYSCYCLE COUNTs assigned.
a) - This works as expected in the vast majority of situations;
however, if there are multiple instances where generations
are written in non-chronological order (outside of normal
generation wrapping), consider changing the cycleby parameter
to use the create date exclusively if the retention for these
datasets does not match the other Tape Management System.
For example: GDG(CYCLEBY(CRDATE) DUPLICATE(KEEP))
4) - "Mixed BYDAYSCYCLE for GDG datasets", which is when different
generations (belonging to the same GDG base) are getting
different BYDAYSCYCLE COUNTs assigned.
a) - DFSMSrmms behavior appears to be the same as the other Tape
Management System.
copies of the same tape dataset (with the exact same DSN but on
different volumes) are all getting the same BYDAYSCYCLE COUNT.
a) - This is the expected behavior and just uses the normal
BYDAYSCYCLE rules to retain datasets. The other Tape
Management SYSTEM and RMM should agree with each other in
this scenario.
2) - "Mixed BYDAYSCYCLE for non-GDG datasets", which is when multiple
copies of the same tape dataset (with the exact same DSN but on
different volumes), but different versions/copies of the dataset
are getting assigned different BYDAYSCYCLE COUNTs
a) - This is the scenario where RMM retains the datasets by the
lowest COUNT value, whereas the other Tape Management System
retains the datasets with the highest COUNT value.
3) - "Non-Mixed BYDAYSCYCLE for GDG datasets", which is when different
generations (belonging to the same GDG base) are getting the same
BYDAYSCYCLE COUNTs assigned.
a) - This works as expected in the vast majority of situations;
however, if there are multiple instances where generations
are written in non-chronological order (outside of normal
generation wrapping), consider changing the cycleby parameter
to use the create date exclusively if the retention for these
datasets does not match the other Tape Management System.
For example: GDG(CYCLEBY(CRDATE) DUPLICATE(KEEP))
4) - "Mixed BYDAYSCYCLE for GDG datasets", which is when different
generations (belonging to the same GDG base) are getting
different BYDAYSCYCLE COUNTs assigned.
a) - DFSMSrmms behavior appears to be the same as the other Tape
Management System.
Cause
Our analysis of this issue has shown that the above scenarios can arise when a client is using an EDGUX100 exit to assign Management Value VRSes or EDGDEFxx deftable and they are coding DIFFERENT EXPDT=yyddd PARAMETER FOR SAME DATASET NAME in their JCL to assign a VRS/Management value and they are not using any actual dataset VRSes to assign retention. For example,
this would cause 2 different management values to be assigned from EDGUX100 or DEFTABLE:
.
DSN=A.B.C,EXPDT=99005
DSN=A.B.C,EXPDT=99200
DSN=A.B.C,EXPDT=99200
Resolving The Problem
The recommendation from the RMM support mission is to change the following.
.
GDG(CYCLEBY(GENERATION) DUPLICATE(KEEP))
To:
GDG(CYCLEBY(CRDATE) DUPLICATE(KEEP))
To:
GDG(CYCLEBY(CRDATE) DUPLICATE(KEEP))
Document Location
Worldwide
[{"Line of Business":{"code":"","label":""},"Business Unit":{"code":"","label":""},"Product":{"code":"SSAUSZ","label":"DFSMSrmm"},"ARM Category":[{"code":"","label":""}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions","Type":"MASTER"}]
Was this topic helpful?
Document Information
Modified date:
05 March 2024
UID
ibm17127683