Hi,

Time for my 2 cents worth.

I have no problem with schedules being associated with administrators,
and those schedules not being able to run if the administator is
deleted. However, I do have a problem with not being told that something
I am about to do ie delete an administator, is going to have an adverse
affect on my ADSM server. And I think that is is unreasonable to have to
remember to check for these sorts of things. We have a few dozen
administrators with enough privilege to add/update schedule (mostly
within a single domain) and maybe 100 scheduled events.

What I'd like to see is that when a 'remove admin' is performed, a check
should be made that there are no schedules associated with that
administator. I see it working along the lines of a 'remove node' where
a check is made that there is no data stored against that node.


Trevor

> -----Original Message-----
> From: Nicholas Cassimatis [SMTP:nickpc AT US.IBM DOT COM]
> Sent: Thursday, July 30, 1998 3:59 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Re[2]: Admin deleted, job not run
>
> Jerry,
>
> In my experience with this, the best thing to do was to LOCK the ID of
> any
> admins who leave.  After a few months, I'd lower them to OPERATOR
> status,
> unlock the ID, and see if anything fails (keeping an eye right on it
> to run the
> scheduled operation manually).  I can then update those schedules, and
> delete
> the ID safely.
>
> Nick Cassimatis
>
> nickpc AT us.ibm DOT com
>
> If you don't have the time to do it right the first time, where will
> you find
> the time to do it again?
>
>
>
> ADSM-L AT VM.MARIST DOT EDU on 07/29/98 01:43:55 PM
> Please respond to ADSM-L AT VM.MARIST DOT EDU
> To: ADSM-L AT VM.MARIST DOT EDU
> cc:
> Subject: Re[2]: Admin deleted, job not run
>
>
> Richard -
>
> The problem we would probably get into here is one with the security
> department - While the root user concept is a fundamental part of
> Unix, it is
> not a mainframe concept.  The security folks in my shop have a
> "mainframe
> mindset" that basically says that ids will not be shared between
> people.
> Since there is an alternative (of sorts) here -they probably wouldn't
> approve
> this type of approach.
>
> The bureaucratic mind never fails to amaze me.
>
> Jerry Lawson
> jlawson AT thehartford DOT com
>
> ______________________________ Reply Separator
> _________________________________
> Subject: Re: Admin deleted, job not run
> Author:  owner-adsm-l AT VM.MARIST DOT EDU at SMTP
> Date:    7/29/98 8:48 AM
>
>
> >In my shop, that would bring ADSM to its knees, since I set up all of
> >the automation using my id.
>
> I think the obvious solution here is to simply define a general
> administrative
> ID within a shop (much like root on a Unix system) and use that for
> administrative tasks involving configuration changes where ADSM is
> sensitive to
> the administrator ID.  Use private administrator IDs for queries, Set
> commands,
> and the like.  Individual administrators can then come and go, but the
> general
> one can persist.
>      Richard Sims, Boston University OIT