S211KENO@HTIKHT5.BITNET (02/07/86)
With VAX/VMS V4.1 it was possible to prohibit direct access to batch and print execution queues with INITIALIZE/QUEUE/PROTECTION=WORLD <execution queue>. At our site users had access to generic queues only. With SUBMIT/CHARACTERISTIC= they still had the possibility to indicate in which execution queue a job would run. This worked fine: generic queues were waiting queues and execution queues were 'real' execution queues. One of the benefits is that in a vaxcluster the batch-workload is evenly distributed among all nodes by job controller. In V4.2 Digital cancelled this nice feature without any announcement. Users need WRITE access to all execution queues otherwise jobs remain pending in the generic queue. TSC made me angry by saying they had cleared a bug. They say an execution queue with no access to world may not run jobs in that queue. They see no difference between "submitting to" and "running in". By the way, TSC didn't tell me where the "bug" was mentioned in the systems dispatch... They told me I had used an unsupported feature. But how could I know it was unsupported ? Is everything which they don't document explicitly unsupported ??? The worst of all is that from a system management point of view we are just loosing control over job scheduling/distribution with V4.2. because now we have to grant WRITE access to world for every execution queue. I think an execution queue initialized with /ENABLE_GENERIC should behave like a pure execution queue (only running jobs), not a waiting queue. Apparently Digital does not agree; I hope they will read this. Any comments, ideas, workarounds ? Kees Noyens Tilburg University The Netherlands