Why do you consider this an 'oddly configured environment?' We use this all the time. Our daily status report is generated from a shell script scheduled via client command. We use a client command to run our AutoVault reports. Our automated checkin script runs this way which does some Perl processing.
This provides us a single place for scheduling all our TSM-related tasks, plus using the Q EV command we can atleast see if the schedule ran or not. Bill -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of ARhoads Sent: Monday, March 04, 2002 10:37 AM To: [EMAIL PROTECTED] Subject: Re: Server-side scripting: not supported? I don't like leaving clients with oddly configured environments. ----- Original Message ----- From: "Bill Boyer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 04, 2002 6:37 AM Subject: Re: Server-side scripting: not supported? > Then why don't you just create a client schedule in TSM with ACTION=COMMAND > pointing to your shell script that you would normally execute via cron?? Now > TSM is handling your scheduling for you. > > Bill Boyer > DSS, Inc. > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of > ARhoads > Sent: Friday, March 01, 2002 8: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