Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!decvax!ittatc!dcdwest!sdcsvax!ucbvax!info-vax From: S211KENO@HTIKHT5.BITNET Newsgroups: mod.computers.vax Subject: VMS V4.2 QUEUE PROTECTIONS Message-ID: <8602071415.AA10617@ucbvax.berkeley.edu> Date: Fri, 7-Feb-86 09:16:05 EST Article-I.D.: ucbvax.8602071415.AA10617 Posted: Fri Feb 7 09:16:05 1986 Date-Received: Sat, 8-Feb-86 05:45:53 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 33 Approved: info-vax@sri-kl.arpa With VAX/VMS V4.1 it was possible to prohibit direct access to batch and print execution queues with INITIALIZE/QUEUE/PROTECTION=WORLD . 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