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