Well if you need to change it, that's means basically to change the stop/start fields from arsseg table according to the new field, the bit field of the field you want to change to the new field that contains the date for the segment field. And the new date field must be EXACTLY the same date field of the original date field. (date (old format) -> date (old format) // date -> date // date/time (old format) -> date/time (old format) // date/time -> date/time)
And potentially all stop/start entries in the ARSLOAD table if you have a retention load type.
In addition to that, all the LoadID in your System Log will be wrong, so the usage of "arsadmin unload" will not work correctly.
So even if it is possible, I will not advice to do that. Not at all. If you REALLY want to change your segment field, my advice would be to create a new application group, with exactly what you need, and begin to archive documents in this new AG. Have your folder mapped to this new AG in addition to the current AG.
The current (old) AG is considered Read-Only, and when no documents are inside anymore (expired), then you can remove it.
Or the other possibility, which is quite expensive would be to do an AG migration to a new AG. This can be done in 2 ways:
1) Export every load ID from the original AG and load in the new AG
2) Create a new AG, and copy the segment tables from the old to the new AG (arstblsp is your friend) and then in TSM (or your storage manager) to copy the content of the files to the new location. For TSM you could rename the filespace for that.
Of course all these short suggestions means that you have a real good knowledge of how CMOD works in order to not break anything and crash your archive.
So if you don't understand how to proceed on my suggestions, then I would suggest:
- either the new AG creation and switch of the load to the new AG, and let the old AG die slowly
- Or export every load ID from the original AG and load it in the new AG
But in any case try to avoid hack CMOD if you don't know what you are doing, because nobody will save you if something goes bad. And IBM Support won't support you.
In any cases, whatever solution you choose, BACKUP BACKUP BACKUP TEST TEST TEST !!! :-D
