IDXACTIVATE / IDXFIX leave index admin locks after being interrupted

IDXACTIVATE / IDXFIX sessions hang.
Unable to activate an index using IDXACTIVATE after a previous IDXACTIVATE session was interrupted.
Unable to fix indexes using IDXFIX after a previous IDXFIX session was terminated.

 

PROMON shows RGET lock type with transaction 0 and table id 0
Previous IDXACTIVATE / IDXFIX session has been disconnected using PROSHUT -C disconnect or PROMON Option 8 to disconnect the userid.
Previous IDXACTIVATE or IDXFIX  session has been sent SIGSEGV, SIGHUP,SIGQUIT or SIGTERM kill signals.
IDXACTIVATE feature was introduced in OpenEdge 10.1A

Index admin lock clean code is not properly executed on disconnect or when the process is being terminated prior to completion.

Upgrade to OpenEdge 10.2B08, 11.2.1, 11.3.0 or later. Where the index admin lock is properly cleared out when index utilities are disconnected.

To clean up the admin lock, the database needs to be restarted, unless a new idxactivate/idxfix session can be started which manages to inherit the same userid as the previously disconnected/terminated idxactivate/idxfix session and allowed to run to completion.

This would be achievable in a controlled environment by not allowing any other users to connect and explicitly allocating dummy connections to use user-slots until the user-slot previously used by the terminated / disconnected IDXFIX / IDXACTIVATE session is then available for the new online idxactivate/idxfix session to use.

Progress Articles: 

P128640, Unable to run IDXACTIVATE online if remote server process present   
P129256, Error 1422 after backing out of online IDXACTIVATE