Did this thread mention the use of cloptsets? using them, you CAN change
include-exclude options, and the changes ARE picked up dynamically, with no
restart of the client needed.

> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Michael Oski
> Sent: Tuesday, June 19, 2001 11:53 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: dsm.sys file not being read in aix
>
>
> Richard,
>
> I'll give it a try, I was basically stating my understanding of the
> documentation. It seemed that the point of the scheduler need to be
> restarted after changing the dsm.opt or dsm.sys files is made, but no
> mention that the same was true for the inclexcl file. I assumed that
> this was by design and would work this way. I HAVE mis-assumed before,
> however (grin), so I wouldn't be surprised if this is not the case.
>
> If my assumption is incorrect, then the only true benefit I can see in
> separating the include/exclude statements from the dsm.opt file would be
> purely cosmetic - and quite disappointing. I have junior admin's that
> have the authority to update the config files since I set the file
> permissions to allow them write access. They don't have Unix-level
> authority to kill the dsmc sched command running as root though. So a
> restart of the scheduler would involve a page to a senior admin in the
> event an update was needed. Hmmm...... I WILL play with this! (don't
> like being paged at 2am because someone 11 time-zones away needs
> something included/excluded)
>
> I'll let you all know what I find.
> MO
>
> On Tuesday, June 19, 2001, at 06:08 AM, Richard Sims wrote:
>
> >> Having include/excludes in the dsm.sys file works, it's just not the
> >> preferred method. If you need to adjust your includes/excludes, and a
> >> "dsmc sched" process is running, the process will not pick up the
> >> changes to dsm.sys since it is read only upon startup. By placing the
> >> list in an inclexcl file, you can update that file while the scheduler
> >> is running and the updated file will be re-read when a backup actually
> >> kicks off.
> >
> > Michael - Under what client and level have you observed this to be true?
> >
> > This is not the behavior I would expect, given that the client absorbs
> > and retains its options specifications in total when it starts.
> > I tried this under the 3.7.2 AIX client, by invoking 'dsmc' to conduct
> > an interactive session, and then doing 'show inclexcl' thereunder.
> > It did not "see" changes made to the include-exclude file while the
> > dsmc process continued: only a fresh start picked up the changes.
> > Could you try the same test under your client/level and verify?
> >
> >   thanks, Richard Sims, BU
> >
>