Joseph, The reasons you are doing this are probably different than ours. We have production processes that need the backups synchronized with them. The production control department must be able to hold backups if things are running late or reschedule at a 5 minute notice. Or hold everything because there is a problem being worked on. And, of course your basic reasons.
However, you will find that the open systems 3rd party schedulers are not like a mainframe scheduler in the ability to give you status on running process. The basically throw it over the wall and put a message if the process does not finish by a certain time. However, if your processes do not hang up, you will get return codes back that can be used to influence the overall schedule as necessary. -----Original Message----- From: Joseph Seigh [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 27, 2002 6:53 AM To: [EMAIL PROTECTED] Subject: Re: TSM with 3rd party scheduler Quoting Philippe Girard <[EMAIL PROTECTED]>: > I do not know what platform you are working on, > but with your scheduler if you can send command to TSM like: > DSMCADMC -ID=xxx -PA=xxxx command > > you can control TSM from your scheduler. You got the question the wrong way around. We have a mechanism to send commands and get the results from TSM. It's an expect/perl script. Only naive and foolish persons would expose their passwords by putting them in a unix command parameter list. We're looking for a 3rd party scheduler that lends itself to scripting and automation. The scheduler that is part of TSM is, to put it mildly, less than inadequate. It takes a Darwinian approach to client scheduling. There's no decent feedback mechanism on the status of a schedule. What's "Pending" mean? Almost nothing. Just that the schedule's window is open and you don't need the events log to tell you that. It doesn't tell you whether the client has actually received the schedule and is waiting for some other reason before starting such as not starttime yet, or no schedule sessions available from server, etc... And that 5 minute sleep loop in the schedule push thread does not help either. That's why clientactions take an average of 2.5 minutes to start if any of you were wondering. You would think that someone doing threads programming would know about pthread condition variables. I would think that with something as appallingly bad as the TSM scheduler, that lots of people would not put up with it. But maybe not. Do most people suffer this thing? Joe Seigh disclaimer: The opinions expressed herein are mine and not necessarily those of Genuity.
