It seems that when a job is set to be an Asynchronous/background process and calls
the function JobGetStatus that the function waits for the job being checked to
finish before returning. This seems counter-intuitive.

This not correct. JobGetStatus doesn't wait for the other job to complete. It is something else that causes the job containing JobGetstatus to freeze.

Please provide more details about what you are doing so I can figure what causes that freezing.

: It seems that when a job is set to be an Asynchronous/background process and
: calls
: the function JobGetStatus that the function waits for the job being checked
: to
: finish before returning. This seems counter-intuitive.

OK, here are some steps to reproduce the problem:

1. Create a new folder called New Folder.
2. Create a new JAL job called "New Job A".
3. Make the script as follows:

Wait(30)
4. Ascynchronous checked, and Detached Checked.
5. Set to [No Schedule].
6. Default all other settings.
7. Create another new JAL job called "New Job B".
8. Make the script as follows replacing the NetworkSend first parameter with a valid computer name:

Dim ReturnValue number

JobGetStatus("New Job A",ReturnValue)

NetworkSend("LEIGHXP",ReturnValue)
9. Ascynchronous checked, and Detached Checked.
10. Set to [No Schedule].
11. Enter a recipient computer with the messager service on.
12. Default all other settings.
13. Save changes.
13. Run "New Job A" and then "New Job B".
14. Note that "New Job A" does not send a network message until "New Job B" has finished.
15. Adjust length of Wait command and rerun to observe changes in "New Job B" runtime.

Are you launching these jobs manually or you are letting the system to start them on schedule?

: OK, here are some steps to reproduce the problem: 1. Create a new folder
: called New Folder.
: 2. Create a new JAL job called "New Job A".
: 3. Make the script as follows: Wait(30)
: 4. Ascynchronous checked, and Detached Checked.
: 5. Set to [No Schedule].
: 6. Default all other settings.
: 7. Create another new JAL job called "New Job B".
: 8. Make the script as follows replacing the NetworkSend first parameter with
: a valid computer name: Dim ReturnValue number

: JobGetStatus("New Job A",ReturnValue)

: NetworkSend("LEIGHXP",ReturnValue)
: 9. Ascynchronous checked, and Detached Checked.
: 10. Set to [No Schedule].
: 11. Enter a recipient computer with the messager service on.
: 12. Default all other settings.
: 13. Save changes.
: 13. Run "New Job A" and then "New Job B".
: 14. Note that "New Job A" does not send a network message until
: "New Job B" has finished.
: 15. Adjust length of Wait command and rerun to observe changes in "New
: Job B" runtime.

: Are you launching these jobs manually or you are letting the system to start
: them on schedule?

In the case of my example they are being executed manually.

: Are you launching these jobs manually or you are letting the system to start
: them on schedule?

I have tested these same jobs with their schedule set to On Scheduler Startup.
The behavior seems to be correct when run in this manner, so it seems to be a
problem that only occurs when manual executions are done.

When you execute jobs manually you always run them in the foreground (asynchronous property is ignored; see docs for details) that's why each job waits for the previous job to complete.
Manual run should be used for job testing and troubleshooting. To manually run a job without blocking other jobs use "24x7 /JOB [job id]" command in DOS or use 24x7 Remote Control.

: In the case of my example they are being executed manually.

: When you execute jobs manually you always run them in the foreground
: (asynchronous property is ignored; see docs for details) that's why each
: job waits for the previous job to complete.
: Manual run should be used for job testing and troubleshooting. To manually
: run a job without blocking other jobs use "24x7 /JOB [job id]"
: command in DOS or use 24x7 Remote Control.

Ok, I see, so the issue does indeed only effect jobs run manually for testing or
troubleshooting like I am trying to do. Thanks for the workarounds. Do you know
when this bug will be fixed? Also, where in the docs can I find information about
this. I have looked and can't find it. It would be helpful to know because I
have another job that behaves differently when run manually and I wanted to make
sure I'm not overlooking a known issue.

This is not a bug. This is by design and done this way for a number of reasons.

For more info please see in the on-line help the following topics:

1. Job Processing Flow (the entire topic and especially second paragraph)
2. Testing Job Execution

: Ok, I see, so the issue does indeed only effect jobs run manually for testing
: or
: troubleshooting like I am trying to do. Thanks for the workarounds. Do you
: know
: when this bug will be fixed? Also, where in the docs can I find information
: about
: this. I have looked and can't find it. It would be helpful to know because I
: have another job that behaves differently when run manually and I wanted to
: make
: sure I'm not overlooking a known issue.

: This is not a bug. This is by design and done this way for a number of
: reasons.

: For more info please see in the on-line help the following topics: 1. Job
: Processing Flow (the entire topic and especially second paragraph)
: 2. Testing Job Execution

Well, it may not be a bug persay, but it does behave like a bug. At the very
least the behaviour is inconsistent and as I said initially, counter-intuitive.
Behind the scenes design difficulties aside, there is no logical or interface
reason why the behavior should change when running a job manully. In essence
the result of this design difference is that we must now test all our jobs
using command line launching in order to get consistent behavior. This is
cumbersome. The behavior should match any other scheduled execution.

Then how are guys going to test and debug script type jobs if they run invisible in the background?

: Well, it may not be a bug persay, but it does behave like a bug. At the very
: least the behaviour is inconsistent and as I said initially,
: counter-intuitive.
: Behind the scenes design difficulties aside, there is no logical or interface
: reason why the behavior should change when running a job manully. In essence
: the result of this design difference is that we must now test all our jobs
: using command line launching in order to get consistent behavior. This is
: cumbersome. The behavior should match any other scheduled execution.

: Then how are guys going to test and debug script type jobs if they run
: invisible in the background?

If a programmer doesn't want the script to run in the background then
they should leave the Asyncronous checkbox unchecked.

Here you go... to debug a job you have to change job properties and then after debugging don't forget to undo your changes.

I guess renaming "Run Now" button label to "Test Now" should make the purpose of that function obvious to most people.

: If a programmer doesn't want the script to run in the background then
: they should leave the Asyncronous checkbox unchecked.

: Here you go... to debug a job you have to change job properties and then
: after debugging don't forget to undo your changes.

: I guess renaming "Run Now" button label to "Test Now"
: should make the purpose of that function obvious to most people.

Exactly! To test your Asynchronous job in a Synchronous manner, simply change
the settings so that it will run as a Synchronous job. If you want to test an
Asynchronous job in its typical Asynchrous mode just run it. In the same
fashion if you want to test a Synchronous job in its typical Synchronous manner
simply run it.

I agree with you. The "Run Now" button should be renamed. Perhaps "Run in the
Foreground" may be a more descriptive title. In any case this would then leave
the "Run Now" label free for a new button that would follow the user mental model
more closely and simply run the job using the current settings of the job.

By the way, I appreciate your responses especially considering the time
involved. Many a company would have given up on the issue after one or two
replies. I know my replies have been rather terse, but I hope banter such as
this can both improve the product and remove confusion (whether self induced
or otherwise) for programmers such as myself.