Client has submitted a job to VMBatch with few options (taking most defaults).
The job did not (would not) run - STATUS shows 'Worker Availability'.
Client submitted the same job with a specific WORKDISK value (not defaulting to his 'A' disk size) and the job ran successfully.
In the CA VM:Batch™ CA User's and Group Manager's Guide Release 1.4, it describes:
There are no workers available with a 193 minidisk as large or larger than the requested size.
There is at least one worker with a work disk large enough to run the job; but every such worker already has a job allocated to it, does not provide other required resources, cannot run the desired job class, or is tagged unavailable due to an error preventing its use. An autolog error can cause this condition.
It would appear that the wrong STATUS message is being produced.
It seems you were receiving the correct status message at the time and current situation of VM:Batch et al when the job with the 1500 cylinder A-Disk was submitted.
That would have been as follows:
--- 1) You had one or more VM:Batch worker machines that had a 1500 cyl (or greater) work disk
--- 2) Of those, they also met all the other job criteria to run the job
--- 3) They were all busy at the time you submitted the job.
Therefore, there are workers that can run the job, but they are all currently active, or maybe drained.
Based on your DEFAULT for most of your batch worker classes, the size is set to 35999-3390 or 17999-3390
or 5-3390 for class V only.
Class V is isolated to a specific string of workers, whereas the other workers (with the large cyl value for WORKDISK) run the other classes.
If the job submitter's A-DISK is less than the DEFAULT WORKDISK for that class, then the submitter's A-Disk size is used for the size of the WORKDISK.
Anyway, when you changed the size of the submitter's A-Disk to 10 cyls, there was a worker machine available with at least a 10 cyl work disk ... so that job ran without being queued.
If I have have my class WORKDISK defaults set link yours, for example 35999-3390, but have no worker machines defined with at least a 1500 cyl work disk ... and the submitter's A-Disk is 1500 cyls,
the job is queued with a STATUS of "WAIT" and BLOCKED BY "Work Disk".
When VMBATCH is in this state, if a modify one of the VMBATnnn workers to have a 1500 cyl work disk, then force a refresh of the VMBATCH CONFIG file to force VMBATCH to refresh the updated worker machine(s), the waiting job takes off.
In the above scenario, if I have a worker with a 1500 cyl work disk, but that worker is currently active, then submit the job (the submitter's A-Disk is 1500 cyls), the job is queued with at STATUS of "WAIT" and BLOCKED BY "Worker Availability". This is the situation you had.
When the job completes that had the "1500 cyl" worker tied up, the waiting job (BLOCKED BY "Worker Availability") takes off and runs.
Review your VMBATnnn worker directory entries to see how many actually have 1500 cyl or greater work disk. Then, based on that information determine if it is possible that you do have workers defined that could run the job (have at least a 1500 cyl work disk), but that they all may have been active (or possibly drained) doing other work at the time you submitted the job that got queued with BLOCKED BY "Worker Availability".
If you change your WORKDISK size to be consistent with (the same size as the largest CLASS A worker's A-DISK) it will solve this problem.
This condition is documented in the VM:Batch documentation.
Information can be found in the "Reviewing Job Status" section at:
Specifically under the "Blocked By Field" link on that page at: