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 [EMAIL PROTECTED] 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. >
