OK, a little deeper... we have 5 groups of stg areas, basically... Since TSM doesn't give you a good way to "control" (wait=yes is good with move data, but there's nothing for, say, migration) the movement from disk to tape we HAVE to use move data commands... We have over 100 disk vols. We simultaneously run move datas. If one area completes then, it goes onto the ba stg. ALL move datas and ba stgs have to complete (5 general areas) prior to the db backup, etc.... A good scheduler, will get this done with ease. Scripting...that would be complex.
-----Original Message----- From: ARhoads [mailto:[EMAIL PROTECTED]] Sent: Friday, March 01, 2002 10:17 AM To: [EMAIL PROTECTED] Subject: Re: Server-side scripting: not supported? But, of course, that is the purpose of the script. ----- Original Message ----- From: "Williams, Tim P {PBSG}" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 01, 2002 6:18 AM Subject: Re: Server-side scripting: not supported? > Even if TSM did support scripting.... > it would have to be a much more robust scheduler.... > best daily practices (high level)? > move all backup data that came in to tape and clear disk for the next > night... > next but not before...make the vault copy ba stg.... > next after that but not before a db backup (full) > move drmedia after that... > etc... > the scheduler would have to have dependancy ability... > We use an external scheduler for the administrative functions... > We use TSMs internal scheduler for scheduling of backup and archives. > > > -----Original Message----- > From: ARhoads [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 01, 2002 7:41 AM > To: [EMAIL PROTECTED] > Subject: Re: Server-side scripting: not supported? > > > This has been bugging me for a long time as well since it means I have to > use cron to automate the TSM daily processing rather than TSM's own > scheduler for administrative commands. I'd rather schedule TSM daily > processing inside TSM to make it easier for customers to see everything TSM > related from inside the TSM administrative client. > > The security issue is bunk. Other IBM products can access the O.S. just > fine (like DB2). > > Steffan > ----- Original Message ----- > From: "Seay, Paul" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, February 28, 2002 9:20 PM > Subject: Re: Server-side scripting: not supported? > > > > This is more of a security issue than anything. If you allow TSM to spawn > > scripts, the child process inherits the same security. Which is typically > > root. In their glory, they simply said no rather than opening up the OS I > > guess. They definitely are not explaining themselves well. > > > > -----Original Message----- > > From: Joseph Seigh [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, February 28, 2002 7:31 AM > > To: [EMAIL PROTECTED] > > Subject: Re: Server-side scripting: not supported? > > > > > > Quoting Ted Byrne <[EMAIL PROTECTED]>: > > > Has anyone received a similar response from TSM support in the past? > > > We are working on an issue with a process running for a very long > > > time, and received the following as part of the response from TSM > > > support: > > > > > > [W]as that the > > > run-time of a specific backup process, or was > > > that the run-time of the entire script. > > > > > > Since we do not support scripts, I need to verify > > > that this problem is not your script. Try running > > > each command in your script manually. > > > > > > The specific instance was a storagepool backup that was still running > > > a day later, parked on a 16+ GB file. The storagepool backup was > > > tape to tape; the drives are on separate, dedicated SCSI adapters. > > > > > > TSM Server is Win2k, > > > TSM version 4.2.1.0, > > > IBM 3583 Library > > > > > > > TSM does not support scripting. I assumed at one point that meant the > > scripts per se, but no it's scripting. I tried to pin down the precise > > definition of scripting since in unix everything runs from a shell more or > > less, with an > > exec() system call, and with some tty and enviroment restrictions applied. > > No, just sh, ksh, and csh (the standard shells) from the command line. > > > > It doesn't say much for TSM that they cannot even state what their command > > runtime environment should be, and that they impose arbitrary restrictions > > on their command usage instead. > > > > Joe Seigh
