ADSM-L

Re: Questions concerning file/user exits

2005-02-17 11:29:00
Subject: Re: Questions concerning file/user exits
From: "Jones, Eric J" <eric.j.jones AT LMCO DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 17 Feb 2005 11:03:59 -0500
Thanks for the information.
The TSM service runs under the local ADMIN account so it should have
permissions.
The batch file I'm running is the following which is very basic and the
commands executable from any directory.  The batch file runs fine from
the command line so that looks to be ok as far as the commands go.
The 1st command does not execute(looked and old file is still there) so
I assumed it was the way I put in the "preschedulecmd".

--------------------------------------------------------------------
rem   delete old backup
Del d:\NTBACKUP\system_object.bfk
rem   Backup system object
ntbackup backup systemstate /j "SystemState_Backup" /f "
D:\NTBACKUP\system_object.bkf" /v:yes /l:f /m COPY

Thanks again,
Eric

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Andrew Raibeck
Sent: Thursday, February 17, 2005 10:35 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Questions concerning file/user exits



I don't know what your script or environment look like, so it would be
difficult to give a definitive answer. However, the following
information might be useful to you, from article 1108971 at ibm.com:

Problem The PRESCHEDULECMD option has been configured to run a script
prior to starting the incremental backup. When running the script
manually, it runs fine. But when ITSM runs it, ITSM says it failed with
return code 1. Why does this happen?   Solution NOTE: While the examples
given in this article are oriented toward Windows, the principles
discussed can apply to other operating systems as well.

There are many reasons why a script may fail to run successfully. Common
reasons include:

o Syntax errors: The script has an outright error that prevents
successful execution. Such a script will most likely fail whether it is
run manually or by ITSM.

o Environmental differences: The operating system environment settings
may differ between the environment in which ITSM runs and the
environment in which an account runs. For example, suppose a script runs
a custom program, like this:

REM Launch my custom program located in C:\MyPrograms\prog1
report.exe E:\stats\stats.in C:\reports\stats.out

When run manually, the script runs fine, but fails when run by ITSM.

One likely possibility is that C:\MyPrograms\prog1 is not in the PATH
environment variable when ITSM runs it. If the user's personal Windows
account includes C:\Programs\prog1 in the PATH environment variable, but
ITSM runs under a different account that does not include this directory
in PATH, then the program will not be able to run. A couple of possible
solutions are to either add the directory to the PATH variable, or to
fully-qualify the program name. Both of these can be accomplished in the
script:

REM Launch my custom program located in C:\MyPrograms\prog1
set PATH=%PATH%;C:\MyPrograms\prog1
report.exe E:\stats\stats.in C:\reports\stats.out

or

REM Launch my custom program located in C:\MyPrograms\prog1
C:\MyPrograms\prog1\report.exe E:\stats\stats.in C:\reports\stats.out

A third alternative is to simply add C:\MyPrograms\prog1 to the system
PATH environment variable.

o Security differences: If the user account has privileges unavailable
to the account under which ITSM runs, and a program or command in the
script requires one or more of those privileges, then ITSM will not be
able to run the script correctly. Alternative solutions include:

- Configure the ITSM scheduler service to run under an account that has
the necessary privileges.

- Modify the account in which the ITSM scheduler service runs so that
the account has the necessary privileges.

- Modify the program so that it does not require the privileges if those
privileges are not really necessary.

Another problem related to security is if the script attempts to access
network resources. If ITSM runs under the local system account, then
that account does not have access to network resources. In this case,
try running ITSM under a different account that does have network
privileges.

o Insufficient diagnostics within the script itself to validate the
results of commands or programs used in the script. For example,
consider a script that contains the following:

net stop service1
net stop service2
net stop service3

The script will attempt to run each of these commands in turn, but it
does not test the results of each "net stop" command to see if it really
worked. The script should be enhanced to:

- execute the first "net stop" command
- test the return code from the command
- issue a message indicating whether the command succeeded
- repeat the above steps for the remaining commands
- exit with a return code that best represents the overall
status of the script (0 if all commands processed
successfully, or nonzero if one or more commands failed).

When implemented, these steps can help capture information that can be
useful in validating the execution of the script and diagnosing
problems.

The attached file, tempsample, contains a sample implementation using
the above steps. The script will write status messages to an output file
(defined by the OUTFILE variable at the top of the script). The three
service names are also specified in variables at the top of the script
to avoid repeating each service name multiple times.

NOTE: This script is intended as a sample only, and is provided on an
"as is" basis without warranty of any kind.



Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2005-02-17
06:31:12:

> Good Morning.
> I setup in the DSM.OPT file a preschedulecmd with a batch file that
I've
> tested and it worked well outside of TSM.  When the backup kicked
> off(serverinitiated) it failed.
> In the dsmerror.log I'm receiving the following error.
> ------------------------------------------------------------
> 02/16/2005 19:01:25 ANS1902E The PRESCHEDULECMD command failed. The
> scheduled event will not be executed.
> 02/16/2005 19:01:25 ANS1512E Scheduled event 'CAGE_DEV_INTEL' failed.
> Return code = 12.
> --------------------------------------------------------------
> It looked like I only needed quotes arount the command if blanks were
> present which none are.
> The line in the DSM.OPT file is
> preschedulecmd d:\NTBACKUP\SYSTEMSTATE_Backup.bat
>
> The backup in TSM ran fine until I added the preschedulecmd.  Nothing
> ran in the batch file.
>
> Do I need to add/change anything in the DSM.OPT file preschedulecmd?
> It's running on a win2K machine with SP4 and TSM 5.2.2
> The server is AIX 5.2 with TSM 5.2.2
>
> Thanks for the help,
> Eric
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf
Of
> Jurjen Oskam
> Sent: Friday, January 21, 2005 8:06 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Questions concerning file/user exits
>
>
> On Fri, Jan 21, 2005 at 09:34:52AM -0000, Davis Adrian wrote:
>
>    [ passing filetextexit output to a script ]
> > I presume that this has already been thought of - So I was wondering
> if
> > anybody has tried it? If so are there any problems?
>
> This is exactly what I'm doing, and it works quite well. I created
> a named pipe, and let the TSM server use that as a filetextexit
> (use the APPEND option). On the other end of the pipe a Perl-script
> is running, which reads from the pipe and takes actions depending on
> the messages it receives.
>
> Beware that such a setup could result in unwanted signals to the TSM
> server (SIGPIPE). Test this well.
>
> --
> Jurjen Oskam
>   "E-mail has just erupted like a weed, and instead of considering
>   what to say when they write, people now just let thoughts drool
>   out onto the screen." - R. Craig Hogan

<Prev in Thread] Current Thread [Next in Thread>