IBM Support

II14640: INFO APAR TO DOCUMENT AND CLARIFY CA RECLAIM SETTINGS FAQ

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • INTRAN

Error description

  • CA RECLAIM was released with z/OS 1.12. CA RECLAIM is designed
    to actively manage the Control Areas (CA) within a VSAM data set
    that did contain records at one point in time, but have been
    emptied by ERASE requests on all of the records.
    CA RECLAIM sets these CAs to be reused whenever possible and
    is a planned improvement to to overall VSAM processing.
    .
    CA RECLAIM applies to VSAM KSDSes, AIXes and Catalogs. There is
    no CA RECLAIM processing for ESDS, RRDS, VRRDS or LINEAR data
    sets.
    .
    The default settings for CA RECLAIM are as follows:
    .
      IGDSMSxx CA_RECLAIM(NONE)
      DATACLASS CA-RECLAIM - Defaults to YES on z/OS 1.12
    .
    To enable CA-RECLAIM, do the following:
    .
      IGDSMSxx CA_RECLAIM(DATACLAS)
    .
    This will enable CA RECLAIM on that system.
    .
    NOTE:*****************
    At this point, all VSAM data sets that show a value of YES on a
    IDCAMS Listcat output: CA-RECLAIM(YES) are enabled for CA
    RECLAIM processing. All KSDS, AIX data sets and Catalogs, unless
    specified to CA-RECLAIM(NO) via an ALTER or that had a SMS
    DATACLASS assigned during allocation with CA-RECLAIM set to
    NO will show as YES.
    .
    Here is why:
    The value for a specific data set as shown by an IDCAMS listcat
    in addition to the value in the SMS parmlib for CA_RECLAIM is
    what is checked when CA RECLAIM processing is determining
    whether it should incur CA RECLAIM for a particular data set.
    The listcat value must be YES and the SMS parmlib value must be
    DATACLAS.
    .
    To disable CA RECLAIM for a data set you can use IDCAMS ALTER
    NORECLAIMCA to alter the CA-RECLAIM value for that data set. Or
    if you wish to enable CA RECLAIM for a data set you can use an
    IDCAMS ALTER RECLAIMCA. Note that with the PTF for OA35288 you
    can do either IDCAMS ALTER commands with a generic input to
    change a number of data sets with one command.
    .
    The value of YES or NO in the SMS DATACLASS is only used when a
    dataclass is assigned to a data set during define processing. If
    a dataclass is not assigned during define processing then the
    data set will default to a value of CA-RECLAIM(YES) when a data
    set is defined. Note that changing the value in the SMS dataclas
    will only affect any new defines. Any existing data sets with
    that dataclass will reflect the value in the SMS dataclass at
    the time of the define.
    .
    Depending on the age of VSAM data sets, you may have some data
    sets that are not eligible for CA RECLAIM show a value on a
    listcat of CA-RECLAIM(YES). Data sets created prior to the
    installation of the PTF for OA26256 on z/OS 1.10, or data sets
    created on z/OS 1.9 or earlier releases may show a value of
    CA-RECLAIM(YES) for ESDS, RRDS, LINEAR VRRDS data sets.
    Installation of the PTFs for apar OA36052 will correct the
    listcat output.
    .
    CA RECLAIM does require additional control blocks. Prior to the
    PTFs for OA36033 if the data set was eligible for CA RECLAIM the
    control blocks would be obtained, regardless of whether the SMS
    PARMLIB value for CA_RECLAIM was NONE or DATACLAS. This could
    result in applications receiving S878 abends even though CA
    RECLAIM  was disabled at the system level. The PTFs for OA36033
    will only obtain the control blocks at open time if the data set
    is eligible for CA RECLAIM and the SMS parmlib value of
    CA_RECLAIM is DATACLAS. If the setting of the SMS parmlib value
    of CA-RECLAIM is NONE when a data set that is eligible for CA
    RECLAIM is opened, then no control blocks will be obtained.
    However, if the SMS parmlib value is changed via the SETSMS
    command to DATACLAS, then if the control blocks will be
    obtained as needed for data sets that do not currently
    have them, but are eligible for CA RECLAIM.
    .
    There is a tool available that will produce a one line listing
    of data sets that are currently eligible for CA RECLAIM. While
    you can run an IDCAMS LISTCAT LEVEL or LISTCAT CATALOG to get
    a list of data sets, either of these will also produce a large
    amount of output and also list data sets that are not eligible
    for CA RECLAIM.
    This tool can be downloaded from the following FTP site:
    ftp://public.dhe.ibm.com/servers/storage/support/software/dfsms/
    It is on this site as CARECLAM.JCL.CNTL.TRSD. It will need to
    be downloaded in binary mode to a data set with the following
    DCB attributes: LRECL=1024,RECFM=FB,BLKSIZE=6144,DSORG=PS .
    After downloading it will need to be untersed using AMATERSE.
    Note that when untersing the output data set will be a PDS, so
    you need to supply directory blocks for the output data set when
    untersing. A space allocation of (TRK,(1,1,6)) should be fine.
    If you have questions or concerns about this tool open an ETR
    to component 5695DF106.
    
    IDCAMS LISTCAT changes for CA RECLAIM.
    The first is the addition of CA-RECLAIM(YES). This indicates
    that the data set is eligible for CA RECLAIM processing when
    opened.
    
    The second change is that when a RECLAIM of a CA occurs,
    as a result of an ERASE request, 1 will be added to the
    number of SPLITS-CA for the data component.
    
    In addition, if the 'new' CA used for a CA split in the 'add to
    end' PUT processing is a reclaimed CA, the SPLITS-CA count will
    will also be incremented; otherwise the 'add to end' CA split is
    is still not counted as in previous releases after apar OA38887
    is installed.
    
    Including both the CA reclaims and the 'add to end' CA splits
    when the new CAs are reclaimed CAs in the SPLITS-CA count is
    necessary for many VSAM applications such as those that need to
    be aware that the index structure has changed.
    
    This means you may see an increase in the number reported for
    SPLITS-CA for the data component over that reported for previous
    releases.
    
    
    The third change is that 1 is added to number of REC-DELETED for
    the index component for the data set. This reflects the total
    number of times CA RECLAIM has occurred for this data set.
    Taking the SPLITS-CA value from the data component and
    subtracting the REC-DELETED value from the index component will
    give the number of CA splits that have occurred for the data
    component.
    
    The fourth change is that the value of REC-INSERTED for the
    index component will indicate the number of CA's that have been
    been reused.
    
    This INFO APAR will be updated as necessary to reflect the most
    common questions and answers.
    .
    Additional information can also be found in the following
    manuals:
    .
    z/OS V1R12.0 DFSMSdfp Storage Administration (SC26-7402-14)
    7.3.6 Defining Shareoptions and RLS attributes for data class
    .
    z/OS V1R12 DFSMS Using Data Sets (SC26-7410-10)
    In Chapter 10 - Optimizing VSAM Performance
    2.5.3.3.2 Enabling and Disabling CA Reclaim
    

Local fix

  • None.
    
    
    KEYWORDS:  CARECLAIM
    

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

  • APAR number

    II14640

  • Reported component name

    V2 LIB INFO ITE

  • Reported component ID

    INFOV2LIB

  • Reported release

    001

  • Status

    INTRAN

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2011-07-20

  • Closed date

  • Last modified date

    2012-03-29

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19N","label":"APARs - OS\/390 environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSSN3L","label":"z\/OS Communications Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]

Document Information

Modified date:
29 March 2012