Fix issue with accounting when using PrivateData=jobs... users would not be able to view there own jobs unless they were admin or coordinators which is obviously wrong.

Fix displaying of account coordinators with sacctmgr.  Possiblity to show deleted accounts.  Only a cosmetic issue, since the accounts are already deleted, and have no associations.

Fix issue when changing a users name in accounting, if using wckeys would execute correctly, but bad memcopy would core the DBD.  No information would be lost or corrupted, but you would need to restart the DBD.

    --mem-per-cpu options on a heterogeneous cluster. Patch from Bjorn-Helge
    Mevik, University of Oslo.

    --cpus-per-task option. Patch from Martin Perry, Bull.

    --resv-ports option is used.

BLUEGENE - when running in overlap mode make sure to check the connection type so you can create overlapping blocks on the exact same nodes with different connection types (i.e. one torus, one mesh).

    can be found in the user's default search path. Modify slurmstepd to find
    the executable. Patch from Andrej Gritsenko.

    of leaving in UNKNOWN+POWER. Patch from Andrej Gritsenko.

Fix so slurmctld will pack correctly 2.1 step information. (Only needed if a 2.1 client is talking to a 2.2 slurmctld.)

    resources (gres).

    scheduling which prevented some jobs from starting as soon as possible.

    select/cons_res plugin. Patch from Rod Schulz, Bull.

Avoid filling slurmd logs about unkillable jobs.

    damon that should be running on the node is not running. Patch from Rod
    Schulz, Bull.

rather than COMPLETED state

BLUEGENE - Added back a lock when creating dynamic blocks to be more thread safe on larger systems with heavy load.

Fix associations/qos for when adding back a previously deleted object the object will be cleared of all old limits.

The man page for slurm.conf, select/cons_res parameter SelectTypeParameters, values CR_Socket and CR_Socket_Memory states the following:

"Note that jobs requesting one CPU will only be given access to that one CPU"

I think this statement is incorrect, or at least very misleading to users. A job requesting one CPU will only be allocated one CPU, but unless task/affinity is enabled or some other CPU binding mechanism is used, the job can access all of the CPUs on the node.  That is, a task that is distributed to the node can run on any of the CPUs on the node, not just on the one CPU that was allocated to its job. I propose the following patch to replace "given access to" with "allocated".

Regards,
Martin Perry

Fix cosmetic sacctmgr issue where if the user you are trying to add doesn't exist in the /etc/passwd file and the account you are trying to add them to doesn't exist it would print (null) instead of the bad account name.