DIRMC, and what are the side effects of directories expiring before files?

[wrkqvms]

(First post ever - I apologize if it's not the correct category for this).

Greetings.
Due to a business need I've set up a management class with NOLIMIT in both version count and retain time. It was intended to be used only for a particular group of documents.
When researching why all my directories rebound themselves to it, I've discovered the DIRMC setting, and its consequences.

I'm running TSM 6.3.

As the documentation is far from helpful, could you please help me find answers to the following questions.



* Is it correct that DIRMC always affects the whole node and there is no way to assign different MCs to different directories on the same node?

* A new "version" of the directory is backed up whenever a backup runs and files inside are modified, right?

* The directory backup is used for the GUI, and for storing permissions/ACLs, right?

* Does the "file disappears from GUI once the directory expires" issue mentioned in answers on this forum affects only the Point In Time mode, or also the "Show all inactive" mode?

* What happens when I have an inactive file inside a directory of VEREXISTS=3, and there have been for example five new versions of the directory backed up since the deletion of the inactive file? Does the inactive file disappear from the GUI too?

* Do I understand right, that no matter if the file's directory expired or not, it is always possible to retrieve the file via the full path in the commandline client until the file expires?

* Do these "disappearances" affect QUERY BACKUP too, so will I have to remember and type the full path to file, or will it always be "findable" via the command line as long as it is not expired?



Yes, I'm trying to "test out" the answers, but it'll take a few days to get an appropriately "expired" structure.
That's why I'd be grateful for your help.

With best regards,
W.

 

[moon-buddy]

To answer a part of your question:

DIRMC can be applied as a whole or for disks or for directories. It is how you enter the DIRMC on he OPT file (I assume you are running the BA on Windows (?)).

Example:

Include "*:\...\DIR1" DIRMC

 

[wrkqvms]

Yes, on Windows. And if you really can get it to work like you quoted, I think you forgot to share some other configuration info with me.

To reiterate:
NEVER_EXPIRES = management class I want to use for the documents in one particular path; as it offers longest (infinite) retain, the directories default to this class.
ONEYEAR = my default management class.
ONEWEEK, ONEMONTH = other managementclasses, will use them for example reasons.
DIRMC = a dsm.opt command to change the management class for a directory.

DSM.opt:
include "E:\SpecialFiles\...\*" NEVER_EXPIRES
Result:
All directories on the node = NEVER_EXPIRES (as that's the one with longest retain)
E:\SpecialFiles subtree (files and directories) = NEVER_EXPIRES
Rest of the files = ONEYEAR (the default class)

DSM.opt:
DIRMC ONEMONTH
include "E:\SpecialFiles\...\*" NEVER_EXPIRES
Result:
All directories on the node = ONEMONTH
E:\SpecialFiles subtree (only files, NOT directories) = NEVER_EXPIRES
Rest of the files = ONEYEAR (the default class)



Trying to follow your example:

DSM.opt:
include "E:\SpecialFiles\...\*" DIRMC
Result:
ANS9989W Management class DIRMC specified on the INCLUDE statement in dsm.opt at line 12 does not exist.
All directories on the node = NEVER_EXPIRES (as that's the one with longest retain)
E:\SpecialFiles subtree (only files, NOT directories) = ONEYEAR (the default class)
Rest of the files = ONEYEAR (the default class)

DSM.opt:
include "E:\SpecialFiles\...\*" DIRMC ONEMONTH
Result:
ANS9989W Management class DIRMC specified on the INCLUDE statement in dsm.opt at line 12 does not exist.
All directories on the node = NEVER_EXPIRES (as that's the one with longest retain)
E:\SpecialFiles subtree (only files, NOT directories) = ONEYEAR (the default class)
Rest of the files = ONEYEAR (the default class)

DSM.opt:
include "E:\SpecialFiles\...\*" ONEWEEK DIRMC ONEMONTH
Result:
All directories on the node = NEVER_EXPIRES (as that's the one with longest retain)
E:\SpecialFiles subtree (only files, NOT directories) = ONEWEEK
Rest of the files = ONEYEAR (the default class)

DSM.opt:
include "E:\SpecialFiles\...\*" ONEMONTH
include "E:\SpecialFiles" ONEWEEK
Result:
All directories on the node = NEVER_EXPIRES (as that's the one with longest retain)
E:\SpecialFiles subtree (only files, NOT directories) = ONEWEEK
Rest of the files = ONEYEAR (the default class)

As far as I can tell, TSM ignores 3rd and further "parameters", and interprets the 2nd as management class name.
It also ignores management class specified for a directory, in favour of the global DIRMC setting.
The node-global DIRMC command seem to be the only way to alter the directory management class.



So...

can anyone confirm or deny whether I can still restore an unexpired file from commandline when the directory it was in expired and GUI doesn't show it anymore?

Best regards,
-- W.

 

[drivechip]

I do not have the perspective anymore by your provided DSM.opt alternatives. When you not provide any management class for directories (backup operation) with the dirmc command the management class with the longest retention will be applied to your directories. When there are multiple with the same value the fist in alphabetical order is used. This means that it should not be problem that a directory expires as long as files are active in it as long you didn't overwrite it. I do not see a need for backups to apply a specilized dirmc as long as you don't need another copy destination.

This is the reason why all your directories were rebounded when you introduced a management class with no limit settings.

For archives it works another way. As far as I know the directory doesn't expire as long as any files are archived and retained in it.

I remember that there is a documentation about the selection of management class for directories by TSM and the expiration. Unfortunately I do not find it anymore. Maybe sombody else can confirm that.

Yes, you should be able to restore backuped files from already expired top directories by using dsmc. Unfortunately I do have tested it yet.

 

[hogmaster]

Yes, you can restore the file even when the directory is gone, the path is part of the file object, all information store with the directory , like access date and rights will be gone, but the file is still available, try to restore from the command line.

Which tsm version are you using?

 

[moon-buddy]

Trying to follow your example:

DSM.opt:
include "E:\SpecialFiles\...\*" DIRMC
Result:
ANS9989W Management class DIRMC specified on the INCLUDE statement in dsm.opt at line 12 does not exist.
All directories on the node = NEVER_EXPIRES (as that's the one with longest retain)
E:\SpecialFiles subtree (only files, NOT directories) = ONEYEAR (the default class)
Rest of the files = ONEYEAR (the default class)

If you look at the error, it will tell you right away that you have not defined any management class called DIRMC - define it and all is well.

 

[wrkqvms]

TSM 6.3.

My problem is that my "longest retention" class has NOLIMIT for all four parameters. That is, unlimited number of versions, unlimited retention time.
This is appropriate for this special data (which changes rarely, but all versions have to be preserved), but it is extremely unappropriate for directories.
I don't ask for separate DIRMC per location, moon-buddy claimed it was possible.

All I need to know is whether I can safely set DIRMC to ONEYEAR (my default management class, so enough for all other files other than these specials)
and will still be able to restore these ancient specialfiles ten years from now when their directory object is gone.

Hogmaster, sounds great, I prefer commandline to the GUI anyway.
One last question - would I need to "remember" and type the whole path for such a restore, or will QUERY BACKUP with wildcards show me these files?
I *think* I've read that QUERY BACKUP doesn't need the preserved directories (unlike GUI), but I can't find it now.

If you look at the error, it will tell you right away that you have not defined any management class called DIRMC - define it and all is well.

DIRMC is not a management class, it is a DSM.opt parameter. - http://pic.dhe.ibm.com/infocenter/tsminfo/v6r3/topic/com.ibm.itsm.client.doc/r_opt_dirmc.html
And this option was what I was talking about.

Thank you and regards,
-- W.

 

[moon-buddy]

TSM 6.3.

My problem is that my "longest retention" class has NOLIMIT for all four parameters. That is, unlimited number of versions, unlimited retention time.
This is appropriate for this special data (which changes rarely, but all versions have to be preserved), but it is extremely unappropriate for directories.
I don't ask for separate DIRMC per location, moon-buddy claimed it was possible.

All I need to know is whether I can safely set DIRMC to ONEYEAR (my default management class, so enough for all other files other than these specials)
and will still be able to restore these ancient specialfiles ten years from now when their directory object is gone.

Hogmaster, sounds great, I prefer commandline to the GUI anyway.
One last question - would I need to "remember" and type the whole path for such a restore, or will QUERY BACKUP with wildcards show me these files?
I *think* I've read that QUERY BACKUP doesn't need the preserved directories (unlike GUI), but I can't find it now.


DIRMC is not a management class, it is a DSM.opt parameter. - http://pic.dhe.ibm.com/infocenter/tsminfo/v6r3/topic/com.ibm.itsm.client.doc/r_opt_dirmc.html
And this option was what I was talking about.

Thank you and regards,
-- W.

Then, you can't use the syntax that I have shown you.

DIRMC is used differently. Define a new management class and apply it to the syntax I sent earlier and this should work. By the way, I have been using this syntax for years now and all works. The management class - regardless of what the default is - is applied on the directory specified at.

 

[wrkqvms]

Then, you can't use the syntax that I have shown you.
DIRMC is used differently. Define a new management class and apply it to the syntax I sent earlier and this should work. By the way, I have been using this syntax for years now and all works. The management class - regardless of what the default is - is applied on the directory specified at.

Yes, but the management class you specify on INCLUDE line does not affect the directories themselves, only files inside those directories!
Directories themselves are always either in the class specified by DIRMC, or auto-selected class of longest retention.

And this is the point of my whole question:
"May I put directories in a managementclass with shorter (in this case non-infinite) retention than some files, and still be able to restore these files when directory expired."
The consensus for now seems to be "yes, except only from the commandline client", which is OK for me.

Anyone else willing to chip in with their experiences about this kind of restore situation?

Regards,
-- W.

 

[moon-buddy]

Yes, but the management class you specify on INCLUDE line does not affect the directories themselves, only files inside those directories!
Directories themselves are always either in the class specified by DIRMC, or auto-selected class of longest retention.

And this is the point of my whole question:
"May I put directories in a managementclass with shorter (in this case non-infinite) retention than some files, and still be able to restore these files when directory expired."
The consensus for now seems to be "yes, except only from the commandline client", which is OK for me.

Anyone else willing to chip in with their experiences about this kind of restore situation?

Regards,
-- W.

The whole idea is to retain the files with different points in time. The file retention is really in question, right? If the management class is file bound, the drectory retention follows.