Ticket 6983

Summary:	strange job order after scontrol top command
Product:	Slurm	Reporter:	seongmo.yeon
Component:	Scheduling	Assignee:	Jacob Jenson <jacob>
Status:	RESOLVED INVALID	QA Contact:
Severity:	6 - No support contract
Priority:	---
Version:	18.08.6
Hardware:	Linux
OS:	Linux
Site:	-Other-	Alineos Sites:	---
Atos/Eviden Sites:	---	Confidential Site:	---
Coreweave sites:	---	Cray Sites:	---
DS9 clusters:	---	HPCnow Sites:	---
HPE Sites:	---	IBM Sites:	---
NOAA SIte:	---	OCF Sites:	---
Recursion Pharma Sites:	---	SFW Sites:	---
SNIC sites:	---	Linux Distro:	---
Machine Name:		CLE Version:
Version Fixed:		Target Release:	---
DevPrio:	---	Emory-Cloud Sites:	---

Description seongmo.yeon 2019-05-08 16:34:53 MDT

I observed strange behavior with scontrol top command.

For example, let say I have 3 jobs in pending such that

100
101
102

I want to put 102 to the top of the list with scontrol top 102 such that

102
100
101

at the first try, the job order showed as I intended.
after scontrol top 101, the job order looks like

101
100
102

but my intention was 

101
102
100

Is this behavior a intended logic?

I know if I try the command with list like scontrol top 101 102 100, the result is as I intended.