Back in the days of VM, my favorite automation tool for ADSM was Host
Management Facility. Unix cron is a poor substitute, but it's what we've
got to work with. I do a majority of my scheduling from within the TSM
server with administrative schedules that trigger TSM Scripts. This is a
rather poor tool, and I'm moving more and more things to Unix scripts,
including one that will simply sit there and watch everything coming
from the console. Sometimes it's hard to keep track of what is started
from TSM Schedules and what is started from Unix crontab.
STEP ONE in developing your own bowl of spaghetti is to define your own
standard API for entering TSM server commands. Call it anything, such as
"tsmdoit". Then you've got to religiously use tsmdoit everywhere. Even
if you only have one server now, be sure to include a server name
option, because you might have more than one someday.
The whole point is that once we get a real, secure, API to dsmadmc that
doesn't expose passwords in clear test, or that doesn't involve
convoluted hacks, hashes, excryptions, and whatever to partly and
inadequately hide them, then you can change tsmdoit easily in one place
to use the new API, and you won't have to change any of the rest of your
own code.
And yes, we really need this; dsmadmc is a huge security hole that
inhibits development of better and more creative tools to manage TSM.
Roger Deschner ACCC Basic Systems Group rogerd AT uic DOT edu
On Sun, 2 Apr 2006, Jurjen Oskam wrote:
>On Sat, Apr 01, 2006 at 09:46:00PM -0500, Allen S. Rout wrote:
>
>> Speaking as someone buried in my own PERL up to my nose:
> [snip: quite a good argument]
>> I don't think I could be as effective with a third-party product as I
>> am with my own stuff. I do think that the person who gets my job
>> after I get hit by a truck will curse me for years.
>
>Thanks, those are good points. But it does beg the question: how bad is
>your current situation? :) I mean, is it such a spaghetti that nobody,
>except you as the developer, can *really* get it? Isn't *that* something
>you could change, so that your successor can as effective as you are?
>(Implementing and migrating to a third party product costs time and money,
>wouldn't that better be spent cleaning up the custom code?)
>
>Third-party programs are indeed spread more widely, but this also means
>they must be more complex because they must support configurations which
>you don't even use. Homegrown code has only the complexity you need.
>
>
>As a side note: it would really *really* be nice to have a documented
>API to enter dsmadmc commands....
>--
>Jurjen Oskam
>
>Savage's Law of Expediency:
> You want it bad, you'll get it bad.
>
|
