to allow sview to display blocks correctly.

to avoid overlapping erroneously.

Before you could get overlapping reservations if you asked for a core
based reservation and then a whole node reservation.  This fixes that.

describing the error code.

Test 3.11 was failing in some configurations without this as
the CPU count in the RPC was lower than the number of nodes in
the required node list

MaxProcSecondsPerJob.

error

terminating a job.

and abort the job.

a midplane.

MaxNode limit.

only needs to be called once.

    reference.

s_p_options_t struct.

The CPU specification enforcement is strict rather than advisory.

warning.

of cpus in the job_resources_t structure so as nodes finish the correct
cpu count is displayed in the user tools.

Previous logic would only make available the CPUs associated with
the first N GRES, where N is the number of requested GRES. CPUs
which might be made available by using different GRES were not
considered available.
bug 1092

Eliminate race condition in enforcement of MaxJobCount limit for job arrays.
The job count limit was checked for a job array before setting the slurmctld
job locks. If new jobs were submitted between the test and the job array
creation such that the job array creation would result in MaxJobCount being
exceeded, then a fatal error would result.
bug 1091

message back.  In slow systems with many associations this could speed
responsiveness in sacctmgr after adding associations.

Fix error handling for job array create failure due to inability to copy
job files (script and environment).
See bug 1077

are hard links to the first element specification files. If the
controller fails to make the links the files are copied instead.

reserved for higher priority jobs.

since the slurmd will send the same message.

correctly.

ran inside the allocation can read the environment correctly.

This fixes some problems creating advanced reservations on heterogeneous systems, especially when core counts are specified in the reservation.
bug 1068

Make "srun --gres=none ..." work when executed without a job allocation
(i.e. srun creates the allocation plus the step). Previous logic would
try to create the job with a gres value of "none".

Fix for possible error if job has GRES, but the step explicitly requests a
GRES count of zero.

and only caused confusion since the cpu_bind options mostly refer to a
step we opted to only allow srun to set them in future versions.