This is just a little overview of what I found out on how to purge data using ARSMAINT -o Function. Always review with IBM before taking any actions.
We are new to CMoD. We have been working with it for 6 months now and there are lots of things we are learning. When it was set up - ARSODF_EXPIRE_DAYS was set to high. This cause us to keep way too much data. Before we finally did a purge on the DST Table, it contained over 100 million rows. This required a drastic purge process.
After reading the manual on ARSMAINT - we thought we could use the following syntax ARSMAINT -o -t YYYY-MM-DD
This did not work. So we contacted Support who recommended the following process which did work.
1) Set ARSODF_EXPIRE_DAYS to how many days back you want to set the expiration date to. For example, if you set it to 10 then the expire date will be today-10 as a starting point
2) Cycle SOCKS address space to pick up the new Expire Days
3) Run ARSMAINT -o no need to include the -t the date is controlled by the EXPIRE DAYS parm
This was successful. We could see that ARSMAINT was now purging about 4 million rows in 7 minutes
Some of the other actions we took to ensure that it ran quickly and without locking issues
1) Shutdown all CMOD tasks. Leaving up only one SOCK address space where we would run ARSMAINT -o
2) Changed the locking to Tablespace locking for the duration of the window to do the purges on the DST/DRT/PPT
Once we were done, we restore locking back to where it was before Tablespace locking
We also used this Query on each table to see if we really had purged rows. Changing DST to DRT or PPT to get counts from those tables.
-- LIST ALL ENTRIES IN ODF TABLE BY DATE AND COUNT
--
SELECT DATE(DST_PROCESS_DT), COUNT(*)
FROM ARSUSER.ARSDFDST
WHERE DST_PROCESS_DT <= '2018-12-31-00.00.00.000000'
GROUP BY DATE(DST_PROCESS_DT)
ORDER BY DATE(DST_PROCESS_DT)
WITH UR;
This is what we did to resolve our issue of a large number of rows in our ODF Tables for DST/DRT/PPT
Hope this helps someone else.
Lizette