> 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:jseigh AT GENUITY DOT COM]
> Sent: Thursday, February 28, 2002 7:31 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Server-side scripting: not supported?
>
>
> Quoting Ted Byrne <tbyrne AT DSSCORP DOT COM>:
> > 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