> 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:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> ARhoads
> Sent: Friday, March 01, 2002 8:41 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> 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" <seay_pd AT NAPTHEON DOT COM>
> To: <ADSM-L AT VM.MARIST DOT EDU>
> 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: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