When using Remote Control accessing a Master Scheduler, the Remote Control client seems to only synchronize with the default queue plus 9 user defined queues. We are running 18 queues on the Master Scheduler. Is there a way to allow the Remote Control client to synchronize on all of the Queues on the Master Scheduler?

Are there any unusual characters used in the queue names (double quotes, [], = , etc)?

BTW: I am not aware of any limitatitons on the number of queues

: When using Remote Control accessing a Master Scheduler, the Remote Control
: client seems to only synchronize with the default queue plus 9 user
: defined queues. We are running 18 queues on the Master Scheduler. Is there
: a way to allow the Remote Control client to synchronize on all of the
: Queues on the Master Scheduler?

No unusual characters.... It only loads the first 9 user defined queues it sees.

: Are there any unusual characters used in the queue names (double quotes, [],
: = , etc)?

: BTW: I am not aware of any limitatitons on the number of queues

If you've applied 3.1.3 upgrade and then created more queues, it may cause the problem. Perhaps, you hade only 10 queues before the upgrade. It appears that this upgrade does not update some files. As a result the Remote Control, after upgrade, doesn't synchronize new queues. Please wait for the full version 3.1.3 to be setup for downloading. The full version setup should update all 24x7 files and this should fix the problem.

: No unusual characters.... It only loads the first 9 user defined queues it
: sees.

I did apply the 3.1.3 ugrade but the queues existed prior to the upgrade being applied.

Not only does upgrade 3.1.3 not update some files, it wipes out the queues on the Master with only the queues that Remote Control sees. So if you had 20 user defined queues on the Master and then did a Save Remote from Remote Control you will be left with only 9 user defined queues on the Master. Eleven of your queues will have disappeared.

This seems like a serious bug.... one that could severely impact your job processing if you didn't catch what happened.

One reason why you might want to use many queues is so that long running jobs to different machines do not get serialized in one queue on the Master Scheduler. The absence of the queue for the job will not cause the job not to run. The jobs will however be run out of the default queue causing the serializaion that you were trying to avoid.

I identified a problem with the queue processing on September 28, 2001. Through a lot of e-mails and a lot of my time trying to debug the problems, version 3.1.3 looked very promising. At this point I am not able to use this solution because of another issue that has appeared.

When do you expect the full version of 3.1.3 to be available?

Please advise.

Thank you.

: If you've applied 3.1.3 upgrade and then created more queues, it may cause
: the problem. Perhaps, you hade only 10 queues before the upgrade. It
: appears that this upgrade does not update some files. As a result the
: Remote Control, after upgrade, doesn't synchronize new queues. Please wait
: for the full version 3.1.3 to be setup for downloading. The full version
: setup should update all 24x7 files and this should fix the problem.

It should be available this weekend.

By the way, why don't you use asynchronous jobs to avoid job contention?
If you have to run subsequent jobs, can compose them into one big job?

: I did apply the 3.1.3 ugrade but the queues existed prior to the upgrade
: being applied.

: Not only does upgrade 3.1.3 not update some files, it wipes out the queues on
: the Master with only the queues that Remote Control sees. So if you had 20
: user defined queues on the Master and then did a Save Remote from Remote
: Control you will be left with only 9 user defined queues on the Master.
: Eleven of your queues will have disappeared.

: This seems like a serious bug.... one that could severely impact your job
: processing if you didn't catch what happened.

: One reason why you might want to use many queues is so that long running jobs
: to different machines do not get serialized in one queue on the Master
: Scheduler. The absence of the queue for the job will not cause the job not
: to run. The jobs will however be run out of the default queue causing the
: serializaion that you were trying to avoid.

: I identified a problem with the queue processing on September 28, 2001.
: Through a lot of e-mails and a lot of my time trying to debug the
: problems, version 3.1.3 looked very promising. At this point I am not able
: to use this solution because of another issue that has appeared.

: When do you expect the full version of 3.1.3 to be available?

: Please advise.

: Thank you.

I started to go down the asynchronous path when I started developing the strategy for using 24x7 to control our database environment. The plan was to be able to review all job failures from one central location. When running jobs in asynchronous mode the e-mail notification when there is an execution error simply does not work. Synchronous mode works.

Do you concur with this? I tried this under 3.1.3 and get no notification using asynchronous mode.

: It should be available this weekend.

: By the way, why don't you use asynchronous jobs to avoid job contention?
: If you have to run subsequent jobs, can compose them into one big job?