arsdoc delete question

[fnb4321]

   I have alot of large older documents that are no longer needed. If I run an arsdoc delete on these documents would it also free up the space/cache they were using ?

[demaya]

Yes.

[Justin Derrick]

Actually, no.

arsdoc delete only deletes index entries. 

You should be using arsmaint with the expiration options (-c for cache, -d for database).  Documents in TSM will expire on the schedule defined in the policies that the documents were stored under.  If your expiration type is load, CMOD will send TSM an explicit delete command to remove the load, but if the expire type is Segment or Document, TSM will expire the objects on it's own schedule.

-JD.

[Alessandro Perucchi]

I agree with Justin.

I hope that someday, when the last index is deleted with "arsdoc delete", CMOD will see it and remove the Load that was associated with it :-) But for the moment, Nope !

[jeffs42885]

What about an ARSADMIN UNLOAD?

This is how I do it

arsadmin unload -h$ODHOST -u$ODUSER -p$ODPW -g$APPLGRP -L$LOADID -Q

for the load ID, I usually just do the partial load ID from the sytem log, and then add -0-0 at the end of it.

From what I know, this should delete the indeces and the data. Someone please correct me if I am wrong.

[ewirtz]

Hi,
we have put retention logic outside OnDemand because of special requirements that cannot be taken out of the box.
We process the deletes of the loads with arsadmin unload. We take the loadids from message 87 to do the deletes.

regards

Egon

[Alessandro Perucchi]

What about an ARSADMIN UNLOAD?

This is how I do it

arsadmin unload -h$ODHOST -u$ODUSER -p$ODPW -g$APPLGRP -L$LOADID -Q

for the load ID, I usually just do the partial load ID from the sytem log, and then add -0-0 at the end of it.

From what I know, this should delete the indeces and the data. Someone please correct me if I am wrong.

Yes that's a good solution, the only problems, that I know,  that can arise... I say can, because in practice I've never had this case... but you should be aware of it:

Case 1
It is possible, ok only remotely possible, that you have 2 load ids with the same partial load ID, but with different dates. And by doing a 0-0, you take everything, even the one you didn't want to remove.

Case 2
It is possible that in one Load to have deprecated documents, and still relevant documents for the business, so with that approach, you will remove the relevant and not relevant document...


I just say that not to cause panic, but to have a clear view, and do some checks before doing a "arsadmin unload", because that removes documents forever (except if you have a backup of them somewhere). So this is a harmful command.
If you are sure, and 100% that this command will run as wanted, with exactly the document that you do not want anymore. Then fine. Otherwise be careful

Sincerely yours,
Alessandro

[Alessandro Perucchi]

we have put retention logic outside OnDemand because of special requirements that cannot be taken out of the box.
We process the deletes of the loads with arsadmin unload. We take the loadids from message 87 to do the deletes.

Hello Egon,

Now with the new "System Load" folder you don't have to parse the message 87 :-) you have it directly in the field Load_id :-)

Sincerely yours,
Alessandro

[ewirtz]

Hello Alessandro,

thanks for that info. Unfortunately we need informations that derive from the file name. So we still need the message 87 


Regards

Egon

[Justin Derrick]

Egon:

Do you think your document expiration logic could be useful to the rest of the CMOD community?  Consider writing an enhancement request that would cover your situation... 

-JD.

[pankaj.puranik]

Alessandro

I didn't understand the Case 2 you mentioned..

[ewirtz]

Hi Justin,

some of the reasons for an own solution:

1) we have criteria for retention logic that are not on application group level but on a grouping within the application group
2) one of the retention rules is deleting after x years at the end of the year

Everything could be done by dynamically setting and releasing holds. But these holds are on the index level and everything has to be done with additional 'hold' programming.

I think the whole is a design question as well. If you have a rule for a application group or part of an application group it's anough to store this information on that level and not on every index entry. But if you have a rule for an individual document you need to store it on document level = index level. These aspects are relevant for optimizing the delete performance.
 
regards

Egon

[Steve Bechtolt]

Why not use the CMOD Enhanced Retention Management add-on? This allows you to put a hold on individual documents (index records) which will prevent them from being deleted.  when arsmaint data expiration runs, only the documents (indexes and data objects) are deleted.

[ewirtz]

Hi Steve,
there are some reasons not to use it:
1 it costs money
2 you have to do a lot of 'setting and dropping hold' programming to fullfill special needs which is as much programming or more as an external solution.
3 the solution ist not so efficient because hold is on document level. Even if grouping is possible you have to go back to the document level in your programming

I think (2) s the most important thing.

regards

Egon