ARSMAINT has lmit to expire loadid per time

[teera_aoo]

I am using ARSMAINT to expire documents that have reached the aging criteria as defined in the Application Group in CMOD 10.1.0.3.


Command:
arsmaint -c -d -u admin -p xxxx -n 0 -x 0 -g MY-APPGROUP

However, it seems that there is a limit to the number of load IDs that can be expired at one time.

For example, if 1,000 documents meet the aging criteria for expiration in CMOD, the first execution of ARSMAINT will expire only the first 100 load IDs. The next execution will expire load IDs 101–200, and so on, until all 1,000 load IDs are expired.

I'm unsure whether this behavior has been previously observed or if IBM has issued any notice regarding this change in the ARSMAINT program. Additionally, I haven't found any new parameters that would allow an increase in the limit for the number of load IDs expired per execution.

# arsmaint
ARS1201I Usage: arsmaint [-c [-n <min>] [-x <max>]] [-d] [-D <pct>] [-e] [-f <full>] [-g <name>] [-i] [-I <od_inst>] [-L] [-m] [-o] [-r] [-R] [-t <yyyy-mm-dd> [-u <userid>] [-p <passwd>]]
        Version:  10.1.0.3
        -c Expire Cache
        -d Expire Database
        -D <pct> Threshold of load being held before reloading
                 (defaults to 0% - not reloaded)
        -e Migrate Database Tables
        -f <full> Cache Full - When to send alert message (defaults to 95%)
        -g <name> Application Group Name (Defaults to all)
        -h <od_inst> OnDemand Instance Name (same as -I)
        -i Expire Migrated Imported Database Tables
        -I <od_inst> OnDemand Instance Name (same as -h)
        -L Update load id table with application id
        -m Migrate Cache
        -n <min> Min cache threshold percentage (Only for -c, Defaults to 80%)
        -o Expire OnDemand Distribution Facility
        -p <passwd> OnDemand Passwd Stash File (Only for -t)
        -r Database Statistics
        -R Reload Resources
        -s Cache Filesystem statistics
        -t <yyyy-mm-dd> Date To Expire/Migrate (Defaults to Today)
        -u <userid> OnDemand Userid (Only for -t)
        -v Verify/Validate Cache Filesystems
        -x <max> Max cache threshold percentage (Only for -c, Defaults to 80%)

[Justin Derrick]

I've never seen this behaviour before -- in my experience, arsmaint has always been happy to wipe out thousands of loads at once, clearing out an entire App Group if the data was old enough.

There's also a patch n 10.5.0.1 for an expiration issue:

      PH22616 - When an Application Group has over 5000 loads to expire that
                are under implicit hold, arsmaint -cd -g AGName will go into
                an infinite loop

-JD.

[enelson]

I see the same behavior on multiplatform 10.5.0.8 as we see a 456 msg showing 100 loads expired, then it will expire those loads and move on to the next group where another 456 msg will show 100 loads and continue on.

[mayank81089]

In our case we have not seen any such behavior either as it is flushing load ids which are due to be removed irrespective of any fixed number like 100 

CMOD 10.5.0.5

I remember it not working at all post CMOD upgrade and then we followed below IBM technote which resolved our problem and it started working again.

https://www.ibm.com/docs/kk/cmofm/10.5.0?topic=linux-creating-arscache-file-instance