|ALLOWMULTICOMPUTE||ALLOWMULTICOMPUTE tells Moab how to resolve conflicting information from different resource managers. If ALLOWMULTICOMPUTE is specified, Moab will use the STATE and OS information from the resource manager that reports the node as online.|
|DISABLEPERJOBNODESETS||Disables a job's ability to override the system specified node set. See 13.3 Resource Manager Extensions for more information.|
|FASTGROUPLOOKUP||Moab will use the system call getgrouplist to gather group information. This can significantly improve performance on some LDAP systems.|
Speeds up start time if there are existing reservations.
On very large systems, if there is a reservation in the checkpoint file on all the nodes, it would take a really long time for Moab to start up. For every node in the reservation, Moab checks every other node. With this flag, Moab just uses the nodelist that was checkpointed to create the reservation. It speeds up the startup process because it doesn't have to check every node. Where Moab would take 8 - 10 minutes to start up with an 18,000 node reservation without the flag, Moab can start up in 2-3 minutes with the flag.
With the flag you will see one difference in checknode. A reservation that uses all the procs on a node initially shows that all the procs are blocked. Without the flag, and as jobs fill on the node, the blocked resources will be configured - dedicated (ex. 5/6). With the flag, the blocked resources will always be what the reservation is blocking and won't change when jobs fill on the node.
|FILELOCKHA||This is a High Availability feature. FILELOCKHA prevents scheduling conflicts between multiple Moab servers.|
|JOBSUSERSVWALLTIME||Allows jobs submitted without a walltime request or default walltime received from a class or queue but with an ADVRES:reservation to inherit their walltime limit from the reservation instead of the Moab default. The job walltime limit is then the remaining time of the reservation to which the job was submitted.|
Instructs Moab to normalize all tasks that it receives via an mshow -a command. Moab normalizes the task definition to one processor and then changes the tasks requested to the number of processors requested. For example, when the following is received by Moab:
mshow -a -w mintasks=1@procs:4+mem:4096
It is changed to this:
mshow -a -w mintasks=4@procs:1+,mem:1024,tpn=4
|SHOWREQUESTEDPROCS||Shows requested processors regardless of NodeAccessPolicy in showq. When SINGLEJOB NODEACCESSPOLICY is used and the job requests one processor, showq displays the job with one processor.|
|STRICTSPOOLDIRPERMISSIONS||Enforces at least a 511 permission on the Moab spool directory.|
This enables the mapping of a job's GROUP to become the user's GROUP upon receiving a job from a remote Moab instance. The job is then in the GROUP of the user who owns the job during execution. If not enabled, the job is rejected if the GROUP is not valid on the executing Moab instance.