Hi,

Are global variables present when executing a
notification script via the remote control?

Situation: I have a startup script which sets many
global variables. They work fine in both the script
and notification script when running 24x7 on the
machine it is installed on. But when I use the remote
control feature from a client and I click the
"run now" button, the global variables in the JOB script
are recognized, but the variables in the NOTIFICATION
script are not and I get an error message.

Example:
1. Set up script job (on server).
2. Set the code to:

dim global.MyVar, string, "Hello World"

FileSave("c:\\MyVarScript.txt",global.MyVar)
3. set up a notification script on FINISH event.
4. Set the code to:

FileSave("c:\\MyVarNotification.txt",global.MyVar)
5. go to a client, start the remote control, and run

the job on the remote.

Result: The job script will run fine, but the notification
script will produce an error:
Notification action failed: An error occurred....
Line 1: Undefined variable.

If this is the case, then re-running a job remotely
(which we will need to do often) will not be possible.

Please advise.

Robert

This is because the notification script is not executed on the target machine. Notification actions are always run on the system where the job is initiated. When you use the remote control you do not actually trigger a job, you submit it from the remote control just as master scheduler submites jobs to remote agents.

: Hi,

: Are global variables present when executing a
: notification script via the remote control?

: Situation: I have a startup script which sets many
: global variables. They work fine in both the script
: and notification script when running 24x7 on the
: machine it is installed on. But when I use the remote
: control feature from a client and I click the
: "run now" button, the global variables in the JOB script
: are recognized, but the variables in the NOTIFICATION
: script are not and I get an error message.

: Example: 1. Set up script job (on server).
: 2. Set the code to: dim global.MyVar, string, "Hello World"

: FileSave("c:\\MyVarScript.txt",global.MyVar)
: 3. set up a notification script on FINISH event.
: 4. Set the code to:
: FileSave("c:\\MyVarNotification.txt",global.MyVar)
: 5. go to a client, start the remote control, and run

: the job on the remote.

: Result: The job script will run fine, but the notification
: script will produce an error: Notification action failed: An error
: occurred....
: Line 1: Undefined variable.

: If this is the case, then re-running a job remotely
: (which we will need to do often) will not be possible.

: Please advise.

: Robert

Okay, that being said, why are notification scripts
executed on the client even when you specify remote?
Just curious. And is there a workaround?

What I am doing now is that I set globals (at startup)
based on the computer name and when the notification
script is run, it will do something pertinent to that
server, let's say on an ERROR event:

ConcatEx(global.ErrorFilesPath,"MyErrorFile.txt",dest)
FileMove("C:\\MyErrorFile.txt",dest)

My global is set like this:

Set (global.ErrorFilesPath, "\\\\@V"computer"\\24x7\\ErrorFiles\\")

Robert

: This is because the notification script is not executed on the target
: machine. Notification actions are always run on the system where the job
: is initiated. When you use the remote control you do not actually trigger
: a job, you submit it from the remote control just as master scheduler
: submites jobs to remote agents.

Remote Control reuses the same code and methods that are used by master schedulers running jobs on remote computers. There is a simple reason why notification actions are always local - job scheduling and linkage are got to be centralized in order to maintain job dependencies.

Here is an example: let's say you have 2 jobs, job A and Job B scheduled to run remotely on computers A and B. Job B is linked to job A and it cannot start before job A is complete.
The linkage is done using file dependencies on the scheduling computer. Sooo if job A creates a semaphore file on computer A (as a result of the local notification action) this file will not be seen by the scheduler machine and the job B will never start.

Now, as a workaround for global variables consider developing a job that will copy global variables from one machine to another. There are many ways how this can be done, for example you can use GetRemoteVariable statement or dump values to a file and then load them into variables. The first method is much simpler but the second one is much faster is you have lots of variables. To bring a file across a network use FileTransfer or FileTransferEx.

: Okay, that being said, why are notification scripts
: executed on the client even when you specify remote?
: Just curious. And is there a workaround?

: What I am doing now is that I set globals (at startup)
: based on the computer name and when the notification
: script is run, it will do something pertinent to that
: server, let's say on an ERROR event:
: ConcatEx(global.ErrorFilesPath,"MyErrorFile.txt",dest)
: FileMove("C:\\MyErrorFile.txt",dest)

: My global is set like this: Set (global.ErrorFilesPath,
: "\\\\@V"computer"\\24x7\\ErrorFiles\\")

: Robert

Okay, that being said, why are notification scripts
executed on the client even when you specify remote?
Just curious. And is there a workaround?

What I am doing now is that I set globals (at startup)
based on the computer name and when the notification
script is run, it will do something pertinent to that
server, let's say on an ERROR event:

ConcatEx(global.ErrorFilesPath,"MyErrorFile.txt",dest)
FileMove("C:\\MyErrorFile.txt",dest)

My global is set like this:

Set (global.ErrorFilesPath, "\\\\@V"computer"\\24x7\\ErrorFiles\\")

Robert

: This is because the notification script is not executed on the target
: machine. Notification actions are always run on the system where the job
: is initiated. When you use the remote control you do not actually trigger
: a job, you submit it from the remote control just as master scheduler
: submites jobs to remote agents.