Author Topic: ARSMAINT and OAM  (Read 3251 times)

Greg Ira

  • Full Member
  • ***
  • Posts: 240
    • View Profile
ARSMAINT and OAM
« on: February 10, 2012, 07:37:27 AM »
I didn't want to hijack the other the other thread regarding document holds so I'm starting a new one. 
In the other thread Ed stated "- Because the application group has an expiration of LOAD - arsmaint (or arsadmin unload) is able to call OAM to delete the objects as well."

I was a little suprised to read this as I've been going under the assumption that ARSMAINT only touches cache and indexes.  Does ARSMAINT really delete OAM objects?  I suppose it's possible if CMOD is issuing an OSREQ DELETE command but there's no mention of this in the manual.  We have a couple of users who tend to mix up the use of Expire by Storage manager and Expire by load so this would be useful to know.


Alessandro Perucchi

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1002
    • View Profile
Re: ARSMAINT and OAM
« Reply #1 on: February 13, 2012, 12:45:16 AM »
Hello Greg,

maybe the documentation does not describe exactly what arsmaint does. But it is certain that arsmaint touches the cache and the indexes (with all the document that are linked behind).

Meaning that if you have an expiration type:

  • Segment Type: The whole segment is "dropped", and all object in TSM/OAM/Cache/... are deleted
  • Load Type: Only the group of index that in this Load-ID is deleted with all associated objects in TSM/OAM/Cache/...


But CMOD gives the "order" to the Storage Manager to delete the documents. If the storage manager is not ready to delete the document itself (for any reasons), then it won't delete it immediately. But it will when he is ready to do it.

I'm from the Unix/Windows side of CMOD, and we don't use OAM, we use TSM. So what I'm saying here is maybe not entirely relevant for you. But you will see the idea behind:

Case one:
  Index life: 1 year
  Object life: 1.5 year
  Result: after 1 year the indexes are removed from CMOD, and TSM receives the order to delete, but for him he has still 0.5 years until he can delete the objects, so he won't do it now.

Case two:
   Index life: 1 year
   Object life: 0.5 year
   Result: Because TSM has a shorter retention time, after 0.5 year the objects are removed, but the indexes are still there... and when ARSMAINT is launched then the indexes are removed and gives to TSM the order to delete the objects, which are already removed 0.5 years ago.

Case three:
  Index life: 1 year
  Object life: event based + 1 month
  Result: After 1 year the indexes are deleted with arsmaint, and sends the signal to TSM to remove them, TSM because he is configured with event based signals, tries to remove the document right away, but because he has the rule to keep the document 1 additional month, he waits until that month is passed in to delete that document.


As you can see in all these cases, you need to have some synchronisation between Storage manager and CMOD for the retention. If nothing is synchronized, then you end end with a situation like Case 2... which is quite bad.

I hope I've answered a little bit your question and helped to clarify this mixed-up between the several layer of expiration.


Sincerely yours,
Alessandro
Alessandro Perucchi

#Install #Migrations #Conversion #Educate #Repair #Upgrade #Migrate #Enhance #Optimize #AIX #Linux #Multiplatforms #DB2 #Windows #Oracle #TSM #Tivoli #Performance #Audits #Customizing #Availability #HA #DR #JavaApi #ContentNavigator #ICN #WEBi #ODWEK #Services #PDF #AFP #XML