After successful deployment of a JSCH object to one of our AE systems, an automated process uses the QuitTask Java API class to quit and restart the schedule automatically, without user intervention. Several times in the past couple of days, we have seen a new problem related to this process.
For example, yesterday at 16:53 the program tried to quit the running JSCH with run ID 636959964.
The message returned by the Automation Engine was error U00000009, a message that one typically sees only when trying to manipulate objects or tasks to which one does not have authorization. And strangely, rather than quitting the already-running task, the Automation Engine appears to have tried to start a new task, the one with run ID 637429790. The details of this task reveal that this is where the error 9 appeared.
No tasks were running under the running JSCH task at the time. Has anyone else seen this behavior?
Ok, I figured it out. The automated process tried to quit the schedule, failed due to an authorization error, and then tried anyway to restart it. The attempt to restart it is what caused the FAULT_OTHER task to appear. So it looks like a simple authorization problem. I also need to redesign the program so it doesn't try to start the schedule again if it wasn't able to quit it.
While we don't have an automated process to restart schedules, we do have an include in each schedule that will cancel the old run after executing an updated schedule after a deployment. I believe it might have been a provided Include. JOBI.CANCEL_OLD
:SET &ME_NAME = SYS_ACT_ME_NAME:SET &ME_RUN = SYS_ACT_ME_NR:SET &OLD_RUN = GET_UC_OBJECT_NR(&ME_NAME):IF &ME_RUN <> &OLD_RUN: SET &RET = CANCEL_UC_OBJECT(&OLD_RUN):ENDIF