CMOD data retention and external storage managers - Azure

[paynedr]

We currently are using TSM as the external storage manager with CMOD on AIX. We are moving to Azure cloud and will use Azure object storage as the external storage manager. With TSM, the migration of the data would reset the 'start' date for expiration of the object files, since TSM manages and ages the data based on the store/load date. We want to avoid this reset of course, so we need to understand how data migrated/loaded to the Azure object storage is managed in terms of expiration. If we keep expiration by segment, for example, will CMOD manage expiration of the object files based on the segment date, i.e., expire a segment table's worth of data from Azure storage when a whole segment AG table is expired and dropped? And if it is not managed that way, how is it?  Or would we need to migrate our expire by segment AGs to expire by load to make expiration work properly?
Thanks and I welcome any ideas and ESPECIALLY anyone with experience with using Azure.

[TRDFan]

I unfortunately ran into something like this in early 2020. rdate aka 'default value lowercase t' = segment date. I think they mentioned something about doing some kind of database update..like

1) take an export of app group tables
2) where doc_name = FAA123, set rdate='01/01/2021'  or something like that.

Unfortunately- the project got canceled due to you know what.

As far as Azure, I have played with CMOD/Azure using Cache storage, filesystem storage, but i havent tried azure object storage yet. It works pretty good. Look forward to moving this type of setup into production some day!

[Justin Derrick]

Can't help with an answer, but I'm just here to give moral support and raise my hand as being interested in the question.

If you're migrating to cloud storage, I'd almost consider reloading it to get some of the latest features - document hashes, docid's, encryption, etc.  At the same time, I'd be batching your documents up in multiple-gigabyte sizes and switch to expiration by load.

Also, I haven't looked at it lately, but I thought TSM has started supporting S3-compatible storage as well - maybe just add another level of storage there?  It depends heavily on your TSM infrastructure too...  So many questions...

-JD.