Job getting stuck in queue

No, you don't need them.

Try a simple proof of concept test. Create 1 program jobs with the following command line
cmd /C "@echo set extractcontrol=Hello World!" > setvar.bat && setvar.bat

Run this job.

Create a JAL script type job with the following script
MessageBox "@V"env:extractcontrol""

Run this job in test mode and receive a "Helo World!" message box.

I've done this exactly as suggested and I get a blank messagebox.

I'm running the latest version of the windows scheduler on windows server 2003 running as a process for reference.

Hmm... looks like your OS doesn't support && command line extensions. The getter is surely correct. It is the setter which is not doing the required job.

Please try this solution for the setter using a JAL job
Dim(pid, number)
FileSave("setvar.bat", "set exportcontrol=Hello World!")
RunAndWait("setvar.bat", "", 0, pid)

Right I think the issue is with scope not the command as such. Commandline extensions are available on my server.

The reason I think this is that when I point the getter at a system variable, SystemRoot for example, it works fine. When I point it at a manually user defined variable, (done using set var=value from a command prompt and verified using set) the getter is unable to see that variable.

Set only initialises variables for the current command shell. The setter job calls and closes a command shell, therefore extinguishing that variable immediately.

I'm experimenting with the windows support tool setx, which allows setting of system variables

I disagree. The issue there is that the "setter" doesn't set the value. Schedule "cmd" command, when it appears on the screen type manually

set exportcontrol=Hello World!
exit

After this run the "getter". You shjould see the result.

For automated processing, please use the FileSave method suggested in the previous post.

This is what was run in the cmd window
C:\Program Files\24x7 Automation 3>set expcont=tworks

C:\Program Files\24x7 Automation 3>exit

The picture is what comes out.

So what you are saying is that 24x7 jobs should run in the same cmd environment as each other, therefore directly inheriting any environment changes.

What it seems to me is happening here is that the cmd process that 24x7 runs under is starting a nested command window

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds_shelloverview.mspx?mfr=true
(this is for xp but should hold true for server 2003)

but that nested command window is unable to modify the environment of it's parent, therefore the other job that is run later to get the value that was created in the child process is unable to retrieve it because it runs under the parent process.

I've verified this by running the cmd job once, setting a variable, exiting, then running the cmd job again, and the new var is not found under set. It again inherited the environment of the parent.

Indeed, this method doesn't work on XP. But here is a trick. In the scheduler's settings enable the Tracing option on the Log page. Restart the scheduler and this should make the setter\getter jobs to work. Tip: in this mode, all started command processes will have access to the "parent" environment, they will actually share the console.

By the way, please disable the job status display option. This is option . It used to work in old days on Windows 9.x and Nt 4, but on newest systems it causes lots of problems.

I've disabled the job status display as suggested. That could be why I was having trouble with loops.

However trace has been on the whole time! I think the problem is that the started command processes do indeed share the parent process, but unless the scheduler is restarted then that parent process does not recieve a refresh of the environment variable and hence any subsequent child processes don't get the var change either.

Ok, here is another method that should work on all Windows systems, in the setter job code the following

Call( "kernel32.dll", "SetEnvironmentVariableA", "SS", False, "MY_VAR", "@T"hh:mm:ss"" )

Note that the last parameter is the value you set and the parameter before is the name of the variable. This script modifies the environment block of the scheduler process.

Thanks very much for you time.